[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained Control ofRequired Extensions
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: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