Subject: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Jun 2007 13:16:08 -0400

Jonathan Lennox had noted that the current potential configurationa 
algorithm combined with the standard SDP rules of ignoring unknown 
attributes, may lead an answerer to select a potential configuration 
with attributes it does not support, when the intent was to actually 
have the answerer select a potential configuration with attributes the 
answerer does support. Clearly, this does not produce the desired outcome.

The reason for this is that we still use the standard SDP rules where we 
ignore unknown SDP attributes.

The design team did not get a chance to discuss this issue in Prague, 
however there seems to be a few possible solutions to this one:

1) Continue with the current scheme, but allow the answerer to select 
only a potential configuration if the potential configuration makes 
sense and can be supported. This would ensure that any attributes that 
are required in order for a potential configuration to be used would 
have to be supported by the answerer in order for him to select that. 
For example, if the media stream is for SRTP, and the potential 
configuration specifies use of the "crypto" attribute for keying 
material, which the answerer didn't support, the answerer would move on 
to the next potential configuration (which could use a different keying 
mechanism).

2) Require that all attributes used by a potential configuration MUST be 
supported by the answerer in order for that potential configuration to 
be valid (and hence be able to be selected). An attribute is supported 
if both the attribute type and its value can be supported. This raises 
some potential ambiguity with payload types for example, where an rtpmap 
is both understood and supported, but the actual codec is not.

3) As 2), however allow for individual attribute capabilities to be 
marked as "optional" in a potential configuration. If an "optional" 
attribute capability is not supported by the answerer, the potential 
configuration would still be considered valid.

4) Similar to 3), except the default would be "optional", and we can 
mark certain attributes as mandatory.

Option 1 seems flaky and is not recommended.
Option 2 is simple to specify and use, however, as noted, it is not 
clear it has sufficient flexibility
The recommendation here is for either option 3 or 4, with the choice 
depending on whether you believe optional or mandatory attributes are 
the more common use cases for SDP Capability Negotiation.

My preference is for option 4. Compared to option 3, this option aligns 
slightly better with standard SDP as well, inasmuch as the default 
operation is normal SDP, and any changes from that requires an explicit 
indication (mandatory attribute).

Please let me know if you disagree or have any comments on this.

Thanks

-- Flemming

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

---

From: Matt Lepinski <[email-masked]>
Date: Wed, 27 Jun 2007 13:58:05 -0400

Flemming,

I'm concerned that marking individual attributes within a potential 
configuration as mandatory or optional will increase the perception of 
complexity for SDP capability negotiation. Therefore, my preference 
would be to avoid Options (3) and (4).

Personally, I can't think of a use-case where the lack of flexibility in 
Option (2) would cause signficant problems. Therefore, I'd favor Option (2).

- Matt Lepinski :->

Flemming Andreasen wrote:

> The reason for this is that we still use the standard SDP rules where 
> we ignore unknown SDP attributes.
>
> material, which the answerer didn't support, the answerer would move 
> on to the next potential configuration (which could use a different 
> keying mechanism).
>
>
> 2) Require that all attributes used by a potential configuration MUST 
> be supported by the answerer in order for that potential configuration 
> to be valid (and hence be able to be selected). An attribute is 
> supported if both the attribute type and its value can be supported. 
> This raises some potential ambiguity with payload types for example, 
> where an rtpmap is both understood and supported, but the actual codec 
> is not.
>
> My preference is for option 4. Compared to option 3, this option 
> aligns slightly better with standard SDP as well, inasmuch as the 
> default operation is normal SDP, and any changes from that requires an 
> explicit indication (mandatory attribute).
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 27 Jun 2007 14:13:08 -0400

Matt Lepinski wrote:
> Personally, I can't think of a use-case where the lack of flexibility 
> in Option (2) would cause signficant problems. 
How about rtpmaps mapping to an unsupported codec (which codec 
negotiation/standard 3264 procedures would have taken care of) ? It will 
be a quite common use case for the media capabilities extension.

> Therefore, I'd favor Option (2).
>
Per the above, I think there are important use cases that will make this 
option problematic.

-- Flemming

>> have the answerer select a potential configuration with attributes 
>> the answerer does support. Clearly, this does not produce the desired 
>> outcome.
>>
>> sense and can be supported. This would ensure that any attributes 
>> that are required in order for a potential configuration to be used 
>> would have to be supported by the answerer in order for him to select 
>> that. For example, if the media stream is for SRTP, and the potential 
>> be supported by the answerer in order for that potential 
>> configuration to be valid (and hence be able to be selected). An 
>> attribute is supported if both the attribute type and its value can 
>> be supported. This raises some potential ambiguity with payload types 
>> for example, where an rtpmap is both understood and supported, but 
>> the actual codec is not.
>>
>> default operation is normal SDP, and any changes from that requires 
>> an explicit indication (mandatory attribute).
>>