Subject: [MMUSIC] SDP Capability Negotiation & Media Capability extension

From: "Francois Audet" <[email-masked]>
Date: Fri, 2 Mar 2007 12:06:11 -0600

The Capability Negotiation document uses this format:

	a=creq: cap-v0

The Media Negotiation document uses this format:

	a=creq:v1

I'm assuming this is an error and it should really say a=creq: cap-v1?

Is this correct?

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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 2 Mar 2007 12:58:57 -0600

- What do we do with RFC 3407 and RFC 3388? Are we deprecating
them? 
	  If not, what are the interactions of this draft with them? I
think
	this 
	  needs to be covered. (Maybe it's as simple as saying MUST not
be used 
	  together: I don't know).
	  
	3407 (simcap) provides both more and less than the core SDP
capability negotiation framework. More in terms of covering things like
codecs, and min/max values. Less in terms of only providing
capabilities; there is nothing related to potential configurations and
their associated negotiation. Once you add the media capabilities
extensions to the mix, it's a different story though. Consequenlty, the
media capabilities draft says something about 3407, whereas this one
does not (there are no interactions between "pure" core SDP cap neg and
3407, just a bit of overlap). Let me know if you think that needs to be
called out (and/or something differently should be said).  

What I'm trying to understand is "is it legal to use Capability
Negotiation and RFC 3407 at the same time?", and if so, how does it
work. 
 
I think the answer is no, you should not. If you want to use Capability
negotiation, and you need to do media negotiation, then use
draft-ietf-mmusic-sdp-media-capablities. 
 
That is what I think needs to be spelled out (if I am understanding
correctly).

	 With respect to 3388 (grouping), I don't see any overlap or
interactions either (at least not with the core), however you can
clearly define grouping semantics and/or SDP Capability Negotiation
extensions that does lead to overlap. I'm not sure what to say about
that in the core document (or that we even should be saying anything
about it). Instead, we should be aware of this potential overlap and
interactions when (if) defining new extensions for either, and may need
to deal with them on a case-by-case basis. I'm pretty sure there is both
a need and use for both though (albeit, if we were to do it all over,
maybe not with all the currently defined grouping semantics).  

This is exactly what I was afraid. It is not giving me a warm fuzzy
feeling.
If you can not really explain who those 2 interacts or not, I don't
think anybody can.
 
I don't think we can "wing it" like this. If we don't know yet what the
interactions are, let's flag it as an open issue.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 2 Mar 2007 15:16:50 -0600

- Woulnd't the a=csup: cap-v0 be functionaly identical
to a:creq:
		cap-v0??? 
		  I think they would. If that's the case, I'd like
clarification of if 
		  a=csup: cap-v0 is legal or or not to include (I'd say
no). The fact
		that 
		  a-csup: cap-v0 is specifically spelled out in examples
on page 10 is 
		  very confusing because I can't figure out a use case.
If John's point 
		  about the whole cap-v0 being redundant and therefore
should be
		removed, 
		  then it would solve the problem. 

	Note that the example on page 10 is merely an isolated parameter
encoding example. Having said that, you could envision a "cap-v1"
extension at some point, and you may have a need to indicate that you
also support "cap-v1". Another (more immediate) example is an offer
requiring support an extensions the answerer does not have; the answer
will then not perform sdp capability negotiation, however the answer
will include the "csup" attribute with a list of supporting extensions -
"cap-v0" would be in that list. 

The point I'm trying to make is that a=csup: cap-v0 means exactly the
same thing as a=creq: cap-v0, since cap-v0 is mandatory if you support
this draft (or any other extensions).
 
(For cap-v1, the distinction makes sense, but not for cap-v0).
 
I'd like that the spec only use ONE format, say "a=creq: cap-v0 when
sending, and accept both in receiving. And all the examples in the draft
should use a=creq: cap-v0.

		- Here is another idea. Could we redefine cap-v0 to be
"best-effort
		transport 
		  negotiation"? All the examples in this document are
related to that
		(which 
		  I'm okay with). 

	I'm not sure what that means or more importantly what the draft
implications of doing that are. Can you elaborate ? 

		I'm a bit worried that the scope of cap-v0 is wider
		than that 
		  and since it is pretty vague what it would be used
for, it would be an
		undue 
		  requirement for people who need to support the only
concrete usecase
		we have 
		  today (i.e., best-effort SRTP/RTP?). 

	Please see the media capabilities extensions for something else
it will be used for. Use for other transport protocols (e.g. AVPF) is a
use-case as well. 

		Kind of a blank check. We could
		defer to 
		  cap-v1 for other applications. 

	If I understand correctly, I think this would amount to
essentially throwing all the generality we have built-in out, and focus
on solving the best-effort SRTP use case (plus maybe other transport
protocols) only. That's not the guidance we got from either the AD(s) or
the WG chairs, and it's also not what the requirements and hence current
scope (and solution) is. I hope you are not arguing against that
direction at this (late) point. We've tried pretty hard to focus on the
core part that is of importance to the best-effort SRTP (and transport
protocol in general) folks, while at the same time making it somewhat
general and extensible so that people with additional requirements can
use it as well (by way of defining extensions). In the process of doing
that, there is no doubt a bit more implementation work than a
"best-effort SRTP" only solution would incur, however we normally try
and come up with somewhat general and reusable specifications as opposed
to point-specific solutions. Again, we've tried pretty hard to make this
delta as small as possible (witness the exclusion of media capabilities
for example) while still making it generally usable. If you have
specific suggestions for how we can better do that (anpreferably have
them specified before and agreed to in Prague), then please let us know.

No, that's not really what I'm saying.
 
I'm OK with SRTP and AVPF.
 
I also understand that if I use cap-v1 I can support the stuff in the
media capabilties draft.
 
What is not clear to me is how much I am singing up for by claiming
support for cap-v0. I know there is the SRTP/AVPF stuff included in
Capability Negotiation. So that's ok. I know that it does not include
the cap-v1 in media negotation. But I don't understand the hidden
requirements in-between.
 
For example, couldn't somebody use cap-v0 to negotiate other stuff, like
different ptimes, or any of the other attributes? What about recvonly
and sendrecv at the same time? Different languages, framerate, fmtp?
 
If I say cap-v0, am I exposing myself to that? That's what is not clear
to me. Maybe it's just me...

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 2 Mar 2007 15:30:09 -0600

The core framework does not enable you to express any
constraints on inter-media description configuration selection (too
complicated). You can specify session-level MIKEY by use of a
session-level key-mgmt attribute capability and media-level
sdescriptions by use of a media-level crypto-attribute for both the
audio and the video stream. You will then have a potential configuration
attribute for each media description listing MIKEY and sdescriptions as
alternatives. However, the solution does not have the expressive power
to require selection of the same mechanism by both media descriptions,
or alternative mechanisms. Do you have a use case in mind for this ? Is
this something you see as important for the core negotiation framework ?

		- Section 4.1: 
		
			- I find the second Offer/Answer in the diagram
to be
		distracting. 
			  I'd rather it would be omitted, and the text
on page 33
		describing the 
			  possibility of having a second offer/answer to
"lock down" the
		exchange 
			  to describe it more as an optional procedure.
I.e., it should
		be more 
			  clear that this is really just OPTIONAL (in
fact, I think this
		whole 
			  second offer/answer thing should be in a 4.1.1
subsection,
		clearly 
			  labelled as an optional enhancement). 

	That probably requires further discussion. It is currently at
RECOMMENDED/SHOULD strength (specified in Section 3.5.3), whereas ICE
has similar functionality at MUST strength (ice-13, Section 8). Can you
elaborate on why you want this to be at OPTIONAL/MAY strength ?  

It just seems orthogonal to this draft. 
 
If ICE is used at the same time, then yes, it makes sense. If not
however, I'm not convinced at all that we should RECOMMEND this. It
seems to me that this procedure is useful only if there is a middleblox.
 
I doubt that anybody would want to do the second Offer/Answer in an
Enteprise for example, where there is no middleboxes, as it will
significantly add to the load of the proxies, whithout any benefit.
 
It makes perfect sense to describe this process in ICE (which is all
about Middleboxes), but it doesn't make any sense to me in this
document.
 
If you word it to say that if Middleboxes are present, then it is
RECOMMENDED (and refer to ICE for the precedent), I'm OK with it. But
for the generic non-middlebox scenarios, it really needs to be a MAY.

---

From: "Robert R. Gilman" <[email-masked]>
Date: Fri, 02 Mar 2007 16:27:36 -0700

Francois-
As things are changing, the media negotiation draft hasn't kept up with the
cap negotiation draft (which we all consider more time critical).  At the
last team meeting, I believe we decided that one didn't need the a=creq:
line if only cap-v0 elements were used, since the presence of any of the
attributes implied support and need for cap-v0.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 2 Mar 2007 18:07:10 -0600

Heuh????

My point is that it should say a=creq: cap-v1 instead of a=creq:v1.
                               --------------            ---------

> -----Original Message-----
> From: Robert R. Gilman [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 15:28
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]; Flemming Andreasen; [email-masked]
> Subject: Re: SDP Capability Negotiation & Media Capability extension
> 
> Francois-
> As things are changing, the media negotiation draft hasn't 
> kept up with the cap negotiation draft (which we all consider 
> more time critical).  At the last team meeting, I believe we 
> decided that one didn't need the a=creq:
> line if only cap-v0 elements were used, since the presence of 
> any of the attributes implied support and need for cap-v0.
> -Bob

---

From: "Robert R. Gilman" <[email-masked]>
Date: Fri, 02 Mar 2007 17:44:06 -0700

Of course.

Francois Audet wrote:
>>>I'm assuming this is an error and it should really say 
>>
>>a=creq: cap-v1?
>>
>>>Is this correct?
>>>
>>
>>
>>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 04 Mar 2007 14:07:22 -0500

Note that "a=creq: cap-v0" will no longer be required in -05.

-- Flemming

Robert R. Gilman wrote:
>>> From: Robert R. Gilman [mailto:[email-masked]] Sent: Friday, March 
>>> 02, 2007 15:28
>>> As things are changing, the media negotiation draft hasn't kept up 
>>> with the cap negotiation draft (which we all consider more time 
>>> critical).  At the last team meeting, I believe we decided that one 
>>> didn't need the a=creq:
>>> line if only cap-v0 elements were used, since the presence of any of 
>>> the attributes implied support and need for cap-v0.
>>> -Bob

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 04 Mar 2007 14:26:09 -0500

Francois Audet wrote:
>  
>
>     - What do we do with RFC 3407 and RFC 3388? Are we deprecating them?
>       If not, what are the interactions of this draft with them? I think
>     this
>       needs to be covered. (Maybe it's as simple as saying MUST not be
>     used
>       together: I don't know).
>      
>     capability negotiation framework. More in terms of covering things
>     like codecs, and min/max values. Less in terms of only providing
>     capabilities; there is nothing related to potential configurations
>     and their associated negotiation. Once you add the media
>     capabilities extensions to the mix, it's a different story though.
>     Consequenlty, the media capabilities draft says something about
>     3407, whereas this one does not (there are no interactions between
>     "pure" core SDP cap neg and 3407, just a bit of overlap). Let me
>     know if you think that needs to be called out (and/or something
>     differently should be said).  
>
> Negotiation and RFC 3407 at the same time?", and if so, how does it work.
>  
> I think the answer is no, you should not. If you want to use 
> Capability negotiation, and you need to do media negotiation, then use 
There will be a section on the relationship to 3407 in -05.

>     clearly define grouping semantics and/or SDP Capability
>     Negotiation extensions that does lead to overlap. I'm not sure
>     what to say about that in the core document (or that we even
>     should be saying anything about it). Instead, we should be aware
>     of this potential overlap and interactions when (if) defining new
>     extensions for either, and may need to deal with them on a
>     case-by-case basis. I'm pretty sure there is both a need and use
>     for both though (albeit, if we were to do it all over, maybe not
>     with all the currently defined grouping semantics).  
>
> I don't think we can "wing it" like this. If we don't know yet what 
> the interactions are, let's flag it as an open issue.
>
The design team discussed the 3388 relationship on our last call, and 
the team members agreed that they didn't see any 3388 interactions with 
the core capabilities document at this point. I've taken another look at 
the currently registered 3388 grouping semantics, and I still don't see 
any interaction. Clearly, you can define extensions to either of these 
frameworks that will duplicate functionality provided by the other. For 
example, earlier versions had transport addresses as capabilities, which 
would overlap with the ANAT grouping semantics. Even so, there wouldn't 
have been any interactions per se - just duplicate functionality (ICE 
however is a different story). Based on this, I'm not sure what we would 
say, so I have left it out for now. If you still think there is an 
issue, and if you can perhaps provide an example, we can take another 
look at it.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 04 Mar 2007 14:41:46 -0500

Francois Audet wrote:
>  
>
>>     - Woulnd't the a=csup: cap-v0 be functionaly identical to a:creq:
>>     cap-v0??? 
>>       I think they would. If that's the case, I'd like clarification of if 
>>       a=csup: cap-v0 is legal or or not to include (I'd say no). The fact
>>     that 
>>       a-csup: cap-v0 is specifically spelled out in examples on page 10 is 
>>       very confusing because I can't figure out a use case. If John's point 
>>       about the whole cap-v0 being redundant and therefore should be
>>     removed, 
>     extension at some point, and you may have a need to indicate that
>     you also support "cap-v1". Another (more immediate) example is an
>     offer requiring support an extensions the answerer does not have;
>     the answer will then not perform sdp capability negotiation,
>     however the answer will include the "csup" attribute with a list
>     of supporting extensions - "cap-v0" would be in that list. 
>
> The point I'm trying to make is that a=*csup*: cap-v0 means exactly 
> the same thing as a=*creq*: cap-v0, since cap-v0 is mandatory if you 
> support this draft (or any other extensions).
>  
> sending, and accept both in receiving. And all the examples in the 
> draft should use a=creq: cap-v0.
>
Note that the updated draft will no longer require use of 
"a=creq:cap-v0" in an offer - it will be implied by the presence of a 
pcfg attribute.

>  
>
>>     - Here is another idea. Could we redefine cap-v0 to be "best-effort
>>     transport 
>>       negotiation"? All the examples in this document are related to that
>>     (which 
>>       I'm okay with). 
>>       and since it is pretty vague what it would be used for, it would be an
>>     undue 
>>       requirement for people who need to support the only concrete usecase
>>     we have 
>     Please see the media capabilities extensions for something else it
>     will be used for. Use for other transport protocols (e.g. AVPF) is
>     a use-case as well.
>     essentially throwing all the generality we have built-in out, and
>     focus on solving the best-effort SRTP use case (plus maybe other
>     transport protocols) only. That's not the guidance we got from
>     either the AD(s) or the WG chairs, and it's also not what the
>     requirements and hence current scope (and solution) is. I hope you
>     are not arguing against that direction at this (late) point. We've
>     tried pretty hard to focus on the core part that is of importance
>     to the best-effort SRTP (and transport protocol in general) folks,
>     while at the same time making it somewhat general and extensible
>     so that people with additional requirements can use it as well (by
>     way of defining extensions). In the process of doing that, there
>     is no doubt a bit more implementation work than a "best-effort
>     SRTP" only solution would incur, however we normally try and come
>     up with somewhat general and reusable specifications as opposed to
>     point-specific solutions. Again, we've tried pretty hard to make
>     this delta as small as possible (witness the exclusion of media
>     capabilities for example) while still making it generally usable.
>     If you have specific suggestions for how we can better do that
>     (anpreferably have them specified before and agreed to in Prague),
>     then please let us know. 
>      
>
> support for cap-v0.
You are signing up for the general negotiation framework provided. Since 
it can be used with any transport protocol value and any attribute name 
and value as well, you are signing yourself up for negotiation of such 
parameters (you are of course free to just not negotiate all of that 
stuff and just default to the actual configuration). You are also 
signing up for the part about required extensions, and ensure you 
process capability negotiation in accordance with it (again, you can 
just choose not to support such extensions and be done with it).

> I know there is the SRTP/AVPF stuff included in Capability 
> Negotiation. So that's ok. I know that it does not include the cap-v1 
> in media negotation. But I don't understand the hidden requirements 
> in-between.
>  
> For example, couldn't somebody use cap-v0 to negotiate other stuff, 
> like different ptimes, or any of the other attributes? What about 
> recvonly and sendrecv at the same time? Different languages, 
> framerate, fmtp?
>  
> If I say cap-v0, am I exposing myself to that?
Yes. One thing I'd like to point out however is that the capability 
negotiation process is by and large constructed as a syntactically 
driven process where you simply add, remove, and/or delete strings in 
the offered SDP, and then move on to the normal O/A procedures using one 
of the "resulting SDPs" as the actual offer. Thus, there is not a lot of 
added semantics processing here (which I consider to be the hard part), 
and in particular, we have aimed to try and avoid having ambiguity in 
the "resulting SDPs", which in turn would require more intelligence to 
deal with (for example, presence of multiple conflicting attributes, or 
attributes that don't make sense given what is being negotiated). You 
will see a few changes in -05 to deal with that. On the surface, they'll 
probably look more complicated, but once you go through them, I think 
you will find that they actually make it less complicated by having very 
specific syntactic replacement rules in place to avoid any of these 
potential ambiguities, which is where all your real implementation and 
interoperability problems begin IMO.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 04 Mar 2007 14:48:58 -0500

Francois Audet wrote:
>  
>
>     The core framework does not enable you to express any constraints
>     on inter-media description configuration selection (too
>     sdescriptions by use of a media-level crypto-attribute for both
>     the audio and the video stream. You will then have a potential
>     configuration attribute for each media description listing MIKEY
>     and sdescriptions as alternatives. However, the solution does not
>     have the expressive power to require selection of the same
>     mechanism by both media descriptions, or alternative mechanisms.
>     Do you have a use case in mind for this ? Is this something you
>     see as important for the core negotiation framework ?
>
>>     - Section 4.1: 
>>
>>     	- I find the second Offer/Answer in the diagram to be
>>     distracting. 
>>     	  I'd rather it would be omitted, and the text on page 33
>>     describing the 
>>     	  possibility of having a second offer/answer to "lock down" the
>>     exchange 
>>     	  to describe it more as an optional procedure. I.e., it should
>>     be more 
>>     	  clear that this is really just OPTIONAL (in fact, I think this
>>     whole 
>>     	  second offer/answer thing should be in a 4.1.1 subsection,
>>     clearly 
>     RECOMMENDED/SHOULD strength (specified in Section 3.5.3), whereas
>     ICE has similar functionality at MUST strength (ice-13, Section
>     8). Can you elaborate on why you want this to be at OPTIONAL/MAY
>     strength ?  
>
> Enteprise for example, where there is no middleboxes, as it 
> will significantly add to the load of the proxies, whithout any benefit.
>  
> about Middleboxes), but it doesn't make any sense to me in this document.
>  
OK - the design team discussed this on our last call, and there were no 
strong opinions on whether it should be RECOMMENDED or MAY (there was 
general consensus that it should not be a MUST). I think your suggested 
update strikes a good balance between the two, so I have incorporated it 
in the upcoming -05

Thanks

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Mar 2007 11:28:36 -0600

I'm good with the resolution of this point.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Sunday, March 04, 2007 11:26
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]
	Subject: Re: SDP Capability Negotiation RFC 3407 & RFC 3388

	Francois Audet wrote: 

			- What do we do with RFC 3407 and RFC 3388? Are
we deprecating them? 
			  If not, what are the interactions of this
draft with them? I think
			this 
			  needs to be covered. (Maybe it's as simple as
saying MUST not be used 
			  together: I don't know).
			  
			3407 (simcap) provides both more and less than
the core SDP capability negotiation framework. More in terms of covering
things like codecs, and min/max values. Less in terms of only providing
capabilities; there is nothing related to potential configurations and
their associated negotiation. Once you add the media capabilities
extensions to the mix, it's a different story though. Consequenlty, the
media capabilities draft says something about 3407, whereas this one
does not (there are no interactions between "pure" core SDP cap neg and
3407, just a bit of overlap). Let me know if you think that needs to be
called out (and/or something differently should be said).  

		What I'm trying to understand is "is it legal to use
Capability Negotiation and RFC 3407 at the same time?", and if so, how
does it work. 
		 
		I think the answer is no, you should not. If you want to
use Capability negotiation, and you need to do media negotiation, then
use draft-ietf-mmusic-sdp-media-capablities. 
		 
		That is what I think needs to be spelled out (if I am
understanding correctly).

			 With respect to 3388 (grouping), I don't see
any overlap or interactions either (at least not with the core), however
you can clearly define grouping semantics and/or SDP Capability
Negotiation extensions that does lead to overlap. I'm not sure what to
say about that in the core document (or that we even should be saying
anything about it). Instead, we should be aware of this potential
overlap and interactions when (if) defining new extensions for either,
and may need to deal with them on a case-by-case basis. I'm pretty sure
there is both a need and use for both though (albeit, if we were to do
it all over, maybe not with all the currently defined grouping
semantics).  

		This is exactly what I was afraid. It is not giving me a
warm fuzzy feeling.
		If you can not really explain who those 2 interacts or
not, I don't think anybody can.
		 
		I don't think we can "wing it" like this. If we don't
know yet what the interactions are, let's flag it as an open issue.

	The design team discussed the 3388 relationship on our last
call, and the team members agreed that they didn't see any 3388
interactions with the core capabilities document at this point. I've
taken another look at the currently registered 3388 grouping semantics,
and I still don't see any interaction. Clearly, you can define
extensions to either of these frameworks that will duplicate
functionality provided by the other. For example, earlier versions had
transport addresses as capabilities, which would overlap with the ANAT
grouping semantics. Even so, there wouldn't have been any interactions
per se - just duplicate functionality (ICE however is a different
story). Based on this, I'm not sure what we would say, so I have left it
out for now. If you still think there is an issue, and if you can
perhaps provide an example, we can take another look at it. 
	
	Thanks
	
	-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Mar 2007 11:32:21 -0600

I'm ok for point about cap-v0.
 
For the what does it means to support the draft, I'll wait to see the
-05 draft. But from what you are describing below, it looks like you are
on the right track.

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Sunday, March 04, 2007 11:42
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]
	Subject: Re: SDP Capability Negotiation: csup: cap-v0 vs creq:
cap-v0

	Francois Audet wrote: 

				- Woulnd't the a=csup: cap-v0 be
functionaly identical to a:creq:
				cap-v0??? 
				  I think they would. If that's the
case, I'd like clarification of if 
				  a=csup: cap-v0 is legal or or not to
include (I'd say no). The fact
				that 
				  a-csup: cap-v0 is specifically spelled
out in examples on page 10 is 
				  very confusing because I can't figure
out a use case. If John's point 
				  about the whole cap-v0 being redundant
and therefore should be
				removed, 
				  then it would solve the problem. 

			Note that the example on page 10 is merely an
isolated parameter encoding example. Having said that, you could
envision a "cap-v1" extension at some point, and you may have a need to
indicate that you also support "cap-v1". Another (more immediate)
example is an offer requiring support an extensions the answerer does
not have; the answer will then not perform sdp capability negotiation,
however the answer will include the "csup" attribute with a list of
supporting extensions - "cap-v0" would be in that list. 

		The point I'm trying to make is that a=csup: cap-v0
means exactly the same thing as a=creq: cap-v0, since cap-v0 is
mandatory if you support this draft (or any other extensions).
		 
		(For cap-v1, the distinction makes sense, but not for
cap-v0).
		 
		I'd like that the spec only use ONE format, say "a=creq:
cap-v0 when sending, and accept both in receiving. And all the examples
in the draft should use a=creq: cap-v0.

		 

				- Here is another idea. Could we
redefine cap-v0 to be "best-effort
				transport 
				  negotiation"? All the examples in this
document are related to that
				(which 
				  I'm okay with). 

			I'm not sure what that means or more importantly
what the draft implications of doing that are. Can you elaborate ? 

				I'm a bit worried that the scope of
cap-v0 is wider
				than that 
				  and since it is pretty vague what it
would be used for, it would be an
				undue 
				  requirement for people who need to
support the only concrete usecase
				we have 
				  today (i.e., best-effort SRTP/RTP?). 

			Please see the media capabilities extensions for
something else it will be used for. Use for other transport protocols
(e.g. AVPF) is a use-case as well. 

			If I understand correctly, I think this would
amount to essentially throwing all the generality we have built-in out,
and focus on solving the best-effort SRTP use case (plus maybe other
transport protocols) only. That's not the guidance we got from either
the AD(s) or the WG chairs, and it's also not what the requirements and
hence current scope (and solution) is. I hope you are not arguing
against that direction at this (late) point. We've tried pretty hard to
focus on the core part that is of importance to the best-effort SRTP
(and transport protocol in general) folks, while at the same time making
it somewhat general and extensible so that people with additional
requirements can use it as well (by way of defining extensions). In the
process of doing that, there is no doubt a bit more implementation work
than a "best-effort SRTP" only solution would incur, however we normally
try and come up with somewhat general and reusable specifications as
opposed to point-specific solutions. Again, we've tried pretty hard to
make this delta as small as possible (witness the exclusion of media
capabilities for example) while still making it generally usable. If you
have specific suggestions for how we can better do that (anpreferably
have them specified before and agreed to in Prague), then please let us
know. 

		 
		I also understand that if I use cap-v1 I can support the
stuff in the media capabilties draft.
		 
		What is not clear to me is how much I am singing up for
by claiming support for cap-v0. 

	You are signing up for the general negotiation framework
provided. Since it can be used with any transport protocol value and any
attribute name and value as well, you are signing yourself up for
negotiation of such parameters (you are of course free to just not
negotiate all of that stuff and just default to the actual
configuration). You are also signing up for the part about required
extensions, and ensure you process capability negotiation in accordance
with it (again, you can just choose not to support such extensions and
be done with it). 

		I know there is the SRTP/AVPF stuff included in
Capability Negotiation. So that's ok. I know that it does not include
the cap-v1 in media negotation. But I don't understand the hidden
requirements in-between.
		 
		For example, couldn't somebody use cap-v0 to negotiate
other stuff, like different ptimes, or any of the other attributes? What
about recvonly and sendrecv at the same time? Different languages,
framerate, fmtp?

	Yes. One thing I'd like to point out however is that the
capability negotiation process is by and large constructed as a
syntactically driven process where you simply add, remove, and/or delete
strings in the offered SDP, and then move on to the normal O/A
procedures using one of the "resulting SDPs" as the actual offer. Thus,
there is not a lot of added semantics processing here (which I consider
to be the hard part), and in particular, we have aimed to try and avoid
having ambiguity in the "resulting SDPs", which in turn would require
more intelligence to deal with (for example, presence of multiple
conflicting attributes, or attributes that don't make sense given what
is being negotiated). You will see a few changes in -05 to deal with
that. On the surface, they'll probably look more complicated, but once
you go through them, I think you will find that they actually make it
less complicated by having very specific syntactic replacement rules in
place to avoid any of these potential ambiguities, which is where all
your real implementation and interoperability problems begin IMO. 
	
	-- Flemming