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

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

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.  
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(and the paragraph after is also kind of twisted).

	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.

General:
========

Can an attribute be repeated in an acap?
----------------------------------------

   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?

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic