[MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained Control of Required Extensions

[Flemming Andreasen <[e-mail]>]

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