Subject: Re: [MMUSIC] RE: SDP Capability Negotiation

From: Flemming Andreasen <[email-masked]>
Date: Sun, 04 Mar 2007 13:32:19 -0500

Elwell, John wrote:
> Flemming,
>
> See my responses below.
>
> John 
>
>   
>> 	4. Section 3.1 - there is no point in listing the 
>> supported or required base - this can be implied simply by 
>> the presence of a=csup / a=creq.
>> 	
>> You could have a rule like that, but what does it then mean 
>> when say "cap-v1" is included in a "a=csup" ? Would "cap-v0" 
>> be supported as well ? I suppose that would be up to the 
>> definition of "cap-v1", but let's say "cap-v1" is not 100% 
>> backwards compatible, how would the offerer then indicate 
>> that it supports both "cap-v0" and "cap-v1" operation ? With 
>> the current definitions, we could have a "creq" attribute 
>> listing "cap-v0", and then a "csup" attribute listing 
>> "cap-v1" - the rules for "v1" could then say that you can 
>> "upgrade" to using "v1" operation. A "v1" compliant endpoint 
>> could do that, whereas a "v0" compliant endpoint would just 
>> continue with the "v0" operation. 
>>
>> If we infer "v0" support by presence of certain attributes 
>> instead (I'd prefer the "pcfg" attribute since that would 
>> then allow for omitting the "csup" and "creq" attributes in 
>> the best-effort SRTP case today), then we can easily do 
>> something similar, however what about the case where the 
>> offerer supports only "v1" operation ? We would now need to 
>> include a "creq=cap-v1" attribute, but I suppose that's fine: 
>> We don't have to pay the price until (if) v1 actually comes along. 
>>
>> I'll wait for others to chime in here, since the current 
>> solution was agreed to by the design team, but it seems ok to 
>> me (we still need the option tag but don't have to require 
>> its use in an offer that supports "v0" or other independent 
>> extensions only). 
>>     
> [JRE] I don't have a strong opinion - I will go along with the majority.
>   
The design team agreed to go along with your suggestion which will be 
reflected in the next version.

>
>   
>> 	 
>> 	14. Do we need to make any statements about 
>> asymmetrical (direction-sensitive) attributes? I am thinking 
>> here of things like a=sendonly and a=rcvonly. If you have an 
>> a=acap:1 a=sendonly line, and this is used by a potential 
>> configuration that gets selected as the actual configuration 
>> by the answerer, then if the answerer promotes the sendonly 
>> attribute to a regular a=sendonly line in the answer, then 
>> this is clearly wrong (but a=rcvonly would be correct). 
>>
>> Agreed. 
>>
>> 	I don't have any practical use cases for using this, so 
>> perhaps we just need to exclude this type of attribute from 
>> use in a=acap lines.
>>
>> I'm not following this part - why can direction attributes 
>> not be provided in acap lines ? Conversely, it sounds to me 
>> like you want us to outlaw something that is already 
>> forbidden by the existing o/a procedures (as supplemented by 
>> the procedures here) ? 
>>     
> [JRE] Since I do not have any other examples, I guess sendOnly and rcvOnly
> are the only attributes of concern. I would just like to see a brief mention
> of the special handling these receive (e.g., an a=acap a=sendOnly in an
> offer would result in an a=rcvOnly in the answer if a potential
> configuration in which it occurred is selected as the actual configuration
> in the answer).
>
>   
Ok - I'll add a sub-section for these.

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