[Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection

[Александр Дружилов]

---------- Forwarded message ----------
From: Александр Дружилов <alexdruzhilov at gmail.com>
Date: 2016-09-26 14:31 GMT+03:00
Subject: Freeswitch uses wrong ICE candidate to establish connection
To: freeswitch-users at lists.freeswitch.org


*The short description of problem*
We are using Freeswitch for conference calls through webRTC. Chrome
collects ICE candidates (from two net interfaces: ethernet and wifi), sends
them to Freeswitch and Freeswitch accepts one of this candidates. After
that Freeswitch tries to make DTLS handshake, but Chrome ignores it and
sends STUN pings over and over again. But if I disable one of this network
interfaces, then everything works fine. From my point of view the problem
is that Freeswitch uses wrong ICE candidate (it takes this candidate from
STUN pings, but there is no exactly such candidate in SDP). I also admit
that may be the root of the problem is inside Chrome (because Firefox works
properly in this case), but I interested in possible explanations an may be
solutions from the Freeswitch side.

*Versions*
Freeswitch 1.6.9, 1.6.10
Chrome 52, 53, 54
Server OS: CentOS 7.2.1511
Client OS: Ubuntu 16.04

*IP addresses*
1) 172.15.1.1 - local VM (VirtualBox)
2) 192.168.22.57 - local ethernet interface
3) 192.168.41.185 - local wi-fi interface
4) 52.202.171.116 - Freeswitch IP

*Succsess case*
Chrome sends offer with this candidates (Ethernet and WI-FI addresses)
a=candidate:988003974 1 udp 2122260223 192.168.22.57 56687 typ host
generation 0 network-id 1
a=candidate:3404510875 1 udp 2122194687 192.168.41.185 57467 typ host
generation 0 network-id 4 network-cost 10
a=candidate:988003974 2 udp 2122260222 192.168.22.57 60099 typ host
generation 0 network-id 1
a=candidate:3404510875 2 udp 2122194686 192.168.41.185 54887 typ host
generation 0 network-id 4 network-cost 10
a=candidate:3148593202 1 udp 1686052607 80.254.60.17 56687 typ srflx raddr
192.168.22.57 rport 56687 generation 0 network-id 1
a=candidate:3148593202 2 udp 1686052606 80.254.60.17 60099 typ srflx raddr
192.168.22.57 rport 60099 generation 0 network-id 1

Freeswitch choose srflx candidate
2016-09-26 10:54:28.337897 [DEBUG] switch_core_media.c:6434 AUDIO RTP
[sofia/external576460752303423473 at wrike] 172.16.106.100 port 17052 ->
80.254.60.17 port 56687 codec: 111 ms: 20
Receives STUN pings from this interface and everything goes as expected -
media stream established.

*Failure case (add one interface (VirtualBox) or disable one of existing
interfaces)*
Chrome sends offer with one additional interface (VirtualBox).
a=candidate:1861086701 1 udp 2122260223 172.15.1.1 43367 typ host
generation 0 network-id 3
a=candidate:988003974 1 udp 2122194687 192.168.22.57 54230 typ host
generation 0 network-id 1
a=candidate:3404510875 1 udp 2122129151 192.168.41.185 42752 typ host
generation 0 network-id 4 network-cost 10
a=candidate:1861086701 2 udp 2122260222 172.15.1.1 55301 typ host
generation 0 network-id 3
a=candidate:988003974 2 udp 2122194686 192.168.22.57 44112 typ host
generation 0 network-id 1
a=candidate:3404510875 2 udp 2122129150 192.168.41.185 46978 typ host
generation 0 network-id 4 network-cost 10
a=candidate:3148593202 1 udp 1685987071 80.254.60.17 54230 typ srflx raddr
192.168.22.57 rport 54230 generation 0 network-id 1
a=candidate:3148593202 2 udp 1685987070 80.254.60.17 44112 typ srflx raddr
192.168.22.57 rport 44112 generation 0 network-id 1

Freeswitch choose VirtualBox interface as main candidate
2016-09-26 11:03:40.513295 [DEBUG] switch_core_media.c:6434 AUDIO RTP
[sofia/external/576460752303423471 at wrike] 172.16.106.100 port 17000 ->
172.15.1.1 port 42374 codec: 111 ms: 20

After a few STUN pings Freeswitch changes his main candidate to the public
address of my Wi-Fi interface (but it was not included in SDP by chrome and
I don't know exactly why).
2016-09-26 11:03:40.912987 [NOTICE] switch_rtp.c:1258 Auto Changing video
stun/rtp/dtls port from 172.15.1.1:43367 to 80.254.60.17:42752

Freeswitch tries to make DTLS handshake with this candidate, but fails
because Chrome ingores this "Client Hello" request.

All necessary data attached for success and failure cases (freeswitch logs,
wireshark dump made on client, SDP).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160927/155d7530/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: failure.zip
Type: application/zip
Size: 1390885 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160927/155d7530/attachment-0002.zip 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: success.zip
Type: application/zip
Size: 392671 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160927/155d7530/attachment-0003.zip