Subject: Re: Multiple streams per call,

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 14:33:45 -0400

> Megaco supports multiple media streams per termination => so
> 1 call (or
> conference) with multiple streams may corresponds to 1 context viewed
> from a media gateway.
We have been very careful to not associate a "context" with a "call".
In particular, depending on how you want to look at the definition of
a call, a context could be less than a call, or more than one call.

A context supports more than one termination, and more than one
media stream.

> The reciprocal is not so clear to me: MUST all the media
> streams from 1
> call be associated to 1 context.
No, but you might have some difficulty with interoperability if you
built a gateway that assumed each stream was, for example, on a
separate termination.  The protocol would allow you to do this.
I suspect no package describing a multimedia termination would do so.

> In other term, is there a "one for one" relationship between
> Context and
> Call?
> In fact, I think no.
And we agree.

> I was thinking about a case where terminal A and terminal B are trying
> to establish an Audio/Video (with separate streams) call. But as audio
> encoding supported by A and B are compatible, video encoding are not
> compatible thus requiring the transcoding function of the
> media gateway
> MG1. In such case, I think that the MGC should control the
> audio stream
> in order to go from A to B directly, while video stream go from A to B
> via MG1.
> Does it seem to you to be a scenario in the scope of Megaco?
> Comments welcome,
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.

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.

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.

I'm still not thrilled with the whole stream idea, but it does work.

Brian

---

From: Chip Sharp <[email-masked]>
Date: Fri, 14 Apr 2000 15:58:28 -0400

At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:

...snip...

>having two streams, and each of the RTP terminations having one

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.

>two contexts, each with two terminations, with one stream in

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.

>The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B

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.

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
------------------------------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 21 Apr 2000 08:57:40 -0400

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,
> > >
> > >
> --
> 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: Tom-PT Taylor <[email-masked]>
Date: Fri, 21 Apr 2000 09:35:45 -0400

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.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, April 21, 2000 8:58 AM
> To:   [email-masked]

---

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

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

> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, April 26, 2000 12:34 AM
> To: Rosen, Brian
> Cc: [email-masked]
> 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
> >
> > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > Sent: Friday, April 21, 2000 9:36 AM
> > > To: [email-masked]
> > > > > > > I assume when you say "RTP connections" above,
> you mean "RTP
> > > > > > > terminations"
> > > > > > > I'm not sure what kind of termination you are
> talking about,
> > > > > > > but I'll call
> > > > > > > it X.
> > > > > > >
> > > > > > > context, say Context A.  Termination X has 2
> streams assigned
> > > > > > > to it.  One
> > > > > > > send-receive).  Termination RTP-A-Audio would be
> configured
> > > > > > > with only the
> > > > > > > Therefore the video stream goes to MG1 and the
> audio stream
> > > > > > > goes to MGB, as
> > > > > > > described.
> > > > > > >
> > > > > > >
> > > > > > > I'm not sure what the two mystery terminations
> are again, but
> > > > > > > I'll call
> > > > > > > them Y and Z.
> > > > > > >
> > > > > > >  From the below, it seems video is connected to
> MG-B; however
> > > > > > > there is no
> > > > > > > implementation-specific mechanism connects
> terminations Y & Z
> > > > > > > in order to
> > > > > > > MG1 could just have 2 RTP terminations with one
> stream in one
> > > > > > > context.  Of
> > > > > > > Thanks for the illustration.  I haven't really
> thought about
> > > > > > > it in a while.
> > > > > > >
> > > > > > >

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 26 Apr 2000 08:15:15 -0500

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.

> Sent: Wednesday, April 26, 2000 8:37 AM