- FreeSWITCH-users - FreeSWITCH Mailing Lists

Fax to an extension of B leg
by Grzegorz Orzeł 26 Feb '21

26 Feb '21

Hi folks, I have a FreeSwitch serving multiple services. One of them is fax2mail/mail2fax. Logic is implemented as a set of lua scripts and it works fine. I’d like extend mail2fax direction. Currently it (lua script) picks number B, tiff file and sends it directly to B using command originate as follows: originate {<_bunch_of_headers_>} sofia/service/+4812345678(a)some.domain <mailto:sofia/service/+4812345678@some.domain>;user=phone &txfax(<_tiff_file_path_>) XML <_some_profile_> What I’d like to do is to add possibility to dial some other extension number. Lest’s say fax is available on +4812345678 but when the call is aswered there needs to be dialed number 123. I’ve already reviewed all FreeSwitch books on safaribooks, googled but I haven't found any example… :-/ Maybe it is enough to simply add it to the call url - I mean something like: originate {<_bunch_of_headers_>} sofia/service/+4812345678,,123(a)some.domain <mailto:123@some.domain>;user=phone &txfax(<_tiff_file_path_>) XML <_some_profile_> Can you give me some hint how to do that? Thanks in advance, Grzegorz

2 1

"Shadow calls" - duplicate calls executing in parallel
by Sam van Herwaarden 26 Feb '21

26 Feb '21

Hi all, I was just wondering if others have experienced this: on a few of the FreeSWITCH systems I've interacted with, I've observed situations where incoming phone calls seem to be duplicated. So there seem to be two call processes for the same phone number, also both receiving things like DTMF events. The timestamps of events tend to be very close (sub-second) but not necessarily identical. It's not very common, less than 1 per 1000 calls has this happening. It does tend to throw off some of our tooling (both in call handling and analysis). Curious to know if there could be an obvious cause/easy fix. Kind regards, Sam

1 0

Orphaned channels
by Ryan Delgrosso 25 Feb '21

25 Feb '21

Hi All, Ive stumbled into a situation where I see orphaned channels accumulate on FS occasionally. If from the API (not cli) i dump channels, i find some entries with a UUID and all other values null. If i do this from the CLI it seems to go to the DB which doesnt show these orphans The FS 'show status' command shows call counts which include the orphaned channels If I attempt to run any 'uuid_' commands on them I just get "-ERR No such channel!" Only hupall seems to tangibly impact these but thats a bit of a nuclear option. Any way to prevent/clean these or identify and prevent them from getting orphaned in the first place? FS Ver is 1.10.2 on CentOS using DB via odbc Thanks in advance -Ryan

1 0

DTMF not passing from the A Leg to the B Leg
by Keith Croxford 24 Feb '21

24 Feb '21

I'm coming across a strange, intermittent behavior with RFC2833 DTMF packets. This is occurring in a production environment, and I've been able to duplicate this with a very minimal FreeSWITCH installation in a virtual machine. Details of the problem: A customer occasionally has a problem report where their callers are unable to use the IVR menu. From the user's standpoint, the digits are not detected. Upon further review, we do receive DTMF event packets from the carrier, however, they do not traverse the bridge from the A leg to the B leg. >From the console logs, I see the following with the first digit. -- 2021-02-20 11:28:30.842108 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2021-02-20 11:28:30.881612 [DEBUG] switch_rtp.c:1890 rtcp_stats_init: audio ssrc[1488669269] base_seq[26830] 2021-02-20 11:28:30.933002 [DEBUG] switch_rtp.c:7550 Correct audio ip/port confirmed. 2021-02-20 11:28:34.881612 [DEBUG] switch_rtp.c:7550 Correct audio ip/port confirmed. 2021-02-20 11:28:34.923555 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 1:400 2021-02-20 11:28:34.923555 [INFO] switch_channel.c:515 RECV DTMF 1:400 2021-02-20 11:28:34.923555 [DEBUG] switch_rtp.c:5424 Send start packet for [1] ts=160 dur=160/160/400 seq=51938 lw=160 2021-02-20 11:28:34.942196 [DEBUG] switch_rtp.c:5323 Send middle packet for [1] ts=160 dur=320/320/400 seq=51939 lw=320 2021-02-20 11:28:34.942196 [DEBUG] switch_rtp.c:5323 Send end packet for [1] ts=160 dur=480/480/400 seq=51940 lw=320 2021-02-20 11:28:34.942196 [DEBUG] switch_rtp.c:5323 Send end packet for [1] ts=160 dur=480/480/400 seq=51941 lw=320 2021-02-20 11:28:34.942196 [DEBUG] switch_rtp.c:5323 Send end packet for [1] ts=160 dur=480/480/400 seq=51942 lw=320 2021-02-20 11:28:34.942196 [DEBUG] switch_rtp.c:5271 Queue digit delay of 40ms 2021-02-20 11:28:35.421487 [DEBUG] switch_rtp.c:6985 Correct audio RTCP ip/port confirmed. -- However, on the following series of digits, they are detected as seen in the logs from switch_rtp.c and switch_channel.c. However, they do not proceed to the "Send start packet" step as seen with the previous digit. This mirrors what I see on the B leg client, as it only detects the first digit. -- 2021-02-20 11:28:37.521489 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 1:400 2021-02-20 11:28:37.521489 [INFO] switch_channel.c:515 RECV DTMF 1:400 2021-02-20 11:28:46.082031 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 3:400 2021-02-20 11:28:46.082031 [INFO] switch_channel.c:515 RECV DTMF 3:400 2021-02-20 11:28:46.481377 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 6:400 2021-02-20 11:28:46.481377 [INFO] switch_channel.c:515 RECV DTMF 6:400 2021-02-20 11:28:47.061795 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 4:400 2021-02-20 11:28:47.061795 [INFO] switch_channel.c:515 RECV DTMF 4:400 2021-02-20 11:28:47.461504 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 5:400 2021-02-20 11:28:47.461504 [INFO] switch_channel.c:515 RECV DTMF 5:400 2021-02-20 11:28:47.881346 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 0:400 2021-02-20 11:28:47.881346 [INFO] switch_channel.c:515 RECV DTMF 0:400 2021-02-20 11:28:48.281220 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF 0:400 2021-02-20 11:28:48.281220 [INFO] switch_channel.c:515 RECV DTMF 0:400 2021-02-20 11:28:48.805572 [DEBUG] switch_rtp.c:7789 RTP RECV DTMF #:400 2021-02-20 11:28:48.805572 [INFO] switch_channel.c:515 RECV DTMF #:400 2021-02-20 11:29:04.881294 [NOTICE] sofia.c:1079 Hangup sofia/external/ nobody(a)192.168.1.71 [CS_EXECUTE] [NORMAL_CLEARING] -- Yet, they do arrive on the Freeswitch instances. I've attempted to add <action application="set" data="rtp_manual_rtp_bugs=ignore_dtmf_duration"/> to my inbound dialplan xml. I'm leaning toward these being a "weird" DTMF packet and not a FreeSWITCH issue, but I'm curious if anyone has encountered a similar problem, or has advice of what we could test on the FS side. -- Supporting Details: Test Environment: I took a packet capture from production and filtered it down to the A leg's RFC2833 packets, and saved this to a new file. I then used this pcap file in a SIPP UAC scenario which is acting as the A Leg. Freeswitch sits in the middle and I've configured it following this guide ( https://freeswitch.org/confluence/display/FREESWITCH/SBC+FreeSWITCH+Configu…) as a barebones SBC. Freeswitch is version 1.8.3 The B Leg is a simple pjsua client configured to answer an inbound call. -- Best Regards, KC

4 4

New system: sofia is on wrong IP address
by Steven Schoch 24 Feb '21

24 Feb '21

The last time I played with FreeSWITCH was 10 years ago, and now I'm helping a local nonprofit retire their obsolete analog phone system. I have a pbx system with 2 network cards: One dedicated to the phones, plugs into a PoE switch. On that network, the pbx has a DHCP server for the phones, as well as an FTP server for the Polycom SoundPoint IP 320 phones. The IP address on that network is 192.168.3.2. Since I'm setting up the system here at home, the other network card is on my Xfinity LAN, with an IP address of 10.0.0.167 (via DHCP from the Comcast modem). I understand the "domain" should be fairly fixed, so I set that to my "phone" network: <X-PRE-PROCESS cmd="set" data="phone_ip_v4=192.168.3.2"/> <X-PRE-PROCESS cmd="set" data="domain=$${phone_ip_v4}"/> <X-PRE-PROCESS cmd="set" data="domain_name=eastwest"/> I defined an sofia profile named "phone" with these lines: <param name="rtp-ip" value="$${phone_ip_v4}"/> <param name="sip-ip" value="$${phone_ip_v4}"/> I also used the default "internal" profile, in case an SIP device is hooked up to the main LAN, but that's not important. However, a "sofia status" shows this: Name Type Data State ================================================================================================= external-ipv6 profile sip:mod_sofia@ [2601:647:4802:9220:c816:30ae:6a9a:d191]:5080 RUNNING (0) 192.168.3.2 alias internal ALIASED external profile sip:mod_sofia@67.164.101.201:5080 RUNNING (0) external::sip2sip gateway sip:eastwest@sip2sip.info REGED external::flowroute gateway sip:6509889800@us-west-or.sip-flowroute.com NOREG phone profile sip:mod_sofia@10.0.0.167:5060 RUNNING (0) internal-ipv6 profile sip:mod_sofia@ [2601:647:4802:9220:c816:30ae:6a9a:d191]:5060 RUNNING (0) internal profile sip:mod_sofia@67.164.101.201:5060 RUNNING (0) ================================================================================================= 5 profiles 1 alias Why does the "phone" profile have "sip:mod_sofia@10.0.0.167:5060". Shouldn't that have the 192.168.3.2 address? And why isn't my phone registering? -- Steve

3 7

Working with an ancient SPA-3000 in the UK, can't get gateway registration working?
by Matthew Macdonald-Wallace 22 Feb '21

22 Feb '21

Hi all, In an attempt to add VoIP to my home network, I'm working with Freeswitch and FusionPBX. My outbound connection to the PSTN is via an aging SPA-3000, and whilst I can get the SPA-3000 to register correctly as a "user", I can't get the "gateway" side of things in FusionPBX/Freeswitch to register with the SPA-3000 for outgoing calls. All of the articles I can find online relate to the SPA-3201 or similar, which is a very different beast to the SPA-3000. The error in the logs is as follows: 2021-02-20 08:53:57.680948 [NOTICE] sofia_reg.c:454 Registering b1039375-091b-478c-86e4-11a25d3c9d00 2021-02-20 08:54:00.820948 [ERR] sofia_reg.c:2470 b1039375-091b-478c- 86e4-11a25d3c9d00 Failed Registration with status Service Unavailable [503]. failure #35 2021-02-20 08:54:01.700955 [WARNING] sofia_reg.c:511 b1039375-091b-478c- 86e4-11a25d3c9d00 Failed Registration [503], setting retry to 30 seconds. and my settings look like this: Gateway: outbound username: 1900 password: 1234 >From User: <my landline number> >From Domain: <BLANK> Proxy: <IP ADDRESS OF SPA-3000>:5060 Realm: <IP ADDRESS OF SPA-3000> Expire Seconds: 800 Retry Seconds: 30 Distinct To: <BLANK> Auth Username: user Extension <Blank> Register Transport: <BLANK> Register Proxy: <IP ADDRESS OF SPA-3000>:5060 Outbound Proxy: <IP ADDRESS OF SPA-3000> Caller ID in From: True Suppress CNG: <BLANK> Sip CID Type: <BLANK> Codec Preferences: <BLANK> Extension in Contact: <BLANK> Ping: <Blank> Ping Min: <Blank> Ping Max: <Blank> Channels: 1 Hostname: <Blank> Domain: Global Context: Public Profile: External Enabled: True Description: Blank I'm sure this is something really obvious that I'm missing in the settings, so all help is appreciated! Thanks in advance, Matt

3 2

Re: [Freeswitch-users] Chrome is deprecating plan-b SDP semantics. Will verto be updated?
by David P 21 Feb '21

21 Feb '21

I've dipped into a few of the ClueCon 2021 youtube videos in search of an announcement, but I haven't found any yet. I did see Anthony express excitement about the WebRTC spec being finalized. Has there been an announcement about verto getting unified-plan support? On Sun, 14 Feb 2021, 1:09 am , < freeswitch-users-request(a)lists.freeswitch.org> wrote: Google announced that support in Chrome for "plan-b" SDP semantics will be > removed this August: > > https://groups.google.com/g/discuss-webrtc/c/Zrsn2hi8FV0/m/KIbn0EZPBQAJ?aut… > As I understand it, this means that FS' verto js library will stop working > unless it's updated to use "unified-plan" semantics. > > I searched github and google for "verto" and "jquery.verto.js" to see if > I'd missed an announcement that this change was in-progress or done, but I > don't get a good match at either. Has it been moved out of > https://github.com/signalwire/freeswitch to a community repo? Does it > have a maintainer? > > I can't become the maintainer, but this is a serious problem for us if we > don't have a solution by August. > > Btw, Brian, thank you for your answer about HLS. >

1 0

Hardware Specification and Performance
by Praveenkumar T 20 Feb '21

20 Feb '21

Dear, I have been going through the below link and It would be helpful if you could let me know the below two points. https://freeswitch.org/confluence/display/FREESWITCH/Specifications 1. like to know more about the maximum concurrent call the free switch can support with the recommended system requirement. 2. Does it need any upgrade in the system hardware requirements/additional packages if one tries to bring SBC before the Freeswitch in case of external SIP trunk configuration. Thanks & Regards Praveen

3 2

Freeswitch High Memory Consumption
by edson＠inoutglobal.xyz 20 Feb '21

20 Feb '21

Dears, Is it possible to find out what Freeswitch's task leads operation system run out of memory? It causes OS to start OOM Killer. 1-This is a backtrace Log output. https://pastebin.com/SLEPh4p2 2-dmesg output showing OOM killer in action. [1385455.947689] Out of memory: Kill process 21698 (freeswitch) score 834 or sacrifice child [1385455.956673] Killed process 21698 (freeswitch) total-vm:12718944kB, anon-rss:8202856kB, file-rss:0kB, shmem-rss:0kB Regards, Edson

2 1

Realtime audio translation English <--> Spanish
by Chad Phillips 19 Feb '21

19 Feb '21

Google's translation service seems like it could support realtime translation of a conversation between an English and Spanish speaker. Granted, there would be delays in translation, but that would be no different than a live interpreter. I'm imagining: Spanish <--> FreeSWITCH <--> Google Translate <--> FreeSWITCH <--> English ...such that the audio of both speakers would not go directly to the other party, but would instead be passed to Google Translate, with the returned audio being played to the other party. Has anybody taken a crack at this? Chad

4 3