IETF Logo Mail Archive

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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 02 September 2010 18:30 UTC

Return-Path: <dworley@avaya.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 37FEA3A67D4 for <sip@core3.amsl.com>; Thu, 2 Sep 2010 11:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.417
X-Spam-Level:
X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 6tQcMuHk7KOz for <sip@core3.amsl.com>; Thu, 2 Sep 2010 11:30:32 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0420F3A672E for <sip@ietf.org>; Thu, 2 Sep 2010 11:30:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,309,1280721600"; d="scan'208";a="205724252"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Sep 2010 14:30:53 -0400
X-IronPort-AV: E=Sophos;i="4.56,309,1280721600"; d="scan'208";a="511608613"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Sep 2010 14:30:52 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 2 Sep 2010 14:30:52 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Nitin Kapoor <nitinkapoorr@gmail.com>, "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>, "sip@ietf.org" <sip@ietf.org>
Date: Thu, 2 Sep 2010 14:28:55 -0400
Thread-Topic: [Sip] Infinite Number of RTP payload in "mline"
Thread-Index: ActJ3Mp5RqyQbMefRsu13yWvcUasdwA7+jEZ
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C07@DC-US1MBEX4.global.avaya.com>
References: <AANLkTikg9wcC0Q3hyc3g6h1rJoQfPrEFd=VJc_NCoNCV@mail.gmail.com>
In-Reply-To: <AANLkTikg9wcC0Q3hyc3g6h1rJoQfPrEFd=VJc_NCoNCV@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Sip] 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: Thu, 02 Sep 2010 18:30:33 -0000

________________________________________
From: sip-bounces@ietf.org [sip-bounces@ietf.org] On Behalf Of Nitin Kapoor [nitinkapoorr@gmail.com]

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

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

v2.8.7 | Report a Bug | By Email