FW: [Megaco] LCN mapping

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Thu Jan 17 20:09:21 EST 2002



-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH]
Sent: Thursday, January 17, 2002 7:59 PM
To: 'Christer Holmberg'
Cc: megaco at ietf.org; sg16 at jf.intel.com
Subject: RE: [Megaco] LCN mapping


H.248 Annex M.4 (packages for H.324 operation) says this right at the end of
section M.4.6:

"When logical channels are opened for audio, video and data, the termination
shall be connected to the appropriate terminations respectively."

In other words, it happens by magic.  You make a valid point: there is
something missing in the specification.  One possibility is to say that the
MG associates streams with logical channels in the sequence in which the two
are respectively defined.  Because of the possibility of misordering it
would be safer to have an explicit means for the purpose.

I wonder if it is too soon to amend Annex M.4?  I'm copying this message to
the SG 16 list so they can think about the issue.



-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at lmf.ericsson.se]
Sent: Thursday, January 17, 2002 6:34 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: megaco at ietf.org
Subject: Re: [Megaco] LCN mapping



Hi,

>The short answer is that the relationship between LCN (Logical Channel
>Number) and streamID is set by the application control, which probably
>resides in the MGC.

I agree. But, how do I indicate that relationship to the MG, where the
actual LCN and streamID "connection" is?

>Assuming your H.223 mux is operating as part of the H.324 system it was
designed for, the control information >is carried in H.245 signalling, gets
routed to the MGC, and results in H.248 requests back
>to the MG.

I agree. But, again, in that request the MGC have to tell the MG how to
do the mapping.

>However, let me first address your proposed multiplexing structure.  I
>should mention that several of us (Christian Groves, Roni Even, Marcello
>Pantaleo and myself) are nearing the end of a discussion initiated by
>Christian, on additional words to add around the multiplex concept,
>clarifying it and at the same time allowing it to be used to represent
Nx64K
>wideband service.  I will report the results and reasoning to the list
>shortly.  In any event, the basic multiplex concept I have been defending
>(based on what we already have in RFC 3015/H.248)is something that
>specifically has one or more circuits on one side and appears as an
ordinary
>termination to the rest of the context on the other.  Along the way, it
>hides the circuits (which are represented by terminationIDs of their own)
>from the rest of the context.
>
>In your present example, you have the multiplexing termination (T3), 30 or
>24 circuits which support it (the circuits in the E1/T1), and the RTP
>termination T2.  If you are running H.324, the recommended way to tie the
>circuits together is to use H.226 channel aggregation (set up with V.140
>signalling) under the H.223 multiplex.  Because H.226 is mentioned in H.324
>(Annex F) but not in H.223, I suspect we have to model the two layers of
>multiplexing explicitly.  This blows holes in my idea that all multiplexes
>are supported directly by circuits.  In diagramatic terms, we have the
>following situation:
>
>                        Context interior ---->
>                    _________                 _________
>       Data stream  | H.226 |                 | H.223 |   Audio stream
>Ckt 1 ..............| "MUX" |                 |  MUX  | .................
>       . . .        | term  |   Data stream   | term  |
>       Data stream  |       | ................|       |   Video stream
>Ckt n ..............|       |                 |       | .................
>                    |       |                 |       |
>                    ---------                 ---------
>
>Here the H.226 MUX termination contains/is supported by the individual
>circuits, which appear as terminations in their own right.  The H.223 MUX
>termination contains/is supported by the H.226 MUX termination.
>
>The model I have been arguing for is that a multiplexing termination hides
>all of the terminations it contains from the rest of the context.  One
>implication of this is that the streamIDs of the streams flowing between
the
>contained terminations and the multiplexing termination are local rather
>than global in scope.
>
>Looking at the above diagram, people may ask how we know that the stream
>between the H.226 and H.223 multiplexing terminations is a data stream,
>while the streams passing from the H.223 termination to the rest of the
>context are audio and video.  I will maintain that this is a result of the
>definition of the respective multiplexes.  If this is not clear, we need an
>explicit description of the exterior-side and context-side streams
supported
>by each multiplex somewhere within our Megaco/H.248 documentation.

I look at the above diagram, and my question is still the same: how do I
map the Audio- and Video straems coming out from the H.223 MUX term to
specific RTP terminations (and possibly specific streams within them)?

>I come to my final point.  Your example included the RTP termination T2
>within the multiplex.  In my view this is a mistake: T2 is just another
>termination in the context.  All it sees is T3, the H.223 multiplexing
>termination, and it exchanges audio and video with that termination.

Ok, but my question STILL remains :) T3 does see the mux termination,
but I need to be able to tell my context that stream 1 (eg audio) from
the mux shall be mapped to stream X in T3, and stream 2 (eg video) shall
be mapped to stream Y in T3.

...or, if I want to use separate RTP terminations for audio and video, I
need to be able to tell that mux stream 1 shall be mapped to RTP
termination T3, and stream 2 into RTP termination T4.

>I hope this makes things clearer.  The question has raised some points
which
>I will now have to reflect back into my conversation with Christian and
all.
>Even better if they bring that conversation to this list.

Maybe I've missed some point, but I am still as confused :)

Regards,

Christer Holmberg
Ericsson Finland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20020117/cd8a84a0/attachment-0003.html>


More information about the sg16-avd mailing list