- FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] One-way audio but not video on 10.4
by David P 30 Aug '20

30 Aug '20

> > I strongly suspect the problem is due to FS choosing a different port than is offered. I've seen this a few times by comparing the offer SDP a=candidate entries with the address:port in FS log entries containing 'Choose rtp'. This won't work if the user is behind a firewall that allows incoming response only through ports opened for outgoing requests. Another thing I wonder about is when verto provides a BUNDLE offer, should it use the same address and port for both audio and video. I think I've seen that it doesn't, but maybe BUNDLE doesn't require it. --------- Forwarded message ---------- > From: Nathan Stratton <nathan(a)robotics.net> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Cc: > Bcc: > Date: Sat, 29 Aug 2020 11:13:24 -0400 > Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4 > Looks like your client is not hitting a stun server to get the public IP > address, however, I have been wondering why it's not possible to make > FreeSWITCH work without using STUN on the client as long as FreeSWITCH is > on a public IP. > > ><> > nathan stratton > > > On Sat, Aug 29, 2020 at 3:00 AM David P <davidswalkabout(a)gmail.com> wrote: > >> The client is current verto running on current Chrome/Win10. >> >> The client's SDP shows srflx and relay candidates from Twilio at same >> network cost as the "private" host candidates, and FSv10.4 chooses the host >> candidates. >> >> ---------- Forwarded message ---------- >>> From: Mike Jerris <mike(a)freeswitch.org> >>> >>> If client still isn’t putting in non rfc1918 candidates in audio you >>> need to figure out why that is first. >>> >>> On Aug 26, 2020, at 7:17 PM, David P <davidswalkabout(a)gmail.com> wrote: >>> >>> I've introduced Twilio STUN and TURN to our iceServers since then. All >>> have the same network cost in the SDP and FSv10.4 chooses a host. Verto >>> reports the remote stream arrived but getStats shows zero audio bytes in or >>> out, and it's silent to our user. I applied a display filter using our >>> Freeswitch's public IP ip.src == 52.xx.yy.zz or ip.dst == ip.src == >>> 52.xx.yy.zz and in addition to TLS I see some TCP ACKs from our user's >>> 10.0.0.189 but I don't know what else to look for. >>> >>> >>> ---------- Forwarded message ---------- >>>> From: Mike Jerris <mike(a)freeswitch.org> >>>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> >>>> Cc: >>>> Bcc: >>>> Date: Wed, 26 Aug 2020 16:19:56 -0400 >>>> Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4 >>>> >>> >>> >>>> Configure stun in your client so you get proper candidates that are >>>> reachable. >>>> >>>> On Aug 19, 2020, at 6:18 PM, David P <davidswalkabout(a)gmail.com> wrote: >>>> >>>> Yesterday I had a verto call in which the <video> contained a remote >>>> echo (which is how we configure it) but there was no audio out nor in >>>> (confirmed by getStats showing zero audio bytes out or in). >>>> >>>> I was using: >>>> FreeSWITCH Version 1.10.4-release+git~20200805T110119Z~133fc2c870~64bit >>>> (git 133fc2c 2020-08-05 11:01:19Z 64bit) >>>> from Chrome84/Win10 >>>> >>>> I noticed the video candidates included a relay but the audio ones >>>> didn't: >>>> >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e m=audio 62058 UDP/TLS/RTP/SAVPF >>>> 111 103 104 9 0 8 106 105 13 110 112 113 126 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 192.168.208.1 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp >>>> 2122260223 192.168.208.1 62058 typ host generation 0 network-id 1 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp >>>> 2122194687 172.20.4.169 62059 typ host generation 0 network-id 2 >>>> network-cost 10 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp >>>> 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp >>>> 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 >>>> network-cost 10 >>>> >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e m=video 13143 UDP/TLS/RTP/SAVPF 96 >>>> 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 35.160.47.89 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp >>>> 2122260223 192.168.208.1 62060 typ host generation 0 network-id 1 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp >>>> 2122194687 172.20.4.169 62061 typ host generation 0 network-id 2 >>>> network-cost 10 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp >>>> 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp >>>> 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 >>>> network-cost 10 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:3112167340 1 udp >>>> 25042943 35.jj.kk.mm 13143 typ relay raddr 210.55.134.98 rport 53504 >>>> generation 0 network-id 2 network-cost 10 >>>> >>>> The relay was chosen for video, and it appeared that the same candidate >>>> was going to be chosen for audio, but then an "AUDIO RTP" suggests it chose >>>> a private IPv4. And it seems that private IPv4 wasn't treated as a >>>> peer-reflexive candidate, so the media couldn't be routed... >>>> >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >>>> switch_core_media.c:4338 Choose rtp candidate, index 2, >>>> 35.jj.kk.mm:13143 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >>>> switch_core_media.c:4104 >>>> verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4 choosing family >>>> v4 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >>>> switch_core_media.c:4349 Choose same candidate, index 0, for rtcp based on >>>> rtcp-mux attribute 35.jj.kk.mm:13143 >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >>>> switch_core_media.c:4401 setting remote video ice addr to index 2 >>>> 35.jj.kk.mm:13143 based on candidate >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >>>> switch_core_media.c:4436 Setting remote rtcp video addr to >>>> 35.jj.kk.mm:13143 based on candidate >>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >>>> switch_core_media.c:8663 AUDIO RTP >>>> [verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4] 10.0.0.100 >>>> port 26610 -> 192.168.208.1 port 62058 codec: 111 ms: 20 >>>> >>>> Am I interpreting the log correctly? >>>> >>>> Is there a way to avoid this? >>>> >>>> Note that in /usr/local/freeswitch/conf/autoload_configs/acl.conf.xml >>>> we already deny private IPv4 (although I think we should allow them so they >>>> could be used peer-reflexively): >>>> <list name="disallow-privateIPv4" default="allow"> >>>> <node type="deny" host="10.0.0.0" mask="255.0.0.0"/> >>>> <node type="deny" host="172.16.0.0" mask="255.240.0.0"/> >>>> <node type="deny" host="192.168.0.0" mask="255.255.0.0"/> >>>> </list> >>>> >>>> >>> >>

1 0

Re: [Freeswitch-users] One-way audio but not video on 10.4
by David P 29 Aug '20

29 Aug '20

The client is current verto running on current Chrome/Win10. The client's SDP shows srflx and relay candidates from Twilio at same network cost as the "private" host candidates, and FSv10.4 chooses the host candidates. ---------- Forwarded message ---------- > From: Mike Jerris <mike(a)freeswitch.org> > > If client still isn’t putting in non rfc1918 candidates in audio you need > to figure out why that is first. > > On Aug 26, 2020, at 7:17 PM, David P <davidswalkabout(a)gmail.com> wrote: > > I've introduced Twilio STUN and TURN to our iceServers since then. All > have the same network cost in the SDP and FSv10.4 chooses a host. Verto > reports the remote stream arrived but getStats shows zero audio bytes in or > out, and it's silent to our user. I applied a display filter using our > Freeswitch's public IP ip.src == 52.xx.yy.zz or ip.dst == ip.src == > 52.xx.yy.zz and in addition to TLS I see some TCP ACKs from our user's > 10.0.0.189 but I don't know what else to look for. > > > ---------- Forwarded message ---------- >> From: Mike Jerris <mike(a)freeswitch.org> >> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> >> Cc: >> Bcc: >> Date: Wed, 26 Aug 2020 16:19:56 -0400 >> Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4 >> > > >> Configure stun in your client so you get proper candidates that are >> reachable. >> >> On Aug 19, 2020, at 6:18 PM, David P <davidswalkabout(a)gmail.com> wrote: >> >> Yesterday I had a verto call in which the <video> contained a remote echo >> (which is how we configure it) but there was no audio out nor in (confirmed >> by getStats showing zero audio bytes out or in). >> >> I was using: >> FreeSWITCH Version 1.10.4-release+git~20200805T110119Z~133fc2c870~64bit >> (git 133fc2c 2020-08-05 11:01:19Z 64bit) >> from Chrome84/Win10 >> >> I noticed the video candidates included a relay but the audio ones didn't: >> >> f6e23797-4ad2-b761-2a6d-97846c122d7e m=audio 62058 UDP/TLS/RTP/SAVPF 111 >> 103 104 9 0 8 106 105 13 110 112 113 126 >> f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 192.168.208.1 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp >> 2122260223 192.168.208.1 62058 typ host generation 0 network-id 1 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp >> 2122194687 172.20.4.169 62059 typ host generation 0 network-id 2 >> network-cost 10 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp >> 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp >> 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 >> network-cost 10 >> >> f6e23797-4ad2-b761-2a6d-97846c122d7e m=video 13143 UDP/TLS/RTP/SAVPF 96 >> 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116 >> f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 35.160.47.89 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp >> 2122260223 192.168.208.1 62060 typ host generation 0 network-id 1 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp >> 2122194687 172.20.4.169 62061 typ host generation 0 network-id 2 >> network-cost 10 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp >> 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp >> 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 >> network-cost 10 >> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:3112167340 1 udp >> 25042943 35.jj.kk.mm 13143 typ relay raddr 210.55.134.98 rport 53504 >> generation 0 network-id 2 network-cost 10 >> >> The relay was chosen for video, and it appeared that the same candidate >> was going to be chosen for audio, but then an "AUDIO RTP" suggests it chose >> a private IPv4. And it seems that private IPv4 wasn't treated as a >> peer-reflexive candidate, so the media couldn't be routed... >> >> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >> switch_core_media.c:4338 Choose rtp candidate, index 2, 35.jj.kk.mm:13143 >> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >> switch_core_media.c:4104 >> verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4 choosing family >> v4 >> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >> switch_core_media.c:4349 Choose same candidate, index 0, for rtcp based on >> rtcp-mux attribute 35.jj.kk.mm:13143 >> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >> switch_core_media.c:4401 setting remote video ice addr to index 2 >> 35.jj.kk.mm:13143 based on candidate >> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >> switch_core_media.c:4436 Setting remote rtcp video addr to >> 35.jj.kk.mm:13143 based on candidate >> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] >> switch_core_media.c:8663 AUDIO RTP >> [verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4] 10.0.0.100 >> port 26610 -> 192.168.208.1 port 62058 codec: 111 ms: 20 >> >> Am I interpreting the log correctly? >> >> Is there a way to avoid this? >> >> Note that in /usr/local/freeswitch/conf/autoload_configs/acl.conf.xml we >> already deny private IPv4 (although I think we should allow them so they >> could be used peer-reflexively): >> <list name="disallow-privateIPv4" default="allow"> >> <node type="deny" host="10.0.0.0" mask="255.0.0.0"/> >> <node type="deny" host="172.16.0.0" mask="255.240.0.0"/> >> <node type="deny" host="192.168.0.0" mask="255.255.0.0"/> >> </list> >> >> >

2 1

Re: [Freeswitch-users] One-way audio but not video on 10.4
by David P 27 Aug '20

27 Aug '20

I've introduced Twilio STUN and TURN to our iceServers since then. All have the same network cost in the SDP and FSv10.4 chooses a host. Verto reports the remote stream arrived but getStats shows zero audio bytes in or out, and it's silent to our user. I applied a display filter using our Freeswitch's public IP ip.src == 52.xx.yy.zz or ip.dst == ip.src == 52.xx.yy.zz and in addition to TLS I see some TCP ACKs from our user's 10.0.0.189 but I don't know what else to look for. ---------- Forwarded message ---------- > From: Mike Jerris <mike(a)freeswitch.org> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Cc: > Bcc: > Date: Wed, 26 Aug 2020 16:19:56 -0400 > Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4 > > Configure stun in your client so you get proper candidates that are > reachable. > > On Aug 19, 2020, at 6:18 PM, David P <davidswalkabout(a)gmail.com> wrote: > > Yesterday I had a verto call in which the <video> contained a remote echo > (which is how we configure it) but there was no audio out nor in (confirmed > by getStats showing zero audio bytes out or in). > > I was using: > FreeSWITCH Version 1.10.4-release+git~20200805T110119Z~133fc2c870~64bit > (git 133fc2c 2020-08-05 11:01:19Z 64bit) > from Chrome84/Win10 > > I noticed the video candidates included a relay but the audio ones didn't: > > f6e23797-4ad2-b761-2a6d-97846c122d7e m=audio 62058 UDP/TLS/RTP/SAVPF 111 > 103 104 9 0 8 106 105 13 110 112 113 126 > f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 192.168.208.1 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp > 2122260223 192.168.208.1 62058 typ host generation 0 network-id 1 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp > 2122194687 172.20.4.169 62059 typ host generation 0 network-id 2 > network-cost 10 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp 1518280447 > 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp > 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 > network-cost 10 > > f6e23797-4ad2-b761-2a6d-97846c122d7e m=video 13143 UDP/TLS/RTP/SAVPF 96 97 > 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116 > f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 35.160.47.89 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp > 2122260223 192.168.208.1 62060 typ host generation 0 network-id 1 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp > 2122194687 172.20.4.169 62061 typ host generation 0 network-id 2 > network-cost 10 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp 1518280447 > 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp > 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 > network-cost 10 > f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:3112167340 1 udp 25042943 > 35.jj.kk.mm 13143 typ relay raddr 210.55.134.98 rport 53504 generation 0 > network-id 2 network-cost 10 > > The relay was chosen for video, and it appeared that the same candidate > was going to be chosen for audio, but then an "AUDIO RTP" suggests it chose > a private IPv4. And it seems that private IPv4 wasn't treated as a > peer-reflexive candidate, so the media couldn't be routed... > > f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] > switch_core_media.c:4338 Choose rtp candidate, index 2, 35.jj.kk.mm:13143 > f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] > switch_core_media.c:4104 > verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4 choosing family > v4 > f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] > switch_core_media.c:4349 Choose same candidate, index 0, for rtcp based on > rtcp-mux attribute 35.jj.kk.mm:13143 > f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] > switch_core_media.c:4401 setting remote video ice addr to index 2 > 35.jj.kk.mm:13143 based on candidate > f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] > switch_core_media.c:4436 Setting remote rtcp video addr to > 35.jj.kk.mm:13143 based on candidate > f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] > switch_core_media.c:8663 AUDIO RTP > [verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4] 10.0.0.100 > port 26610 -> 192.168.208.1 port 62058 codec: 111 ms: 20 > > Am I interpreting the log correctly? > > Is there a way to avoid this? > > Note that in /usr/local/freeswitch/conf/autoload_configs/acl.conf.xml we > already deny private IPv4 (although I think we should allow them so they > could be used peer-reflexively): > <list name="disallow-privateIPv4" default="allow"> > <node type="deny" host="10.0.0.0" mask="255.0.0.0"/> > <node type="deny" host="172.16.0.0" mask="255.240.0.0"/> > <node type="deny" host="192.168.0.0" mask="255.255.0.0"/> > </list> > >

2 1

faxploit
by mayamatakeshi 26 Aug '20

26 Aug '20

Hi, *Check Point researchers have discovered a vulnerability in the ITU T.30 fax protocol that could be hacked to launch a cyberattack and gain access to a network.* https://www.healthcareitnews.com/news/fax-machines-can-be-hacked-breach-net… The phrase above indicates a flaw in the T.30 protocol itself and not in particular implementations. This is from 2018. I don't remember reading anything about this in the fs mailing list. Was freeswitch/spandsp audited to ensure application rxfax is safe? https://blog.checkpoint.com/2018/08/12/faxploit-hp-printer-fax-exploit/

4 4

One-way audio but not video on 10.4
by David P 26 Aug '20

26 Aug '20

Yesterday I had a verto call in which the <video> contained a remote echo (which is how we configure it) but there was no audio out nor in (confirmed by getStats showing zero audio bytes out or in). I was using: FreeSWITCH Version 1.10.4-release+git~20200805T110119Z~133fc2c870~64bit (git 133fc2c 2020-08-05 11:01:19Z 64bit) from Chrome84/Win10 I noticed the video candidates included a relay but the audio ones didn't: f6e23797-4ad2-b761-2a6d-97846c122d7e m=audio 62058 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 192.168.208.1 f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp 2122260223 192.168.208.1 62058 typ host generation 0 network-id 1 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp 2122194687 172.20.4.169 62059 typ host generation 0 network-id 2 network-cost 10 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 network-cost 10 f6e23797-4ad2-b761-2a6d-97846c122d7e m=video 13143 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116 f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 35.160.47.89 f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp 2122260223 192.168.208.1 62060 typ host generation 0 network-id 1 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp 2122194687 172.20.4.169 62061 typ host generation 0 network-id 2 network-cost 10 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 network-cost 10 f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:3112167340 1 udp 25042943 35.jj.kk.mm 13143 typ relay raddr 210.55.134.98 rport 53504 generation 0 network-id 2 network-cost 10 The relay was chosen for video, and it appeared that the same candidate was going to be chosen for audio, but then an "AUDIO RTP" suggests it chose a private IPv4. And it seems that private IPv4 wasn't treated as a peer-reflexive candidate, so the media couldn't be routed... f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4338 Choose rtp candidate, index 2, 35.jj.kk.mm:13143 f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4104 verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4 choosing family v4 f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4349 Choose same candidate, index 0, for rtcp based on rtcp-mux attribute 35.jj.kk.mm:13143 f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4401 setting remote video ice addr to index 2 35.jj.kk.mm:13143 based on candidate f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4436 Setting remote rtcp video addr to 35.jj.kk.mm:13143 based on candidate f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:8663 AUDIO RTP [verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4] 10.0.0.100 port 26610 -> 192.168.208.1 port 62058 codec: 111 ms: 20 Am I interpreting the log correctly? Is there a way to avoid this? Note that in /usr/local/freeswitch/conf/autoload_configs/acl.conf.xml we already deny private IPv4 (although I think we should allow them so they could be used peer-reflexively): <list name="disallow-privateIPv4" default="allow"> <node type="deny" host="10.0.0.0" mask="255.0.0.0"/> <node type="deny" host="172.16.0.0" mask="255.240.0.0"/> <node type="deny" host="192.168.0.0" mask="255.255.0.0"/> </list> Cheers, David

2 1

Handling client network changes
by Lợi Đặng 26 Aug '20

26 Aug '20

Hi all, I'm facing a problem dealing with network change on the client that communicates with FreeSwitch server. Before: X1:Y1 <-> FreeSwitchIP:5060 After: X2:Y2 <-> FreeSwitchIP:5060 When the call is established, i.e: initial INVITE answered, everything work fine to me with the use of re-INVITE following rfc3261 on modifying an existing dialog: FreeSwitch recognize my client changed to X2:Y2 and later BYE routed properly. But when the call is NOT established and in early-media state, I have to use the UPDATE and the result is not as expected. Although FreeSwitch also recognized my client changed to X2:Y2 but only for later transactions and BYE, the 200 OK of the initial INVITE is still routed to X1:Y1. That does not meet my requirement as the expectation is X1:Y1 not usable in the middle of the call. I understand that UPDATE may not be suitable for such cases since it's a different transaction from the initial INVITE, also not even the problem with FreeSwitch alone, but can you help to point me out on this? Wanted to know if there's any rfc suitable. A workaround is to create a complete new call with SIP Replaces header at X2:Y2 containing the dialog info of old call at X1:Y1, resulting in FreeSwitch having a very nice replacement, but it's a bit costly to me in another story. Any help would be appreciated. rgds, Loi Dang Thanh Phone : +84. 774.735.448 Email : loi.dangthanh(a)gmail.com

1 0

[FreeSWITCH changes Session limits to lower numbers]
by Bilal Abbasi 26 Aug '20

26 Aug '20

Hi Users, I am actually doing some stress testing with FreeSWITCH version 1.10. I have set session limit to 1000 and just sending 2CPS but when calls go beyond around 200, it shows me below log and lowers the session limit. Artoo reduces the max sessions to 234 thus, saving the switch from certain doom. 2019-12-16 13:23:07.504847 [CRIT] switch_core_session.c:1818 LUKE'S VOICE: Artoo, see what you can do with it. Hang on back there.... It's 8core 32GB physical machine, and the only change in my FS is that i am using mod_avmd to detect beep. Now what i am really looking for is, if i can disable this behaviour of FreeSWITCH, As it automatically lowers the Session limit to 200-300 range.(which is very low, even if the switch can handle say 500 calls later, it will remain 200-300 sessions). Regards Abbasi

3 2

Docker or a traditional VM-based deployment?
by Flavio Donadio 26 Aug '20

26 Aug '20

Hello, all! I am deploying a small FreeSWITCH-based PBX for my business. It’s a really simple and light configuration: around 10 extensions, one SIP trunk, conferencing (audio only). call recording (user started), very simple IVR, fax reception… So simple that even I can do it myself! :D About performance: the most demanding scenario is 10 simultaneous calls, every single one being recorded. Since my business is going “officeless”, I will host this PBX in the cloud. I still haven’t chosen my cloud provider for this, but Azure looks tempting, as I’m already a Microsoft customer (Office 365). Other options are Amazon and Oracle... I’ve been reading a lot about containerization and, although I don't need most of the advantages provided by it, I will be hosting other apps (web-based internal business apps) through other mechanisms (microservices, serverless, etc.), so I thought: maybe a single VM, only for my little PBX, is overkill. Questions: 1. Is Docker hosting more cost-effective for FreeSWITCH? 2. Is there any other advantage, besides cost (and the inherent advantages of containerization, of course), in hosting a FreeSWITCH-based PBX in a container? 3. If not, what is the absolute minimum VM config I should use? Important: I don’t want to use a third-party service. I want to manage my own FreeSWITCH installation. Kind Regards, Flavio

7 14

Specifying G722.1 bitrate
by Andrew White 25 Aug '20

25 Aug '20

Hi all, Our server has had someone send us the following SDP: v=0 o=- 1598394304 1598394304 IN IP4 1.2.3.4 s=- c=IN IP4 1.2.3.4 t=0 0 m=audio 14198 RTP/AVP 8 0 96 9 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G7221/16000 a=fmtp:96 bitrate=24000 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=silenceSupp:off - - - - We have the following configuration in our vars.xml file: <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G7221@16000h,G7221@32000h,OPUS,G722,PCMU,PCMA”/> However the debug log shows the following output: e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[G7221:107:16000:20:32000:1] e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[G7221:115:32000:20:48000:1] …snip… e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [G7221:96:16000:20:24000:1]/[G7221:107:16000:20:32000:1] e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [G7221:96:16000:20:24000:1]/[G7221:115:32000:20:48000:1] e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [G7221:96:16000:20:24000:1]/[opus:116:48000:20:0:1] e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [G7221:96:16000:20:24000:1]/[G722:9:8000:20:64000:1] e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [G7221:96:16000:20:24000:1]/[PCMU:0:8000:20:64000:1] e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [G7221:96:16000:20:24000:1]/[PCMA:8:8000:20:64000:1] …snip… e95e4aaa-e721-11ea-ba06-4735eb6f008b 2020-08-26 08:25:42.327098 [DEBUG] switch_core_media.c:3781 Set Codec sofia/mrf/nobody(a)4.5.6.7 <mailto:sofia/mrf/nobody@4.5.6.7>:5060 G722/8000 20 ms 160 samples 64000 bits 1 channels It seems we’re trying to match G722.1 16-24k (from the sender) with G722.1 16-32k (which we have configured). I cannot however find a way to configure G722.1 in FreeSWITCH to accept that bitrate range. I did try setting “G7221@24000h” in the vars.xml file, however this didn’t seem to have any effect It’s entirely possible I’ve also misunderstood the issue here, so any direction would be very much appreciated. Thanks in advance! Andrew

1 0

Can mod_python be adapted tap media?
by David P 24 Aug '20

24 Aug '20

Hi Brian, We need a media bug that allows us to process inbound audio and video using python. What's the best way to do this? Should we diff mod_python with mod_cv to see what C fns to add to the former in order to receive video streams? And diff with something else to find what audio handlers to add to mod_python? In ClueCon session 2, Nickolay seemed to indicate a need for this also. He streams audio out of FS using unimrcp but mentions that that can't be load-balanced. The other alternative, rtmp, imposes several seconds of latency at the start. It seems that load-balancing media connections into a farm of FSs, and doing media handling in a module, would be better overall. Yet there seems no guidance about how to implement it. That's what a media bug does. record_session is an example of such functionality. /b On Mon, Aug 10, 2020 at 1:24 AM David P <davidswalkabout(a)gmail.com> wrote: Where can I find guidance about creating a media bug for audio+video? Adapt mod_cv? I'd like the inbound streams to be handled by a scriptable env like python. Or could streams be exposed to mod_python?

1 0