August 2020 - FreeSWITCH-users - FreeSWITCH Mailing Lists

CNG Detection for T.38 <--> G.711 Transcoding
by Gabriel Kuri 31 Aug '20

31 Aug '20

Hi All: Trying to do T.38 <--> G.711 transcoding using "t38_gateway=self cng" in the dialplan. Here's the scenario... A-leg: Analog Telephone Adapter (T.38) FS in the middle B-leg: Out to Carrier/Provider (G.711u) The ATA initiates the call outbound to the carrier/provider. The far end FAX machine picks up and the call begins. I'm wanting FS to Re-INVITE T.38 to the ATA on the a-leg when it detects a CNG tone. That seems to work about 50% of the time (on average). The other 50% of the time, it doesn't seem to detect the FAX tone and the call stays as G.711u and eventually fails. Below is the dialplan for reference. I'm guessing the CNG tone detection on FS is hit and miss because of a timing issue, but I'm not really sure. Is it possible to detect the CED, V.21 Preamble, or /ANSAM of the receiving fax (far-end), in order to try and make the switchover more reliable? Or am I barking up the wrong tree here and/or possibly doing something wrong? For what it's worth, I've also tried changing the dialplan to have FS force the T.38 Re-INVITE "nocng" (ie execute_on_answer=t38_gateway self nocng), and FS Re-INVITEs T.38 immediately after the 200 OK. While the ATA seems to accept the T.38 Re-INVITE, it then stops sending RTP/UDPTL traffic entirely and the call eventually fails. It doesn't seem to like the Re-INVITE when it occurs that fast. I've also tried this on multiple ATAs with the same result. Thanks! <extension name="to_fax_dest"> <condition field="destination_number" expression="^\+\d{11}$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="t38_passthru=false"/> <action application="set" data="fax_verbose=true"/> <action application="set" data="fax_enable_t38_request=true"/> <action application="set" data="execute_on_answer=t38_gateway self cng"/> <action application="bridge" data="{refuse_t38=true}sofia/sip/xxxxx(a)aa.bb.cc.dd"/> </condition> </extension>

1 0

Re: [Freeswitch-users] FreeSWITCH suddenly have a child processes
by ziv＠ip-com.co.il 31 Aug '20

31 Aug '20

Hello � We have an occasional situation where the one FreeSWITCH process suddenly have a child process. We do not know what circumstances may have caused it. Happens every few days. The child process consumes memory like the normal process, which is a significant amount. It doesn’t consume CPU. In the case that we didn’t restart FreeSWITCH after the problem happened, later it happened again and we had 2 child processes. When killing the child process, FreeSWITCH seems to continue working normally, but this is not a thing we’d do on our production machines. Happens on one specific FreeSWITCH, our other machines do not show this behavior. The FreeSWITCH log for the time the child process starts shows initialization messages as when the normal process starts, but nothing that could tell us why the child starts. � After noticing the issue on FreeSWITCH 1.8.5, we upgraded to 1.10.5 via “apt” (didn’t build from source) but the problem is still there. � O/S: Debian 9.13 (we didn’t upgrade it when upgraded FreeSWITCH) FreeSWITCH: 1.10.5-release-17-25569c1631~64bit We use FusionPBX to operate the system. � “ps -ef” shows: UID PID PPID C STIME TTY TIME CMD freeswi+ 470 23710 0 11:25 ? 00:00:00 /usr/bin/freeswitch -ncwait -nonat freeswi+ 23710 1 62 Aug26 ? 1-11:31:26 /usr/bin/freeswitch -ncwait -nonat � “top” shows PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23710 freeswi+ -2 19 3627008 1.543g 13972 S 110.7 20.7 2136:50 freeswitch 470 freeswi+ 39 19 3615296 1.507g 884 S 0.0 20.2 0:00.02 freeswitch � An advice will be appreciated, Ziv

2 1

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