Re: [rtcweb] Proposal to break the ICE impasse

[Eric Rescorla <[e-mail]>]

On Wed, Jan 30, 2019 at 6:21 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >>> I understand your point. But still I don't understand the purpose of
> the new draft (set TCP/DTLS/etc in proto line if there are just TCP
> candidates in the offer).
> >>
> >> The purpose is standard compliance. If nominated candidate is UDP,
> proto line should be UDP. If nominated candidate is TCP, proto line should
> be TCP.
> >> If you do not care about the c= and m= line, put the dummy values and
> UDP there, but this breaks legacy interop by causing ICE mismatch.
> >>
> >> This is two separate statements that don't necessarily follow form each
> other
> >>
> >>1. This is a matter of standards compliance.
> >>2. It breaks legacy interop
> >
> >I agree on point (1). I'm still waiting for someone to demonstrate point
> (2)
>
> There are networks where nodes (not always SBCs) use the c/m- information
> to control network resources (e.g., radio bandwidth). Whether UDP vs TCP
> will have a major impact I don't know, but the point is that the c/m-
> information IS used.
>

> Whether the WG has agreed that the c/m- information is "meaningless" in
> the JSEP API I don't know, but it for sure is not "meaningless" on the wire.
>

We're talking solely about the format field in this discussion, and the
whole import of the decision have a fixed field was that in fact we agreed
it was meaningless.

-Ekr


> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
> Putting UDP proto and address from TCP candidate breaks legacy interop as
> well, but it is typically localized to provider managed server, so it is
> possible to patch around this either in JS client or on the server to treat
> WebRTC clients differently. Alternatively, WebRTC clients can add a couple
> lines of code and become compliant with the RFC they decided to implement
> and remove the need for patching.
>
> Of course, if browser follow the ICE spec and set the selected candidate
> in the c/m lines, they must also indicate whether that is over UDP or TCP.
> The problem here is what such a proto line is intended to mean when there
> is ICE candidates of UDP and TCP. But ok, let's assume that browser do
> update c/m lines in the trigger with the selected candidate, and they JUST
> change the proto line to TCP/DTLS if there are just TCP candidates. Now
> thing about this scenario:
>
> 1) Client initial offer with UDP and TCP candidates.
>
> 2) Server answers with both UDP and TCP candidates.
>
> 3.1) UDP is selected. Re-offer is created with just UDP candidates (as per
> spec).
>
> 3.2) or TCP is selected. Re-offer is created with just TCP candidates (as
> per specs).
>
> In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the
> proto line. It can just check the protocol (UDP or TCP) of *any* candidate
> in the offer to know whether UDP or TCP was selected.
>
> Am I wrong?
>
> You are correct. Checking c= and m= line is simply to avoid checking and
> parsing ICE candidates. If monitoring client would handle ICE candidates,
> then the monitoring client would still need to figure out which candidate
> is default to record client media IP.. Keeping c= and m= line in sync with
> default candidate on the client seemed to cause the least amount of
> problems which is why it was left in ice-sip-sdp.
>
> Regards,
> _____________
> Roman Shpount
>
> _______________________________________________
> rtcweb mailing list
> mailto:[e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>