Re: [MMUSIC] ISSUE2: SDP Attribute Multiplexing - CapNeg Analysis

[Flemming Andreasen <[e-mail]>]

On 6/24/14, 11:20 AM, Suhas Nandakumar wrote:
> 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
>
Looks good.


> *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.
>
Looks good.
> *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.
>
I think we need a bit more text and maybe an example for the second 
point as I'm not quite sure what it conveys (for example what does 
"same" mean). I also think we need some restrictions (or at least 
recommendations) on the Offerer to make sure he generates potential 
configurations between the multiplexed streams that can (easily) be 
negotiated to be consistent between those streams. For example, if we 
try to negotiate one or more attributes that must be IDENTICAL, then the 
offered potential configurations should be constructed in a way to make 
that possible. If we could furthermore come up with some rules for 
constructing those in a way that makes it easy to for the answerer to 
pick those compatible potential configurations betweem media streams, 
that would make it much easier to deal with in practice (one possible 
idea could be to require the configuration numbers to line up between 
the media descriptions as a way of easily finding something that is 
compatible between them)

We should also say something about what to do with extensions (which may 
be difficult to do generically, in which case we can just state that and 
say to consult the extension, e.g. like RFC 6871 below).

Section 5.28 also needs to be updated with new category information.

> *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.
To be clear, the requirement is really on the "pcfg" attribute, since it 
controls what gets negotiated (same comment applies to RFC 5939 above). 
Now that ends up placing some requirements on the capabilities (like 
"acap" above or "rmcap" here) that are used in those potential 
configurations, and we should make that clear(er). The reason it comes 
up more here is because payload types are defined by the "pcfg" 
attribute in RFC 6871, not the "rmcap" attribute. More text around how 
to construct these potential configurations and the attributes they 
leverage (similarly to RFC 5939) would be helpful.

Btw, I'm not sure I've seen the definition of "IDENTICAL-PER-PT".

> 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.
mscap seems right.

If "rmcap" needed some kind of payload type (or format type more likely) 
consistency, then "omcap" does too. More definition around which ones 
need to be identical is needed though (and it may be easier to drive 
this requirement though the potential configuration, but I'm not sure).

> 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.
>
I don't think the "lcfg" attribute has any interaction with Bundle since 
it merely describes one or more potential future media streams.

There is also the "sescap" attribute. Presumably you would want to make 
sure that any bundled media descriptions/configurations are also 
acceptable combinations of media streams/configurations as specified by 
"sescap" (it quickly becomes complicated otherwise, so we may want to 
add text to that effect). I don't think there is much more to this one.

Also, section 5.29 needs to be updated with new category information.

Thanks

-- Flemming
> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic