Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-07.txt

From: "Francois Audet" <[email-masked]>
Date: Thu, 1 Nov 2007 16:05:17 -0500

In-line.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Tuesday, October 30, 2007 19:11
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]
	Subject: Re: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-capability-negotiation-07.txt

	They are both correct. The second example (4.1) includes an
extra transport protocol capability (RTP/AVP), but doesn't use it in any
of the potential configurations. In either case, if the potential
configuration cannot be supported, the (least preferred) actual
configuration, i.e. the RTP/AVP profile will be negotiated. 

This is what I don't understand.
One of the examples repeats RTP/AVP in the tcap line,  the other does
not, and they appear to mean exactly the same thing.
Do they mean the same thing? If so, why do we have two ways of saying
the same thing.
If they don't mean the same thing, what is the difference?

		- In the first example, there is only one Offer/Answer
exchange. In the
		second
		  example, there is a second-round of Offer/Answer
exchange to "lock-it
		down" to
		  a plain SAVP offer for the benefits of middle boxes.
Again, which one
		is correct?

	They are both correct. The second offer/answer exchange is not
required but recommended when you think there might be a middle-box in
place. 
	
	The reason the two examples differ is that the 3.1. example is a
very quick introduction that is trying to give an overview of the key
concepts in the framework. The section 4 examples are a bit more
elaborate, however they are all valid. 

		  PS: Personally, I prefer the first one. 

	I know :-)

		I don't see why the we would
		need a second
		  one for middleboxes, and the single offer/answer
should work. And from
		a philosophical
		  perspective, I don't think we should complicate unduly
the protocols
		just for the 
		  benefits of sub-standard middleboxes...
		
		Can you clarify?

	We've had that discussion before (look for thread titled
"SDPCapNeg Issue #6: Second Offer/Answer exchange" on 6/25/07), and the
consensus was that we did not want to require the second offer/answer
exchange, however it is still useful to address some potential middlebox
issues, so we wanted to include it as an option. ICE has a second
offer/answer exchange (REQUIRED if I recall correctly).  

I think the "potential issue" in this particular example is very far
fetched, and I'm quite worried about encouraging everybody to double the
offer/answer process if we don't have to. The same IP address and port
is used, so the middlebox shouldn't really care if it is RTP or SRTP. We
shouldn't use a second Offer/Answer unless we really have good reasons
to believe that it will choke the middle box.
 
The potential "far-fetch" here is the assumption that an SBC would choke
on the Offer having RTP/AVP in the Offer but RTP/SAVP in the Answer. I
really doubt that it would be an issue. 
 
In this case, if the middlebox doesn't understand this draft (and
ignores the new attributes), it would work. It would open the pinhole as
it was described in the c/m lines.
 
I believe ICE only requires the second offer/answer if the chosen
candidate is different from the one in c/m line.

If we really want to show a second offer answer, why don't we show an
example that includes ICE candidates? That I think would be quite
useful.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 2 Nov 2007 10:38:07 +0200

Francois,

The pcfg defines the preferred order of the potential configurations.
Having the profile in the tcap enables you to have it in the preference
list. The profile in the m-line is the least preferred.

Having the profile from the m-line in the tcap also allows defining
potential parameters.

I assume that if you do not see any value in having the profile from the
m-line in the tcap, do not list it there.

Roni Even

From: Francois Audet [mailto:[email-masked]] 
Sent: Thursday, November 01, 2007 11:05 PM
To: Flemming Andreasen
Cc: [email-masked]
Subject: RE: [MMUSIC]I-D
ACTION:draft-ietf-mmusic-sdp-capability-negotiation-07.txt

In-line.

 

	

	I know :-)

	I don't see why the we would
	need a second
	  one for middleboxes, and the single offer/answer should work.
And from
	a philosophical
	  perspective, I don't think we should complicate unduly the
protocols
	just for the 
	  benefits of sub-standard middleboxes...
	 
	Can you clarify?

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 Nov 2007 20:51:50 -0500

Francois Audet wrote:
> In-line.
>
>     ------------------------------------------------------------------------
>     *From:* Flemming Andreasen [mailto:[email-masked]]
>     *Sent:* Tuesday, October 30, 2007 19:11
>     *To:* Audet, Francois (SC100:3055)
>     *Cc:* [email-masked]
>     *Subject:* Re: [MMUSIC] I-D
>     They are both correct. The second example (4.1) includes an extra
>     transport protocol capability (RTP/AVP), but doesn't use it in any
> Do they mean the same thing?
They do.
> If so, why do we have two ways of saying the same thing.
The actual configuration, which is what you find in the m= line and 
associated parameters, contains capabilities by definition. What you see 
in the tcap line is merely those capabilities being repeated. There is 
nothing wrong or harmful in doing so, however if you find it offensive, 
it can be removed from the example,  but the ability to do so of course 
remains.
>>     - In the first example, there is only one Offer/Answer exchange. In the
>>     second
>>       example, there is a second-round of Offer/Answer exchange to "lock-it
>>     down" to
>>       a plain SAVP offer for the benefits of middle boxes. Again, which one
>>     is correct?
>>       
>     required but recommended when you think there might be a
>     middle-box in place.
>
>     very quick introduction that is trying to give an overview of the
>     key concepts in the framework. The section 4 examples are a bit
>     more elaborate, however they are all valid.
>
>>       one for middleboxes, and the single offer/answer should work. And from
>>     a philosophical
>>       perspective, I don't think we should complicate unduly the protocols
>>     just for the 
>     "SDPCapNeg Issue #6: Second Offer/Answer exchange" on 6/25/07),
>     and the consensus was that we did not want to require the second
>     offer/answer exchange, however it is still useful to address some
>     potential middlebox issues, so we wanted to include it as an
>     option. ICE has a second offer/answer exchange (REQUIRED if I
>     recall correctly).  
>
> fetched, and I'm quite worried about encouraging everybody to double 
> the offer/answer process if we don't have to. The same IP address and 
> port is used, so the middlebox shouldn't really care if it is RTP or 
> SRTP.
On the contrary. The middlebox may include a media relay that depends on 
the type of transport protocol, e.g. because it wants to perform 
statistics. Another example is policy authorization for QoS; there is 
different overhead associated with the use of RTP and SRTP, so it does 
matter. These are real examples and hence the functionality is not far 
fetched at all.

> We shouldn't use a second Offer/Answer unless we really have good 
> reasons to believe that it will choke the middle box.
>  
> The potential "far-fetch" here is the assumption that an SBC would 
> choke on the Offer having RTP/AVP in the Offer but RTP/SAVP in the 
> Answer. I really doubt that it would be an issue.
The issue was raised on the mailing list on 6/25/07 ("SDPCapNeg Issue 
#2: Answer not getting through middle-boxes if transport protocol in 
answer differs from offer"). Hadriel Kaplan had pointed out that some 
SBCs will not pass an answer that has a different transport protocol 
than the offer, so I don't know why you think this is far fetched.
 
> ignores the new attributes), it would work. It would open the pinhole 
> as it was described in the c/m lines.
>  
> _I believe ICE only requires the second offer/answer if the chosen 
> candidate is different from the one in c/m line_.
I believe that is correct too. SDP Capability Negotiation is similar; 
you only perform the second offer/answer exchange if you used one of the 
potential configurations instead of the actual configuration from the 
offer.
> example that includes ICE candidates? That I think would be quite useful.
Examples can always be added, althought it may be useful to start a 
separate examples document, since there's already quite a few pages 
dedicated to that in the current draft.

-- Flemming