Subject: Re: Media Format Negotiation in MGCP

From: Nancy-M Greene <[email-masked]>
Date: Mon, 25 Oct 1999 15:20:51 -0400

This discussion also applies to Megaco. SDP media descriptions are found in
the Local and Remote descriptors of the Stream descriptor. The LocalControl
descriptor holds properties defined by packages. The proposed DS0 package
contains fields for preferred coder, preferred decoder, gain, echo
cancellation, .... The first call flow in Annex G of Megaco/H.248 v11
(ftp://standards.nortelnetworks.com/megaco/doc/latest/megaco-h248_protocol.p
df) shows the MGC setting LocalControl values for preferred coder, decoder.
The MG responds with SDP in the Local descriptor, listing the codecs in SDP.
This is sent to the MG on the other side of the call. That MG decides which
codecs it would accept, and send back appropriate SDP in its Local
descriptor. This then is sent to the originating MG in the Remote descriptor
field. In this scenario, the second MG decides the codecs it will support
based on input from the originating MGC, and the originating MG.

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

> ----------
> From:         Christer Holmberg[SMTP:[email-masked]]
> Sent:         Monday, October 25, 1999 6:19 AM
> To:   [email-masked]
> Subject:      Re: Media Format Negotiation in MGCP
>
> <<File: christer.holmberg.vcf>>
>
> Hi,
>
> I am not sure this mail will answer your question, but I'll give it a try
> :)
>
> There is no "good" codec negotiation technique in MGCP, and it's also an
> (one of many) inter-MGC communication problem.
>
> If  you are the MG, you can return a list of codecs that you support, and
> then you have to analyse the RTP packets to find out which of the listed
> codecs the remote party uses.
>
> Or, you could, instead of a list, only return one codec, which you then
> expect the remote party to use when coding packets sent to you . Of
> course, you should pick the codec from the list in the given remote
> connection descriptor, so you know that the remote party will support that
> specific codec.
>
> However, this is not always a good way to do it, beucase now the remote
> party will think that this is the only codec that you support, and it will
> affect scenarios where the remote party would like to, for some reason,
> change the codec.
>
> I guess which way you use depends much on how your MG works technically.
>
> Regards,
>
> Christer
>
>
>

---

From: Nancy-M Greene <[email-masked]>
Date: Tue, 26 Oct 1999 00:12:25 -0400

I made an error in the URL below. It should be
ftp://standards.nortelnetworks.com/megaco/docs/latest

and in there look for
MegacoH248v11.pdf, or MegacoH248v11.doc

Nancy

> ----------
> From:         Greene, Nancy-M [CAR:5N10:EXCH]
> Sent:         Monday, October 25, 1999 3:20 PM
> To:   [email-masked]; 'Christer Holmberg'
> Subject:      RE: Media Format Negotiation in MGCP
>
> This discussion also applies to Megaco. SDP media descriptions are found
> in the Local and Remote descriptors of the Stream descriptor. The
> LocalControl descriptor holds properties defined by packages. The proposed
> DS0 package contains fields for preferred coder, preferred decoder, gain,
> echo cancellation, .... The first call flow in Annex G of Megaco/H.248 v11
> (ftp://standards.nortelnetworks.com/megaco/doc/latest/megaco-h248_protocol
> .pdf) shows the MGC setting LocalControl values for preferred coder,
> decoder. The MG responds with SDP in the Local descriptor, listing the
> codecs in SDP. This is sent to the MG on the other side of the call. That
> MG decides which codecs it would accept, and send back appropriate SDP in
> its Local descriptor. This then is sent to the originating MG in the
> Remote descriptor field. In this scenario, the second MG decides the
> codecs it will support based on input from the originating MGC, and the
> originating MG.
>
> Nancy

---

From: David Cromwell <[email-masked]>
Date: Tue, 26 Oct 1999 10:09:53 -0400

Nancy,

Maybe I'm not understanding this correctly, but it appears in G.1.2 that the
MGC suggests 30ms packetization to MG1, MG1 replies that it wants to do 20
ms packetization, and the MGC ignores this and suggests 30 ms to MG2. This
appears to be a error in the scenario, but maybe I am not understanding it
correctly.

What would happen if the MGC suggested a single codec that MG1 couldn't
support?  Does MG1 nack the request, or does it suggest an alternative list?
If the latter, then the MGC would forward that list on to MG2.  If MG2 did
not support any of the codecs on the list would it then nack the MGCs
request?

It might be helpful to include a scenario in the spec where the negotiation
over codec or packetization  breaks down.

David
--
[email-masked]                                          Nortel
Networks
ESN:            351-8870
35 Davis Dr
Public:    919-991-8870
RTP, NC 27709

> -----Original Message-----
> Sent: Monday, October 25, 1999 3:21 PM
> in
> .p

---

From: Nancy-M Greene <[email-masked]>
Date: Tue, 26 Oct 1999 21:24:05 -0400

David Cromwell writes:

> Nancy,
>
> Maybe I'm not understanding this correctly, but it appears in G.1.2 that
> the MGC suggests 30ms packetization to MG1, MG1 replies that it wants to
> do 20 ms packetization, and the MGC ignores this and suggests 30 ms to
> MG2. This appears to be a error in the scenario, but maybe I am not
> understanding it correctly.
>
I think you've found an error in the example....

> support?  Does MG1 nack the request, or does it suggest an alternative
I would think it would send an alternate list.

> If the latter, then the MGC would forward that list on to MG2.
>
If it wanted to - otherwise it could refuse the call.

> If MG2 did not support any of the codecs on the list would it then nack
> the MGCs request?
>
It would have to, I think. Isn't there a default codec, though, that all MGs
should support so this doesn't happen?

> It might be helpful to include a scenario in the spec where the
> negotiation over codec or packetization  breaks down.
>
yes, good idea...

> David
> --
> [email-masked]
> Nortel Networks
> ESN:            351-8870
> 35 Davis Dr
> Public:    919-991-8870
> RTP, NC 27709
>
>