[MMUSIC] ISSUE2: SDP Attribute Multiplexing - CapNeg Analysis
Suhas Nandakumar <suhasietf@gmail.com> Tue, 24 June 2014 15:22 UTC
Return-Path: <suhasietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA79B1B2D72 for <mmusic@ietfa.amsl.com>; Tue, 24 Jun 2014 08:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.501
X-Spam-Level: **
X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEQ7fKpw8SJQ for <mmusic@ietfa.amsl.com>; Tue, 24 Jun 2014 08:22:42 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782F21B2D9F for <mmusic@ietf.org>; Tue, 24 Jun 2014 08:20:04 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id m15so540527wgh.9 for <mmusic@ietf.org>; Tue, 24 Jun 2014 08:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cyGEn8GljRb/rw+0Kyo7/ReqfaMz6J9zIrxlPwq5IPI=; b=Sdx64XangBOFEDXoGtJhDolDrpC2fTZKBLKXaM0NULX89G5zT/VsLM9REI6i9q6ktt czNAWbuCBU8ccsB3W4I6BhoXzY3NM0ys01Ed4ot9DdVgpAFTWt3cLkO4K6JzL+4WGHFU dbcqwf1NIFwfYG/4clVvVygiZo5+/UunUPshZm+kE9qTYCj+s0crmzuqBCR52AAPqz6w HXnofjHklOAZ3h2RAJhcUqmPPHoe09fZrMha+MgrNWyoNibBVGw9yHcgsqoUjzfFGwFW dOxAYkhn2SuF4bN5GaW0rSWzUy5TosBYR70Kjsi5c9CdtyJfexPccoBCi3ouAy/SO7Dd TWxA==
MIME-Version: 1.0
X-Received: by 10.194.134.70 with SMTP id pi6mr2252807wjb.1.1403623200803; Tue, 24 Jun 2014 08:20:00 -0700 (PDT)
Received: by 10.194.71.97 with HTTP; Tue, 24 Jun 2014 08:20:00 -0700 (PDT)
Date: Tue, 24 Jun 2014 08:20:00 -0700
Message-ID: <CAMRcRGQnPsxk52UBTp0HfLkiVP73ik1bS7DqFECRw_+dyTD0Yw@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="089e01175d9d48527504fc967ef8"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/frixL8vtz0tBc3Wa_iC9EnfNbDw
Subject: [MMUSIC] ISSUE2: SDP Attribute Multiplexing - CapNeg Analysis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Jun 2014 15:22:45 -0000
Hello All One of the action items from the IETF89 was to complete the analysis for describing multiplexing behavior of CapNeg attributes. Based on some offline discussions with Flemming back in London, I am planning to propose following semantic changes to the upcoming version of SDP Attributes Mux draft. { the english text usage might change in the final version though } *CHANGE 1. Define a new category called INHERIT as below* INHERIT*:* Attributes that encapsulate other SDP attributes and their multiplexing characteristics are INHERITED from the attributes they encapsulate. Such attributes as of today, are defined in [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for indicating and negotiating transport, media and media format related capabilities in the SDP. Example : m=video 3456 RTP/AVP 100 a=rtpmap:100 VP8/90000 a=fmtp:100 max-fr=30;max-fs=8040 a=sqn: 0 a=cdsc: 1 video RTP/AVP 100 a=cpar: a=rtcp-mux m=video 3456 RTP/AVP 101 a=rtpmap:101 VP8/90000 a=fmtp:100 max-fr=15;max-fs=1200 a=cdsc: 2 video RTP/AVP 101 a=cpar: a=rtcp-mux In the above example , the category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attribute *CHANGE 2: Update Section 15 to reflect the discussions from IETF 89 * *Section 15. Multiplexing considerations for Encapsulating Attributes* This sections deals with recommendations for defining the multiplexing characteristics of the SDP attributes that encapsulate other SDP attributes. Such attributes as of today, for example, are defined in [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for indicating and negotiating transport, media and media format related capabilities in the SDP. The behavior of such attributes under multiplexing is in turn defined by the multiplexing behavior of the attributes they encapsulate which are made known once the negotiation process is completed. *RFC3407 Attribute Analysis* sqn : NORMAL cdsc: NORMAL cpar: INHERIT cpar encapsulates b= (bandwidth) or an a= attribute. For bandwidth attribute encapsulation, the category SUM is inherited. For the case of a= attribute, the category corresponding to the SDP attribute being referenced is inherited. cparmin: SPECIAL cparmax: SPECIAL Since these attributes defines minimum and maximum numerical values associated with the attributed described in a=cpar, it is recommended to consult the document defining the attribute. *RFC5939 Attribute Analysis* RFC5939 defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. The attribute a=pcfg encapsulates various capabilities related to transport and media properties via the a=tcap and a=acap attributes respectively, that the Offerer is capable of supporting. Thus the attribute a=pcfg provides a list of potential configurations from the Offerer. In response, the Answerer picks its supported transport and/or media capabilities from the Offered list as part of a=acfg attribute representing the actual configuration selected. Thus a complete Offer/Answer exchange needs to be completed for the Offerer to ensure the right set of configuration parameters based on the actual configuration selected by the Answerer. Within the context of multiplexing several media descriptions with RFC5939 Capability negotiation attributes, following recommendations should be considered: 1. The negotiated transport capability attribute (a=tcap) MUST be IDENTICAL across all the multiplexed m=lines. [ Refer to section XXXXX in BUNDLE]. 2. For attributes encapsulated via a=acap capability attribute, the negotiation MUST ensure the multiplexing behavior of the same inherits the attribute being encapsulated. *RFC6871 Attribute Analysis* RFC6871 extends capability negotiation framework described in RFC5939 by defining media capabilities that can be used to indicate and negotiate media types and their associated format parameters. Building upon the analysis from the previous sections, following recommendations should be considered for dealing with the attributes defined in RFC6871 when multiplexing several SDP media descriptions 1. On negotiation, the category IDENTICAL-PER-PT applies to the attributes that define media capabilities (a=rmcap) and media format capabilities ( a=mfcap), if same Payload Type is being used to define these capabilities. 2. The Media specific capability attribute (a=mscap) , the non RTP media based capability attribute (a=omcap) MUST inherit the multiplexing behavior of the attribute being encapsulated. 3.The behavior for the latent configuration attribute (a=lcfg) follows the reasoning defined for the a=acfg and a=pcfg attributes, since a given latent configuration is provided as a recommendation and is not applied to the on-going Offer/Answer exchange. Example 1: Below SDP example captures the following aspects. - The Offerer offers audio and video streams with several different RTP profiles (AVP, SAVP, SAVPF) as potential configurations. - <Valid Answer > corresponds to the SDP answer where the Answerer accepts RTP/SAVPF as the default profile for both the media streams. In this scenario both the media streams can be successfully multiplexed. - <Invalid Answer> , the Answerer accepts the profile RTP/SAVPF for the audio stream and RTP/AVPF for the video stream. This scenario results in the failure of the multiplexing as defined in the section 7.2 of the BUNDLE specification [I-D.ietf-mmusic-sdp-bundle-negotiation]. <Offer-SDP> v=0 o=- 25678 753849 IN IP4 192.0.2.1 s= t=0 0 c=IN IP4 192.0.2.1 m=audio 3456 RTP/AVP 98 a=tcap:1 RTP/SAVPF a=rtpmap:98 OPUS/48000/2 a=pcfg:1 t=1 m=video 51372 RTP/AVP 101 a=rtpmap:101 H264/90000 a=tcap:2 RTP/SAVPF RTP/AVPF a=pcfg:2 t=2|3 <Valid Answer> v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= m=audio 3456 RTP/SAVPF 98 a=rtpmap:98 OPUS/48000/2 a=acfg:1 t=1 m=video 51372 RTP/SAVPF 101 a=rtpmap:101 H264/90000 a=acfg:2 t=2 <Invalid Answer> v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= m=audio 3456 RTP/SAVPF 98 a=rtpmap:98 OPUS/48000/2 a=acfg:1 t=1 m=video 51372 RTP/AVPF 101 a=rtpmap:101 H264/90000 a=acfg:2 t=3 Please let me know your thoughts Cheers Suhas
- [MMUSIC] ISSUE2: SDP Attribute Multiplexing - Cap… Suhas Nandakumar
- Re: [MMUSIC] ISSUE2: SDP Attribute Multiplexing -… Flemming Andreasen