Re: [Sip] Need opinion

"Kevin P. Fleming" <kpfleming@digium.com> Thu, 30 September 2010 17:39 UTC

Return-Path: <kpfleming@digium.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 BA5343A6DEE for <sip@core3.amsl.com>; Thu, 30 Sep 2010 10:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.339
X-Spam-Level:
X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 bPVxAh7Mksap for <sip@core3.amsl.com>; Thu, 30 Sep 2010 10:39:06 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id E42A03A6DB4 for <sip@ietf.org>; Thu, 30 Sep 2010 10:39:05 -0700 (PDT)
Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1P1N6h-0007SR-Qp for sip@ietf.org; Thu, 30 Sep 2010 12:39:47 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id BD6F8D8194 for <sip@ietf.org>; Thu, 30 Sep 2010 12:39:47 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpHI6XYKab+i for <sip@ietf.org>; Thu, 30 Sep 2010 12:39:46 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id D5D65D8193 for <sip@ietf.org>; Thu, 30 Sep 2010 12:39:46 -0500 (CDT)
Message-ID: <4CA4CB62.9080108@digium.com>
Date: Thu, 30 Sep 2010 12:39:46 -0500
From: "Kevin P. Fleming" <kpfleming@digium.com>
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: sip@ietf.org
References: <D90C1FAC55221D4D9563354E245E3BB103426CB6@HYD-MKD-MBX02.wipro.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79C71@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C71@DC-US1MBEX4.global.avaya.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=05FB8DB2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Sip] Need opinion
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Kevin P. Fleming" <kpfleming@digium.com>
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, 30 Sep 2010 17:39:08 -0000

On 09/30/2010 10:46 AM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: sip-bounces@ietf.org [sip-bounces@ietf.org] On Behalf Of sulabh.deshmukh@wipro.com [sulabh.deshmukh@wipro.com]
> 
> I am some doubt regarding the RFC4566.
> 
> If you see the red marked attribute this same attribute is getting repeated in the SDP.
> I just want to confirm, is this  acceptable behavior?
> ________________________________________
> 
> According to the principle of "Be strict in what you send and lenient in what you accept", sending two lines that say "a=rtpmap:98 AMR/8000/1" should not be done, but the receiver should accept them and interpret them to mean that payload type number 98 is "AMR/8000/1".

To add to what Dale said... if the sender had sent two "a=rtpmap:98"
lines that did not have the same contents, the behavior of the receiver
is undefined, as the sender is not RFC compliant. The receiver could
choose to accept the first one, the second one, or neither, or even
reject the entire request.

This does not mean, though, that the receiver is obligated to watch for
duplicated "a=rtpmap" lines and verify that they match. It *can* do so,
but it can also treat the second one the same as it would if the
contents did not match the first one. As Dale said, though, it's not
costly to confirm that the second one does in fact match the first one,
and accepting the duplicate line is not harmful.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org