December 2020 - FreeSWITCH-users - FreeSWITCH Mailing Lists

HELP DTLS HANDSHAKE to FAIL chromeV87
by Jazmin Marina Florez Marino 07 Dec '20

07 Dec '20

Hi I have a verto client trying to connect to FS using Chrome V87 but we have DTLS problems. The openssl version we are using on FS side is OpenSSL 1.0.2k-fips FreeSWITCH (Version 1.8.4 64bit) FS LOG - Chrome V87 FAILED CONNECTION 2020-12-03 11:23:06.762291 [ERR] switch_rtp.c:3199 video Handshake failure 1 2020-12-03 11:23:06.762291 [INFO] switch_rtp.c:3200 Changing video DTLS state from HANDSHAKE to FAIL 2020-12-03 11:23:06.832295 [ERR] switch_rtp.c:3199 audio Handshake failure 1 2020-12-03 11:23:06.832295 [INFO] switch_rtp.c:3200 Changing audio DTLS state from HANDSHAKE to FAIL 2020-12-03 11:23:06.852295 [NOTICE] switch_rtp.c:3181 Hangup verto.rtc/3520 [CS_EXECUTE] [DESTINATION_OUT_OF_ORDER] 2020-12-03 11:23:06.852295 [DEBUG] switch_core_media.c:7470 verto.rtc/3520 Video thread ended 2020-12-03 11:23:06.872305 [INFO] conference_loop.c:1670 Channel leaving conference, cause: DESTINATION_OUT_OF_ORDER 2020-12-03 11:23:06.872305 [DEBUG] switch_core_session.c:2639 verto.rtc/3520 skip receive message [DISPLAY] (channel is hungup already) 2020-12-03 11:23:06.872305 [DEBUG] mod_conference.c:2467 verto.rtc/3520 skip receive message [TRANSFER] (channel is hungup already) 2020-12-03 11:23:06.872305 [DEBUG] switch_core_media.c:12220 verto.rtc/3520 skip receive message [BITRATE_REQ] (channel is hungup already) 2020-12-03 11:23:06.872305 [DEBUG] switch_core_codec.c:248 verto.rtc/3520 Restore previous codec opus:116. 2020-12-03 11:23:06.872305 [DEBUG] switch_core_session.c:2886 verto.rtc/3520 skip receive message [PHONE_EVENT] (channel is hungup already) 2020-12-03 11:23:06.872305 [DEBUG] switch_core_state_machine.c:650 (verto.rtc/3520) State EXECUTE going to sleep 2020-12-03 11:23:06.872305 [DEBUG] switch_core_state_machine.c:584 (verto.rtc/3520) Running State Change CS_HANGUP (Cur 1 Tot 3) 2020-12-03 11:23:06.872305 [DEBUG] switch_core_state_machine.c:847 (verto.rtc/3520) Callstate Change ACTIVE -> HANGUP 2020-12-03 11:23:06.872305 [DEBUG] switch_core_state_machine.c:849 (verto.rtc/3520) State HANGUP 2020-12-03 11:23:06.872305 [DEBUG] switch_core_state_machine.c:60 verto.rtc/3520 Standard HANGUP, cause: DESTINATION_OUT_OF_ORDER 2020-12-03 11:23:06.872305 [DEBUG] switch_core_state_machine.c:849 (verto.rtc/3520) State HANGUP going to sleep The weird thing is the connection works ok when the version of chrome is V86. Some weeks ago chrome was updated and we detected this issue. FS LOG - ChromeV86 CONNECTION OK 2020-12-03 11:19:19.622294 [INFO] switch_rtp.c:3206 Changing video DTLS state from HANDSHAKE to SETUP 2020-12-03 11:19:19.672317 [INFO] switch_rtp.c:3113 video Fingerprint Verified. 2020-12-03 11:19:19.672317 [INFO] switch_rtp.c:4104 Activating video Secure RTP SEND 2020-12-03 11:19:19.672317 [INFO] switch_rtp.c:4082 Activating video Secure RTP RECV 2020-12-03 11:19:19.672317 [DEBUG] switch_core_sqldb.c:2617 Secure Type: srtp:dtls:AES_CM_128_HMAC_SHA1_80 2020-12-03 11:19:19.672317 [INFO] switch_rtp.c:3155 Changing video DTLS state from SETUP to READY 2020-12-03 11:19:19.672317 [DEBUG] switch_rtp.c:1890 rtcp_stats_init: video ssrc[2719546543] base_seq[1999] 2020-12-03 11:19:19.672317 [DEBUG] switch_core_sqldb.c:2617 Secure Type: srtp:dtls:AES_CM_128_HMAC_SHA1_80 2020-12-03 11:19:19.702298 [INFO] switch_rtp.c:3206 Changing audio DTLS state from HANDSHAKE to SETUP 2020-12-03 11:19:19.702298 [INFO] switch_rtp.c:3113 audio Fingerprint Verified. 2020-12-03 11:19:19.702298 [INFO] switch_rtp.c:4104 Activating audio Secure RTP SEND 2020-12-03 11:19:19.702298 [INFO] switch_rtp.c:4082 Activating audio Secure RTP RECV 2020-12-03 11:19:19.702298 [DEBUG] switch_core_sqldb.c:2617 Secure Type: srtp:dtls:AES_CM_128_HMAC_SHA1_80 2020-12-03 11:19:19.702298 [INFO] switch_rtp.c:3155 Changing audio DTLS state from SETUP to READY 2020-12-03 11:19:19.702298 [DEBUG] switch_core_sqldb.c:2617 Secure Type: srtp:dtls:AES_CM_128_HMAC_SHA1_80

5 4

freeswitch won't open file
by Joli Martinez 05 Dec '20

05 Dec '20

Hello, I have the following function that works normally on lua, but when I copied and pasted it into my freeswitch lua script, the file wont open. I am trying to put the passwords I use in a json format outside the script, so that I can share the script. I have installed the correct libraries for lunajson to work. Any suggestions? --Reads json file and parses it function returnJson(option) freeswitch.consoleLog("INFO", "Inside function\n") local file = io.open("password.json", "r") if not file then return nil end local jsonString = file:read("*a") freeswitch.consoleLog("INFO", "File is open\n") file:close() jsonResult = lunajson.decode( jsonString ) freeswitch.consoleLog("INFO", "Parsing json\n") return ( jsonResult[option] ) end --SID = returnJson("SID") --Token = returnJson("TOKEN") ------------------------------------------------------------------------------------------------------------ 2020-12-04 14:38:13.637108 [ERR] mod_lua.cpp:203 /usr/share/freeswitch/scripts/test.lua:67: attempt to concatenate global 'SID' (a nil value) stack traceback: /usr/share/freeswitch/scripts/test.lua:67: in main chunk

4 6

please give user list
by Md Ahammad Muin 04 Dec '20

04 Dec '20

hello sir please give me a user list

1 0

Re: [Freeswitch-users] Force Inband DTMF Reception (SOLVED)
by Adrian Worutowicz 03 Dec '20

03 Dec '20

Just for the records : In order to receive DTMS in-band for incoming calls, FS must not send in SDP : a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 This is achieved by : In vars.xml : <X-PRE-PROCESS cmd="set" data="rtp_liberal_dtmf=false"/> In sip_profiles\internal.xml and/or external.xml (Settings): Add line : <param name="dtmf-type" value="none"/> Remove line (if exists) : <param name="rfc2833-pt" value="101"/> Big thanks to @seven1240 ! De : FreeSWITCH-users <freeswitch-users-bounces(a)lists.freeswitch.org> De la part de Piotr Gregor Envoyé : lundi 30 novembre 2020 16:58 À : FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Objet : Re: [Freeswitch-users] Force Inband DTMF Reception Cześć Adrian, Tak, to ma sens. Spróbuj może ustawić flagę dtmf_type=none <action application="set" data="dtmf_type=none"/> To powinno sprawić, że w SDP ANSWER nie będzie a=rtpmap:101 telephone-event/8000, tylko nie jestem pewien czy detekcja in-band DTMF będzie włączona. pozdrawiam, Piotr On Mon, 30 Nov 2020 at 15:34, Adrian Worutowicz <adrian.worutowicz(a)esifrance.net<mailto:adrian.worutowicz@esifrance.net>> wrote: Witaj Piotrze, Co za niespodzianka! 😊 Otóż faktycznie INVITE zawiera: v=0 o=BroadWorks 210259115 1 IN IP4 xxx.xxx.xxx.xxx s=- c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=audio 62810 RTP/AVP 8 18 101 a=fmtp:18 annexb=no a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 Zaś SIP/2.0 200 OK zawiera: v=0 o=FreeSWITCH 1606729402 1606729403 IN IP4 xxx.xxx.xxx.xxx s=FreeSWITCH c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=audio 20616 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Gateway to ORANGE, także mam tu niewielkie pole manewru. Powiedzieli mi jednak, że jeśli usunę a=rtpmap:101 telephone-event/8000, to będzie inband – co jest możliwe, bo w tym połączeniu proponują kodek G729 a ja im na to PCMA no i transmisja jest w PCMA (G711A). Także pozostaje pytanie, jak usunąć tę linię z sekcji SDP wysyłanej przez FS w 200 OK. Serdecznie pozdrawiam, Adrian. De : FreeSWITCH-users <freeswitch-users-bounces(a)lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>> De la part de Piotr Gregor Envoyé : lundi 30 novembre 2020 11:58 À : FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Objet : Re: [Freeswitch-users] Force Inband DTMF Reception Cześć Adrian, Tryb w którym FS będzie używał DTMF zależy od trybu który jest oferowany w SDP INVITE. Zazwyczaj klient jest konfigurowalny, np. w Bria: Preferences -> Calls -> DTMF: Send in-band. Tak więc upewnij się, że to nie klient żąda RFC 2833. pozdrawiam serdecznie, Piotr [https://drive.google.com/a/dataandsignal.com/uc?id=1lUdzdLjEycxXcGhDz-bKqDX…] Piotr Gregor Software Engineer M: (+44) 07483 866 525 L: (+44) 01256 597 470 www: dataandsignal.com<http://dataandsignal.com> On Thu, Nov 26, 2020 at 6:03 PM Adrian Worutowicz <adrian.worutowicz(a)esifrance.net<mailto:adrian.worutowicz@esifrance.net>> wrote: I tried in the SIP profile: <param name="dtmf-type" value="none"/> And in dialplan default.xml / <extension name I put <action application="set" data="dtmf_type=none"/> and also I tried <action application="bridge" data="{dtmf_type=none} … None of those worked. De : FreeSWITCH-users <freeswitch-users-bounces(a)lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>> De la part de Dragos Oancea Envoyé : jeudi 26 novembre 2020 18:10 À : FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Objet : Re: [Freeswitch-users] Force Inband DTMF Reception How about if you set channel variable "dtmf_type" to value "none" ? On Thu, Nov 26, 2020 at 5:59 PM Adrian Worutowicz <adrian.worutowicz(a)esifrance.net<mailto:adrian.worutowicz@esifrance.net>> wrote: Hello, For incoming calls, I want to receive DTMF inband. FS receives INVITE and at certain stage sends 200 OK with a SDP section, which always contains : a=rtpmap:101 telephone-event/8000 (what means ‘DTMF in RTP metadata’). Indeed the DTMFs come via RTP. I tried various FS configuration options to remove that line, without success. How to do it? How to tell a gateway to send DTMFs inband ? In advance thank you very, very much, Adrian. _________________________________________________________________________ The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform. Join our online community to chat in real time https://signalwire.community Professional FreeSWITCH Services sales(a)freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users(a)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 https://freeswitch.com _________________________________________________________________________ The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform. Join our online community to chat in real time https://signalwire.community Professional FreeSWITCH Services sales(a)freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users(a)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 https://freeswitch.com _________________________________________________________________________ The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform. Join our online community to chat in real time https://signalwire.community Professional FreeSWITCH Services sales(a)freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users(a)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 https://freeswitch.com

2 1

Help with tls
by Dr. Ogg 03 Dec '20

03 Dec '20

I have been looking for some good documentation regarding the configuration of TLS with FreeSWITCH. If anyone has a good resource, I would be grateful Thanks…

2 1

Masking caller
by Lars Kiesow 03 Dec '20

03 Dec '20

Hi everyone, I'm trying to mask the caller_id_name in a FreeSWITCH dialplan to prevent the real phone numbers to show up in our conferencing software. Someone sent me the following lines: <action application="set" data="MASK=${system echo ${caller_id_name} | grep -o -P '.{0,4}$' | sed 's/^/xxx-xxx-/' }"/> <action application="set_profile_var" data="caller_id_name=${MASK}"/> While this works perfectly and does exactly what I want, I'm unsure about potential security risks. The caller_id_name ends up in a shell command after all and I'm wondering if someone could send a name like `; rm /*` (you get the idea). Is this safe? Is the caller_id_name sanitized? Is there a better way to do something like this? Best regards, Lars

2 1

How to relay DTMF during Early Media (Before Call Answered) ?
by Hamid Hashmi 03 Dec '20

03 Dec '20

Hello I have been trying to relay DTMF in Early Media (Before Call Answered), I have tried the following option. (Ref<http://freeswitch-users.2379917.n2.nabble.com/start-dtmf-generate-during-ea…>) <extension name="other"> <condition> <action application="export" data="nolocal:absolute_codec_string=AMR-WB,AMR"/> <action application="export" data="nolocal:execute_on_media=start_dtmf_generate> <action application="set" data="uuid_bridge_continue_on_cancel=true"/> <action application="set" data="bridge_early_media=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=false"/> <action application="set" data="effective_caller_id_number=${sip_from_user}"/> <action application="set" data="hold_music=/etc/freeswitch/dialplan/Call_Hold.mp3"/> <action application="set" data="ringback=%(2000,4000,440.0,480.0)"/> <action application="set" data="limit_ignore_transfer=false" /> <action application="bridge" data="sofia/internal/${destination_number}@${loadbalancer}"/> <action application="set" data="sip_copy_multipart=false"/> <action application="log" data="1 B-leg hangup cause: ${last_bridge_hangup_cause}"/> <action application="set" data="sip_h_X-RBT-Enabled=No"/> <action application="transfer" data="${last_bridge_hangup_cause}"/> </condition> </extension> but it didn't generate any DTMF in early media and it caused an issue of Robotic sound in transcoding from AMR-WB to G729 as well. OS: DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS" NAME="Ubuntu" VERSION="18.04.2 LTS (Bionic Beaver)" Container: PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" Freeswitch: FreeSWITCH Version 1.9.0-n20180314T133342Z-1~jessie+1+git~20180305T173609Z~dd0bb0e331~64bit (-n20180314T133342Z-1~jessie+1git dd0bb0e 2018-03-05 17:36:09Z 64bit) PS: DTMF is working fine once the call is answered. Regards Hamid R. Hashmi

1 0

Full Trickle ICE via mod_sofia supported?
by Alexander Haugg 02 Dec '20

02 Dec '20

Hello, I only mean that the client can deliver candidates. The Freeswitch of course sends all candidates in the first SDP. Currently I'm trying to implement the Full Trickle mechanism as described here https://tools.ietf.org/id/draft-ietf-mmusic-trickle-ice-sip-11.html Candidates should be forwarded via SIP Info during the connection setup. Since I haven't succeeded so far, I have the following questions. Is Full Trickle supported via mod_sofia? If so, which settings or sip headers are required? Thanks Alex

1 0

Change SDP by SIP UPDATE
by Oleg Belousov 02 Dec '20

02 Dec '20

Hi. Is there a possibility in Freeswitch to update the SDP of a pre-answered call by SIP UPDATE message? Call flow is as following: 1. FS responds to A-party with 183/SDP (SDP IP==FS IP) and performs some checks in preanswer mode 2. If checks on step 1 passed ok, FS initiates a call to B-party, receives from B-party 183/SDP (SDP IP = MGW_B) and sends to A-party 183/SDP with same new SDP IP = MGW_B, so doing change of SDP parameter in the same transaction. That scenario executes with below commands (need in media travel directly between parties after the bridge) session:execute("set","bypass_media=true") second_session = session:execute("bridge",BridgeStr); The question: is there a parameter which allows during the bridge to update SDP by SIP UPDATE, instead of changing SDP using provisional responses? A-party switch does not accept such SDP change and thus there is a problem with audio after the bridge. -- obelousov.tel

1 0

20ms silent RTP inserted into conference call output (about 1 out of every 100 packets)
by Larry Hemenway 01 Dec '20

01 Dec '20

We're setting up a conference bridge as follows: (canned wav file) --> chrome --(g722)--> FreeSWITCH conference --(linear PCM)--> c++ app What we are seeing is that FreeSWITCH is inserting 20 ms of silence into the linear PCM output. It does not drop any audio - it is just inserting extra silence. On some traces we see ~1 out of every 100 output audio packet as silence. There is no regular cadence for the insertion. We are able to verify this in two ways: 1. When we look at the linear PCM tcpdump trace, we can identify silence because it's all 0xff. 2. We convert both the g722 and linear PCM into wav files. This is how we observe that no audio is dropped, just 20ms of silence added. The linear PCM wav file adds 20ms of audio and falls behind the g722 audio. We look at the pacing from the tcpdump and chrome is pacing every 20ms. FreeSWITCH, likewise, is also producing at 20ms intervals. We did try turning on the jitter buffer in FreeSWITCH and now see mitigated packets instead of silence, so that did not fix the issue. We'll probably turn off PLC next as mitigated packets are not easily identifiable. After reading https://github.com/signalwire/freeswitch/issues/735 I went back and looked at an old trace and it does appear that we see silence in the output linear PCM ~50-70ms after getting an RTCP packet from chrome. It's not 1:1; in the trace I looked at we had 44 rtcp packets, but only 20 silent packets, but for every silent packet we see an RTCP packet 50-70ms earlier. I hope to get more traces to verify this after turning PLC off. Environment: FreeSWITCH version 1.10.3, running inside a container on bare metal. This is reproducible running a single conference with two participants - no loading. We are turning off encryption in Chrome so we can decode the g722 (no dtls/srtp) and feeding chrome a canned wav file, so we can compare audio. Has anyone else seen this issue? Any suggestions on how to start debugging? I'm trying to trace through read_rtp_packets() in switch_rtp.c, but am a bit lost and not sure if that is where I should start. This issue is severely degrading our audio quality measurements so its causing a lot of headaches for us at the moment.

1 0