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

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

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