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

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 17 Dec 2004 23:15:11 -0500

Why would the MGC care if the MG can do 2833?  If it matters, then the MGC
can explicitly signal it in the Local descriptor by choosing a dynamic
payload number and including the appropriate rtpmap and associated a line
parameters.

If the MGC sends $ as the payload list, the MG can return as many payload
numbers as it likes, ordered by preference.  So if the MG wishes to include
2833 as an option, it would return the info necessary in the SDP along with
whatever other codecs it may wish to choose.

If the MGC really NEEDS to know if the MG can do RFC2833 out of band
signalling of telephony events, then it could try auditing the Local
descriptor for that information... but the response may be particularly
unwieldy and difficult to parse for the MGC.

Kevin 

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

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?

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

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

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

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

_______________________________________________
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: Mon, 20 Dec 2004 11:59:17 -0500

> If the MGC sends $ as the payload list, the MG can
 > return as many payload numbers as it likes,
 > ordered by preference.

So it seems the best way to handle the case is:
When MGC sends "m=audio $ RTP/AVP $",
MG should interpret the 2nd $ as a *list*
of codec it supports. This makes the best
sense to me, just not sure if the 2nd '$' in
"m=" is *allowed* by H248 to be a *list* of
codecs (rather than *choose one* codec).
I guess the answer is yes(?).

I agree that the best way is for MGC to assign the
payload number for 2833, and provides the list of
codecs. This issue is only for MGCs that
do not support it that way, and just expects
MGs to take care SDPs automatically.

Thanks for the helpfull discussion.
-Richard

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Mon, 20 Dec 2004 18:17:04 -0500

The MGC would like to know if the MGs can (or cannot) do RFC2833 because,
while controlling two participating MGs, it needs to know the capabilities
of both when sending media parameters to both. It can explicitly specify it
in the Local Descriptor as you have said, but in that case that Add command
would get fail if that MG does not support RFC2833 (and the exact reason why
the add command (inability to support RFC2833) would not be clear from the
error response) in which case the call would not be established.

Bala

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Friday, December 17, 2004 11:15 PM
To: Balasubramanian Pitchandi; 'Richard Sun'
Cc: 'Marcello Pantaleo (AC/EDD)'; [email-masked]
Subject: RE: [Megaco] how codec negotiation is triggered by MGC?

Kevin 

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

Bala 

-----Original Message----- 

the 
Agree. 

so. 

Regards, 
Richard 

asked

---

From: [email-masked]
Date: Wed, 22 Dec 2004 09:42:32 +0100

Just two side comments, the perspective here is too narrow in my opinion:

When (1) both parties connected to the same MG, or when (2) a single MGC is
controlling both MGs (where the parties connected are), are valid
scenarios, but not the general case.

Did you further consider the more general cases:
(3) case with MGC-to-MGC signalling (both MGs are associated to different
controllers), or
(4) different encoding modes (one MG uses binary encoding, other MG uses
text encoding => MGC must support dual mode, what about  ... SDP handling
...)?

I my opinion, the underlying issues is there are two fundamentally
different types of negotiation procedure from network perspective ("which
are both may collapse at a control interface like in our case with H.248):

1st type: end-to-end or peer-to-peer negotiation (=> only related to
protocol endpoints, "termination capability negotiation")
       => for instance, examples for VoIP H.248 case: H.248 MG peering
either another H.248 MG, or another non-H.248 MG, or an H.248 VoIP terminal
(RFC 3054), or an non-H.248 VoIP terminal (like SIP phone, H.323 terminal)

2nd type: hop-by-hop negotiation (=> related to protocol endpoints and all
involved in path nodes, "bearer capability negotiation")
       => examples for H.248 systems: negotiation procedures in 3GPP
Release 4 Circuit-Switched domain, or BICC Capability Set 2

Now, in case of decomposed systems like H.248, there are (at least) two
vertical control methods: a) strict control by MGC, or b) "more autonomous
control" by MG [see for instance H.248-controlled T.38 service where both
"negotiation" controls are supported].

The 2nd negotiation category (hop-by-hop) is typically "strictly
controlled" (because there are call/session control protocols or bearer
control protocols as prime negotiators).

The "RFC2833 case" of this email thread belongs to the 1st category in my
opinion. I tend to agree Kevin's view here.
regards
Albrecht

                      "Balasubramanian                                                                                          
                      Pitchandi"               To:      "'Kevin Boyle'" <[email-masked]>, "'Richard Sun'"            
                      <[email-masked]>          <[email-masked]>                                                                
                      Sent by:                 cc:      "'Marcello Pantaleo \(AC/EDD\)'" <[email-masked]>,      
                      megaco-bounces@i         [email-masked]                                                                  
                      etf.org                  Subject: RE: [Megaco] how codec negotiation is triggered by MGC?                 

                      21.12.2004 00:17                                                                                          

The MGC would like to know if the MGs can (or cannot) do RFC2833 because,
while controlling two participating MGs, it needs to know the capabilities
of both when sending media parameters to both. It can explicitly specify it
in the Local Descriptor as you have said, but in that case that Add command
would get fail if that MG does not support RFC2833 (and the exact reason
why the add command (inability to support RFC2833) would not be clear from
the error response) in which case the call would not be established.

Bala

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Friday, December 17, 2004 11:15 PM
To: Balasubramanian Pitchandi; 'Richard Sun'
Cc: 'Marcello Pantaleo (AC/EDD)'; [email-masked]
Subject: RE: [Megaco] how codec negotiation is triggered by MGC?

Kevin

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

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.

Bala

-----Original Message-----

the
Agree.

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

Regards,
Richard

asked