Subject: Re: Annex E edits to Network, RTP, and DS0 pkgs

From: Nancy-M Greene <[email-masked]>
Date: Thu, 16 Dec 1999 16:45:02 -0600

Christian Groves writes:

> I obivously support that : Local equates to receive, remote to send. I
> think this aligns the text and binary formats of the protocol and you
> need less memory in the MG to store these. Currently having both
> send/receive Local and Remote favours SDP and results in duplication in
> data.
>
Christian, I don't think it means duplicate data, and I don't see why the
ASN.1 can't do it this way as well. Local is the information the MGC needs
to tell the MG (and vice versa) about the media being sent and received on
this side. Remote is the information from the remote side - in particular
the RTP port and IP address of the remote side.

> To me it also means that H248 is also a negotiation protocol which
> I don't believe it is. I also believe that Local>receive, Remote>send is
> an easier concept to grasp, the diagram should make it apparent.
> The binary version doesn't really support having send/recieve in one
> descriptor. One oversight when doing the ASN1 was that we left out being
> able to group properties like SDP. I believe this is an error so I've
> proposed the following ASN1 to fix it:
>
> LocalRemoteDescriptor ::= SEQUENCE
> {
>       propertyGroup   SEQUENCE OF PropertyParm
>                                              -- SEQUENCE FOR GROUPS
> }
>
> First group has the highest preference.
> This will mean that both text and binary can represent sets of
> properties. Just pairs of tag/value doesn't work ie H323 faststart.
>
>
>
>

---

From: Nancy-M Greene <[email-masked]>
Date: Thu, 16 Dec 1999 17:39:04 -0500

Tom, your first example, where you use $ for wildcarding values the MG will
fill in, in Local, is fine.

Instead of your 2nd example, I propose that we include the two codecs that
are asymmetric on ONE m= line. I do NOT think we should overload a=sendonly
and a=recvonly - those attributes have another meaning in SDP.

So, instead of what you have below, I propose the line
   m= audio $ RTP/AVP 98 97 | audio $ RTP/AVP 0

where the first part of the m= line is the codec the MG will use to send,
and the second part is the codec the MG should expect to receive.

Tom's example 2:
> This works fine when the same coding is used in both directions.  What
> happens if send and receive preferences/capabilities differ?  According to
> our present text, send and receive preferences/capabilities must both be
> shown in Local.  I will illustrate this with a completely artificial
> example, where MGC A wants MG 1 to use the G.729 plus encoded tones
> combination for sending, but PCMU for receiving.  Then the steps above
> would be as follows:
>
> (1) MGC A to MG 1:
>
>    ... Add = $ {  Media  {
>                        LocalControl { Mode = ReceiveOnly },
>                        Local = SDP {
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 96 97
> a=sendOnly               ;Want to send G.729 plus the encoded tones
> payload
> a=rtmap:96 G729
> a=rtpmap:97 X-TONES
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 0
> a=recvOnly                ; Want to receive G.711 mu-law
>                                           } } }...
>
>
> (2) MG 1 fills in the terminationID and the address and port for the PCMU
> it is to receive, but cannot fill in the missing items for the sent
> information.  It returns the "send" media description anyway to show that
> it is prepared to handle it:
>
>    ... Add = 1000 {  Media  {
>                        LocalControl { Mode = ReceiveOnly },
>                        Local = SDP {
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 96 97
> a=sendOnly               ;Want to send G.729 plus the encoded tones
> payload
> a=rtmap:96 G729
> a=rtpmap:97 X-TONES
> v=0
> c=IN IP4 216.210.157.16
> m=audio 6450 RTP/AVP 0
> a=recvOnly                ; Want to receive G.711 mu-law
>                                           } } }...
>
> (3) The media descriptions are signalled to the far end.
>
> (4) MGC B has to manipulate the information before passing it on to MG 2:
> "send" becomes "receive" and vice versa.
>
> (5), (6), (7) play out as before.
>
> -------------------------------------------------- End of example
> -------------------------------------------------------
<snip>
>
> So, are we OK with wildcarded SDP instead of LocalControl to guide
> allocation?  For asymmetric coding, which of the two styles do we prefer:
> local send and receive capabilities both expressed in Local, or Local
> equates to receive, Remote to send?  And finally, do we need a different
> placeholder from "choose" for values we don't intend the local MG to fill
> in, as in the Remote descriptor just above?
>
To answer your questions,
1) yes wildcarded SDP should be used instead of LocalControl
2) I prefer the 3rd style I proposed above - put the asymmetric codecs side
by side in one m= line.

Nancy

---

From: Nancy-M Greene <[email-masked]>
Date: Thu, 16 Dec 1999 17:54:35 -0500

Hi Christian,

> ----------
> From:         Christian Groves[SMTP:[email-masked]]
> Sent:         Monday, December 13, 1999 9:11 AM
> To:   [email-masked]
> Subject:      Re: Annex E edits to Network, RTP, and DS0 pkgs
>
> G'Day Nancy,
>
> I believe that we need to discuss the complete content of these
> packages. In Redbank at the plenary we accepted this package in concept
> but not the contents.
>
Yes, we need to review each of the packages.

> I have several concerns on these packages:
> o The packages are SDP centric and are not applicable to the binary
> version of the protocol. ie. This is not acceptable for base packages.
>
That's not true - there is a binary tag for every package name, and for
every property, event, signal, and statistic in each package.

> o Properties in the base package are not applicable for extended
> packages. ie. DS0 has RTP properities
>
>
>
> I make the following proposals to start to move forward:
> o DS0 package
> - Don't see the point in extending Network package which is very RTP
> specific. Makes more sense to have a stand alone DS0 package. ie.
>      Reasons:
>      > em < not applicable to DS0
>      > em < not applicable to DS0
>      > ptime < not applicable to DS0
>      > encryption < not applicable to DS0
>
I proposed that nt (network), em (preferred encoding method), dm (preferred
decoding method), ptime (preferred packetization period) ba (bandwidth), and
encr (encryption) all come out of the network package, because they can
already be specified in sdp. As well, they all have counterparts (or they
should have) in Annex C - Tags for Media Stream Properties. This means that
these fields go in the Local descriptor - as SDP for text encoding, and as
tag/value pairs for binary encoding.

>      > jit
>      > event:quality alert < rtp specific
>
It can be argued that quality alert is not necessarily rtp specific - that
is why it is in the network package.

> Cheers, Christian
>
> Nancy-M Greene wrote:
> >
> > Here are a set of proposed edits for Annex E of Megaco/H.248.
> >
> > E.9 Network Package
> >
> > Due to recent discussions on not duplicating in LocalControl what can
> > be sent in sdp, it is proposed to delete the properties for nt/nt,
> > nt/em, nt/dm, nt/ptime, nt/ba, and nt/encr.
> >
> > - nt/nt is replaced with the c= sdp line and NOTE there are
> > definitions to be made thru IANA for this c= line for ATM, and for T38
> >
> > - nt/em, nt/dm are replaced by the m= lines - one line per codec, and
> > ordered in order of preference
> > - nt/ptime is replaced by a=ptime:xx in sdp
> > - nt/ba is replaced with b= sdp line
> > - nt/encr is replaced with the k= sdp line
> >
> > - nt/jit is left where it is, unless it is something that needs to be
> > set per codec. Can it be set per codec??? If so, then it should be an
> > attribute in the a= line in the sdp.
> >
> > ***Also, add to section 7.1.8 Local and Remote Descriptors
> > Using SDP for capability negotiation
> > If an MG or MGC wishes to propose more than one choice for the SDP, it
> > does so by sending more than one m= line. All a=, k= lines associated
> > with an m= line directly follow it before the subsequent m= line.
> >
> > E.10 RTP Package
> >
> > The following two stats are missing:
> >
> > - Add to E.10.4 Statistics
> > Octets Sent
> >   StatisticID: os (0x000x)
> >   Type: double
> >   Possible values: any 64 bit integer
> > Octets Received:
> >   StatisticID: or (0x000x)
> >   Type: double
> >   Possible values: any 64 bit integer
> >
> > - Change Type & Possible Values in PacketLoss - Value can be a
> > fraction such as 0.2  - so Type is double, with the top 32 bits  for
> > the left of the decimal and the bottom 32 bits  for the right of the
> > decimal. Add 0.2 as example of a Possible Value.
> >
> > E.11 DS0 Package
> >
> > Here, the silence suppression property should instead be set in the
> > sdp - it can apply per codec.
> >
> > Therefore, delete ds0/ss property. Instead, if silence suppression, or
> > voice activity detection is to be used, it is marked in the sdp for
> > the specific codec it is to be used with.
> >
> > Nancy
> >
> --------------------------------------------------------------------------
> > Nancy M. Greene
> > Internet & Service Provider Networks, Nortel Networks
> > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>

---

From: Nancy-M Greene <[email-masked]>
Date: Thu, 16 Dec 1999 17:56:45 -0500

> >   Possible values: any 64 bit integer
In fact the above change is NOT necessary. The Octets Sent and Octets
Received stats are actually defined in the Network package. Since the Rtp
package extends the Network package,  it automatically gets these two stats.

Nancy

---

From: Tom-PT Taylor <[email-masked]>
Date: Sat, 18 Dec 1999 14:45:33 -0600

SDP session descriptions have a perfectly clear meaning.  The code I show
indicates that the originator is willing to support a send session with
specified characteristics and a receive session with specified
characteristics.  The one thing we are not free to do is monkey with the
basic SDP -- that's MMUSIC's territory.  Having said that, I'm a bit
concerned that wildcarding may fall into that category.

> -----Original Message-----
> From: Greene, Nancy-M [CAR:5N10:EXCH]
> Sent: Thursday, December 16, 1999 5:39 PM
> To:   [email-masked]'; Taylor, Tom-PT
> [CAR:B904-I:EXCH]
> Subject:      RE: Annex E edits to Network, RTP, and DS0 pkgs
>
> Tom, your first example, where you use $ for wildcarding values the MG
> will fill in, in Local, is fine.
>
> are asymmetric on ONE m= line. I do NOT think we should overload
> a=sendonly and a=recvonly - those attributes have another meaning in SDP.
>
>       This works fine when the same coding is used in both directions.
> What happens if send and receive preferences/capabilities differ?
> According to our present text, send and receive preferences/capabilities
> must both be shown in Local.  I will illustrate this with a completely
> artificial example, where MGC A wants MG 1 to use the G.729 plus encoded
> tones combination for sending, but PCMU for receiving.  Then the steps
> above would be as follows:
>
>       (1) MGC A to MG 1:
>
>          ... Add = $ {  Media  {
>       (2) MG 1 fills in the terminationID and the address and port for the
> PCMU it is to receive, but cannot fill in the missing items for the sent
>       (4) MGC B has to manipulate the information before passing it on to
> MG 2: "send" becomes "receive" and vice versa.
>
> 2) I prefer the 3rd style I proposed above - put the asymmetric codecs
> side by side in one m= line.
>
> Nancy
>
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Sun, 19 Dec 1999 07:58:52 -0600

Well, Christian votes for making "Local" equate to "receive", "Remote" to
"send".  This is an alternative to Nancy's proposal for modified SDP syntax
to show separate encoding and decoding capabilities when necessary.
(Actually, thinking it over, I suspect either proposal is better than the
way I did it, but Nancy's still runs into the procedural issue of which WG
can modify SDP.)

Christian raises the good question of whether Megaco/H.248 should be a
negotiation protocol.  This is a tricky point.  For a start, there is a
difference between what happens between the MGC and the MG at the
originating end and what happens at the terminating end.  Speaking of the
originating end only, there are two ways to look at the exchange between the
MGC and the MG:

(1) The MGC provides "policy guidance" to the MG.  The MG returns its
current capabilities constrained by the policy envelope.  The MGC can take
the information provided by the MG and use it to shape the message sent to
the far end.

(2) The MGC reserves a set of resources in the MG, subject to the outcome of
negotiation with the far end.

Clearly, these two interpretations impose different requirements on our
protocol, so we really must be sure of our intent.  Although I have been
(partly unconsciously) thinking in terms of the first interpretation, I
think the second one is a more realistic statement of the relationship
between the MGC and the MG.  Taking it as a working hypothesis that (2) is
our intent, I see a requirement on the protocol to distinguish between
capabilities required simultaneously and capabilities which are
alternatives.  I visualize a process in the MG whereby it reserves the
resources required to serve any one of the mutually exclusive alternatives
imposed by the MGC.  The brute force way to do this would be to reserve
resources separately for each alternative.  A more intelligent allocation
would identify resources common to different alternatives and not allocate
them twice over.

Our protocol should allow this more intelligent allocation process but not
require it.  Christian Huitema has shown us how to distinguish between
simultaneous and mutually exclusive sets of requirements when using SDP:
each mutually exclusive requirement set is presented as a separate session.
It is up to SG 16 to define how to do this with binary encoding.  My
concrete proposal is that we augment section 7.1.8 "Local and Remote
Descriptors") to express the intent of the process as stated in (2) above,
and explain how to express simultaneous and mutually exclusive sets of
alternatives.

One further comment below, mainly directed to Christian.

> From: Christian Groves [SMTP:[email-masked]]
> Sent: Wednesday, December 15, 1999 5:02 AM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   [email-masked]; Greene, Nancy-M
> [CAR:5N10:EXCH]; Hubert Przybysz
> Hello Tom,
> Thanks for the examples I think they clarify a few issues.
>
> I think end to end-end information needs to be put in Local AND Remote.
>
> In answer to your questions:
> > allocation?
> I am happy that Local/Remote describes capabilities of the media stream.
> There is an issue of 'Choose' vs 'allocate' which i'll talk about.
>
> > For asymmetric coding, which of the two styles do we
> > prefer: local send and receive capabilities both expressed in Local,
> > or Local equates to receive, Remote to send?
>
> data. To me it also means that H248 is also a negotiation protocol which
> > And finally, do we need
> > a different placeholder from "choose" for values we don't intend the
> > local MG to fill in, as in the Remote descriptor just above?
        [[TomT]]
        The issue you raise below is addressed by my initial remarks.  What
I meant, however, is that there is some information which is neither chosen
nor allocated by the local MG, in particular the address to which a given
media flow should be sent.  So I am asking what notation we use as a
placeholder for such information, given that we want at least to indicate
the protocol stack intended to be used for the transmission.

> I'm not sure of the question here as it probably relates to SDP but i'll
> present an example to clarify what I think it means:
>
> H323 Faststart. A H225 message is sent with multiple OLC structures
> describing the sent capabilities and the receive capabilities. According
> to H323 fastconnect procedures, the sending endpoint must be able to
> receive media of the specified capabilities on all of the specified
> ports in the OLCs. ie. you must allocate resources in the MG to receive
> all the possible streams. Therefore if you use localDescriptor with the
> groups of parameters according to the OLC you don't want to CHOOSE a
> group you want to allocate resources for ALL these groups. The groups
> still represent the same logical stream. Once a reply is received on the
> CallControl level you can remove the not needed groups. I don't think
> H248 handles this today for either text or binary.
> As a solution how about adding an indicator to say CHOOSE or ALLOCATE
> for groups of properties or SDP fields between V lines?? So Tom if
> that's what you mean then I support you.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > Time I intervened here to obtain a clear view of the WG position on
> > media description.  I have proposed that in the MGC->MG messages we
> > take any information which is end-to-end relevant out of LocalControl
> > and put it into Local instead.  I have heard no objection to this
> > proposal, but to make it absolutely clear I will give an example.
> >
> > (1) MGC A wants MG 1 to set up an RTP/UDP/IP connection for voice.
> > Because the call may involve DTMF signalling, MGC A directs that the
> > MG provide either G.711 (PCMU) or the combination of G.729 and the new
> > tone signalling payload type (which is shown here as experimental,
> > with a dynamic payload number).  The latter alternative is preferred,
> > to conserve bandwidth, so it is listed first.  The only item in
> > LocalControl is Mode, which is set to receiveOnly to start with.
> >
> > MGC A -> MG 1:
> >
> >    ... Add = $ {  Media  {
> > v=0                                   ; First alternative: G.729 plus
> > the encoded tones payload
> > c=IN IP4 $
> > m=audio $ RTP/AVP 96 97
> > a=rtmap:96 G729
> > a=rtpmap:97 X-TONES
> > v=0                                   ; Second alternative: G.711
> > mu-law
> > c=IN IP4 $
> > m=audio $ RTP/AVP 0
> >                                           } } }...
> >
> > (2) MG 1 returns the first alternative it can handle (which happens to
> > be MGC A's preferred alternative), with terminationID, address, and
> > port filled in.
> >
> > MG 1 -> MGC A:
> >
> >    ... Add = 1000 {  Media  {
> > v=0                                   ; G.729 plus the encoded tones
> > payload
> > c=IN IP4 216.210.157.16
> > m=audio 6450 RTP/AVP 96 97
> > a=rtmap:96 G729
> > a=rtpmap:97 X-TONES
> >                                           } } }...
> >
> > (3) MGC A signals this information to MGC B using SIP+SDP or
> > H.225.0/Q.931 with fast setup.  Note that the above is written on the
> > assumption that the coding is symmetric.  I show SDP indicating
> > asymmetry below.
> >
> > (4) MGC B now has to tell MG 2 to set up a context and create an RTP
> > termination.  It is clear that the Remote descriptor should contain
> > the information from the far end.  The question is whether it is
> > necessary to provide anything in the Local descriptor.  I'll assume
> > that we are operating under the convention that it is necessary to
> > provide a skeleton for the MG to fill in.  Hence the following:
> >
> > MGC B -> MG 2:
> >
> >     ... Add = $ {  Media  {
> >                        LocalControl { Mode = SendReceive },
> >                        Local = SDP {
> > v=0
> > c=IN IP4 $
> > m=audio $ RTP/AVP 96 97
> > a=rtmap:96 G729
> > a=rtpmap:97 X-TONES
> >                                           }
> >                    Remote = SDP {
> > v=0
> > c=IN IP4 216.210.157.16
> > m=audio 6450 RTP/AVP 96 97
> > a=rtmap:96 G729
> > a=rtpmap:97 X-TONES
> >                                           } } }...
> >
> > (5) MG 2 is able to support the proposed encoding, so it returns a
> > positive response with the terminationID and address/port information
> > filled in.  Beyond that, it looks just like what was sent down in step
> > (4), so I won't take the space to reproduce it.
> >
> > (6) MGC B signals acceptance of the connection to MGC A, including the
> > address/port information added by MG 2.
> >
> > (7) MGC A passes the complete package down to MG 1 with Remote filled
> > in.
> >
> > happens if send and receive preferences/capabilities differ?
> > According to our present text, send and receive
> > preferences/capabilities must both be shown in Local.  I will
> > illustrate this with a completely artificial example, where MGC A
> > wants MG 1 to use the G.729 plus encoded tones combination for
> > sending, but PCMU for receiving.  Then the steps above would be as
> > follows:
> >
> > (1) MGC A to MG 1:
> >
> >    ... Add = $ {  Media  {
> > PCMU it is to receive, but cannot fill in the missing items for the
> > sent information.  It returns the "send" media description anyway to
> > show that it is prepared to handle it:
> >
> >    ... Add = 1000 {  Media  {
> > (4) MGC B has to manipulate the information before passing it on to MG
> > 2: "send" becomes "receive" and vice versa.
> >
> > As an alternative, we can follow the suggestion Christian Groves has
> > made: "Local" describes what the MG will receive, and "Remote"
> > describes what it will send.  I'm not sure that simplifies anything.
> > Steps (1) and (2) look like this:
> >
> > (1) MGC A->MG 1:
> >
> >    ... Add = $ {  Media  {
> >                    Remote = SDP {
> > (2) MG 1 can fill in address/port for what it will receive:
> >
> > MG 1->MGC A:
> >
> >    ... Add = 1000 {  Media  {
> >                    Remote = SDP {
> > (3), ..., (7) etc.
> > allocation?  For asymmetric coding, which of the two styles do we
> > prefer: local send and receive capabilities both expressed in Local,
> > or Local equates to receive, Remote to send?  And finally, do we need
> > a different placeholder from "choose" for values we don't intend the
> > local MG to fill in, as in the Remote descriptor just above?
> >
> >      From:   Christian Groves [SMTP:[email-masked]]