Subject: [MMUSIC] Capability negotiation and best effort SRTP

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Jan 2007 13:49:19 +0000

Am I alone in this, or does anyone else share my concern that the design
team seems to be producing a rather complicated solution to capability
negotiation? Whilst this might satisfy a whole bunch of requirements, the
one important requirement that I and some others really needed a quick and
simple solution for - best effort SRTP - seems to be getting drowned. My
concerns are:
- the complexity of the solution means that it will not be a trivial RFC,
and therefore will require several iterations of review, perhaps spread over
the period of several IETF meetings;
- the complexity will make it more difficult to implement and test;
- the complexity may deter vendors from implementing it, with a strong risk
that it will not become the industry standard.

I would urge the design team to consider a quick and simple solution to best
effort SRTP that can be extended later to cover additional requirements. I
don't have a specific proposal, but that is partly because I haven't managed
to get my brain around the complexity of what is being proposed at present.

Defence shields in place!

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 22 Jan 2007 16:56:49 +0100

Hi John,

thanks for your initiative. 

Here are some thoughts on doing only best-effort negotiation based on
the current work on SDP capability negotiation 

Recap of the current discussion

==================================

Fleming's draft draft-ietf-mmusic-sdp-capability-negotiation-00.txt
defines a lot of new attributes.

The proposed new attributes are:

A new attribute ("a=cver") that lists the version of the SDP --> based
on telco result this is no longer needed

A new attribute ("a=csup") that lists the supported capabilities of the
negotiation framework

A new attribute ("a=creq") that lists the capabilities that are required

A new attribute ("a=cmed") that related to the media types/format as
capabilities 

A new attribute ("a=capar") that defines attribute parameter values
(e.g. a=crypto: ) as capabilities

A new attribute ("a=ctrpr") that defines how to list transport protocols
(e.g. RTP/AVP) as capabilities

A new attribute ("a=pcfg") that lists the potential configurations
supported

A new attribute ("a=acfg") to be used in an answer SDP for actually used
potential configurations

The a=capar: attribute can carry everything that was specified as SDP
attribute, ranging e.g. from a=crypto:, a=keymgmt: to the media related
a=fmtp: attribute. 

The combinations between mentiond attribute are indeed quite complex and
intransparent, at least at first sight. 

Bob Gilman's extended proposal

==================================

Bob proposes some modification on the definition of the original a=cmed
attribute (e.g. mime subtypes for media) and even more new attributes
related to media capabilities: 

"a=cenc:"   This line defines encoding attributes for the media mime
subtype

"a=cfmt:"   This line defines format parameters for the media mime
subtype

"a=cptmap:" This line defines the mapping payload type(s) and media mime
subtype

These new attributes would carry media related data that were supposed
to be carried in the a=capar: attribute in Fleming's original proposal.
Basically, I like this proposal since it distinguishes between
media-related and other attributes. However, it makes things even less
transparent and more complex.

Thinking how this can be simplified in order to match the currently
urgent need for standardised best effort SRTP I have the following
thoughts.

Application to best-effort SRTP from Fleming's draft

====================================================

Below are the essentials of the example offer from Fleming's draft for
best-effort SRTP 

m=audio 3456 RTP/AVP 0 18  

a=ctrpr:1 RTP/SAVP RTP/AVP 

a=capar:1 a=crypto: ...

a=pcfg: p=1 a=1 

a=pcfg: p=2  

The answer could look like 

m=audio 4567 RTP/SAVP 0 18  

a=crypto: ...

a=acfg: p=1 a=1 

Possible simplification

=======================

Based on this example one would just need to support the attributes

a=ctrpr: for RTP/AVP vs. RTP/SAVP

a=capar: for carrying a=crypto: (for sDescriptios) or a=keymgmt: (for
MIKEY)

a=pcfg: for offering the supported alternatives

a=acfg: for indicating the chosen alternative in the SDP answer

All the other attributes from above are more or less related to media
capabilities.

If we sort the capabilities according to their purpose we get:

1) attributes for basic negotiation and extensibility --> a=csup:,
a=creq:, a=pcfg: and a=acfg:

2) attribute for negotiation of the transport protocol --> a=ctrpr:
RTP/AVP RTP/SAVP RTP/AVPF RTP/SAVPF ...

3) attribute for negotiation of attributes a=capar: 

   Following Bob's proposal, only usage for SDP security descriptions or
MIKEY would currently remain here  

   (Unless the AVPF profiles require some attributes, needs to be
checked).

4) attributes for negotiation of media capabilities a=cmed:, a=cenc:,
a=cfmt:, a=cptmap: 

Now negotiation of transport profiles for SRTP vs RTP requires 1), 2)
and 3).

Negotiation of media needs 1) and 4) if Bob's proposal gets accepted.

The support both alternatives could be indicated in the a=csup:
attribute, e.g "a=csup: trpr" for the first case, "a=csup: med" for the
second case and "a=csup: med,trpr" for both together.

Negotiating these capabilities could be done based on the content of the
a=csup: attribute in SDP offer and SDP answer. 

Is this a considerable simplification?

Should the design team just focus on the best-effort part, since this is
currently a pressing issue?

I assume that a stable draft on best-effort-only could be achieved quite
quickly, whereas the media related work will surely take much more time
and could probably be done in a separate document defining an extension
to the framework.

Regards

Thomas

________________________________

	From: Elwell, John 
	Sent: Monday, January 22, 2007 2:49 PM
	To: [email-masked]
	Subject: [MMUSIC] Capability negotiation and best effort SRTP

	Am I alone in this, or does anyone else share my concern that
the design team seems to be producing a rather complicated solution to
capability negotiation? Whilst this might satisfy a whole bunch of
requirements, the one important requirement that I and some others
really needed a quick and simple solution for - best effort SRTP - seems
to be getting drowned. My concerns are:

	- the complexity of the solution means that it will not be a
trivial RFC, and therefore will require several iterations of review,
perhaps spread over the period of several IETF meetings;

	- the complexity will make it more difficult to implement and
test; 
	- the complexity may deter vendors from implementing it, with a
strong risk that it will not become the industry standard.

	I would urge the design team to consider a quick and simple
solution to best effort SRTP that can be extended later to cover
additional requirements. I don't have a specific proposal, but that is
partly because I haven't managed to get my brain around the complexity
of what is being proposed at present.

	John

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Jan 2007 08:40:32 +0000

On 22 Jan 2007, at 15:56, Stach, Thomas wrote:
...
> Below are the essentials of the example offer from Fleming's draft  
> for best-effort SRTP
>

Why do we need to specify the actual ("m=" line configuration) as a  
potential configuration? I'd like to signal:

a=ctrpr:1 RTP/SAVP
a=capar:1 a=crypto: ...
a=pcfg: p=1 a=1

as the offer, with an implied potential configuration 0 for RTP/AVP.  
That comes close to the simplicity of the best-effort-srtp draft for  
that use case, but with more extensibility.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 23 Jan 2007 10:47:53 +0200

Colin,
Your example is the same as the example in section 2.1 of the draft
Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2007 10:41 AM
> To: Stach, Thomas
> Cc: Elwell, John; [email-masked]
> Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Jan 2007 09:15:51 +0000

Roni,

I'm not sure which example you're refering to? The example I see in  
section 2.1 is significantly more complex.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 23 Jan 2007 10:16:30 +0100

> Sent: Tuesday, January 23, 2007 9:41 AM
> To: Stach, Thomas

Colin, that's fine with me. 
I just took the example from section 3.1. as a basis.
Regards
Thomas

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 23 Jan 2007 11:24:13 +0200

Colin,
What I meant is that this example is showing that you do not need to
list AVP in the ctrpr and if you do not have p= in the pcfg than it
means that you offer AVP
Roni

> Sent: Tuesday, January 23, 2007 11:16 AM
> To: Even, Roni
> Cc: Stach, Thomas; Elwell, John; [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Jan 2007 13:04:19 +0000

Okay - my main point is that showing how this can simply solve the  
best effort srtp example is important.

Colin

-- 
Colin Perkins
http://csperkins.org/