IETF Logo Mail Archive

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

Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Tue, 10 May 2011 02:05 UTC

Return-Path: <Bert.Greevenbosch@huawei.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 6C07BE06D6 for <mmusic@ietfa.amsl.com>; Mon, 9 May 2011 19:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 waetrygGyQP4 for <mmusic@ietfa.amsl.com>; Mon, 9 May 2011 19:05:12 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC02E06F1 for <mmusic@ietf.org>; Mon, 9 May 2011 19:05:12 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY00BJZJ1ELC@szxga04-in.huawei.com> for mmusic@ietf.org; Tue, 10 May 2011 10:03:14 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY00BDCJ1EP8@szxga04-in.huawei.com> for mmusic@ietf.org; Tue, 10 May 2011 10:03:14 +0800 (CST)
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 10 May 2011 10:03:11 +0800
Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 10 May 2011 10:03:11 +0800
Date: Tue, 10 May 2011 02:03:09 +0000
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
X-Originating-IP: [10.70.109.52]
To: "mmusic@ietf.org" <mmusic@ietf.org>
Message-id: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_pAbvuLDBWSBABChfIErmkQ)"
Content-language: en-US
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: Question on unknown attributes in SDP offer/answer
Thread-index: AcwOtmkZFU6Yd/DzREOAXyjmslhSwQ==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Subject: [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 02:05:13 -0000

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.23.0 | Report a Bug | By Email