|
Stach, Thomas wrote: Right.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. 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.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? 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). 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.If yes, then such an extended "bracket syntax" should be specified already in the core. Thanks -- Flemming Regards Thomas-----Original Message----- From: Flemming Andreasen [mailto:fandreas at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/mmusic |
_______________________________________________ mmusic mailing list mmusic at ietf.org https://www1.ietf.org/mailman/listinfo/mmusic