Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-03)

From: Flemming Andreasen <[email-masked]>
Date: Mon, 19 Feb 2007 22:00:04 -0500

Greetings

I have just submitted an updated solution document as 
draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which you can 
retrieve from 
http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-03.txt 
until it appears in the archives.

The list of changes (from Section 9.1):
o Base option tag name changed from "v0" to "cap-v0".
o Added new section on extension capability attributes
o Firmed up offer/answer procedures.
o Added security considerations
o Added IANA considerations

Thanks

-- Flemming

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Feb 2007 08:28:58 +0000

Flemming,

On 20 Feb 2007, at 03:00, Flemming Andreasen wrote:
> I have just submitted an updated solution document as draft-ietf- 
> mmusic-sdp-capability-negotiation-03.txt, which you can retrieve  
> from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp- 
> capability-negotiation-03.txt until it appears in the archives.
>

This is looking good, especially with the clarifications to the offer/ 
answer procedures.

I would like to highlight one design choice on the list: when  
attributes are included in "a=acap:" lines of a potential  
configuration, those attributes are added to the set in the actual  
configuration during the offer/answer exchange. This may sometimes  
result in meaningless attributes, as is noted in Section 3.5.2 (half  
way down page 25). An alternative is for the attributes in the  
"a=acap:" lines of a potential configuration to replace those in the  
actual configuration if that potential configuration is accepted.  
This removes the potential for meaningless attributes, and makes  
negotiation simpler, at the cost of needing to duplicate attributes  
that are common to the actual and potential configurations.

I'd like to hear opinions on this choice. I have a slight preference  
for changing the draft so attributes in potential configurations  
replace those in the actual during the negotiation phase, since that  
seems conceptually simpler. I'm curious whether people believe it  
would introduce too much overhead though. Comments?

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

---

From: Matt Lepinski <[email-masked]>
Date: Wed, 21 Feb 2007 11:16:00 -0500

I appreciate Colin's desire for conceptual simplicity, and as long as 
we're only talking about media-level attributes, I agree with Colin's 
proposed change. However, I don't see a good way to integrate Colin's 
change with the semantics of session-level attributes. Perhaps someone 
can propose a good way for "attribute replacement" to work at the 
session level? However, in the absence of such a proposal, my preference 
is for keeping the document as it is.

To help clarify the point in question, let me provide a couple of 
examples to clarify the point in question. (I'm the kind of person who 
has trouble thinking clearly without examples).

Here is an offer for "Best-Effort SRTP" as the document is currently 
written:

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 1
a=creq: cap_v0
m=audio 3456 RTP/AVP 18
a=fmt:18 annexb:no
a=tcap:1 RTP/SAVP RTP/AVP
a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA...
a=pcfg:1 t=1 a=1

Notice that if the potential configuration (using SAVP) is chosen then 
the crypto attribute is "added" to the set of media stream attributes. 
(That is, the a=fmt attribute remains regardless of which configuration 
is chosen).

Colin has proposed that attributes in potential configurations "replace" 
the existing media stream attributes. Therefore, one would re-write the 
above example as follows:

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 2
a=creq: cap_v0
m=audio 3456 RTP/AVP 18
a=fmt:18 annexb:no
a=tcap:1 RTP/SAVP RTP/AVP
a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA...
a=acap:2 a=fmt:18 annexb:no
a=pcfg:1 t=1 a=1,2

In this particular case, the first SDP offer is perhaps a bit simpler 
than the second SDP offer. However, I would agree with Colin that in 
cases repeating session-level attributes adds only a small amount of 
overhead.

Now consider an example where the offerer perfers unencrypted media, but 
is willing to encrypt if the answerer requires media privacy.

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 3
a=creq: cap_v0
m=audio 3456 RTP/SAVP 18
a=fmt:18 annexb:no
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA...
a=tcap:1 RTP/AVP RTP/SAVP
a=pcfg:1 t=1

In this case, if the answerer accepts the potential configuration, the 
answerer must deal with the fact that there is a "meaningless" a=crypto 
attribute being offered for an AVP media stream. Certainly, this is 
something that implementations can deal with, but I agree with Colin 
that the following offer is more clear:

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 4
a=creq: cap_v0
m=audio 3456 RTP/SAVP 18
a=fmt:18 annexb:no
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AAA...
a=tcap:1 RTP/AVP RTP/SAVP
a=acap:1 a=fmt:18 annexb:no
a=pcfg:1 t=1, a=1

This brings us to session attributes. Following the "additive" 
paradaigm, each media-level potential configuration is able to "add" 
potential attributes at the session-level as well as the media level. 
That is, in the following example:

v=0
o=jdoe 12345 67890 IN IP4 10.0.0.1
c=IN IP4 10.0.0.2
t=0 0
s=Example 5
a=creq: cap_v0
a=recvonly
a=acap:1 a=key-mgmt:mikey ABAC...
m=audio 3456 RTP/AVP 18
a=tcap:1 RTP/SAVP RTP/AVP
a=pcfg:1 t=1, a=1

The a=recvonly attribute is always active and the a=key-mgmt attribute 
only if the potential configuration is selected.

First, I find it unappealing to have potential configurations "add" 
attributes at the session level and "replace" attributes at the 
media-level. (I think this loses any conceptual simplicity that would be 
gained by "replacement" at the media-level.). Second, I'm not sure how 
define a clear semantics for "replacement" at the session-level.

That is, let's say I select a potential configuration for media stream 
#1, and the "standard" configuration for media stream #2. Does selecting 
a potential configuration for media stream 1 replace (eliminate) the 
existing session level attributes? If so, are there cases where this 
would have bad interactions with media stream #2, whose "standard" 
configuration may be expecting the presence of certain session-level 
attributes?

Just my two cents,
- Matt Lepinski :->

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Thu, 22 Feb 2007 08:45:14 +0100

Hi

If I understand things correctly (snippet below from section 3.5.3),
there will be two offer/answers during call setup. The second
offer/answer in order to ensure that "intermediaries" understand. This
might have some issues regarding call setup times e.g in wireless access
where service radio bearers might have a limited bitrate, currently I
cannot tell much this might mean in extra call setup time.

One possible solution is that it may be possible that the call could be
setup already after the first offer/answer ?, this probably assumes that
possible radio resource management understands the first offer/answer.

Regards
Ingemar

============================== 
   If the offer/answer exchange was succesful, and if the answerer 
   selected one of the potential configurations from the offer as the 
   actual configuration, then the offerer SHOULD perform another 
   offer/answer exchange: The new offer should contain the selected 
   potential configuration as the actual configuration, i.e. with the 
   actual configuration used in the "m=" line and any other relevant 
   attributes. This second offer/answer exchange will not modify the 
   session in any way, however it will help intermediaries that look at 
   the SDP, but do not understand or support the capability negotiation 
   extensions, to understand the details of the media stream(s) that 
   were actually negotiated.  
============================== 

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: den 20 februari 2007 04:00
> To: mmusic
> Subject: [MMUSIC] SDP Capability Negotiation: Updated 
> solution document (-03)
> 
> Greetings
> 
> draft-ietf-mmusic-sdp-capability-negotiation-03.txt, which 
> you can retrieve from 
> o Added new section on extension capability attributes o 
> Firmed up offer/answer procedures.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Feb 2007 07:09:15 -0500

> possible radio resource management understands the first offer/answer.
That's correct. As far as the offerer and the answerer is concerned, all 
media stream negotiation is complete after the first exchange. The 
second exchange is merely done as a courtesy to any intermediaries that 
may not understand what was actually going on. If those intermediaries 
do understand it (and have a need to a know in the first place), then 
the second exchange is effectively a no-op for all parties.

-- Flemming

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Fri, 23 Feb 2007 15:01:27 +0100

Hi
 
I checked out a little and _very_ rougly speaking the call setup time
will be increased by ~1.0 second due to the extra offer/answer, this of
course depends heaviliy on the achievable compression ratio of SigComp
and the bitrate of the signaling radio bearer, the figures assume HSPA
access.
 
Ingemar

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: den 22 februari 2007 13:09
	To: Ingemar Johansson S (LU/EAB)
	Cc: mmusic
	Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated
solution document (-03)

		Hi
		
		If I understand things correctly (snippet below from
section 3.5.3),
		there will be two offer/answers during call setup. The
second
		offer/answer in order to ensure that "intermediaries"
understand. This
		might have some issues regarding call setup times e.g in
wireless access
		where service radio bearers might have a limited
bitrate, currently I
		cannot tell much this might mean in extra call setup
time.
		
		One possible solution is that it may be possible that
the call could be
		setup already after the first offer/answer ?, this
probably assumes that
		possible radio resource management understands the first
offer/answer.

	That's correct. As far as the offerer and the answerer is
concerned, all media stream negotiation is complete after the first
exchange. The second exchange is merely done as a courtesy to any
intermediaries that may not understand what was actually going on. If
those intermediaries do understand it (and have a need to a know in the
first place), then the second exchange is effectively a no-op for all
parties.
	
	-- Flemming 

		Regards
		Ingemar
		
		============================== 
		   If the offer/answer exchange was succesful, and if
the answerer 
		   selected one of the potential configurations from the
offer as the 
		   actual configuration, then the offerer SHOULD perform
another 
		   offer/answer exchange: The new offer should contain
the selected 
		   potential configuration as the actual configuration,
i.e. with the 
		   actual configuration used in the "m=" line and any
other relevant 
		   attributes. This second offer/answer exchange will
not modify the 
		   session in any way, however it will help
intermediaries that look at 
		   the SDP, but do not understand or support the
capability negotiation 
		   extensions, to understand the details of the media
stream(s) that 
		   were actually negotiated.  
		============================== 

			-----Original Message-----
			From: Flemming Andreasen
[mailto:[email-masked]] 
			Sent: den 20 februari 2007 04:00
			To: mmusic
			Subject: [MMUSIC] SDP Capability Negotiation:
Updated 
			solution document (-03)
			
			Greetings
			
			I have just submitted an updated solution
document as 

http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capa
			bility-negotiation-03.txt
			until it appears in the archives.
			
			The list of changes (from Section 9.1):
			o Base option tag name changed from "v0" to
"cap-v0".
			o Added new section on extension capability
attributes o 
			Firmed up offer/answer procedures.
			o Added security considerations
			o Added IANA considerations

			Thanks
			
			-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 23 Feb 2007 09:31:03 -0500

Ingemar Johansson S (LU/EAB) wrote:
> will be increased by ~1.0 second due to the extra offer/answer, this 
> of course depends heaviliy on the achievable compression ratio of 
> SigComp and the bitrate of the signaling radio bearer, the figures 
> assume HSPA access.
Thanks. To put that in perspective, what is the approximate call setup 
time without the extra offer/answer (and does it use preconditions, 
resource reservation, etc.) ?

-- Flemming
>  
> Ingemar
>  
>
>     ------------------------------------------------------------------------
>     *From:* Flemming Andreasen [mailto:[email-masked]]
>     *Sent:* den 22 februari 2007 13:09
>     *To:* Ingemar Johansson S (LU/EAB)
>     *Cc:* mmusic
>     *Subject:* Re: [MMUSIC] SDP Capability Negotiation: Updated
>     solution document (-03)
>
>
>
>     concerned, all media stream negotiation is complete after the
>     first exchange. The second exchange is merely done as a courtesy
>     to any intermediaries that may not understand what was actually
>     going on. If those intermediaries do understand it (and have a
>     need to a know in the first place), then the second exchange is
>     effectively a no-op for all parties.
>
>     -- Flemming
>
>>     Regards
>>     Ingemar
>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Feb 2007 11:53:19 -0800

But there is only this additional delay if the middleboxes don't
understand the first offer/answer, exchange, right?  The solution
seems to be upgrade the software in them so they understand the
new SDP Capability Negotiation in the first exchange.  

The extra o/a is just to provide some accommodation during the
transition to everything understanding SDP Cap. Neg.  

-d

> From: Ingemar Johansson S (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Friday, February 23, 2007 6:01 AM
> To: Flemming Andreasen
> Cc: mmusic
> Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated 
> solution document(-03)
> 
> Hi
>  
> I checked out a little and _very_ rougly speaking the call 
> setup time will be increased by ~1.0 second due to the extra 
> offer/answer, this of course depends heaviliy on the 
> achievable compression ratio of SigComp and the bitrate of 
> the signaling radio bearer, the figures assume HSPA access.
>  
> Ingemar
>  
> 
> 
> 	Subject: Re: [MMUSIC] SDP Capability Negotiation: 
> Updated solution document (-03)
> 	
> 	
> 
> 
> 	That's correct. As far as the offerer and the answerer 
> is concerned, all media stream negotiation is complete after 
> the first exchange. The second exchange is merely done as a 
> courtesy to any intermediaries that may not understand what 
> was actually going on. If those intermediaries do understand 
> it (and have a need to a know in the first place), then the 
> second exchange is effectively a no-op for all parties.
> 	
> 	-- Flemming 
> 	
> 	
> 
> 		Regards
> 		Ingemar
>

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Feb 2007 12:28:19 -0500

Colin Perkins wrote:
> This is looking good, especially with the clarifications to the 
> offer/answer procedures.
>
> actual configuration if that potential configuration is accepted. This 
> removes the potential for meaningless attributes, and makes 
We had a brief thread titled "How big can SDP get" in the May-June 2006 
timeframe. Magnus constructed a 10k SDP by using a large number of 
attribute lines. While the purpose of that example was to purposely 
generate a large SDP, it nevertheless illustrated that these SDPs can 
get quite large in practice, and if SDP capability negotiation 
automatically requires them to be 50-100% larger, then we're headed for 
trouble. I have a desire to maintain clear semantics as well, however I 
think the price can quickly become too high here (just think ICE and 
crypto attribute duplication), and hence I vote for keeping the 
structure as-is.

-- Flemming

> --Colin Perkins

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Feb 2007 12:33:08 -0500

Dan Wing wrote:
> understand the first offer/answer, exchange, right? 
Right  - and to be clear, it does not add to actual call setup delay.  
If the second o/a exchange can not be performed until receipt of the 200 
Ok (read: no PRACK or preconditions), then there could be a clipping 
issue. As you note below, the solution to this problem is to upgrade the 
middle-boxes.

-- Flemming

>  The solution

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 26 Feb 2007 08:45:05 +0100

Hi
 
The approximate call setup time without the extra offer/answer is ~3.8s.
This again assuming HSPA access and as I understand it should include
everything. Note hiowever that this is no exact figure, more to be
viewed as an example.
 
Ingemar

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: den 23 februari 2007 15:31
	To: Ingemar Johansson S (LU/EAB)
	Cc: mmusic
	Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated
solution document (-03)

		Hi
		 
		I checked out a little and _very_ rougly speaking the
call setup time will be increased by ~1.0 second due to the extra
offer/answer, this of course depends heaviliy on the achievable
compression ratio of SigComp and the bitrate of the signaling radio
bearer, the figures assume HSPA access.

	Thanks. To put that in perspective, what is the approximate call
setup time without the extra offer/answer (and does it use
preconditions, resource reservation, etc.) ? 
	
	-- Flemming 

		Ingemar

			From: Flemming Andreasen
[mailto:[email-masked]] 
			Sent: den 22 februari 2007 13:09
			To: Ingemar Johansson S (LU/EAB)
			Cc: mmusic
			Subject: Re: [MMUSIC] SDP Capability
Negotiation: Updated solution document (-03)

				Hi
				
				If I understand things correctly
(snippet below from section 3.5.3),
				there will be two offer/answers during
call setup. The second
				offer/answer in order to ensure that
"intermediaries" understand. This
				might have some issues regarding call
setup times e.g in wireless access
				where service radio bearers might have a
limited bitrate, currently I
				cannot tell much this might mean in
extra call setup time.
				
				One possible solution is that it may be
possible that the call could be
				setup already after the first
offer/answer ?, this probably assumes that
				possible radio resource management
understands the first offer/answer.

			That's correct. As far as the offerer and the
answerer is concerned, all media stream negotiation is complete after
the first exchange. The second exchange is merely done as a courtesy to
any intermediaries that may not understand what was actually going on.
If those intermediaries do understand it (and have a need to a know in
the first place), then the second exchange is effectively a no-op for
all parties.
			
			-- Flemming 

				Regards
				Ingemar
				
				============================== 
				   If the offer/answer exchange was
succesful, and if the answerer 
				   selected one of the potential
configurations from the offer as the 
				   actual configuration, then the
offerer SHOULD perform another 
				   offer/answer exchange: The new offer
should contain the selected 
				   potential configuration as the actual
configuration, i.e. with the 
				   actual configuration used in the "m="
line and any other relevant 
				   attributes. This second offer/answer
exchange will not modify the 
				   session in any way, however it will
help intermediaries that look at 
				   the SDP, but do not understand or
support the capability negotiation 
				   extensions, to understand the details
of the media stream(s) that 
				   were actually negotiated.  
				============================== 

				-----Original Message-----
				From: Flemming Andreasen
[mailto:[email-masked]] 
				Sent: den 20 februari 2007 04:00
				To: mmusic
				Subject: [MMUSIC] SDP Capability
Negotiation: Updated 
				solution document (-03)
				
				Greetings
				
				I have just submitted an updated
solution document as 

				
				The list of changes (from Section 9.1):
				o Base option tag name changed from "v0"
to "cap-v0".
				o Added new section on extension
capability attributes o 
				Firmed up offer/answer procedures.
				o Added security considerations
				o Added IANA considerations

				Thanks
				
				-- Flemming

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 26 Feb 2007 08:51:16 +0100

Hi
 
I was kind of thinking in this direction too. Doesn't this however
assume that middleboxes notify the endpoints in some way that it
understands the first offer/answer. 

Ingemar

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: den 25 februari 2007 18:33
	To: Dan Wing
	Cc: Ingemar Johansson S (LU/EAB); 'mmusic'
	Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated
solution document(-03)

	Dan Wing wrote: 

		But there is only this additional delay if the
middleboxes don't
		understand the first offer/answer, exchange, right? 

	Right  - and to be clear, it does not add to actual call setup
delay.  If the second o/a exchange can not be performed until receipt of
the 200 Ok (read: no PRACK or preconditions), then there could be a
clipping issue. As you note below, the solution to this problem is to
upgrade the middle-boxes. 
	
	-- Flemming 

		 The solution
		seems to be upgrade the software in them so they
understand the
		new SDP Capability Negotiation in the first exchange.  
		
		The extra o/a is just to provide some accommodation
during the
		transition to everything understanding SDP Cap. Neg.  
		
		-d

			-----Original Message-----
			From: Ingemar Johansson S (LU/EAB) 
			[mailto:[email-masked]] 
			Sent: Friday, February 23, 2007 6:01 AM
			To: Flemming Andreasen
			Cc: mmusic
			Subject: RE: [MMUSIC] SDP Capability
Negotiation: Updated 
			solution document(-03)
			
			Hi
			 
			I checked out a little and _very_ rougly
speaking the call 
			setup time will be increased by ~1.0 second due
to the extra 
			offer/answer, this of course depends heaviliy on
the 
			achievable compression ratio of SigComp and the
bitrate of 
			the signaling radio bearer, the figures assume
HSPA access.
			 
			Ingemar

			
				From: Flemming Andreasen
Negotiation: 

			
			
					Hi
					
					If I understand things correctly
(snippet below 
			from section 3.5.3),
					there will be two offer/answers
during call 
			setup. The second
					offer/answer in order to ensure
that 
			"intermediaries" understand. This
					might have some issues regarding
call setup 
			times e.g in wireless access
					where service radio bearers
might have a 
			limited bitrate, currently I
					cannot tell much this might mean
in extra call 
			setup time.
					
					One possible solution is that it
may be 
			possible that the call could be
					setup already after the first
offer/answer ?, 
			this probably assumes that
					possible radio resource
management understands 
			the first offer/answer.

				That's correct. As far as the offerer
and the answerer 
			is concerned, all media stream negotiation is
complete after 
			the first exchange. The second exchange is
merely done as a 
			courtesy to any intermediaries that may not
understand what 
			was actually going on. If those intermediaries
do understand 
			it (and have a need to a know in the first
place), then the 
			second exchange is effectively a no-op for all
parties.
				
				-- Flemming 

					Regards
					Ingemar
					
					============================== 
					   If the offer/answer exchange
was succesful, 
			and if the answerer 
					   selected one of the potential
configurations 
			from the offer as the 
					   actual configuration, then
the offerer 
			SHOULD perform another 
					   offer/answer exchange: The
new offer should 
			contain the selected 
					   potential configuration as
the actual 
			configuration, i.e. with the 
					   actual configuration used in
the "m=" line 
			and any other relevant 
					   attributes. This second
offer/answer 
			exchange will not modify the 
					   session in any way, however
it will help 
			intermediaries that look at 
					   the SDP, but do not
understand or support 
			the capability negotiation 
					   extensions, to understand the
details of the 
			media stream(s) that 
					   were actually negotiated.  
					============================== 

						-----Original
Message-----
						From: Flemming Andreasen

						Sent: den 20 februari
2007 04:00
						To: mmusic
						Subject: [MMUSIC] SDP
Capability 
			Negotiation: Updated 
						solution document (-03)
						
						Greetings
						
						I have just submitted an
updated 
			solution document as 

	
						until it appears in the
archives.
						
						The list of changes
(from Section 9.1):
						o Base option tag name
changed from 
			"v0" to "cap-v0".
						o Added new section on
extension 
			capability attributes o 
						Firmed up offer/answer
procedures.
						o Added security
considerations
						o Added IANA
considerations

						Thanks
						
						-- Flemming

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Feb 2007 11:19:13 -0800

> Hi
>  
> I was kind of thinking in this direction too. Doesn't this 
> however assume that middleboxes notify the endpoints in some 
> way that it understands the first offer/answer. 

For SIP, if all the Via headers show that all intermediary 
devices were aware of SDP CapNeg, that should provide a way 
to avoid doing the second O/A.

-d