Re: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained Control ofRequired Extensions

Stach, Thomas wrote:
> Fleming,
>
> I agree. 
> We should not unnecesarily restrict the extensibility.
>
> I just want to clarify what you have in mind. 
> The declaration of optional and mandatory attributes from draft 06 looks
> as follows:
> a=pcfg:1 a=1,2,[3,4]
> Here attribute 1 and 2 are mandatory to support and [3,4] are optional.
>
> If there is an extension foo that defines a letter f for the pcfg
> attribute.
> A a=creq:foo at media level would mean that the extension must be
> supported for the m-line 
> and all related pcfg for this m-line.
>   
Right.
> If just a potential configuration is affected the pcfg attribute one
> could extend the "bracket syntax" to the extensions.
> That could look like
> a=pcfg:1 a=1,2,[3,4] f=1,2 in case of mandatory support for 1,2 and 
> a=pcfg:1 a=1,2,[3,4] [f=1,2] in case of optional support for 1,2 and 
> a=pcfg:1 a=1,2,[3,4] f=1,[2] in case of mandatory support for f=1 and
> optionallly f=2.
>
> Is this (or something similar) what you have in mind?
>   
The current rules say that unknown or unsupported potential 
configuration parameter extensions are ignored, and hence I was thinking 
more along the lines of listing the required option tags as part of the 
pcfg line, e.g.

a=pcfg:1 a=1,2,[3,4] f=1,2 r=foo, in case of mandatory support for 1,2 and 
a=pcfg:1 a=1,2,[3,4] f=1,2 in case of optional support for 1,2 and 
a=pcfg:1 a=1,2,[3,4] f=1,[2] r=foo in case of mandatory support for f=1 and optionallly f=2.

Your proposal works equally well though, if not better since it's a more 
compact representation. It requires a few minor changes to the current 
rules and syntax, but that could certainly be done (we might consider 
just using a separate prefix on the parameter, e.g. "-f=1,[2]" while we 
are at it  to cover all possible combinations of required extension 
support).

> If yes, then such an extended "bracket syntax" should be specified
> already in the core.
>   
It's only specified for the attribute capability list values, not the 
extension capability list (or list values), so we still need to make a 
few tweaks.

Thanks

-- Flemming
> Regards
> Thomas
>
>
>   
>> -----Original Message-----
>> From: Flemming Andreasen [mailto:fandreas@cisco.com] 
>> Sent: Tuesday, September 11, 2007 11:32 PM
>> To: mmusic
>> Subject: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained 
>> Control ofRequired Extensions
>>
>> The core SDP Capability Negotiation Framework includes support for 
>> extensions. Unknown extensions are by default ignored, however 
>> extensions can have an option tag associated with them, and 
>> support for 
>> those can be required. The way this is done currently is by 
>> including a 
>> single "a=creq" at the session-level and/or media-level(s), which 
>> indicate the option tags that MUST be supported in order to 
>> process the 
>> SDP Capability Negotiation extensions. When provided at the 
>> session-level, the extensions must be supported throughout the entire 
>> SDP, and when provided at the media-level, the extensions must be 
>> supported for that particular media description ("m=" line).
>>
>> As part of the media capabilities discussion, Magnus expressed some 
>> concerns about forward compatibility and not having enough 
>> flexibility 
>> for later (if media capabilities are not included in the core, which 
>> they are not). Proper extensibility support is key to address 
>> this IMO, 
>> and the question here is whether the current extension mechanism is 
>> flexible enough.
>>
>> The design team had originally discussed "required" option tags being 
>> supported not only at the session and media level (as is done 
>> currently), but to also support them at the individiaul potential 
>> configuration level. This way, rather than requiring support for a 
>> particular extension throughout the entire SDP or in a 
>> particular media 
>> description in order to even use the SDP capability negotation 
>> framework, we can simply skip individual potential configuration 
>> attributes where the necessary extensions are not supported.
>>
>> At the time, it was felt that we could get by without such 
>> functionality, however I'd like to reconsider that here. The basic 
>> question is whether there ever is a need to require support for a 
>> particular extension in one potential configuration, but not 
>> another one 
>> in the same media description. I believe the answer to that 
>> is yes once 
>> we start considering combinations of capabilities. Consider the 
>> following example:
>>
>> a) If the transport protocol is AVPF, and media capabilities are 
>> supported, then use H.264 with the RFC 4588 RTP 
>> retransmission payload 
>> format. The RTP retransmission uses session-multiplexing and we have 
>> another extension in place to indicate an inter-media stream 
>> synchronization dependency. This extension must be supported as well.
>> b) If the transport protocol is regular AVP, and media 
>> capabilities are 
>> supported then use H.264 with FEC (RFC 2198 and 
>> draft-ietf-avt-ulp-23.txt)
>>
>> The two alternatives above each correspond to a potential 
>> configuration 
>> which uses transport protocol capabilities (core) and media 
>> capabilities 
>> (extension), however the first one requires support for an additional 
>> capability (which the second does not). Thus, indicating required 
>> capabilities at the media-level alone does not produce the desired 
>> result (consider the case where the answerer supports only the media 
>> capabilities).
>>
>> While the use cases for this functionality may not be that 
>> common, they 
>> are nevertheless there, and will be important to some. I believe the 
>> functionality is important to have, it doesn't add much additional 
>> complexity, and if we are to have it, it needs to be in the 
>> core. Based 
>> on this, I'd like to suggest we add this functionality in the core.
>>
>> Please let me know if you agree or disagree with this.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
>>     
>
>   