[MMUSIC] Re: draft-ietf-mmusic-sdp-capability-negotiation-07: More comments

[Flemming Andreasen <[e-mail]>]

Thanks for the comments Francois - responses below

Francois Audet wrote:
> These are a few of minor comments and questions on 
> draft-ietf-mmusic-sdp-capability-negotiation, based
> on comments I've received from implementors wanting 
> clarification.
>
>
> Section 3.2:
> -----------
>
> In the description of the a=pcfg attribute, it would be helpful to clearly state
> that the intent is that the potential configuration are preferred to the implicit
> configuration described in the m/c lines. (It is describe later in the document, 
> in greater details, but an up-front note on this would be useful).
>   
ok - I'll add that.
>
> Section 3.4.2 (p.19, second paragraph):
> ---------------------------------------
>
> The intent of the following sentence is not completely clear:
>
>    Transport capabilities are inherently included in the "m=" line, 
>    however they still need to be specified explicitly in a "tcap" 
>    attribute if they are to be used as a capability.  
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   
How about the following instead:

<quote>
The ability to use a particular transport protocol is inherently implied 
by including it in the "m=" line. However, if a potential configuration 
needs to reference that transport protocol, it is necessary to include 
it explicitly in a "tcap" attribute.
</quote>

> (and the paragraph after is also kind of twisted).
>
>   
Does the above help ? If not, can you elaborate on the problematic parts 
of the paragraph after (e.g. would it help if I define the notion of an 
"implicit transport capability" clearly ?)
> 	Basically, it is not very clear when the transport from the m-line
> 	should be repeated in the tcap line. There are examples in the document
> 	when it is not repeated, and examples where it is, even if the transport
> 	is not use in a t= pcfg attribute.
>
>   
It is needed in a tcap line if a potential configuration needs to use it 
as a transport capability.


> General:
> ========
>
> Can an attribute be repeated in an acap?
>   
Yes. You will in fact have to do this in some cases when using 
delete-attributes to get rid of other attributes.
> ----------------------------------------
>
>    For example, is the following "legal":
> 		
>       v=0 
>       o=- 25678 753849 IN IP4 192.0.2.1 
>       s=  
>       c=IN IP4 192.0.2.1 
>       t=0 0 
>       m=audio 53456 RTP/AVP 0 18  
>       a=crypto:1 AES_CM_128_HMAC_SHA1_80              
>          inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4  
>          FEC_ORDER=FEC_SRTP 
>       a=tcap:1 RTP/SAVP RTP/AVP 
>       a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80              
>          inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4  
>          FEC_ORDER=FEC_SRTP 
>       a=pcfg:1 t=1 a=1 
>
>   I would expect that "Yes", it would be legal, and the answerer would 
>   ignore the a=crypto:1 line because it doesn't mean anything for RTP/AVP.
>   Is this correct?
>   
 From an SCPCapNeg point of view, the above is entirely legal. From an 
RFC 4568 (sdescriptions) point of view, we are in a bit more of a grey 
area with the basic question being how an answer may process an SDP 
offer that contains a crypto attribute but vanilla RTP as the transport 
protocol. I suspect it will work, but the RFC does not address. In any 
case, this is orthogonal to the SDPCapneg discussion.

>
> Can we leave the crypto outside of an acap and use capability
> negotiation just to negotiate the transport?
> -----------------------------------------------------------
>
>   For example, is the following Offer legal:
>      
>       v=0 
>       o=- 25678 753849 IN IP4 192.0.2.1 
>       s=  
>       c=IN IP4 192.0.2.1 
>       t=0 0 
>       m=audio 53456 RTP/AVP 0 18  
>       a=crypto:1 AES_CM_128_HMAC_SHA1_80              
>          inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4  
>          FEC_ORDER=FEC_SRTP 
>       a=tcap:1 RTP/SAVP RTP/AVP 
>       a=pcfg:1 t=1
>
>   Again, I would expect "Yes", and the answerer supporting capability
>   negotiation and SDESCRIPTIONS would use the a=crypto line, but the
>   answerer not supporting capability negotiation or SDESCRIPTIONS
>   would ignore the a=crypto line. Is this correct?
>
>   (This particular format has some significant backward compatibility advantages with 
>   existing implementations).
>
>   
Same answer. It works fine from an SDPCapNeg point of view, but we are 
in the same grey area when it comes to sdescriptions with an offer that 
contains a crypto attribute with vanilla RTP. I suspect it will work, 
but it's not defined in RFC 4568.

-- Flemming


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