Subject: [Megaco] Regarding different payload types in local and remote descriptor for same codec

From: "Prerna Nagar" <[email-masked]>
Date: Wed, 26 Sep 2007 16:23:56 -0700

Hi All,
 
Consider a case when a Add request comes to media gateway and the request
looks like:
 
Add Request
{Context = $ { Add = DS/1/1/2 { Media { LocalControl { Mode = SendReceive }
} } ,
Add = $ { Media { LocalControl { Mode = SendReceive, ReservedValue = OFF } ,
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP $
},Remote {
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP 106 100
a=rtpmap:106 PCMU/8000/1
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
} } } }}
 
Here  "CHOOSE" in Local resolves to a list of codecs supported by the
gatway(PCMU will resolve to 0)
Next intersection of codecs between local and remote takes place.
But here in Local  PCMU has a static value "0" and remote understands "106"
as PCMU (different payload types).
 
Question is : How the codec negotiation should work and how the response
should look like?
 
Should it look like :
1. 
a=tgwrtp/8079  { m { 
Local {
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
 } ,
Remote{
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP 106 100
a=rtpmap:106 PCMU/8000/1
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
 }}  } }}
 
or
2.
a=tgwrtp/8079  { m { 
Local {
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP 106 100
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
 } ,
Remote{
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP 106 100
a=rtpmap:106 PCMU/8000/1
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
 }}  } }}
 
Regards,
Prerna

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

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 27 Sep 2007 08:48:42 +0200

This is not an H.248 issue in my understanding, this relates to the "AVP
Profile", thus a RFC 3550 matter (I've Cc'ed [email-masked]) in my
understandning:
 
When RTP/AVP allows to use different PT codepoint values for the same
media format, then the SDP is correct.
When RTP/AVP does not allow to use different PT codepoint values for the
same media format, then the SDP is incorrect (and the MG must reply with
an error code because the ADD.request was incorrect).
 
-Albrecht
 
PS
Different media formats per traffic direction is possible (but this was
not the question).
 
PSS
I guess that PCMU is not used as "VBD codec" (i.e. with a dynamic PT
value). But if yes, then the SDP is incorrect. The SDP must then follow
V.152, see "a=" line ...

________________________________

	From: Prerna Nagar [mailto:[email-masked]] 
	Sent: Donnerstag, 27. September 2007 01:24
	To: [email-masked]
	Subject: [Megaco] Regarding different payload types in local and
remotedescriptor for same codec

	Hi All,
	 
	Consider a case when a Add request comes to media gateway and
the request looks like:
	 
	Add Request
	{Context = $ { Add = DS/1/1/2 { Media { LocalControl { Mode =
SendReceive } } } ,
	Add = $ { Media { LocalControl { Mode = SendReceive,
ReservedValue = OFF } ,
	Local {
	v=0
	c=IN IP4 $
	m=audio $ RTP/AVP $
	},Remote {
	v=0
	o=- 0 0 IN IP4 -
	s=-
	c=IN IP4 210.2.12.2
	t=0 0
	m=audio 16400 RTP/AVP 106 100
	a=rtpmap:106 PCMU/8000/1
	a=rtpmap:100 X-NSE/8000/1
	a=fmtp:100 192-194
	} } } }}
	 
	Here  "CHOOSE" in Local resolves to a list of codecs supported
by the gatway(PCMU will resolve to 0)
	Next intersection of codecs between local and remote takes
place.
	But here in Local  PCMU has a static value "0" and remote
understands "106" as PCMU (different payload types).
	 
	Question is : How the codec negotiation should work and how the
response should look like?
	 
	Should it look like :
	1. 
	a=tgwrtp/8079  { m { 
	Local {
	v=0
	o=- 0 0 IN IP4 -
	s=-
	c=IN IP4 210.2.12.2
	t=0 0
	 
	or
	2.
	
	a=tgwrtp/8079  { m { 
	Local {
	v=0
	o=- 0 0 IN IP4 -
	s=-
	c=IN IP4 210.2.12.2
	t=0 0
	 
	Regards,
	Prerna

---

From: Ashish Singh <[email-masked]>
Date: Thu, 27 Sep 2007 09:01:14 -0700

If gateway can support asymmetric payload type (receiving and sending 
media using different payload types), then option 1 seems fine.

If gateway doesn't have capability to support asymmetric PT, then it 
should follow option 2. Gateway should not reject this call as CA has 
sent $. Gateway can resolve $ by its configured list of codecs, but  
still it can give precedence to Remote descriptor's  payload type, if 
same codec is present in Remote desc. Afterwards, codec negotiation 
phase will select the PCMU with 106 as PT in both local and remote. 
Local desc in option2 is slightly incorrect. rtpmap attribute for 106 
should also be present in local desc. Option2 should look like:

a=tgwrtp/8079  { m {
*Local *{
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP *106* 100
*a=rtpmap:106 PCMU/8000/1*
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
 } ,
*Remote*{
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
m=audio 16400 RTP/AVP *106* 100
*a=rtpmap:106 PCMU/8000/1
*a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
 }}  } }}

Prerna Nagar wrote:
> Hi All,
>  
> Consider a case when a Add request comes to media gateway and the 
> request looks like:
>  
> *Add Request*
> m=audio $ RTP/AVP *$*
> m=audio 16400 RTP/AVP *106* 100
> a=rtpmap:*106 PCMU/8000/1*
> But here in Local  PCMU has a static value "0" and remote understands 
> "106" as PCMU (different payload types).
>  
> /Question is : How the codec negotiation should work and how the 
> response should look like?/
> // 
> Should it look like :
> *1.*
> a=tgwrtp/8079  { m {
> *Local *{
> v=0
> o=- 0 0 IN IP4 -
> s=-
> c=IN IP4 210.2.12.2
> t=0 0
> m=audio 16400 RTP/AVP *0* 100
> *Remote*{
> m=audio 16400 RTP/AVP *106* 100
> *a=rtpmap:106 PCMU/8000/1
> *a=rtpmap:100 X-NSE/8000/1
> a=fmtp:100 192-194
>  }}  } }}
>  
> or
> *2.*
> a=tgwrtp/8079  { m {
> *Local *{
> v=0
> o=- 0 0 IN IP4 -
> s=-
> c=IN IP4 210.2.12.2
> t=0 0
> m=audio 16400 RTP/AVP *106* 100
> *Remote*{
> m=audio 16400 RTP/AVP *106* 100
> *a=rtpmap:106 PCMU/8000/1
> *a=rtpmap:100 X-NSE/8000/1
> a=fmtp:100 192-194
>  }}  } }}
>  
> Regards,
> Prerna
> ------------------------------------------------------------------------
>

---

From: "Yogesh" <[email-masked]>
Date: Fri, 28 Sep 2007 08:37:21 +0530

Hi Prerna,
 
logically MG should give preference to Remote, but in most of the cases it
is implementation specific.
 
Now the question is if MG gets $ in Local, MG has to display its
capabilities,
if that is the case, MG should change its codec as per the remote and
display it or not?
 
if remote is present, MG should still give preference to Remote and display
the capabilities accordingly, for successful negotiation.
 
Talking about solutions you proposed,
 
1> In first case your negotiation will fail if Remote GW is unable to change
the codec payload to 0 ( zero )
    what I want to say is, your response will reach remote and now remote
will see Local=106, and remote=0
    so remote GW has to change its local to 0 ( zero ) for successful
negotiation.
    ( This is nothing but Remote GW has to give preference to Remote for
successful negotiation)
 
2> where as in second case you are giving preference to Remote and changing
your Local accordingly, 
    this looks fine as codec is negotiated as per remote payload type.
 
3> Third case will be change remote as per your Local and send it across for
further negotiation. 
     What I mean by this is, MG gets Local=0 (zero ) and remote = 106, MG
response will be Local=zero and Remote=zero.
     But I dont think changing remote payload type is advisable. 
 
as I told you earlier logically preference should be given to Remote and
hence,
 
a=tgwrtp/8079  { m { 
Local {
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
 
This looks fine to me, unless 106 is not configured for any other codec.
 
If any one has better understanding, please suggest.

Cheers !!!

Yogesh Pathare

Senior Engineer - Testing

A R I C E N T

Presidency Tower B

Fourth Floor 

Gurgaon , India 122001

Main     +91 1243911200 Ext 5512

  _____  

From: Prerna Nagar [mailto:[email-masked]] 
Sent: Thursday, September 27, 2007 4:54 AM
To: [email-masked]
Subject: [Megaco] Regarding different payload types in local and remote
descriptor for same codec

Hi All,

Add Request

 
Should it look like :
1. 
a=tgwrtp/8079  { m { 
Local {
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
 
or
2.
a=tgwrtp/8079  { m { 
Local {
v=0
o=- 0 0 IN IP4 -
s=-
c=IN IP4 210.2.12.2
t=0 0
 
Regards,
Prerna