Fwd: Freeswitch uses wrong ICE candidate to establish connection
---------- Forwarded message ---------- From: Александр Дружилов <alexdruzhilov@gmail.com> Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@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@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@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).
Are you using mod_sofia with sip or mod_verto ? can you try with varto-communicator and mod_verto wss port ? On Tue, Sep 27, 2016 at 11:09 AM, Александр Дружилов < alexdruzhilov@gmail.com> wrote:
---------- Forwarded message ---------- From: Александр Дружилов <alexdruzhilov@gmail.com> Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@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@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@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@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@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 ¯\_(ツ)_/¯
Bugs get reported to Jira @ https://freeswitch.org/jira so they don’t fall thru the cracks From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of ????????? ???????? Sent: Tuesday, September 27, 2016 4:10 AM To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection ---------- Forwarded message ---------- From: Александр Дружилов <alexdruzhilov@gmail.com <mailto:alexdruzhilov@gmail.com> > Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@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@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 <http://172.15.1.1:43367> to 80.254.60.17:42752 <http://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).
"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/browse/FS-9570). 2016-09-27 16:35 GMT+03:00 Ken Rice <krice@freeswitch.org>:
Bugs get reported to Jira @ https://freeswitch.org/jira so they don’t fall thru the cracks
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *????????? ???????? *Sent:* Tuesday, September 27, 2016 4:10 AM *To:* freeswitch-users@lists.freeswitch.org *Subject:* [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection
---------- Forwarded message ---------- From: *Александр Дружилов* <alexdruzhilov@gmail.com> Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
If you have already reported this on Jira, that’s the best place to hold discussions of the ticket… that way it doesn’t get lost among all the messages flying around on the mailing list From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of ????????? ???????? Sent: Tuesday, September 27, 2016 8:58 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection "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/browse/FS-9570). 2016-09-27 16:35 GMT+03:00 Ken Rice <krice@freeswitch.org <mailto:krice@freeswitch.org> >: Bugs get reported to Jira @ https://freeswitch.org/jira so they don’t fall thru the cracks From: freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> ] On Behalf Of ????????? ???????? Sent: Tuesday, September 27, 2016 4:10 AM To: freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org> Subject: [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection ---------- Forwarded message ---------- From: Александр Дружилов <alexdruzhilov@gmail.com <mailto:alexdruzhilov@gmail.com> > Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@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@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 <http://172.15.1.1:43367> to 80.254.60.17:42752 <http://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@freeswitch.org <mailto:consulting@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@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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/ browse/FS-9570).
2016-09-27 16:35 GMT+03:00 Ken Rice <krice@freeswitch.org>:
Bugs get reported to Jira @ https://freeswitch.org/jira so they don’t fall thru the cracks
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *????????? ???????? *Sent:* Tuesday, September 27, 2016 4:10 AM *To:* freeswitch-users@lists.freeswitch.org *Subject:* [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection
---------- Forwarded message ---------- From: *Александр Дружилов* <alexdruzhilov@gmail.com> Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@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@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@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@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@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@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@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 ¯\_(ツ)_/¯
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@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@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@freeswitch.org>:
Bugs get reported to Jira @ https://freeswitch.org/jira so they don’t fall thru the cracks
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *????????? ???????? *Sent:* Tuesday, September 27, 2016 4:10 AM *To:* freeswitch-users@lists.freeswitch.org *Subject:* [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection
---------- Forwarded message ---------- From: *Александр Дружилов* <alexdruzhilov@gmail.com> Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@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@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@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@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@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@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@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 ¯\_(ツ)_/¯
If its on Jira, lets put the relevant info there. Putting info here separate from the bug only makes it more likely we will miss a critical deal.
On Sep 27, 2016, at 10:55 AM, Mirko Brankovic <mirkobrankovic@gmail.com> wrote:
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@gmail.com <mailto:mirkobrankovic@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@gmail.com <mailto:alexdruzhilov@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/browse/FS-9570 <https://freeswitch.org/jira/browse/FS-9570>).
2016-09-27 16:35 GMT+03:00 Ken Rice <krice@freeswitch.org <mailto:krice@freeswitch.org>>: Bugs get reported to Jira @ https://freeswitch.org/jira <https://freeswitch.org/jira> so they don’t fall thru the cracks
From: freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of ????????? ???????? Sent: Tuesday, September 27, 2016 4:10 AM To: freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org> Subject: [Freeswitch-users] Fwd: Freeswitch uses wrong ICE candidate to establish connection
---------- Forwarded message ---------- From: Александр Дружилов <alexdruzhilov@gmail.com <mailto:alexdruzhilov@gmail.com>> Date: 2016-09-26 14:31 GMT+03:00 Subject: Freeswitch uses wrong ICE candidate to establish connection To: freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@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@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 <http://172.15.1.1:43367/> to 80.254.60.17:42752 <http://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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
-- Regards, Mirko ¯\_(ツ)_/¯
-- Regards, Mirko ¯\_(ツ)_/¯
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Ken Rice
-
Michael Jerris
-
Mirko Brankovic
-
Александр Дружилов