[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