Subject: Re: Number of LocalConnectionOptions in CRCX

From: Nancy-M Greene <[email-masked]>
Date: Sun, 5 Dec 1999 22:30:51 -0600

Gordon, I will answer with respect to Megaco, which looks like it currently
might have the same problem. In the RTP package, we have defined a property
called ptime. Yet, Gordon points out that the value of ptime is related to
the codec....

Tom Taylor recently posted a msg (subject = Re: Washington Issue 9 -
Wildcards in SDP, sent Dec 3/99) to the list proposing that MGC preferred
values for the sdp should not go into LocalControl at all, but instead be
sent down in the sdp. Choices would be sent as separate sdp blocks within
the LocalDescriptor, and not in the LocalControlDescriptor at all.

This would eliminate the problem you have, Gordon, with MGCP.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

> ----------
> From:         Gordon Cutts[SMTP:[email-masked]]
> Sent:         Thursday, December 02, 1999 3:14 PM
> To:   [email-masked]
> Subject:      Number of LocalConnectionOptions in CRCX
>
> To whoever can help,
>
> As I have yet to send a question concerning MGCP, I hope I have chosen the
> correct area.  My apologies if I have made a mistake.
>
> During some of our interop testing I came across an interesting "grey
> area"
> in the RFC draft-huitema-mgcp-v0r1-05.txt.  Here is the scenario:  The
> Call
> Agent (CA) has already performed an AUEP for LocalConnecitonOptions on our
> gateway to which we reply with two "L" parameter lines since the CODEC
> packetization property is unique to each.  For example:
>
> 200 3 OK
> L: a:PCMU;PCMA, p:20, m:sendonly;recvonly;sendrecv;inactive;netwloop,
> nt:IN
> L: a:G723, p:30, m:sendonly;recvonly;sendrecv;inactive;netwloop, nt:IN
>
> Later in the call flow when the CA sends the initial CRCX to our gateway
> it
> provides multiple "L" parameter lines as well, such as:
>
> CRCX 20 here/[email-masked] MGCP 0.1
> C: 2f
> M: inactive
> X: 16
> R: hu,hf
> L: a:pcmu,p:20
> L: a:G723,p:30
>
> The two "L" lines is what is causing the problem.  The reason they are
> sending two lines is because they don't want to send a single line and run
> into the problem of giving a range for the packetization period where one
> gateway can have a different incremental value than the other, i.e.
> packetization of 5, 10, 20 vs. 10, 20, 30.  From what I can found in the
> spec (2.3.4.  CreateConnection, p.38)
>
>         *    It may state exactly one value, which the gateway will then
> use
> for
>      the connection,
>
>         *    It may provide a loose specification, such as a list of
> allowed
>      encoding methods or a range of packetization periods,
>
>         *    It may simply provide a bandwidth indication, leaving the
> choice of
>      encoding method and packetization period to the gateway.
>
> it is my understanding that the CA only provides one "L" parameter line in
> its CRCX (and MDCX).  Since the CA is the one who is supposed to have the
> brains and the gateways are "dumb" I believe that the CA should either
> tell
> us specifically what we should use, or give us a general idea of what to
> use
> (based upon matching properties with the remote gateway) from which we can
> make a decision based upon priority.
>
> Any help in this area would be greatly appreciated, and promptness would
> be
> REALLY appreciated as time is of great importance.
>
> Thanks to all for your time and effort.
>
> Sincerely,
>
> Gordon Cutts
>

---

From: Pierre Couillaud <[email-masked]>
Date: Mon, 6 Dec 1999 08:55:18 -0500

Nancy, Tom,

I am following your discussion on the list, and I have few issues
related to what Gordon is
mentioning....

MGCP do not allow a lot of flexibility concerning the media negotiation.

You cannot specify on a codec basis some other parameters related to the
specific codec. For
example, I believe that things like "silence suppression", or
"packetization period" are directly
related to one codec and thus must be negotiated on a codec basis, and
not on a media basis.
An example would be for G.711 : there are several silence suppression
algorithm and most of
them are propriaritary one's.

For what I have seen on H.248 so far, the same problem will be present,
because within the
LocalControl Descriptor, again you cannot specify these parameters on a
per-codec basis.

As Tom, mentionned it in his email ( Dec. 3rd : Re: Washington Issue 9 -
Wildcards in SDP ),
there is a lot of redundancy between some H.248 attributes and the
SDP description. Again,
my understanding is that we shouldn't need SDP at all.
If you are looking at the usage of SDP in MGCP, it is primeraly used in
order to specify things
which cannot be specified within any MGCP parameter ( and it is the same
for H.248 ) like :
the IP address of the termination which will handle the media stream, as
well as the port
number for the same purpose.
And if you stricktly look at SDP as defined in its RFC, this one mention
in the introduction that
"SDP is not intented for negotiation of media encodings". SDP is only
meant to advertise to
my peer that "I" will be sending this type of media.

Now, within MGCP, we are trying to use differently the SDP in order to
include negotiation
as part of the SDP description, and the same approach seems to be taken
with Megaco. First,
this goes against the usage of the SDP, second it will gives you more
and more huge SDP
description if you want to be complete, third it completely makes
useless the usage of the MGCP/
H.248 already defined capabilities in order to provide the same
information, fourth it may
introduce more work and more misunderstanding : what to do if a SDP do
not match a LocalControl ???

A good thing with SDP is the definition of "static profile" which allows
you to save time
and bandwidth when transferring data, and I believe this can be usefull,
but again incomplete
so far : in the case of a static profile, a packetization period is
specified for a given profile, and
maybe it would be nice to be able to include other codec related
parameters as well : for example
the value of the silence suppression....

Now, a solution could be to really get rid of the SDP within H.248, and
specify a little bit more
some packages. For example the "Network" package within H.248 could be
enhanced to support
per-codec parameter definition ( basically, in the same manner you would
use a SDP-m description
for each codec to specify ). The ordering within the message itself
would give you the preferred
order, while you could describe specific parameters for the codec by the
use of more additional
info. Finaly, some default values for each codec could be also
introduced in the spec ( this would be
as if you were using a SDP static profile ) : these values could be the
one defined for the static profile.
And in order to give the rest of the info needed, some extra parameters
could be used to provide
( ip, port number, number of media channels, etc... ) which is currently
defined within SDP but
not within H.248....

This is only an initial thought, please don't mis-interpret this
comment, but I would like to
have some opinion on the subject.

Regards,

Pierre

Greene, Nancy-M (N.) [EXCHANGE:CAR:5N10] wrote:

>
>
> Gordon, I will answer with respect to Megaco, which looks like it
> currently might have the same problem. In the RTP package, we have
> defined a property called ptime. Yet, Gordon points out that the value
> of ptime is related to the codec....
>
> Wildcards in SDP, sent Dec 3/99) to the list proposing that MGC
> preferred values for the sdp should not go into LocalControl at all,
> but instead be sent down in the sdp. Choices would be sent as separate
> sdp blocks within the LocalDescriptor, and not in the
> LocalControlDescriptor at all.
>
> -------------------------------------------------------------------------
>
> Nancy M. Greene
>      During some of our interop testing I came across an interesting
>      "grey area"
>      in the RFC draft-huitema-mgcp-v0r1-05.txt.  Here is the
>      scenario:  The Call
>      L: a:PCMU;PCMA, p:20,
>      m:sendonly;recvonly;sendrecv;inactive;netwloop, nt:IN
>      Later in the call flow when the CA sends the initial CRCX to our
>      gateway it
>              *    It may state exactly one value, which the gateway
>      will then use
>      for
>           the connection,
>
>              *    It may provide a loose specification, such as a list
>      of allowed
>      brains and the gateways are "dumb" I believe that the CA should
>      either tell
>      us specifically what we should use, or give us a general idea of
>      what to use
>      Any help in this area would be greatly appreciated, and
>      promptness would be

--

Pierre Couillaud, Nortel Networks
Software Designer - Voice Networking      Phone : (613) 967 5000 x3696
"Anything one man can imagine, other men can make real."
                                                                  Jules Verne