December 2019 - FreeSWITCH-users - FreeSWITCH Mailing Lists

No Adminer subcategory found in Default Setting
by ankit jobanputra 12 Dec '19

12 Dec '19

Hi all, I have freshly installed fusionpbx on my Debian 9.5 os. I didn't find the Adminer in Advanced tab, and as the version is 4.2+ I need to do auto-login to true in Default setting - adminer. But I didn't find that setting too. And I tried to add the same setting in Default setting option but I still didn't find the Adminer in advanced tab. Thanks in advance for your help

2 1

Upgrading from 1.8 to 1.10 on Debian 9
by Bruce Marriner 11 Dec '19

11 Dec '19

Hi, I'm sorry if this is documented already, I tried to find my answer on confluence but didn't have any luck. Is it possible and safe to upgrade directly from 1.8 to 1.10 on Debian 9? Is the procedure documented anywhere? Are there any concerns or problems I should expect? (I did see the note about pgsql change). Thanks.

1 0

DTMF when I originate a call
by Sam van Herwaarden 11 Dec '19

11 Dec '19

Hi, I'm building an application that interfaces with FreeSWITCH through mod_erlang_event. For inbound calls (where a user dials my extension) everything works the way I expect. Unfortunately for outbound calls somehow my DTMF events are not coming through. It seems I'm not the first one to experience this issue, but the solutions I find online do not seem to fix the problem for me. This is what my basic originate command looks like (through mod_erlang_event): {foo, freeswitch@fsdev} ! {api, originate, "{origination_caller_id_number=123456,Paddy-Survey=monitoring,Paddy-Question=intro1}user/1003 123456 XML default 1003 1003"}. Based on solutions online I've experimented with adding execute_after_bridge_app=start_dtmf, execute_on_answer=start_dtmf, dtmf_type=info and drop_dtmf=false to the channel variables but none of those seem to help. (The origination caller ID and Paddy-* variables come through as expected so the variables seem to get set.) I've also tried sending the start_dtmf command from my application after answer, I see the command getting executed in the FreeSWITCH log but it doesn't change the behavior (DTMF still doesn't come through). Finally I've tried calling {foo, freeswitch@fsdev} ! {api, uuid_broadcast, CallUUID ++ " start_dtmf"}. after I answer <http://freeswitch-users.2379917.n2.nabble.com/Why-I-could-not-detect-DTMF-w…>, but this gives me an error 2019-12-10 10:57:18.540690 [ERR] mod_native_file.c:74 Error opening /usr/share/freeswitch/sounds/en/us/callie/start_dtmf.PCMA 2019-12-10 10:57:18.540690 [ERR] mod_sndfile.c:204 Error Opening File [/usr/share/freeswitch/sounds/en/us/callie/start_dtmf.wav] [System error : No such file or directory.] Any suggestions on how I can get my outbound calls to work the same way as my inbound calls? Kind regards, Sam

2 3

t.38 Fax INCOMPATIBLE_DESTINATION
by Jared J 10 Dec '19

10 Dec '19

I have inbound faxing working over g.711 however I recently edited the SpanDSP.conf.xml file and added the following lines: <param name="enable-t38" value="true"/> <param name="enable-t38-request" value="true"/> Now when I try the same inbound fax that was working before I see this error in the fs_cli [NOTICE] sofia.c:8490 Hangup sofia/internal/5555555555(a)example.com [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] My goal was to have the inbound faxes try t.38 first and then fail back to g.711 ... but obviously that isn't working as expected. Can anyone provide some guidance?

1 0

problems with portaudio
by John Covici 10 Dec '19

10 Dec '19

Hi. I finally was able to upgrade fs to master as of llast night. Its working well, except if I use portaudio to make a call. This all worked find in fs 1.6.20. When I call someone I cannot hear anything until I send it a dtmf (rfc2283) and then things work normally, at least I can hear something. I had a look at the logs, but nothing strange in there after typing the digit. Also, I cannot call a local extension from port audio, even though the extension is registered and can be called from another extension. It immediately goes to voicemail. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici(a)ccs.covici.com

4 11

SIP handset connection issues
by Sam van Herwaarden 10 Dec '19

10 Dec '19

Hi, I often have issues where my SIP handset can't seem to connect to my FreeSWITCH server. I'm using Zoiper on iOS and the default freeswitch installation (freeswitch-meta-all) on Debian Buster. The configuration is mostly vanilla - I disabled mod_signalwire, enabled mod_flite and mod_erlang_event, changed the default password and set up an extension that uses mod_erlang_event but that's all. On the server ports 5060, 5070 and 5080 are open on TCP+UDP, ports 3478 and 3479 are open on UDP, and the port range 16384-32768 is also open on UDP. The server runs on a node on DigitalOcean. The issue I'm encountering is that sometimes my handset registers just fine, but other times I get timeout/unreachable errors. Nothing seems to change about the configuration though - I don't restart the server or anything like that. Also, I do see connection attempts on the server from unknown IPs (I'm assuming these are malicious bots trying to get into the system) - this suggests to me that the server is reachable. The system can be unreachable (to me) for days, but then be reachable for days. I have not been able to recognize a pattern. Does anyone have any suggestions what could be going on? Can it be something with my home networking setup? I would be happy to try a different SIP app if anyone has recommendations, it might be easier to debug this problem if I can get more verbose error messages than what Zoiper provides me with. Kind regards, Sam

3 3

Hangup calls RC=200 without RC=183
by Abel Monzon 09 Dec '19

09 Dec '19

Hi. I was trying to get a solution for this but I can't find any online. When FreeSWITCH received an incoming call it send the call trought a provider, but my provider sometimes send OK(200) without 183(Session Progress) and the call is answered. I need from FreeSWITCH to detect this behaviour and send 503 instead of sending OK(200) to the incoming call. This possible? Thank you all for any recommendations Abel.

3 7

Git now asking for password
by Victor Chukalovskiy 08 Dec '19

08 Dec '19

Greetings, since a little while git is asking for username / password when I pull before compiling it: > git clone https://freeswitch.org/stash/scm/fs/freeswitch.git > Cloning into 'freeswitch'... > Username for 'https://freeswitch.org': name > Password for 'https://name@freeswitch.org': I have username / password, so not a biggie. But that was not the case before. Is this a new normal now to steer people towards the repo? Or is there a new url to use? Thx!

2 2

Long increasing audio delay
by Jaan Kaja 07 Dec '19

07 Dec '19

Hello, We are testing webrtc via mod_verto with the verto_communicator demo. After some initial troubles with certificates, we have it running from Chrome and Firefox. Very nice! But, when we leave the connection on for some time, the audio in the direction from the browser to a phone becomes increasingly longer. We have clocked ~11 seconds, if we leave it on long enough. The audio in the other direction has a normal IP telephony delay. We have not found any browser dependencies. The FreeSWITCH version is 1.10.1 (latest stable release). The phone end has been a Blink softphone, or a trunk from a Cisco UCM. The latter negotiated mulaw PCM with a 20 ms packet size. We have tried different server OS:es: * Windows Server 2019 gives the fastest buildup of delay. * Debian installed in a Windows Substrate for Linux gives a slower buildup of delay, but it does continuously increase. * CentOS virtualized in VMWare doesn't have any buildup of delay, and the delay is a normal IP telephony delay. * So, the more Windows, the worse... I have a Wireshark trace, and I can get a TLS stream from it. I can install a key file to decode the stream, but the configuration wants a protocol, and I don't know what to enter there. There are no dissectors for Websocket. So I'm at a bit of a loss, as to how to debug this. I don't see anything obvious in the freeswitch.log. Questions: * Has anyone used webrtc on Windows? * Has anyone had the same problem? * What can be done to debug the problem? Turn on some logging? We could package a Linux machine to our customers, but as everything else is on Windows, it would be nice to make it work. Best regards, Jaan

3 4

t38_gateway hangs up non-deterministic with normal clearing
by Roman Dissauer 06 Dec '19

06 Dec '19

we have an issue with t38_gateway where calls which should be transcoded from PCMA to t38 get hangup non-deterministic. It doesn’t matter if there is only one call or if there are hundrets of calls on the freeswitch. Sometimes it happens that we get several faxes transcoded but then we again have several faxes which don’t go through. problem exists (tested) on FreeSWITCH 1.6 and FreeSWITCH 1.10. this is the dialplan section where t38_gateway is set up for b-leg on an inbound call: <context name="hosted_numbers"> <extension name="43732601458-DDI" continue="true"> <condition field="${outside_call}" expression="^true$" break="never"/> <condition field="${dialed_extension}" expression="^(43732601458)(\d{0,4})$“> ... <action application="set" data="refuse_t38=true"></action> <action application="export" data="fax_enable_t38=true"></action> <action application="export" data="nolocal:sip_execute_on_image=t38_gateway self nocng"></action> <action application="bridge" data="{sip_cid_type=pid,sip_contact_user=accountcode,absolute_codec_string='PCMA@20i,PCMU@20i,G729'}sofia/internal/accountcode@10.23.101.10^+${dialed_extension}@10.23.101.10"></action> ... </condition> </extension> </context> tested freeswitch versions: FreeSWITCH Version 1.6.20-37-987c9b9~64bit (-37-987c9b9 64bit) FreeSWITCH Version 1.10.1-release-12-f9990221e6~64bit (-release-12-f9990221e6 64bit) -> version where logfile is created this is the debug section where the call gets hung up: 287b2821-05a1-4ff6-9449-dac913b803eb 2019-12-03 20:32:23.257123 [DEBUG] switch_core_media.c:5285 sofia/internal/46wp809758(a)10.23.101.10 T38 IS POSSIBLE on request cc222460-f51e-453e-9a09-c2e97e6b8af9 2019-12-03 20:32:23.259118 [ALERT] switch_rtp.c:1595 sofia/external/+4318033811@193.32.51.146:5060 audio stat 100.00 673/673 flaws: 0 mos: 4.50 v: 0.00 0.00/0.00 cc222460-f51e-453e-9a09-c2e97e6b8af9 2019-12-03 20:32:23.259118 [DEBUG] switch_ivr_bridge.c:824 sofia/internal/46wp809758(a)10.23.101.10 ending bridge by request from write function cc222460-f51e-453e-9a09-c2e97e6b8af9 2019-12-03 20:32:23.259118 [DEBUG] switch_ivr_bridge.c:916 BRIDGE THREAD DONE [sofia/external/+4318033811@193.32.51.146:5060] 287b2821-05a1-4ff6-9449-dac913b803eb 2019-12-03 20:32:23.260120 [ALERT] switch_ivr_bridge.c:1893 sofia/internal/46wp809758(a)10.23.101.10 receive message [UNBRIDGE] full logfile of call is enclosed fsctl debug settings: fsctl loglevel debug fsctl debug_level 9

2 4