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

["Stach, Thomas" <[e-mail]>]

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.

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?
If yes, then such an extended "bracket syntax" should be specified
already in the core.

Regards
Thomas


> -----Original Message-----
> From: Flemming Andreasen [mailto:[e-mail]] 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic