ICE connection problem (wrong candidate nominated)
Reported by
teih...@gmail.com,
May 20 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.47 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Make call from my Gateway to chrome. Chrome running on machine with 2 NICs (both has private IP with Internet Access) 2. Remote description has candidates: a=candidate:711375391 1 udp 2130706431 2.2.2.2 5074 typ host a=candidate:711375391 2 udp 2130706430 2.2.2.2 5074 typ host 3. Get local description with candidates a=candidate:3885250869 1 udp 2122260223 172.17.0.1 48874 typ host generation 0 a=candidate:1153304712 1 udp 2122129151 192.168.225.133 53303 typ host generation 0 a=candidate:79019993 1 udp 1686052607 1.1.1.1 48874 typ srflx raddr 172.17.0.1 rport 48874 generation 0 a=candidate:762595145 1 udp 1685921535 1.1.1.1 53303 typ srflx raddr 192.168.225.133 rport 53303 generation 0 4. Wait for negotiation What is the expected behavior? According to rfc (I think so) "Let G be the priority for the candidate provided by the controlling agent. Let D be the priority for the candidate provided by the controlled agent. pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)" In this case G is my gateway (it's caller), D is chrome (it's callee) So, according to the formula should be used 1.1.1.1 48874. What went wrong? Chrome chooses 1.1.1.1 53303 and send DTLS to it, therefore overal connection fails. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? N/A Chrome version: 51.0.2704.47 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0
,
May 20 2016
Is the gateway using aggressive nomination? If so, the issue is probably that our implementation of aggressive nomination differs slightly from the standard. Instead of selecting the highest priority pair when multiple pairs are nominated, we select the last-nominated pair. We do this so that if one of the networks goes down, the controlling ICE agent can switch to a different candidate pair without doing an ICE restart, simply by re-nominating it. Would it be possible for the gateway to send an extra binding request to the desired address, so that our implementation switches to the desired candidate pair?
,
May 23 2016
Thank you! It's sound reasonably, I'll try to implement such behaviour and write here results
,
May 23 2016
We should fix this once we roll out "renomination" as an ice-option.
,
May 24 2016
After check reordering (with last check for highest priority pair) issue was resolved, thank you! Would you please describe ice-option renomination? and how this fix will work?
,
May 24 2016
Basically, the "last one wins" behavior will only occur if a "renomination" ice option is present in the offer and answer, disabling normal "aggressive nomination". This is described here: https://tools.ietf.org/html/draft-thatcher-ice-renomination-00
,
Apr 3 2018
Removing owner and setting status to Available, since the issue isn't currently being worked on. |
||||
►
Sign in to add a comment |
||||
Comment 1 by teih...@gmail.com
, May 20 2016