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

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 14 Dec 1999 15:28:15 -0500

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  {
                       LocalControl { Mode = ReceiveOnly },
                       Local = SDP {
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  {
                       LocalControl { Mode = ReceiveOnly },
                       Local = SDP {

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.

-------------------------------------------------- End of example
-------------------------------------------------------

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

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  {
                       LocalControl { Mode = ReceiveOnly },
                       Local = SDP {

v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
                                          }
                   Remote = SDP {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 96 97
a=rtmap:96 G729
a=rtpmap:97 X-TONES
                                         } } }...

(2) MG 1 can fill in address/port for what it will receive:

MG 1->MGC A:

   ... Add = 1000 {  Media  {
                       LocalControl { Mode = ReceiveOnly },
                       Local = SDP {

v=0
c=IN IP4 216.210.157.16
m=audio 6450 RTP/AVP 0
                                          }
                   Remote = SDP {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 96 97
a=rtmap:96 G729
a=rtpmap:97 X-TONES
                                         } } }...

(3), ..., (7) etc.

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?

> -----Original Message-----
> 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.
>
> 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.
> 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
>      > jit
>      > event:quality alert < rtp specific
>
> 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]
> >
> >
> --------------------------------------------------------------------------
> >
> > Nancy M. Greene
> > Internet & Service Provider Networks, Nortel Networks
> > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

---

From: Christian Groves <[email-masked]>
Date: Wed, 15 Dec 1999 11:02:11 +0100

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?

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

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

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
> (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  {
> (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.
>
> 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  {
> (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.
>
> 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 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  {
> 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?
>