Re: [rtcweb] Proposal to break the ICE impasse

[Roman Shpount <[e-mail]>]

On Tue, Jan 29, 2019 at 2:05 PM Iñaki Baz Castillo <[e-mail]> wrote:

> 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. 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