Subject: Re: LocalConnectionOptions

From: Charles Eckel <[email-masked]>
Date: Mon, 6 Dec 1999 10:54:04 -0800

I believe some of the confusion results from the differences between the
Capabilities and and LocalConnectionOptions paramters.

In the response to the audit endpoint message, the gateway can specify
whcih combinations of codecs and parameter values it supports. Page  54
of RFC 2705 states:

---------------------
 The capabilities for the endpoint similar to the
 LocalConnectionOptions parameter and including event packages and
 connection modes.  If there is a need to specify that some
 parameters, such as e.g., silence suppression, are only compatible
 with some codecs, then the gateway will return several capability sets:
----------------------

As Christian pointed out, the RFC does not make the same statement with
regards to the LocalConnectionOptions. On pg.38-9 it states:

----------------------
   LocalConnectionOptions is a parameter used by the Call Agent to
   direct the handling of the connection by the gateway.  The fields
   contained in LocalConnectionOptions are the following:

   *  Encoding Method,
   *  Packetization period,
   *  Bandwidth,
   *  Type of Service,
   *  Usage of echo cancellation,
   *  Usage of silence suppression or voice activity detection,
   *  Usage of signal level adaptation and noise level reduction, or
      "gain control."
   *  Usage of reservation service,
   *  Usage of RTP security,
   *  Type of network used to carry the connection.

   This set of field can be completed by vendor specific optional or
   mandatory extensions. The encoding of the first three fields, when
   they are present, will be compatible with the SDP and RTP profiles:

   *  The encoding method shall be specified by using one or several
      valid encoding names, as defined in the RTP AV Profile or
      registered with the IANA.
   *  The packetization period is encoded as either the length of time
      in milliseconds represented by the media in a packet, as specified
      in the "ptime" parameter of SDP, or as a range value, specifying
      both the minimum and maximum acceptable packetization periods.
   *  The bandwidth is encoded as either a single value or a range,
      expressed as an integer number of kilobit per seconds.

   For each of the first three fields, the Call Agent has three options:

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

If the CA cannot send multiple LocalConnectionOptions lines, then it
loses the ability to specify multiple codecs with different codec
specific parameters. Is this restriction intentional? Is so, what is the
proposal for working around the scenario Gordon raised?

 Thanks for clarifying.
--
Charles Eckel
Senior Engineer       mailto:[email-masked]
Vovida Networks, Inc.      phone:(408)941-1743
http://www.vovida.com        fax:(408)941-1791

> Subject: Re: Number of LocalConnectionOptions in CRCX
> Date: Mon, 6 Dec 1999 05:55:18 -0800
> From: Pierre Couillaud <[email-masked]>
> To: [email-masked]
>
> 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....
>
> 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
>
> --
>
> 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