Subject: Re: Multiple streams per call,

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Apr 2000 09:37:18 -0400

I see it as a style issue - the more uniform packages (and gateways)
are built, the more likely there will be wide interoperability.
What I would really hate to see is one vendor building MCUs one way,
and other building them another way, so that it was a tremendous
amount of code for one MGC to control both kinds.

Multimedia contexts aren't the issue.  The issue is what is the
general way to model a device that does not have an explicit
protocol mechanism to support it.  The really amusing part of this
discussion is that I was one of the folks in the design team meeting
in Minneapolis that seized on the idea of having each termination be
able to have a different media specification with implicit translation
between them!  It's still a very elegant mechanism, and I've said
so in the context of the translator.  I'm more worried about influencing
the design of packages to ease the burden on the MGC of supporting
lots of MGs.  We can't control it -- we aren't any more effective as
the package police than we are as the protocol police!

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, April 26, 2000 9:15 AM
> To: [email-masked]
> Subject: Re: Multiple streams per call,
>
>
> It seems to me that this is only marginally a standardization
> issue.  You
> may want to build your GW one way, another vendor
> differently.  We will have
> to think about whether we have to define properties to allow
> the MGC to
> discover the difference in internal organization.
>
> :-) My suspicion is that, having stoutly resisted the
> multimedia context
> model, you'd like to bury it on the rebound.
>
> > -----Original Message-----
> > From: Rosen, Brian [SMTP:[email-masked]]
> > Sent: Wednesday, April 26, 2000 8:37 AM
> > To:   [email-masked]
> > Subject:      Re: Multiple streams per call,
> >
> > The reason it's not a v2 issue is that it affects how you design
> > a package for a cs1 implementation of some kind of capability not
> > specifically catered for.
> >
> > In the discussions of "topology" we had a similar disagreement, with
> > the same actors :(.  The topology mechanism works for most common
> > implementations of an audio mixing bridge.  The protocol does not
> > have a mechanism to extend topology, nor to add context properties.
> > We do have the package mechanism.  If I wanted to build a
> very flexible
> > MCU which allowed a wide range of video and audio effects,
> I can't do
> > it with "bare" cs1 capabilities (my "what does T1/T2 bothways mean
> > for a tiling video MCU?" question).
> >
> > On the other hand, I can do it with the mechanism I
> propose.  In fact,
> > it's pretty hard to think of any kind of media device I
> cannot control
> > pretty nicely with such a mechanism.  That is a very good feature of
> > the protocol.
> >
> > Now, what I'm advocating is that we use that mechanism uniformly.
> >
> > What we are discussing is a kind of corner case - the "two RTPs with
> > different media specifications, implied translation" clearly is
> > within the capabilities of the protocol.  It does work.  But all
> > you need to do is add one twist - say that the translator is also a
> > multimedia MCU, and now you can't use the same model.  That is a bad
> > idea.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Wednesday, April 26, 2000 12:34 AM
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > Subject: Re: Multiple streams per call,
> > >
> > >
> > > I like the 'elegant method'. I thought that context
> > > properties could be
> > > used in the situations where the elegant didn't work.
> This I thought
> > > would be the most generic.
> > >
> > > I agree that using the 'internal' termination model is a
> > > valid modelling
> > > technique but I wonder if it is more uniform. ie. Conferences
> > > today are
> > > handled by context but we could equally have a context
> with a mixing
> > > termination and then hang off individual context and
> terminations for
> > > the subscriber legs.
> > >
> > > I think this is something for discussion for v2, either
> approach is
> > > interesting.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > This is beyond the current discussion.  The question
> is, in general,
> > > > how do we model devices that are "different".  In the
> case cited,
> > > > media translation, we could model it as a two
> termination context,
> > > > with the RTP flows, specified by media descriptors,
> describing the
> > > > two sides, and an implicit translation in between.
> This certainly
> > > > works, and is pretty elegant.
> > > >
> > > > The problem is that it doesn't work for all kinds of devices,
> > > > and I wondered if we should model them in a more uniform way.  I
> > > > suggested a set of two termination contexts with an "internal"
> > > > termination that can have characteristics ascribed to it by a
> > > > set of packages implemented on it, and an RTP termination that
> > > > had the external flow on it.  This would also work for the
> > > translator,
> > > > but requires more terminations and more contexts, and thus is
> > > > somewhat less elegant.  It too would work, and has the
> advantage of
> > > > being able to be used for a much wider range of applications.
> > > >
> > > > Brian
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > > > Sent: Friday, April 21, 2000 9:36 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: Multiple streams per call,
> > > > >
> > > > >
> > > > > My view of something like tiling is that we need a per-stream
> > > > > property to
> > > > > express mixing method.  I didn't push this last summer
> > > > > because it was clear
> > > > > that it would have to be designed by specialists in the area,
> > > > > and I figured
> > > > > they should be the ones to step up to the plate when they are
> > > > > serious about
> > > > > building product using Megaco/H.248.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rosen, Brian [SMTP:[email-masked]]
> > > > > > Sent: Friday, April 21, 2000 8:58 AM
> > > > > > To:   [email-masked]
> > > > > > Subject:      Re: Multiple streams per call,
> > > > > >
> > > > > > Yes, the translation MG, you could construct a context with
> > > > > > two RTP ports and use the SDP to imply translation.  The
> > > > > protocol would
> > > > > > allow that.
> > > > > >
> > > > > > The problem is that it would work for things that are
> > > > > expressible in SDP,
> > > > > > but not for more general mechanisms.  For example, suppose
> > > > > you wanted
> > > > > > an MCU that did tiling.  I'd prefer that we use one
> > > > > mechanism for all of
> > > > > > these
> > > > > > kinds of problems.
> > > > > >
> > > > > > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: John Segers [mailto:[email-masked]]
> > > > > > > Sent: Friday, April 21, 2000 5:52 AM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: Re: Multiple streams per call,
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Having been away from the list for a while, I've got some
> > > > > > > catching up to
> > > > > > > do!  Although this thread is probably less urgent
> > > than some of the
> > > > > > > others, this one being related to more advanced (future)
> > > > > > > functionality,
> > > > > > > I'll jump in on this first.
> > > > > > >
> > > > > > > Comparing Brian's proposal for the video translator to
> > > > > less exotic MG
> > > > > > > devices that translate audio, I wonder why the extra ports
> > > > > > > are needed.
> > > > > > > In the audio case, the required transcoding, e.g. from
> > > > > G.711 A-law to
> > > > > > > G.723.1 is inferred from the Termination type/name and/or
> > > > > RTP payload
> > > > > > > type.  No extra ports are introduced to model the
> translator
> > > > > > > resource.
> > > > > > > Why can't it work the same for video?
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > You seem to have everything correct!
> > > > > > > >
> > > > > > > > You are worried about the video translator.  The
> > > > > problem statement
> > > > > > > > was MG-A and MG-B did not have a common video encoding,
> > > > > so the MGC
> > > > > > > > wanted to insert a translator to fix the problem.
> > > > > > > >
> > > > > > > > I think this is very reasonable to do, and I
> would model the
> > > > > > > > translator as a set of pairs of terminations - The
> > > "A" side and
> > > > > > > > the "B" side.  Trying to push these into a single
> > > context, to
> > > > > > > > my way of thinking, is very weird.  Much
> cleaner to have two
> > > > > > > > separate contexts.  I waffled over whether to represent
> > > > > the "ports"
> > > > > > > > of the translator as physical terminations.  In
> > > > > reality, they could
> > > > > > > > be, if the translator was some hard wired fixed
> > > function.  It is
> > > > > > > > possible that it could just be a fancy DSP, and
> the number
> > > > > > > of translations
> > > > > > > > it could do was a variable, determined by what
> > > > > > > > translations were in use.  For example, it might be
> > > able to do
> > > > > > > > 10 MPEG 1 to MPEG 2 translations, but only 3
> MPEG2 to H.261
> > > > > > > translations.
> > > > > > > > In this case, it might be better to model the ports
> > > as ephemeral
> > > > > > > > terminations.  I would still represent them as pairs of
> > > > > > > terminations,
> > > > > > > > which would go in pairs of two termination
> > > contexts, the other
> > > > > > > > termination being (for example) the RTP termination.
> > > > > > > >
> > > > > > > > To help your thinking, instead of calling those
> > > > > > > terminations Y and Z,
> > > > > > > > call them XLate/A and XLate/B.  If the box could do
> > > > > more than one,
> > > > > > > > maybe we would call them XL/1/A and XL/1/B, so you
> > > > > could talk about
> > > > > > > > XL/4/A for example.  Then XL/1/A is in a context
> > > with RTP-A, and
> > > > > > > > XL/1/B is in context with RTP-B.
> > > > > > > >
> > > > > > > > It is possible to have one termination that had two
> > > > > streams (the A
> > > > > > > > stream and the B stream) and then the context
> would have 3
> > > > > > > terminations, the
> > > > > > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > > > > > use streamIDs to
> > > > > > > > keep the streams straight (no need to use topology).
> > > > > > > > This is one of the things I don't like about
> what we did,
> > > > > > > two ways to
> > > > > > > > do the same thing, nothing but "taste" to decide
> > > which to use,
> > > > > > > > guaranteed interoperability problems unless
> some package is
> > > > > > > standardized.
> > > > > > > > Oh well.  Anyway, I think modeling the translator
> > > as having two
> > > > > > > > terminations, an A termination and a B termination,
> > > > > each with one
> > > > > > > > stream, is the best way to do it.
> > > > > > > >
> > > > > > > > In fact, you may have noticed that I used the same
> > > model for the
> > > > > > > > weird function bridge a few emails back -- I think
> > > > > whenever we have
> > > > > > > > odd-function devices, we should model the "ports"
> > > of the device
> > > > > > > > as a termination implementing a specific package.  In
> > > > > this specific
> > > > > > > > case the ports are symmetric (because the flows are
> > > > > send-receive),
> > > > > > > > but in the general case, they may not be.
> > > > > > > >
> > > > > > > > Brian
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Chip Sharp [mailto:[email-masked]]
> > > > > > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > > > > > To: Rosen, Brian; [email-masked]
> > > > > > > > > Subject: Re: Multiple streams per call,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > > > > > >
> > > > > > > > > ...snip...
> > > > > > > > >
> > > > > > > > > >Sure.  Look at it from the point of view of the MGs.
> > > > > > > You have MG-A,
> > > > > > > > > >MG-B and MG1.  MG-A has a termination with two
> > > > > streams, video and
> > > > > > > > > >audio.  It is commanded by the MGC to set up a single
> > > > > > > context with
> > > > > > > > > >the termination and two RTP connections, call them
> > > > > > > RTP-A-Audio and
> > > > > > > > > >RTP-A-Video.  The address it assigns to
> > > RTP-A-Audio is MG-B.
> > > > > > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > > > > > >Again, this is a single context, with the physical
> > > > > termination
> > > > > > > > > >having two streams, and each of the RTP terminations
> > > > > having one
> > > > > > > > > >stream each.
> > > > > > > > >
> > > > > > > > > I assume when you say "RTP connections" above,
> > > you mean "RTP
> > > > > > > > > terminations"
> > > > > > > > > since the word "connection" isn't allowed in
> megaco. (your
> > > > > > > > > MGCP is showing
> > > > > > > > > ;-) ).
> > > > > > > > > I'm not sure what kind of termination you are
> > > talking about,
> > > > > > > > > but I'll call
> > > > > > > > > it X.
> > > > > > > > >
> > > > > > > > > In MG-A, Terminations X, RTP-A-Audio and
> RTP-A-Video all
> > > > > > > > > belong to the same
> > > > > > > > > context, say Context A.  Termination X has 2
> > > streams assigned
> > > > > > > > > to it.  One
> > > > > > > > > stream contains the video, the other stream
> contains the
> > > > > > > > > audio (both in
> > > > > > > > > send-receive).  Termination RTP-A-Audio would be
> > > configured
> > > > > > > > > with only the
> > > > > > > > > Audio stream.  Termination RTP-A-Video would
> be configured
> > > > > > > > > with only the
> > > > > > > > > Video stream.
> > > > > > > > >
> > > > > > > > > Therefore the video stream goes to MG1 and the
> > > audio stream
> > > > > > > > > goes to MGB, as
> > > > > > > > > described.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >Look at MG1.  It has two terminations, with one
> > > > > stream each.  It
> > > > > > > > > >is asked to set up two contexts, one with an RTP
> > > > > connecting to
> > > > > > > > > >MG-A and the other with its RTP connection to
> > > MG-B.  That's
> > > > > > > > > >two contexts, each with two terminations, with
> > > one stream in
> > > > > > > > > >each of the contexts.
> > > > > > > > >
> > > > > > > > > I'm not sure what the two mystery terminations
> > > are again, but
> > > > > > > > > I'll call
> > > > > > > > > them Y and Z.
> > > > > > > > >
> > > > > > > > > Terminations Y and RTP-A belong to a context A and
> > > > > > > contain one stream.
> > > > > > > > > Terminations Z and RTP-B belong to a context B and
> > > > > > > contain one stream.
> > > > > > > > >
> > > > > > > > > The video stream from MGA comes into context A via
> > > > > > > > > Termination RTP-A and
> > > > > > > > > ends up on Termination Y (and vice versa).
> > > > > > > > >
> > > > > > > > > Whatever is on termination Z is transmitted
> out RTP-B via
> > > > > > > > > context B (and
> > > > > > > > > vice versa).
> > > > > > > > >  From the below, it seems video is connected to
> > > MG-B; however
> > > > > > > > > there is no
> > > > > > > > > context containing Terminations Z & Y to allow them to
> > > > > > > > > communicate under
> > > > > > > > > the control of megaco.  Therefore, I assume that
> > > some internal
> > > > > > > > > implementation-specific mechanism connects
> > > terminations Y & Z
> > > > > > > > > in order to
> > > > > > > > > get the video from Context A into context B.
> > > > > > > > > MG1 could just have 2 RTP terminations with one
> > > stream in one
> > > > > > > > > context.  Of
> > > > > > > > > course, H.248 forbids a termination from belonging to
> > > > > > > more than one
> > > > > > > > > context, so you can't just create a context
> > > containing X & Y.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > > > > > audio connects
> > > > > > > > > >to MG-A, the video connects to MG1.
> > > > > > > > > >
> > > > > > > > > >Now look at it from the MGC.  The "call" has 3
> > > > > Megaco contexts.
> > > > > > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> > > > > the MG1 to MG-B
> > > > > > > > > >video.
> > > > > > > > >
> > > > > > > > > Yes, but the MGC has no idea how the video gets from
> > > > > > > Termination X to
> > > > > > > > > Termination Y in MG1.
> > > > > > > > >
> > > > > > > > > Thanks for the illustration.  I haven't really
> > > thought about
> > > > > > > > > it in a while.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >I'm still not thrilled with the whole stream
> idea, but
> > > > > > > it does work.
> > > > > > > > > >
> > > > > > > > > >Brian
> > > > > > > > >
> > > > > > > > > http://www.netaid.org
> > > > > > > > >
> > > --------------------------------------------------------------
> > > > > > > > > -----------
> > > > > > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > > > > > Cisco Systems
> > > > > > > > > Reality - Love it or Leave it.
> > > > > > > > >
> > > --------------------------------------------------------------
> > > > > > > > > ----------
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > John Segers                                  email:
> > > > > [email-masked]
> > > > > > > Lucent Technologies
> > > > >  Room HE 306
> > > > > > > Dept. Forward Looking Work                      phone:
> > > > > +31 35 687 4724
> > > > > > > P.O. Box 18, 1270 AA  Huizen                      fax:
> > > > > +31 35 687 5954
> > > > > > >
> > > > >
> > >
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 27 Apr 2000 10:33:52 +1000

G'Day Brian,

Let's not drag in the topology discussion, I haven't disagreed with you
(yet :-). I mentioned that we needed to consider the issue.

Stylistically we already have a direction set in the protocol that the
context implies a certain functionality ie. mixing. We tried to hide the
internal operation of the MG from the MGC. With topology it is a means
of setting the relationships between terminations for things like
operator break in and another topic which we can't talk about in the
IETF. Topology wasn't designed for mixing and we previously had
earmarked the context properties for mixing properties.

If we define an MCU package then there will be only one way of
implementing an MCU. I agree with you that in v1 you can't do a wide
range of effects on an MCU because we haven't defined any. However these
could be properties on a termination.

I'm not sure that shifting the burden of developing packages to the
protocol know is a good idea. It has been said before on the list that
Full Multimedia would be considered in v2. Is this still the plan?

Cheers, Christian