1184540 - STUN/DTLS issue with ice-lite

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect)

Description

[AjayG]

Attachment: aboutWebrtc.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.134 Safari/537.36

Steps to reproduce:

set Remote description(with a=ice-lite) in Firefox received from my WebRTC Gateway.
created local answer and relayed to gateway



Actual results:

if both server & firefox are in the same LAN ice session is not completing
and firefox start sending client hello before ice completion


Expected results:

first ICE session should complete then firefox should send client hello

please find the pcap (working-WAN, notworking-LAN & working-chrome-LAN) files in below link
https://www.dropbox.com/sh/dzn36f3k370uhu2/AAAlTpgYnEg2aDGRwZ55AS4Ga?dl=0

Comment 1

[Byron Campen [:bwc]]

In the non-working PCAP, I see us sending a STUN check with USE-CANDIDATE, us receiving a success response, and then sending the Client Hello. A success response to a STUN check with USE-CANDIDATE means that ICE is now connected, and traffic can begin flowing. STUN checks on other pairs can still continue, of course.

Comment 2

[Byron Campen [:bwc]]

Also, looking at these pcaps, your end is sending ICE checks, which is not what I would expect an ice-lite endpoint to do. This might be a clue as to what's going on in your implementation.

Comment 3

[AjayG]

i was using libnice-0.1.12 for ice handling in janus-gateway.

In working-chrome PCAP, we didn't get USE-CANDIDATE in initial STUN Request from Chrome but immediately we received client-hello.
I observed delay is the only difference in LAN & WAN.
Can you plz look into the about:webrtc, i was suspecting a=ice-lite.
if i disabled ice-lite then it is working fine

Comment 4

[Byron Campen [:bwc]]

The remote SDP does indeed have a=ice-lite, but the ICE stack doesn't seem to be configured that way. I did notice that Chrome wasn't sending USE-CANDIDATE before starting the DTLS handshake; this is probably invalid, but perhaps it works in practice. I don't know anything about the internals of libnice, so cannot hypothesize what is going on here, but the extra STUN checks that Chrome is sending are probably the key here.

Comment 5

[AjayG]

if gateway and client(FF) are in different networks, then session is establishing properly with the same setup.

Comment 6

[Byron Campen [:bwc]]

Looking at the pcap, the different networks case has a retransmission, perhaps due to latency.

Comment 7

[Maire Reavy [:mreavy]]

Byron -- Do you think there's something actionable for us here?  Sounds like this is likely a bug in libnice, but we may want to consider a workaround.  Ref: Comment 4 ("the extra STUN checks that Chrome is sending are probably the key here"), does it make sense for us to add extra STUN checks (as a kind of workaround)?

Comment 8

[Byron Campen [:bwc]]

Adding gratuitous STUN checks to work around a buggy ice-lite implementation doesn't seem like a good idea to me.

Comment 9

[Maire Reavy [:mreavy]]

(In reply to Byron Campen [:bwc] from comment #8)
> Adding gratuitous STUN checks to work around a buggy ice-lite implementation
> doesn't seem like a good idea to me.

Fair enough.  I'm going to mark this one as INVALID then.