Summary: | ICE Gathering never completes due to srflx candidate | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Thomas Mullen <thomasmullendesign> | ||||
Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Normal | CC: | daginge, feross, youennf | ||||
Priority: | P2 | ||||||
Version: | Safari 11 | ||||||
Hardware: | Mac | ||||||
OS: | macOS 10.13 | ||||||
Attachments: |
|
Description
Thomas Mullen
2018-02-17 15:15:32 PST
I can confirm through Wireshark that the STUN server is sending the srflx candidate. Safari just doesn't emit the event. (In reply to Thomas Mullen from comment #1) > I can confirm through Wireshark that the STUN server is sending the srflx > candidate. Safari just doesn't emit the event. The issue with http://jsfiddle.net/hvkn8b5e/6/ is that the peer connection should be closed so that some clean-up happens and sockets be closed. Otherwise, we run out of sockets and stop doing anything. If you close explicitly the pc, it seems to run fine. Thomas, we just updated to a new libwebrtc endpoint on STP 52. I am wondering whether you could do some additional testing here. (In reply to youenn fablet from comment #2) I usually hit the stall before running out of peer connections, but you're right. http://jsfiddle.net/hvkn8b5e/8/ The stall on the srflx still occurs, even when closing after each test. I'll try STP 52. Created attachment 347617 [details] rtcstats-dump of failing call where no srvflx candidate was emitted We are seeing some instances of this as well. I have attached an rtcstats dump from a failing call done on iOS towards Chrome 68. Please open in https://fippo.github.io/webrtc-dump-importer/rtcstats The issues is that as you can see, onicecandidate is called twice in the initial attempt from the iOS side, generating only host candidates. This causes the call to fail after 15 seconds. Upon an icerestart (initiated by iOS), it works just fine and gathers candidates as normal. Any idea what's going on here? Unfortunately I don't have a perfect repro, as I have yet to discover the cases where this happens consistently. I suspect it might be related to https://bugs.webkit.org/show_bug.cgi?id=181009 but I funnily enough don't have an IPv6 network to test on. Note, my example dump does use trickle, which leads me to believe there is something happening outside disabling trickle here |