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

["Even, Roni" <[e-mail]>]

Flemming,
I think we need this functionality. As for the syntax it is not clear.
What you need to relate is a potential configuration and a specific
required extension (there may be more than one)
Roni

> -----Original Message-----
> From: Stach, Thomas [mailto:[e-mail]]
> Sent: Wednesday, September 12, 2007 5:36 PM
> To: Flemming Andreasen
> Cc: mmusic
> Subject: RE: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained
> ControlofRequired Extensions
> 
> Fleming,
> 
> thanks for reminding me that unknown or unsupported potential
> configuration parameter extensions are ignored.
> I think we should keep this property as it is currently specified.
> That's probably easier to implement and its more inline with current
SDP
> rules in general.
> 
> I would rather go with your proposal of a pcfg parameter r=foo, that
> must be supported in the core.
> 
> I didn't get your point about a separate prefix in "-f=1,[2]". Was it
> just meant as alternative to r=foo?
> 
> Regards
> Thomas
> 
> 
> 
> ________________________________
> 
> 	From: Flemming Andreasen [mailto:[e-mail]]
> 	Sent: Wednesday, September 12, 2007 2:45 PM
> 	To: Stach, Thomas
> 	Cc: mmusic
> 	Subject: 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:[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

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