Subject: Re: Multiple streams per call,

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 16:34:40 -0400

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.
> --------------------------------------------------------------
> ----------
>

---

From: John Segers <[email-masked]>
Date: Fri, 21 Apr 2000 11:51:35 +0200

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

--
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