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

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Feb 2007 08:07:58 +0000

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.

> 
> 
> 	7. Section 3.1 "Potential configurations are always 
> preferred over actual configurations..." I find this 
> confusing, because the example offer to which it refers does 
> not have an a=acfg attribute. We should use a different term 
> to express what is indicated by the "regular" transport and 
> attributes. In fact in lots of places in the document I think 
> the term "actual configuration" is used with different meanings.
> 	
> I don't believe so - can you provides some examples of where 
> you see such inconsistencies ?  The use of the term "actual 
> configuration" to reference what is in the offerered "m=" 
> line, etc. is both deliberate and in line with the overall 
> use of this term (AFAIK), so I would prefer not to have two 
> different terms here. 
> 
> The reason for having the "actual configuration" attribute 
> ("acfg") is because the answerer may use a different 
> configuration from the offer than what was actually included 
> as the actual configuration in the offer, and the offerer 
> needs to know about that in order to process both the answer 
> and incoming media correctly. Thus, the "selected 
> configuration" from the offer is now what the offerer needs 
> to use as the actual configuration (combined with the answer). 
> 
> In any case, I've rephrased the above referenced sentence 
> slightly to try and make it clearer. 
[JRE] I will see if the new version solves the problem.

> 	 
> 	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).

> 	 
> 	15. There are some very long sections in the draft. Is 
> it not possible to break some of them up into sub-sections so 
> that specific aspects can be referenced more easily?
> 	
> Please let me know of any specific suggestions here (the 
> current section splits seem natural to me, and, examples 
> aside, most sections are 2 pages or less, and only two 
> sections are close to 4 pages long)
[JRE] Sections 3.4.1 and 3.5.2 are quite long, but I don't see any way to
split these, so I guess I can live with it.

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