Subject: RE: [Megaco] Clarification Of Multiplex Descriptor Text

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 21 Jan 2002 10:00:46 -0500

While we're on the topic of Annex M.4, I realized while reading it that it
improperly (I think) includes some control terminations in the multiplex.
This may be water under the bridge now -- too late to do anything about it.

Anyway, Christer is asking for more than I would put into the core protocol
specification.  We should probably create an Informational RFC describing
multiplex use with examples, just as we should publish an Informational RFC
giving example call flows.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, January 21, 2002 12:52 AM
To: Christian Groves
Cc: Taylor, Tom-PT [CAR:B800:EXCH]; Clifford Sayre; megaco ietf
Subject: Re: [Megaco] Clarification Of Multiplex Descriptor Text

Hi,

>I think that the H.324 package probably needs to be updated to say how
>this is done. I don't think its a core H.248 issue.

I agree. The idea was that this property would be defined in the H.324
package, and then used within each stream descriptor in the Mux
Termination.

>Perhaps an IG note could be added for the H324 package? I'd like to see a
reply from the
> H324 package authors on how they thought this was to be done.

>Are there any updates you'd like to see to proposed text on
MultiplexDescriptors that Tom posted?

First, as Tom already mentioned, it should be updated so that it also
includes emphemeral bearer terminations (RTP terminations, for example).

Second, it should in detail, on a message level, describe how the
multiplexed connection is set up. Now it only says "use a stream
descriptor" - which means everyone is going to understand it their own
way, and we are going to have lots of interop problems when people start
implementing this :)

Third, it should also describe in detail how the H.223 (or whatever
multiplex method is used) descriptor is used, ie which terminations are
included etc, depending on on which "side" of the multiplexer the
terminations are.

Fourth, I think the whole Annex M.4 misses some things, but that's
another discussion...

I understand if you want to get this document ready before february, but
please let us do this correct from the beginning :)

Regards,

Christer Holmberg
Ericsson Finland

> 
> Regards, Christian
> 
> Christer Holmberg wrote:
> >
> > Hi,
> >
> > I have read the document a few times, but even by having stream
> > descriptors in the mux termination, I still don't understand how each of
> > those stream descriptors are mapped to specific LNCs. Is the StreamID
> > supposed to be the same as the LCN number, or how is the mapping done?
> >
> > A very simple solution would be to add a "LCN property" (to the H.324
> > package, I assume) which would be used in the each stream descriptor to
> > specify to which LCN it is mapped.
> >
> > Comments?
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > Tom-PT Taylor wrote:
> > >
> > > I mentioned that several of us have been discussing additional text
for
> > > Multiplex Descriptors.  I have placed the proposed text as marked up
changes
> > > in the Megaco FTP site.  According to your taste, you can download
> > >
ftp://standards.nortelnetworks.com/megaco/docs/Current/MuxDescription_with_N
> > > x64K.doc
> > > or
ftp://standards.nortelnetworks.com/megaco/docs/Current/MuxDescription_with_N
> > > x64K.pdf
> > >
> > > Based on my reply to Christer Holm yesterday (see "LCN Mapping"), this
> > > proposed text needs a further update.  The supporting bearers
contained by a
> > > multiplexing termination can be ephemeral as well as physical.
However, I
> > > believe it would be essential that any ephemrals mentioned in a MUX
> > > descriptor already exist in the context, since their properties are
probably
> > > not directly inferrable from those of the multiplexing termination.
> > >
> > > Tom Taylor
> > > [email-masked]
> > > Ph. +1 613 736 0961 (ESN 396 1490)
> > >
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jan 2002 22:56:34 +0200

Hi,

>This may be water under the bridge now -- too late to do anything about it.

It includes some properties, ie muxtbl_in/out properties, which are
defined in the LocalControl descriptor. The LocalControl descriptor,
again, is defined in a Stream Descriptor (default StreamID = 1 if no
descriptor is defined). So, one would have to specify a Stream
descriptor for the multiplexer itself... Strange. I don't know if you
were refering to the same issue.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jan 2002 22:56:34 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jan 2002 22:45:02 +0200

Hi,

>giving example call flows.

Why not removing the whole multiplex chapter from the core protocol,
then, and putting it in a separate Annex, or something? The way it's
defined now (even by adding the proposed changes) doesn't help anyone.
You simply can't implement multiplexing with the info you get from that
text (you don't know how to map the LCNs, which btw also are
uni-dirctional, to specific terminations etc etc) - and that's NOT
enough in my opinion.

I thought that the ITU people always wanted to specify everything very
much in detail :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jan 2002 22:45:02 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Tue, 22 Jan 2002 14:04:21 +1100

Hello Christer, 

I don't think we can remove the whole chapter from the protocol at this
stage. I agree with Tom that we can do some call flows in a seperate
annex. I'll add some text on the euphemeral terminations to the proposed
clarification.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 22 Jan 2002 14:04:21 +1100

Hello Christer, 

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jan 2002 09:35:20 +0200

Hi,

>annex.

Oki.

>I'll add some text on the euphemeral terminations to the proposed clarification.

So, we shouldn't say anything about the Stream Descriptors in the Mux
Termination? How they are mapped to the LCNs etc? Personally I don't
care if it's said in the core spec, or in a separate Annex, but I don't
understand what the purpose is to put stuff in the core which nobody can
use :)

Does anyone know if there has been any response on this issue from SG16?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jan 2002 09:35:20 +0200

Hi,

Oki.

Regards,

Christer Holmberg
Ericsson Finland