-----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: Thursday, January 17, 2002 7:59 PM To: 'Christer Holmberg' Cc: megaco@ietf.org; sg16@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@lmf.ericsson.se] Sent: Thursday, January 17, 2002 6:34 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: megaco@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