Re: [Sip] [Sip-implementors] Infinite Number of RTP payload in "mline"

"Paul E. Jones" <paulej@packetizer.com> Wed, 01 September 2010 22:13 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705223A681A for <sip@core3.amsl.com>; Wed, 1 Sep 2010 15:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne6On93esPig for <sip@core3.amsl.com>; Wed, 1 Sep 2010 15:13:34 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D0ECF3A6856 for <sip@ietf.org>; Wed, 1 Sep 2010 15:13:22 -0700 (PDT)
Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o81MDJrV002814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Sep 2010 18:13:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1283379205; bh=tXUmaxgPZyrAWthjX77m7HZv36EL3d+HxWPHxQZgtwQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=XzcZgrQx7d19033D70jdSmKFSPnLmy0iW38ygw860oguUASp4mnllQ9jvVFxvWEGS oWv49jbczL7l20HXf36X39qFQ/eVbRIfI0PsL6nbAXSCIKzYzgH81uNmSUTvRjenuH voDmycsJWEZaMOkToVH7wjA+QIn7MgyndQEdwGVw=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Nitin Kapoor'" <nitinkapoorr@gmail.com>, "'Sameer Sawhney'" <ssawhney@cisco.com>
References: <AANLkTikg9wcC0Q3hyc3g6h1rJoQfPrEFd=VJc_NCoNCV@mail.gmail.com> <003901cb49f7$42769ad0$1ede1eac@cisco.com> <AANLkTikyrqTN5TC=R=aUn3vT0gcgX3g8eMO86Tp0JKJe@mail.gmail.com>
In-Reply-To: <AANLkTikyrqTN5TC=R=aUn3vT0gcgX3g8eMO86Tp0JKJe@mail.gmail.com>
Date: Wed, 1 Sep 2010 18:11:55 -0400
Message-ID: <05dd01cb4a22$b3b04bd0$1b10e370$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05DE_01CB4A01.2CA05980"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGMsPCF30uBjPYRZnvACLtGKHAuAAIDAjMgApGhXNWTVj4XYA==
Content-Language: en-us
Cc: sip@ietf.org, sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip] [Sip-implementors] Infinite Number of RTP payload in "mline"
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2010 22:13:43 -0000

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: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Nitin
Kapoor
Sent: Wednesday, September 01, 2010 6:09 PM
To: Sameer Sawhney; paulej@packetizer.com
Cc: sip@ietf.org; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip] [Sip-implementors] Infinite Number of RTP payload in
"mline"

 

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 <ssawhney@cisco.com> 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: sip-implementors-bounces@lists.cs.columbia.edu
[mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Nitin
Kapoor

Sent: Wednesday, September 01, 2010 7:21 PM
To: sip-implementors@lists.cs.columbia.edu; sip@ietf.org

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

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

_______________________________________________
Sip-implementors mailing list

Sip-implementors@lists.cs.columbia.edu

https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors