Chrome ICE connection problem

[Anton]

Hello all!

I'm developing webrtc gateway and facing with problem during ICE negotiation - chrome chooses different candidate pair than my gateway.

Connection is made from my gateway to Chrome, Gateway is located at public network and has public IP 2.2.2.2 (anonymized) and works on port 5074. 

Chrome works on machine (windows 7) located in private network with public IP 1.1.1.1 and this machine has 2 nic connected to internet (private ip 172.17.0.1 and 192.168.225.133)

Connectivity checks completed successfully, but chrome chooses candidate pair (1.1.1.1 53303; 2.2.2.2 5074), which priority should be lower than priority of other pair (1.1.1.1 48874; 2.2.2.2 5074).

My assumption is based on following things

Chrome 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

So, candidate 1.1.1.1 48874 has higher priority

My Gateway 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

According to rfc 

"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, D is chrome

So, according to the formula should be used 1.1.1.1 48874, but chrome chooses 1.1.1.1 53303 and send DTLS to it, therefore overal connection fails.

Please help me to determine cause of this wrong behaviour. I'm highly appreciate any help!

SDP from chrome, SDP from gateway, and STUN dialogs provided in attached files

[Iñaki Baz Castillo]

2016-05-17 9:05 GMT+02:00 Anton <tei...@gmail.com>:
> So, according to the formula should be used 1.1.1.1 48874, but chrome
> chooses 1.1.1.1 53303 and send DTLS to it, therefore overal connection
> fails.
> Please help me to determine cause of this wrong behaviour. I'm highly
> appreciate any help!

In the SDP of Chrome:

s=Doubango Telecom - chrome

So it's clear that some JS is mangling the SDP offer sent over the
network and it's hard to figure out whether ICE candidates have also
been mangled and whether they have been set into
setRemoteDescription() or just mangled before sending the SDP.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Anton Teykhrib]

Thank you for reply!

Did you mean setLocalDescription (because for Chrome its local SDP)? 

Unfortunatelly I have no chance to change this JS to another at the moment:(

Also I think that it's not a problem, because Chrome sent STUN checks from both interfaces, and priorities in STUN packets in wireshark dumps corresponds to priorities in SDP (except changes to prflx type, as RFC states)

[Iñaki Baz Castillo]

2016-05-17 14:29 GMT+02:00 Anton Teykhrib <tei...@gmail.com>:
> Did you mean setLocalDescription (because for Chrome its local SDP)?
> Unfortunatelly I have no chance to change this JS to another at the moment:(
> Also I think that it's not a problem, because Chrome sent STUN checks from
> both interfaces, and priorities in STUN packets in wireshark dumps
> corresponds to priorities in SDP (except changes to prflx type, as RFC
> states)

Then, if you can properly isolate the issue I recommend opening an
issue in the Chrome's WebRTC project.

[Anton Teykhrib]

Ok, I'll try it (registered issue)

Also, very thank you for your project Oversip, we fully satisfied with it:)

[Taylor Brandstetter]

Thanks for filing an issue! I responded on the issue itself, but I'll also respond on the mailing list for the benefit the community.

The issue is probably that the gateway is using aggressive nomination, and 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 (or the highest-priority pair stops working for some other reason), the controlling ICE agent can switch to a different candidate pair without doing an ICE restart, simply by re-nominating it.

In the future this will hopefully be accomplished by using a new ICE option and STUN attribute, so it won't interfere with standard ICE. You can read about it in this draft: https://datatracker.ietf.org/doc/draft-thatcher-ice-renomination/

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/19a63abc-0b29-4e98-b4c6-d2b1ea0ada04%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Iñaki Baz Castillo]

2016-05-20 14:21 GMT+02:00 Anton Teykhrib <tei...@gmail.com>:
> Ok, I'll try it (registered issue)
> Also, very thank you for your project Oversip, we fully satisfied with it:)

Nice to hear that :)

[Lee Sun]

did you resolve this issue? 

if so, can you please share your solution?

I'm also facing similar problem.

after upgrading chrome to m51, ice connection check was failed. 

caller(chrome) has multiple candidate.

callee(ipphone) has only one candidate.

after reading this, I assume that problem is caused by "aggresive nomination" and wrong candidate is selected

additionally, if i use chrome m50, it is going through. it is happened now only for m51. I checked release note about webrtc, some changes was made about cadidate priorty  .

2016년 5월 21일 토요일 오전 2시 8분 20초 UTC+9, Taylor Brandstetter 님의 말: