Re: [rtcweb] Proposal to break the ICE impasse

[Iñaki Baz Castillo <[e-mail]>]

On Tue, 29 Jan 2019 at 19:05, Roman Shpount <[e-mail]> wrote:

> During steps 1-4, browser client sends an offer which includes both UDP and TCP candidates. It is using one of the UDP candidates as a default candidate in c= and m= line (proto is UDP/... something). Server, also responds with UDP and TCP candidates. It also uses one of the UDP candidates as a default candidate in c= and m= line (proto is UDP/... something). Since client location blocks everything except TCP, only the connectivity check for TCP candidate pair succeeds and TCP candidate gets nominated. Once ICE nomination process is completed, new offer is generated from the client without ICE restart (for instance to add a codec or initiate "fix up" offer). This offer must include locally nominated candidate pair and no other candidates (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2) This means this offer will only have TCP candidates present. This TCP candidate is the default candidate and will be used in c= and m= line resulting in TCP/... proto in the m= line.

This is a very good point:

> This (re)offer must include locally nominated candidate pair and no other candidates

But how is the draft above useful at all if browsers do not set the
selected candidate into c=/m= lines during a re-offer? Imagine browser
do implement the draft above and, indeed, they set "TCP/DTLS/..." in
the proto line of the re-offer with just TCP candidates. Assuming that
they do NOT set the selected candidate pair in the m=/c= line, this is
just valid to know whether UDP or TCP has been selected, nothing else.
Am I wrong?


In the other side, and assuming this is about JavaScript SIP+WebRTC
clients, wouldn't it work if they mangle the SDP re-offer? By checking
the peerconnection stats you can know the selected candidate and so
on.


-- 
Iñaki Baz Castillo
<[e-mail]>