Re: [rtcweb] Proposal to break the ICE impasse

[Roman Shpount <[e-mail]>]

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

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

One way to interpret JSEP in its current state, that it specifies that
address and port in c= and m= line should be updated to the selected
candidate, but proto should always be UDP/..., even if address in c= and
port in m= lines are from the TCP candidate. All I am asking, is if end
point updates address c= and port in m= line, it should update the proto to
match.

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.
>
>
JS SIP + WebRTC clients are one of the issues. For instance, it is possible
to build a network using JS SIP clients (jssip works great :), regular VoIP
clients that support DTLS-SRTP (for instance something pjsip based), and
SBC which support DTLS-SRTP+ICE TCP. All are connected to the SIP-over-WS
enabled proxy. CDRs and monitoring are done from proxy using proxy
generated CDR and SIP signaling capture using something like SIP Homer. The
simplest way to get client connection information is by using "fix-up"
offers and extracting data from SIP signaling. It is possible to build a
separate monitoring solution for WebRTC clients using stats, but using
existing SIP based solutions already works well enough except for bogus
info about nominated candidate in c= and m= lines.

Regards,
_____________
Roman Shpount