Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.txt

[Flemming Andreasen <[e-mail]>]

On 4/12/11 7:24 AM, Gonzalo Camarillo wrote:
>
> Hi,
>
> >> This is the one point on which I disagree -- this is a choice of
> >> alternate transports, so it's more like ICE than CapNeg, it seems 
> to me.
> >>
> > I think it depends on what you are trying to do: Negotiate use of a
> > mechanism that both sides support or find a mechanism that can establish
> > connectivity as verified by ICE. It's probably quite reasonable to
> > support both scenarios. RFC 5939 Section 3.7 has a bit more text around
> > this btw.
> >
> > More discussion/opinions on this point would be useful.
>
> theoretically, I agree there are two scenarios. However, in practice,
> endpoints are interested in establishing the best possible connection.
> ICE allows the endpoints to decide what "the best" means to them. It may
> be the connection that can be established the fastest, or the connection
> with the lowest delay, or whatever. Therefore, endpoints will try every
> possible path until they find the best according to their definition.
>
> Why would two endpoints want to limit themselves to only try
> DCCP-over-IP paths or DCCP-over-UDP paths when they can try both and
> pick the best? Do you have any scenario in mind where endpoints are
> constrained to only try one type of path for some reason?
>
I can make similar arguments for any choice of SDP "transport protocol", 
e.g. middleboxes may allow some transports/profiles, but not others, and 
hence we should always use ICE to just pick one that works. However we 
have recent examples that do not require ICE to negotiate different 
transports, e.g DTLS-SRTP (per RFC 5763), not to mention that CapNeg 
(RFC 5939) was motivated in large part by this use case.

At the end of the day, the question is whether we want to always mandate 
that ICE is implemented in order to negotiate different transports, or 
whether we stick with recommendations based on the scenario you are 
concerned with (negotiation or verified connectivity). RFC 5939 Section 
3.7 describes this trade-off, and I still believe it to be the correct 
one, and hence do not think we should mandate one way or the other.

Thanks

-- Flemming

> Cheers,
>
> Gonzalo
>