Subject: RE: [Megaco] how codec negotiation is triggered by MGC?

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 17 Dec 2004 14:22:13 -0500

Actually, this is not true.  While MGCP does not send SDP from the CA to the
MTA, it *does* send "Local Connection Options" which function in the same
capacity as underspecified Local SDP in H.248 -- to indicate to the MG the
constraints of the SDP it may return.

Now, if the MG wants to always do 2833 and you don't want the MGC to worry
about having to ask the MG to do it, then the MGC could send an
underspecified SDP requesting that the MG choose the codecs.  The MG can
then choose to include a payload number for 2833 if it chooses to do so.

Kevin 

-----Original Message-----
From: Richard Sun [mailto:[email-masked]] 
Sent: Friday, December 17, 2004 2:17 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Marcello Pantaleo (AC/EDD); [email-masked]
Subject: Re: [Megaco] how codec negotiation is triggered by MGC?

Kevin,
Thanks for the reply.

 > Why not just have the MGC choose the payload number for  > the 2833
events?

Good question. That was what I asked. But some MGC implementation says that
MGC does not care rfc2833 and its payload type at all, MGC just expects MG
to turn on rfc2833 automatically. I thought this is not possible, so I asked
the question just to make sure that I do not miss anything.

To put it another way:
does it make any sense for any MGC to say:
"MGC never needs to look at the SDP contents, it just pass SDP among MGs.
MGs should just handle the codec negotiation themself"?

This is indeed possible with MGCP. But it seems that this is really not
possibile with H248.
For H248, MGC always needs to be involved in this codec negotiation.

Let me know if I am wrong. Thanks,
-Richard

Kevin Boyle wrote:

> Why not just have the MGC choose the payload number for the 2833 events?
> 
> Note that the m line example here restricts the payload selectors to 
> those defined as RTP/AVP.  This can be avoided by using $ for that 
> element as well.
> 
> To confirm Marcello's statement, '*' is not a permitted wildcard in 
> underspecified SDP.  '$' is allowed in any position and means choose.
> Note that the use of wildcards is only allowed in the MGC->MG 
> direction.  MGs are always expected to send compliant SDP.
> 
> Kevin
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Sun
> Sent: Friday, December 17, 2004 12:39 PM
> To: Marcello Pantaleo (AC/EDD)
> Cc: [email-masked]
> Subject: Re: [Megaco] how codec negotiation is triggered by MGC?
> 
> Marcello,
> Thanks for your helpfull information.
> 
> Now assume that MGC audits MG and learns that MG supports "PCMU" *and* 
> "telephone-event".
> If "m=audio $ RTP/AVP $" means that
> MG to choose *one* codec, then
> what is the syntax for MGC to instruct MG "use PCMU, *and* choose a 
> payload number for telephone-event"?
> 
> -Richard
> 
> Marcello Pantaleo (AC/EDD) wrote:
> 
>  > Hi,
>  >
>  > MGC can use audit capabilities to get the list of codecs supported 
> by a MG. Alternatively a MGC can be provisioned with MG capabilities.
> 
>  >
>  > MGC wouldn't use Add to know MG capabilities (e.g. supported codecs).
>  >
>  > If MGC sends an Add command with an empty local desciptor, this is 
> a request to release any resources previously reserved for the media 
> flow received, that means nothing given that MGC is now creating the
termination.
> 
>  > If local descriptor is unspecified (i.e. absent), MG considers this 
> as missing mandatory parameter. MG uses whatever previously specified.
> 
>  >
>  > If MGC sends "m=audio $ RTP/AVP $" it requests MG to choose one of 
> the supported codecs, so you don't get the list.
>  >
>  > I don't think you can use * wildcard in the "m=".
>  >
>  > Regards,
>  > Marcello
>  >
>  > -----Original Message-----
>  > From: [email-masked] [mailto:[email-masked]]On
>  > Behalf Of Richard Sun
>  > Sent: Thursday, December 16, 2004 3:08 PM  > To: [email-masked]  > 
> Subject: [Megaco] how codec negotiation is triggered by MGC?
>  >
>  >
>  > Hi, Can anyone pelase clarify the standard for MGC to trigger a 
> codec  > negotiation in MG (i.e, MG should provide a list of codecs it  
> > supports)?
>  >
>  > One way I can think of is an empty "Local{}"
>  > without SDP, such as:
>  > Transaction = 299012 {
>  >   Context = $ {
>  >     Add = aaln/1 {
>  >       Media { Stream = 1 {
>  >         LocalControl {Mode = SendReceive}
>  >     }}},
>  >     Add = $ {
>  >       Media {Stream = 1 {
>  >         LocalControl {Mode=ReceiveOnly},
>  >         Local {}
>  > }}}}}
>  >
>  > The question is: is this legal? Should MG reject the message with 
> some  > kind of error such as "SDP missing", or MG is suppose to fill 
> up the  > SDP section in response?
>  > What if the "Local{}" does not present at all?
>  >
>  > The other way is something like this:
>  > Transaction = 299012 {
>  >   Context = $ {
>  >     Add = aaln/1 {
>  >       Media { Stream = 1 {
>  >         LocalControl {Mode = SendReceive}
>  >     }}},
>  >     Add = $ {
>  >       Media {Stream = 1 {
>  >         LocalControl {Mode=ReceiveOnly},
>  >         Local {
>  > v=0
>  > o=$ $ $ IN IP4 $
>  > s=$
>  > c=IN IP4 $
>  > t=$ $
>  > m=audio $ RTP/AVP -
>  > a=ptime:20
>  > }}}}}}
>  > With "-" in "m=audio $ RTP/AVP -", should MG fill up the list of  > 
> codecs?
>  > Or should it be something like
>  > "m=audio $ RTP/AVP $"?
>  >
>  > Thanks for any information.
>  > -Richard
>  >
>  > _______________________________________________
>  > Megaco mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/megaco
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Richard Sun <[email-masked]>
Date: Fri, 17 Dec 2004 15:55:35 -0500

Kevin, thanks for the response. See below ...

>constraints of the SDP it may return.
Agree.

>then choose to include a payload number for 2833 if it chooses to do so.
So it is true that, in any case, MGC needs to do something special to 
handle rfc2833.
Just want to be clear on "underspecified SDP request":

If MGC just sends "m=audio $ RTP/AVP 0", it means no rfc2833, right?

If MGC sends "m=audio $ RTP/AVP $", it means that MG will choose *one* 
codec,
say, MG may respond "m=audio 8000 RTP/AVP 0", but how MG responds
the payload number for RFC2833 if it always wants to support RFC2833? If 
MGC sends
m=audio $ RTP/AVP $
a=rtpmap:$ telephone-evemts/8000
then can MG responds with
m=audio 8000 RTP/AVP 0 101
a=rtpmap:101 telephone-evemts/8000
If this the true, then is the last $ in "m=" acturally a list?

Or should MG respond with
m=audio 8000 RTP/AVP 0
a=rtpmap:101 telephone-evemts/8000
(is this SDP legal?)

Regards,
Richard

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Fri, 17 Dec 2004 17:51:32 -0500

I don't think MGC can "assume" that the MG can always do RFC2833. MGC cannot
predict how an MG would respond to an underspecified SDP
(including/excluding RFC2833). When interoperating with multiple MGs, you
want to specifically know if each MG can or cannot do RFC2833.

I kinda agree with Richard that there's no clear method as to how the MGC
can learn of MG's ability to do RFC2833 in H.248.

Bala

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Sun
Sent: Friday, December 17, 2004 3:56 PM
To: Kevin Boyle
Cc: Marcello Pantaleo (AC/EDD); [email-masked]
Subject: Re: [Megaco] how codec negotiation is triggered by MGC?

Agree.

Regards,
Richard