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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 03 Jul 2007 17:56:23 -0400

Matt Lepinski wrote:
> Flemming,
>
> Thanks for the reply, I now see where the problem is with solution (2).
>
> Solution (4) seems like the best solution. (I guess it's more 
> convenient to mark my crypto attributes as mandatory than to mark all 
> of my rtpmaps as optional).
>
> It seems that in implementing Solution (4) there are two possibilities:
> A) Mark the attributes as "optional" in the a=acap line
> B) Mark the attributes as "optional" in the a=pcfg line
>
> Both of these options seem reasonable me.
Agreed.
> I guess (B) is probably perferred because it's more expressive. 
> (Although I'm not sure when you'd want an attribute to be optional in 
> one a=pcfg line and mandatory in another a=pcfg line).
That's what I had in my mind too, although I have to admit that I'm 
struggling with use cases as well. Semantically, I think that whether a 
particular attribute needs to be supported or not is a feature of the 
potential configuration it is used in, not the attribute capability 
itself (after all, capabilities are just advertisements of things you 
can do, whereas potential configurations combine a set of capabilities 
to construct a meaningful offer SDP). Looking at the current popular use 
cases (SRTP), the attributes end up being mandatory all the time though.

Taking another look at it and going through some examples, I now 
actually favor 3B (default being mandatory instead of optional as in 4B) 
since that is consistent with the way we use the transport protocol 
capability in the potential configuration (assumed behavior there is 
that you can only use a potential configuration if you support the 
transport protocol included in it, if any). For efficiency, and 
ease-of-human-parsing/debugging, I'd suggest a format as illustrated by 
the following example:

    a=pcfg a=1,2,[3,4]|2,7,[5]

In the first alternative, attribute capabilities 1 and 2 are mandatory 
to support, whereas 3 and 4 are optional. In the second alternative, 
attribute capabilities 2 and 7 are mandatory to support whereas 5 is 
optional. Essentially, we'd have up to two lists of attribute 
capabilities in each alternative; the first one holds the mandatory ones 
and the second one the optional ones.

Thanks

-- Flemming

>
> - Matt Lepinski :->
>
> Flemming Andreasen wrote:
>
>>
>>
>> Matt Lepinski wrote:
>>
>>> 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. 
>>
>> 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
>>
>>> - Matt Lepinski :->
>>>
>>> Flemming Andreasen wrote:
>>>
>>>> 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
>>>>
>>>
>>
>

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 4 Jul 2007 15:40:23 +0200

Flemming,

I agree with your reasoning, that the a=pcfg line should 
declare what attributes are optional/mandatory for the 
potential configuration.
To have "mandatory" as default as for the transport 
protocol makes sense as well.
Your proposed syntax looks good too.

Thanks 
Thomas

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 11:56 PM
> To: Matt Lepinski
> Cc: Jonathan Lennox; mmusic
> Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes 
> and potentialconfiguration selection
> 
> 
> 
> Matt Lepinski wrote:
> > Flemming,
> >

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 03 Jul 2007 09:55:47 -0400

Flemming,

Solution (4) seems like the best solution. (I guess it's more convenient 
to mark my crypto attributes as mandatory than to mark all of my rtpmaps 
as optional).

Both of these options seem reasonable me. I guess (B) is probably 
perferred because it's more expressive. (Although I'm not sure when 
you'd want an attribute to be optional in one a=pcfg line and mandatory 
in another a=pcfg line).

- Matt Lepinski :->

Flemming Andreasen wrote:

>> Personally, I can't think of a use-case where the lack of flexibility 
>> in Option (2) would cause signficant problems. 
>
>>> 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.
>>>
>>> Prague, however there seems to be a few possible solutions to this one:
>>>
>>> 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).
>>>
>>>
>>> types for example, where an rtpmap is both understood and supported, 
>>> but the actual codec is not.
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>