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

From: "Francois Audet" <[email-masked]>
Date: Wed, 14 Nov 2007 12:49:04 -0600

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Nov 2007 12:23:57 -0500

Thanks for the comments Francois - responses below

> on comments I've received from implementors wanting 
ok - I'll add that.
> Section 3.4.2 (p.19, second paragraph):
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 ?)
> 	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.

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

> negotiation just to negotiate the transport?
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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 Nov 2007 12:05:39 -0600

Thanks. Looking good.

See below. I've remove resolved "issues". We're almost done.

-----Original Message-----

From: Flemming Andreasen

> "implicit transport capability" clearly ?)

It's better. I think we still need to make it clear that when a transport protocol
is NOT used in a potential configuration, it may or may not be in the tcap.
That's what's confusing people. Perhaps something like:

<quote>
The ability to use a particular transport protocol is inherently implied 
by including it in the "m=" line, regardless of if it is repeated
in a "tcap" attribute or not. However, if a potential configuration 
needs to reference that transport protocol, it MUST be included 
explicitly in a "tcap" attribute.
</quote>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Nov 2007 13:26:00 -0500

> explicitly in a "tcap" attribute.
Looks good - I'll incorporate that.

-- Flemming