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

Tue Sep 27 18:55:20 MSD 2016

actuallly i forgot kvm, so I have 3 virtual and one real local IP:
ifconfig | grep inet
          inet addr:172.18.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet addr:10.0.0.112  Bcast:10.0.1.255  Mask:255.255.254.0
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0

On Tue, Sep 27, 2016 at 4:48 PM, Mirko Brankovic <mirkobrankovic at gmail.com>
wrote:

> Well I was using mod_verto and I have local on laptop, lan, wifi, virbr0
> (virtualbox), docker0 with local IP and had no issues so far
>
> On Tue, Sep 27, 2016 at 3:57 PM, Александр Дружилов <
> alexdruzhilov at gmail.com> wrote:
>
>> "Are you using mod_sofia with sip or mod_verto ?"
>> We are using mod_sofia.
>>
>> "can you try with varto-communicator and mod_verto wss port ?"
>> Can you please explain how it could be helpful in case of this problem?
>>
>> I have already reported issue in Jira (https://freeswitch.org/jira/b
>> rowse/FS-9570).
>>
>> 2016-09-27 16:35 GMT+03:00 Ken Rice <krice at freeswitch.org>:
>>
>>> Bugs get reported to Jira @ https://freeswitch.org/jira  so they don’t
>>> fall thru the cracks
>>>
>>>
>>>
>>> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
>>> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *?????????
>>> ????????
>>> *Sent:* Tuesday, September 27, 2016 4:10 AM
>>> *To:* freeswitch-users at lists.freeswitch.org
>>> *Subject:* [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).
>>>
>>>
>>>
>>> ____________________________________________________________
>>> _____________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
>
> --
> Regards,
> Mirko
>
> ¯\_(ツ)_/¯
>
>

-- 
Regards,
Mirko

¯\_(ツ)_/¯
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160927/f21ff05d/attachment-0001.html 