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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 11 Sep 2007 17:32:19 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 12 Sep 2007 11:37:36 +0200

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:[email-masked]] 
> Sent: Tuesday, September 11, 2007 11:32 PM
> To: mmusic
> Subject: [MMUSIC] SDPCapNeg-06 Issue #3: More Fine-grained 
> Control ofRequired Extensions
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Sep 2007 08:45:14 -0400

> and all related pcfg for this m-line.
Right.
> 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
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

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 12 Sep 2007 16:35:57 +0200

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:[email-masked]] 
	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. 
		
		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.

	
	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:[email-masked]] 
			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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 20 Sep 2007 16:00:08 +0200

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

> From: Stach, Thomas [mailto:[email-masked]]
> 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,
>