IETF Logo Mail Archive

Re: [MMUSIC] Question on unknown attributes in SDP offer/answer

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Tue, 10 May 2011 19:29 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA58FE06B9 for <mmusic@ietfa.amsl.com>; Tue, 10 May 2011 12:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.374
X-Spam-Level:
X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FQCnmyP0xX0 for <mmusic@ietfa.amsl.com>; Tue, 10 May 2011 12:29:47 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 71399E069F for <mmusic@ietf.org>; Tue, 10 May 2011 12:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2327; q=dns/txt; s=iport; t=1305055787; x=1306265387; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zJmmDZfPstwk6KVayXMrYzCGpQCa6C96uWOurp0Nc10=; b=E5hGqQrCYS//scqSTsWMSuIgZ604l5COU30pYimoJENDhy7jkiqDxr6P nUofbWpq8WLDinhl6EpZv/PEK/tf5a4ARvmgGWAVIvLQWfT4rb96nck3I x/EKz+5dax1SVN0EV9/B1JNT0vTdpmF8QAKOtn0gauYh6ST6FUz31HyIS U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwBACeRyU2rRDoG/2dsb2JhbACXWo4wd6kGnjuGDwSGQo1eik4
X-IronPort-AV: E=Sophos;i="4.64,347,1301875200"; d="scan'208";a="445202458"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 19:29:42 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4AJTgvx032145; Tue, 10 May 2011 19:29:42 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 12:29:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 May 2011 12:29:41 -0700
Message-ID: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C044309FF@xmb-sjc-234.amer.cisco.com>
In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] Question on unknown attributes in SDP offer/answer
Thread-Index: AcwOtmkZFU6Yd/DzREOAXyjmslhSwQAkKg8A
References: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com>
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>, mmusic@ietf.org
X-OriginalArrivalTime: 10 May 2011 19:29:42.0669 (UTC) FILETIME=[9C9FEBD0:01CC0F48]
Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 19:29:49 -0000

Hi Bert,

An end system that is producing an answer to an SDP offer that includes
SDP attributes it does not understand should ignore those attributes and
not include them within the answer. I find this to be done correctly by
most implementations.

Cheers,
Charles


> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
Behalf Of Bert Greevenbosch
> Sent: Monday, May 09, 2011 7:03 PM
> To: mmusic@ietf.org
> Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer
> 
> Hi all,
> 
> 
> 
> I have a question for the SDP offer/answer model experts. It is
related to the "3dFormat" attribute
> draft
(http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00.
txt).
> 
> 
> 
> The issue has been touched before, but more in the context of frame
packing. The current issue
> concerns how a legacy device will treat the for it unknown "3dFormat"
attribute, especially in SIP
> negotiation.
> 
> 
> 
> I have found the following related info:
> 
> 
> 
> *         The SDP spec (RFC 4566) defines that unknown attributes MUST
be ignored:
> "If an attribute is received that is not understood, it MUST be
ignored by the receiver." (section
> 5.13)
> 
> *         The SDP offer/answer spec (RFC 3264) gives no information
about what to do with unknown
> attributes. The spec does not say whether the answerer can/will omit
unknown attributes in its answer.
> 
> *         The SIP spec (RFC 3261) specifies a warning code 306
"Attribute not understood: One or more
> of the media attributes in the session description are not
supported.". It does not mandate using this
> warning code, or specify whether it can be used with a SIP 200 OK
response.
> 
> 
> 
> Ideal would be, when the answerer would omit SDP attributes it does
not understand. In that case, the
> offerer can detect the client does not understand the "3dFormat"
attribute and can update its offer.
> 
> 
> 
> Does any of you know more about how it works in praxis? Is there an
established way on how current
> implementations deal with unknown SDP attributes when doing SIP
negotiation?
> 
> 
> 
> Thanks a lot for your help!
> 
> 
> 
> Best regards,
> 
> Bert

v2.27.8 | Report a Bug | By Email | System Status