Subject: [MMUSIC] draft-ietf-mmusic-sdp-capability-negotiation-07: Comment 2

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Nov 2007 19:08:26 -0600

Other WGLC comment.

MAJOR

Comment 2: The usage of second Offer/Answer for SBC traversal
-------------------------------------------------------------

The examples in section 4 all use a second Offer/Answer to "lock it
down" to
a specific m-line.

This is similar to ICE which has the following rule (section 2.6/ICE):

   Once all of the media streams are completed, the controlling endpoint
   sends an updated offer if the candidates in the m and c lines for the
   media stream (called the DEFAULT CANDIDATES) don't match ICE's
   SELECTED CANDIDATES. 

However, the rules for doing so in this draft are not clear. There
should
be concrete guidance on when a second offer/answer is necessary.

One may be tempted to say that the second offer/answer is sent only if
the chosen tcap is different from the one in the m-line. However, this
is different from ICE because unlike ICE, the IP address and port remain
the same. The whole reason in ICE to do this second offer/answer is to
"lock"
the IP address and port (not the profile).

That is one possibility. I would be OK with specific wording explaining
that
it is the case (which would mean that the example on p. 11 should be
fixed).

That being said, it is not clear that much is gained with this. The
assumption
seems to be that some SBC that do not support capability negotiation
would have a 
problem with the m-line in the Offer having, say, RTP/AVP, but the
Answer having
RTP/SAVP. The rationale seems to be that those SBCs would say "hum, this
is weird, 
I'm going to not open the gate until something else happens". Then,
presumably,
the second Offer/Answer would use, say, RTP/SAVP in both cases, and the
SBC would
go "Ah, I understand now, and I'm ok with it and will now open the
gate".

This seems very far fetched to me. I would expect the SBC behavior to be
one of the 
following behavior instead if it doesn't support Capability negotiation:

1) SBC sees Offer with RTP/AVP, then Answer with RTP/SAVP and says "Who
cares, it's
   the same gate anyway", and just allow the signalling to proceed. It
won't care what
   is actually being send as media since it doesn't process media and
SRTP is RTP 
   anyways.

2) SBC sees Offer with RTP/AVP, then Answer with RTP/SAVP and says "This
is very weird,
   let's clear the call".

None of those scenarios would be helped by a second Offer/Answer. I'm
hoping most
SBC would do behavior 1 because behavior 2 is more difficult to fix.
(See below).

So, my take is that the Second Offer is NOT necessary until there are
additional changes
(as may be the case if ICE is also used).

So, my personal preference would be to remove all the examples with the
second Offer/Answer
because they don't seem to provide any value at all in the examples
listed in the draft.

However, what I would like to see in section 3.7 on "Interactions with
ICE" some text that
explains that if ICE is used and results in a second Offer/Answer, then
that second Offer/Answer 
must use the profile that is selected instead of using the tcap/cap.

Side note on 2 above: I'm really hoping that no SBC would suffer from
the behavior 2 above,
and maybe some SBC vendors could comment. If it is a problem however,
then one way to fix
address it would be for the Answer to use the same profile as the Offer
(instead of the 
chosen one) and instead just use the a=crypto/etc. in the answer.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 Nov 2007 21:30:53 -0500

> Comment 2: The usage of second Offer/Answer for SBC traversal
I believe there is. From Section 3.6.3:
<quote>
   If the offer/answer exchange was successful, and if the answerer
   selected one of the potential configurations from the offer as the
   actual configuration, then the offerer MAY perform another
   offer/answer exchange: This 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 and extensions. This second offer/answer exchange will
   not modify the session in any way, however it will help
   intermediaries (e.g. middleboxes) 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. If it is known or suspected that one or more such
   intermediaries exist, then this second offer/answer SHOULD be
   performed (this is already done when using Interactive Connectivity
   Establishment [ICE], and in those cases, there will not be a need
   for a third offer/answer exchange). Note that, per normal ...
</quote>

Can you elaborate on which part of the above text is unclear ?

> the IP address and port (not the profile).
I think that's debatable. The IP-address and port is locked through the 
STUN Binding Requests which ultimately lead to state machine entering 
the Completed state for a media stream. The nominated (selected) 
candidate is even communicated through STUN itself, so there is arguably 
no need for this second offer/answer exchange from a pure ICE point of 
view.

> it is the case (which would mean that the example on p. 11 should be
I can change the example on p. 11 to include a second O/A exchange if 
that helps.

> SBC would do behavior 1 because behavior 2 is more difficult to fix.
According to Hadriel Kaplan, something along the lines of 2) does in 
fact happen with some SBCs. However, I think there are other important 
scenarios to consider:
1) Middle-box is not an SBC, but some sort of bandwidth authorizing SIP 
entity (some people call them P-CSCFs). It may look at the offer SDP 
only and authorize bandwidth based on that.
2) Middle-box is an SBC, that does process media. This could for example 
be a transcoder. Obviously, it needs to understand the details of the 
media stream being negotiated.

I think both of these examples are quite reasonable, and there are more 
where they cam from.
> (as may be the case if ICE is also used).
Correct - which is also what the draft specifies.
> because they don't seem to provide any value at all in the examples
I disagree per the above. All of the examples in Section 4.1 - 4.3 offer 
RTPAVP but end up negotiating use of another transport protocol, and 
hence a second O/A exchange is shown.

> must use the profile that is selected instead of using the tcap/cap.
I can add some text to that effect, however do note, that tcap etc. may 
still be used, however the actual configuration ("m=" line etc.) must 
contain what was negotiated and selected by ICE as well.

> and maybe some SBC vendors could comment. 
Hadrial commented on this (in Prague I believe) - see above.

> If it is a problem however,
> then one way to fix
I think that puts us down a worse path, where intermediaries that 
actually look at both the answer and offer won't have a chance to figure 
out what's going on (unless they support the framework). It departs even 
more from both standard SDP and the offer/answer model by effectively 
treating the media description as a meaningless set of parameters. It 
would also require a significant rework of the mechanism, which I find 
to be a little late, considering these issues have been discussed on 
several occasions in both meetings and the mailing list.

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 Nov 2007 11:50:14 -0600

I'm going to break it into bite-size chunks... 

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Monday, November 05, 2007 18:31
> To: Audet, Francois (SC100:3055)
> Cc: mmusic; Jean-Francois Mule; Joerg Ott
> Subject: Re: [MMUSIC] 
> draft-ietf-mmusic-sdp-capability-negotiation-07: Comment 2
>>
> fact happen with some SBCs. 

That's my point! A second Offer/Answer will NOT help case 2) above as
the session will have been cleared anyways.

If we don't care about this, I'm OK with this.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 Nov 2007 12:06:55 -0600

Chunk Number 2. 

> > should be concrete guidance on when a second offer/answer is 
> > necessary.
> >   

It's the ambiguity that is a problem. It is too complicated for a
device. 
We should have deterministic behavior instead of MAY/SHOULD/...

If we are going to allow this second offer/answer (I don't "like" it 
that much, but I might be in a minority, so I'm reconsidering), then
let's 
just make a rule for when to use it.

Specifically, if the selected configuration is NOT the m/c-line,
then the Answerer MUST use a second Answer.

So, I'm willing to re-consider my doubts about the necessity
about the second Offer/Answer, and instead have clarity. I'd suggest:

    If the offer/answer exchange was successful, and if the answerer
    selected one of the potential configurations from the offer as the
    actual configuration, and the selected potential configuration is
NOT
    the one from the m/c lines, then the offerer MUST perform another
    offer/answer exchange. This new offer MUST 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 and extensions. This second offer/answer exchange will
    not modify the session in any way, however it will help
    intermediaries (e.g. middleboxes) 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. Note that, per normal ...

And I've removed the stuff about ICE not causing a third Offer/Answer.
That text should be in your section 3.7 on ICE. Something like:

	Note that ICE also uses a second Offer/Answer if the chosen
	candidate is not the same as the one in the m/c-line. When ICE
	and capability negotiation are used at the same time, the same
	second Offer/Answer is used for both capability negotion and
ICE.

That would satisfy me.

Cheers.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Nov 2007 14:25:47 -0500

Francois Audet wrote:
>>> 2) SBC sees Offer with RTP/AVP, then Answer with RTP/SAVP 
>>>       
>> and says "This
>>     
>>> is very weird,
>>>    let's clear the call".
>>>
>>> None of those scenarios would be helped by a second 
>>>       
>> Offer/Answer. I'm
>>     
>>> hoping most
When we discussed case 2) last time, we felt that addressing it would 
make the solution even more complicated and we decided not to address 
it, except to explain it in the draft (which it is).

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Nov 2007 14:34:42 -0500

> We should have deterministic behavior instead of MAY/SHOULD/...
We can certainly increase the strength. I do think a SHOULD is 
appropriate in terms of having the second O/A exchange, since it's done 
solely for the purpose of satisfying intermediaries that don't support 
the framework, which is hopefully not an eternal thing. The reason for 
the second SHOULD is in case the endpoint effectively decides that the 
O/A exchange it just completed is no longer valid. That may not be clear 
and we could either change that to a MUST or explain when it would be 
valid not to do it (maybe a MUST...., except if....).

> 	second Offer/Answer is used for both capability negotion and
Ok.

> That would satisfy me.
Ok - let me know if the above "SHOULD, MUST, except if..." proposal 
works for you as well.

Thanks

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 Nov 2007 14:13:49 -0600

Ok, I'm good on this.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Tuesday, November 06, 2007 11:26
	To: Audet, Francois (SC100:3055)
	Cc: Jean-Francois Mule; mmusic; Joerg Ott
	Subject: Re: [MMUSIC]
draft-ietf-mmusic-sdp-capability-negotiation-07: Comment 2

	Francois Audet wrote: 

			-----Original Message-----
			From: Flemming Andreasen
[mailto:[email-masked]] 
			Sent: Monday, November 05, 2007 18:31
			To: Audet, Francois (SC100:3055)
			Cc: mmusic; Jean-Francois Mule; Joerg Ott
			Subject: Re: [MMUSIC] 
			draft-ietf-mmusic-sdp-capability-negotiation-07:
Comment 2

				2) SBC sees Offer with RTP/AVP, then
Answer with RTP/SAVP 

			and says "This

				is very weird,
				   let's clear the call".
				
				None of those scenarios would be helped
by a second 

			Offer/Answer. I'm

				hoping most
				SBC would do behavior 1 because behavior
2 is more difficult to fix.
				(See below).

			According to Hadriel Kaplan, something along the
lines of 2) does in 
			fact happen with some SBCs. 

		That's my point! A second Offer/Answer will NOT help
case 2) above as
		the session will have been cleared anyways.

	When we discussed case 2) last time, we felt that addressing it
would make the solution even more complicated and we decided not to
address it, except to explain it in the draft (which it is). 
	
	-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 Nov 2007 14:13:38 -0600

> We can certainly increase the strength. I do think a SHOULD is
appropriate in terms 
> of having the second O/A exchange, since it's done solely for the
purpose of satisfying 
> intermediaries that don't support the framework, which is hopefully
not an eternal thing. 
> The reason for the second SHOULD is in case the endpoint effectively
decides that the O/A 
> exchange it just completed is no longer valid. That may not be clear
and we could either 
> change that to a MUST or explain when it would be valid not to do it
(maybe a MUST...., 
> except if....). 
	
Ok: I understanding your point and agree with it, and yes, the current
text is not too clear.

What about this:

	    If the offer/answer exchange was successful, and if the
answerer
	    selected one of the potential configurations from the offer
as the
	    actual configuration, and the selected potential
configuration is not
	    the one from the m/c lines, then the offerer SHOULD initiate
another 
          offer/answer exchange. This second offer/answer exchange will
	    not modify the session in any way, however it will help
	    intermediaries (e.g. middleboxes) 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. This new offer MUST 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 and extensions. Note that, per normal ...

>			second Offer/Answer is used for both capability
negotion and
	
Cool.

		That would satisfy me.

>k - let me know if the above "SHOULD, MUST, except if..." proposal
works for you as well. 

Yep.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Nov 2007 16:08:15 -0500

Sounds good.

Thanks

-- Flemming

Francois Audet wrote:
>> 		And I've removed the stuff about ICE not causing a third
>>     
> Offer/Answer.
>   
>> 		That text should be in your section 3.7 on ICE.
>>     
> Something like:
>   
>> 		
>> 			Note that ICE also uses a second Offer/Answer if
>>     
> the chosen
>   
>> 			candidate is not the same as the one in the
>>     
> m/c-line. When ICE
>   
>> 			and capability negotiation are used at the same
>>     
> time, the same
>   
>> 			second Offer/Answer is used for both capability
>>     
> negotion and
>   
>> 		ICE.	  
>>
>> 	Ok. 
>>     
> 	
> Cool.
>
> 		That would satisfy me.
> 		  
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 16 Nov 2007 18:38:11 -0600

Me again...

More editorial comments, based on questions I'm getting from implementors.

In 3.4.1 (or maybe 3.5.1), it would be helpful to explain that it is possible to have some 
attributes expressed as normal attributes, and others as attribure capabilities.
For example, the following would be valid:

      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/SAVP 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/SAVPF 
-->   a=acap:1 crypto:2 AES_CM_128_HMAC_SHA1_32    
         inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
      a=pcfg:1 t=1
	a=pcfg:2 t=2 a=1

In other words: SAVP with SHA1_80 is preferred, otherwise SAVPF with either SHA1_80 or 
SHA1_32.

---

In section 3.5.1, it is explained very clearly there there may (or may not) be a configuration
list, and what it means if it is not included. Good.

However, it is not very explicit that you may have both the transport and attribute lists, or 
just one of them (i.e., it is not clear that it is ok that have only one). For example, this \
would be 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/SAVP 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/SAVPF RTP/SAVP 
      a=pcfg:1 t=1
	a=pcfg:2 t=2

This is useful when only the transport needs to be potential configurations.

It also is very useful because it will be backward compatible with implementations that only
support SAVP (and not SAVPF) and don't support Capability negotiation.

---

I'd like to see that in there.

Thanks.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2007 13:54:49 -0500

> In other words: SAVP with SHA1_80 is preferred, otherwise SAVPF with either SHA1_80 or 
I think we are getting into very specific use case examples that are 
clearly valid based on the processing rules provided, and I wonder it 
those sorts of things aren't handled better by a (separate) example call 
flow document.

> I'd like to see that in there.
Section 3.5.1 currently says:

<quote>
   A potential configuration list is normally provided after the
   configuration number. When the potential configuration list is
   omitted, the potential configuration equals the actual
   configuration. The potential configuration list contains one or more
   of attribute, transport and extension configuration lists.
  ...
</quote>

Doesn't that cover it ("one or more of...") ? If not, I can try and make 
it more explicit.

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 26 Nov 2007 13:43:24 -0600

> Doesn't that cover it ("one or more of...") ? If not, I can 
> try and make it more explicit.

I think if you explicitly said that it is possible to have a potential
configuration with a transport, but without attributes, it would be fine.
(e.g., a=pcfg:1 t=1).

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2007 14:52:29 -0500

> configuration with a transport, but without attributes, it would be fine.
OK - I'll clarify that.

Thanks

-- Flemming