Subject: [Sip] Infinite Number of RTP payload in "mline"

From: Nitin Kapoor <[email-masked]>
Date: Wed, 1 Sep 2010 09:51:20 -0400

Dear All,

I am facing the problem where one of source is sending bunch of RTP payload
in "mline", and because of that my MSX is stripping 2 codec from that line,
when its forwarding that OFFER to termination end.

This is the "mline" which i am getting from source:

*m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56
118 101 13 120*

This is what my MSX is sending to termination after stripping the payload
from "mline"

*m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56
118 101    *

Now i checked some documents but unable to find anything which says its
correct or not.

Could any one please give some direction on this whether such amount of
payload type is correct in "mline" or it not acceptable .

Thanks,
Nitin Kapoor

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 1 Sep 2010 12:54:12 -0400

This is valid, though I've never seen so many codecs on a single m= line.
Who can practically deal with this? ;-)

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin
Kapoor
Sent: Wednesday, September 01, 2010 9:51 AM
To: [email-masked]; [email-masked]
Subject: [Sip] Infinite Number of RTP payload in "mline"

Dear All,

m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56
118 101 13 120

m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56
118 101    

Thanks,
Nitin Kapoor

---

From: Nitin Kapoor <[email-masked]>
Date: Wed, 1 Sep 2010 18:08:53 -0400

Thanks for your reply.

I checked the RFC and noticed that it does not limit the codec #s in mline,
but nor does it comment on infinite number of codecs support being
mandatory.

So could you please let me know whether it is mandatory to support them or
not. Because if my SBC is not supporting this then i cannot go and ask them
to support this.

Thanks,
Nitin Kapoor

On 1 September 2010 13:00, Sameer Sawhney <[email-masked]> wrote:

> As per spec 2327 this is valid ! check fmt.
>
>
>   media-field =         "m=" media space port ["/" integer]
>                         space proto 1*(space fmt) CRLF
>
>   media =               1*(alpha-numeric)
>                         ;typically "audio", "video", "application"
>                         ;or "data"
>
>   fmt =                 1*(alpha-numeric)
>                         ;typically an RTP payload type for audio
>                         ;and video media
>
>   proto =               1*(alpha-numeric)
>                         ;typically "RTP/AVP" or "udp" for IP4
>
>   port =                1*(DIGIT)
>                         ;should in the range "1024" to "65535" inclusive
>                         ;for UDP based media
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Nitin
> Kapoor
> Sent: Wednesday, September 01, 2010 7:21 PM
> Subject: [Sip-implementors] Infinite Number of RTP payload in "mline"
>
> Dear All,
>
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 1 Sep 2010 18:11:55 -0400

Nitin,

This is just a matter of personal opinion, but I think having that many
codecs offered on an m= line is ridiculous.  I'd like to hear somebody give
justification for doing it :-)

Seriously, how in the world can one build an interoperable system with this
much clutter to dig through?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin
Kapoor
Sent: Wednesday, September 01, 2010 6:09 PM
To: Sameer Sawhney; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] [Sip-implementors] Infinite Number of RTP payload in
"mline"

Thanks for your reply.

Thanks,
Nitin Kapoor

  fmt =                 1*(alpha-numeric)

  port =                1*(DIGIT)

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

Dear All,

Thanks,
Nitin Kapoor

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Sep 2010 18:35:44 -0400

> not. Because if my SBC is not supporting this then i cannot go and ask them

Well, the number is far from infinite. There are only 128 possible 
payload types, so you shouldn't see more than that many values.

Since there is a reasonable upper bound, it shouldn't be so hard to support.

The device that sent you this clearly thought it was something they were 
prepared to deal with. You can refuse the ones you don't like, so what 
is the problem?

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 14:28:55 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Nitin Kapoor [[email-masked]]

I am facing the problem where one of source is sending bunch of RTP payload in "mline", and because of that my MSX is stripping 2 codec from that line, when its forwarding that OFFER to termination end.

m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56 118 101 13 120

This is what my MSX is sending to termination after stripping the payload from "mline"

m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56 118 101

Now i checked some documents but unable to find anything which says its correct or not.
________________________________________

The input SDP is correct, of course.  If the MSX's purpose is to limit the number of codecs that the session may use, or to eliminate the use of the codecs identified by 13 and 120, then it has succeeded.  If its purpose is to be transparent for SIP usage, its behavior is erroneous.

Dale