- FreeSWITCH-users - FreeSWITCH Mailing Lists

Call Lost
by Leonardo Lima Ribeiro 24 Aug '16

24 Aug '16

Hello guys, I have a lua script that does an outbound call through my external sip gateways… The problem is that sometimes the call is lost and I don’t know why, this is the complete log of that call: 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.349227 [NOTICE] switch_channel.c:1091 New Channel sofia/external/8008000800 [813d53c0-0733-40af-9562-922ea19a7f5b] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.349227 [DEBUG] mod_sofia.c:4776 (sofia/external/8008000800) State Change CS_NEW -> CS_INIT 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:473 (sofia/external/8008000800) Running State Change CS_INIT 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:516 (sofia/external/8008000800) State INIT 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] mod_sofia.c:88 sofia/external/8008000800 SOFIA INIT 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] sofia_glue.c:1257 sofia/external/8008000800 sending invite version: 1.7.0 git 222eff1 2015-12-17 22:32:55Z 64bit 813d53c0-0733-40af-9562-922ea19a7f5b Local SDP: 813d53c0-0733-40af-9562-922ea19a7f5b v=0 813d53c0-0733-40af-9562-922ea19a7f5b o=FreeSWITCH 1471968528 1471968529 IN IP4 208.115.55.11 813d53c0-0733-40af-9562-922ea19a7f5b s=FreeSWITCH 813d53c0-0733-40af-9562-922ea19a7f5b c=IN IP4 208.115.55.11 813d53c0-0733-40af-9562-922ea19a7f5b t=0 0 813d53c0-0733-40af-9562-922ea19a7f5b m=audio 22422 RTP/AVP 102 9 0 8 104 101 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:102 opus/48000/2 813d53c0-0733-40af-9562-922ea19a7f5b a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:9 G722/8000 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:0 PCMU/8000 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:8 PCMA/8000 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:104 telephone-event/48000 813d53c0-0733-40af-9562-922ea19a7f5b a=fmtp:104 0-16 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:101 telephone-event/8000 813d53c0-0733-40af-9562-922ea19a7f5b a=fmtp:101 0-16 813d53c0-0733-40af-9562-922ea19a7f5b a=ptime:20 813d53c0-0733-40af-9562-922ea19a7f5b a=sendrecv 813d53c0-0733-40af-9562-922ea19a7f5b m=video 26230 RTP/AVP 103 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:103 VP8/90000 813d53c0-0733-40af-9562-922ea19a7f5b b=AS:1024 813d53c0-0733-40af-9562-922ea19a7f5b a=rtcp-fb:103 ccm fir 813d53c0-0733-40af-9562-922ea19a7f5b a=rtcp-fb:103 ccm tmmbr 813d53c0-0733-40af-9562-922ea19a7f5b a=rtcp-fb:103 nack 813d53c0-0733-40af-9562-922ea19a7f5b a=rtcp-fb:103 nack pli 813d53c0-0733-40af-9562-922ea19a7f5b 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:40 sofia/external/8008000800 Standard INIT 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:48 (sofia/external/8008000800) State Change CS_INIT -> CS_ROUTING 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:516 (sofia/external/8008000800) State INIT going to sleep 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:473 (sofia/external/8008000800) Running State Change CS_ROUTING 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:532 (sofia/external/8008000800) State ROUTING 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] mod_sofia.c:141 sofia/external/8008000800 SOFIA ROUTING 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_ivr_originate.c:67 (sofia/external/8008000800) State Change CS_ROUTING -> CS_CONSUME_MEDIA 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:532 (sofia/external/8008000800) State ROUTING going to sleep 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.390583 [DEBUG] switch_core_state_machine.c:473 (sofia/external/8008000800) Running State Change CS_CONSUME_MEDIA 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.410024 [DEBUG] switch_core_state_machine.c:551 (sofia/external/8008000800) State CONSUME_MEDIA 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.410024 [DEBUG] switch_core_state_machine.c:551 (sofia/external/8008000800) State CONSUME_MEDIA going to sleep 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:30.429866 [DEBUG] sofia.c:6756 Channel sofia/external/8008000800 entering state [calling][0] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] sofia.c:6756 Channel sofia/external/8008000800 entering state [proceeding][183] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] sofia.c:6766 Remote SDP: 813d53c0-0733-40af-9562-922ea19a7f5b v=0 813d53c0-0733-40af-9562-922ea19a7f5b o=BroadWorks 931492917 1 IN IP4 208.73.144.71 813d53c0-0733-40af-9562-922ea19a7f5b s=- 813d53c0-0733-40af-9562-922ea19a7f5b c=IN IP4 208.73.144.71 813d53c0-0733-40af-9562-922ea19a7f5b t=0 0 813d53c0-0733-40af-9562-922ea19a7f5b m=audio 17916 RTP/AVP 0 101 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:0 PCMU/8000 813d53c0-0733-40af-9562-922ea19a7f5b a=rtpmap:101 telephone-event/8000 813d53c0-0733-40af-9562-922ea19a7f5b a=fmtp:101 0-15 813d53c0-0733-40af-9562-922ea19a7f5b a=maxptime:20 813d53c0-0733-40af-9562-922ea19a7f5b m=video 0 RTP/AVP 103 813d53c0-0733-40af-9562-922ea19a7f5b b=AS:1024 813d53c0-0733-40af-9562-922ea19a7f5b 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4153 Audio Codec Compare [PCMU:0:8000:20:64000:1]/[opus:116:48000:20:0:1] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4153 Audio Codec Compare [PCMU:0:8000:20:64000:1]/[G722:9:8000:20:64000:1] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4153 Audio Codec Compare [PCMU:0:8000:20:64000:1]/[PCMU:0:8000:20:64000:1] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4208 Audio Codec Compare [PCMU:0:8000:20:64000:1] ++++ is saved as a match 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4153 Audio Codec Compare [PCMU:0:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4069 Set telephone-event payload to 101@8000 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:2898 Set Codec sofia/external/8008000800 PCMU/8000 20 ms 160 samples 64000 bits 1 channels 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_codec.c:111 sofia/external/8008000800 Original read codec set to PCMU:0 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4417 Set telephone-event payload to 101@8000 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:4473 sofia/external/8008000800 Set 2833 dtmf send payload to 101 recv payload to 101 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:6027 AUDIO RTP [sofia/external/8008000800] 208.115.55.11 port 22422 -> 208.73.144.71 port 17916 codec: 0 ms: 20 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_rtp.c:3793 Starting timer [soft] 160 bytes per 20ms 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:6326 sofia/external/8008000800 Set 2833 dtmf send payload to 101 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:6333 sofia/external/8008000800 Set 2833 dtmf receive payload to 101 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_core_media.c:6356 sofia/external/8008000800 Set rtp dtmf delay to 40 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [NOTICE] sofia_media.c:92 Pre-Answer sofia/external/8008000800! 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.788096 [DEBUG] switch_channel.c:3461 (sofia/external/8008000800) Callstate Change DOWN -> EARLY 813d53c0-0733-40af-9562-922ea19a7f5b 2016-08-23 18:22:33.828095 [DEBUG] switch_cpp.cpp:625 (sofia/external/8008000800) State Change CS_CONSUME_MEDIA -> CS_SOFT_EXECUTE After that nothing happens and this is my Lua command to start this call: local new_session = freeswitch.Session("[origination_caller_id_name=‘9009000900',origination_caller_id_number=‘9009000900']sofia/gateway/14_RINGCENTRAL/8008000800", session); Do you know what I can do to avoid this problem? Thank you, Leo

1 0

Re: [Freeswitch-users] Freeswitch as IVR Tester
by Phil Dunks 24 Aug '16

24 Aug '16

Yes ‘gentones' is a workaround, but not ideal as means modifying the destination IVR to accept inband. So is ‘send_dtmf’ broken? > > From: Kalyani Kulkarni <kalyaneekulkarni(a)gmail.com> > Subject: Re: [Freeswitch-users] Freeswitch as IVR Tester > Date: 23 August 2016 at 05:16:21 BST > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > > > with FreeTDM, I've observed that I've to send DTMFs inband. > > On Mon, Aug 22, 2016 at 9:18 PM, Phil Dunks <phil.dunks(a)netdev.co.uk <mailto:phil.dunks@netdev.co.uk>> wrote: > Hi folks > > I am trying to use FS as an automated test platform to send calls into an IVR system (also FS) and test the various call flows. > > I am using node.js to control the tests over ESL. > > I am using ‘originate xxx &park()’ to initiate the test call to the IVR. > > Then ‘detect_speech’ with pocketsphinx to listen for key phrases in the prompts from the IVR (‘followed by hash’) etc. > > So far so good - although I haven’t tested many different prompts yet. > > I am then trying to use ’send_dtmf’ to navigate the IVR menus. > > I am having some problems with this. > > After the ‘send_dtmf’ is requested, nothing happens. > > I read on a different post that it will work if you do a ‘playback’ before ‘send_dtmf’. > > I tried this, and yes, ‘send_dtmf’ now does something - but not what is expected. > > The CHANNEL_EXECUTE_COMPLETE event for ‘send_dtmf’ returns instantly ( e.g. 1 ms after the associated CHANNEL_EXECUTE event) rather than after the DTMF is sent, which messes up my state machine. > > Also the IVR system does not react to the DTMF. > > I made a test call to an x-lite instead of the IVR, and could hear the DTMF but it was distorted. > > Any help greatly appreciated. > > I am using 1.6.9 (installed from rpm’s) on centos 7. > > Thanks > > Phil >

1 0

how to enable mod_shout
by Achintha 24 Aug '16

24 Aug '16

hi, I installed FreeSWITCH Version 1.6.8 on debian 8.3 (jessie) using command "apt-get install freeswitch-all" it is working properly. now i need to enable mod_shout. then i tried with command "apt-get install mod_shout". i got message "Unable to locate package mod_shout". please advice me to install mod_shout. -- Best Regards.. Achintha

2 2

mod_avmd beep detected event or session variable
by Jason Moran 24 Aug '16

24 Aug '16

Prior to mod_avmd getting updated, I would call avmd with the "start" command and find the detection in javascript via: function onDTMFOrEvent(s, type, obj, arg) { try { if(type == "event" && session.getVariable("avmd_detect") == "TRUE") { console_log("info", "Voicemail Detected\n"); //session.execute("avmd", "stop"); //Deprecated session.execute("avmd_stop"); return false; } } catch (e) { console_log("err", e + "\n"); } return true; } The key line was if(type == "event" && session.getVariable("avmd_detect") == "TRUE"), but the new documentation mentions the "beep detected" event name which can be subscribed with "event plain CUSTOM avmd::beep" which will have the Beep-Status custom field which should have "DETECTED" . Finding that particular event and status is not straightforward. I cannot use obj.Beep-Status as that is invalid JS. Does the "avmd_detect" session variable continue to get populated as before?

2 1

Pure Python ESL Client Library
by Spencer Thomason 24 Aug '16

24 Aug '16

Hi Everyone, I've published a small Python 2.7/3.4 ESL client library we've been using for a while in production but I'd love to get some feedback and more eyes on it. You can grab the code here: https://github.com/sjthomason/PyESL This goals of this implementation are: - Python 2.7 and 3.4 compatibility - API compatability with FreeSWITCH C Python ESL module - A single file module that is easy to drop into an existing project BR, Spencer

1 0

chat platform
by Andres Gomez 23 Aug '16

23 Aug '16

Hi. How I can implement a livechat text and video with freeswitch? Is it more feasible to integrate with a platform like zulip? Thanks!! Andres Gomez

2 1

Freeswitch as IVR Tester
by Phil Dunks 23 Aug '16

23 Aug '16

Hi folks I am trying to use FS as an automated test platform to send calls into an IVR system (also FS) and test the various call flows. I am using node.js to control the tests over ESL. I am using ‘originate xxx &park()’ to initiate the test call to the IVR. Then ‘detect_speech’ with pocketsphinx to listen for key phrases in the prompts from the IVR (‘followed by hash’) etc. So far so good - although I haven’t tested many different prompts yet. I am then trying to use ’send_dtmf’ to navigate the IVR menus. I am having some problems with this. After the ‘send_dtmf’ is requested, nothing happens. I read on a different post that it will work if you do a ‘playback’ before ‘send_dtmf’. I tried this, and yes, ‘send_dtmf’ now does something - but not what is expected. The CHANNEL_EXECUTE_COMPLETE event for ‘send_dtmf’ returns instantly ( e.g. 1 ms after the associated CHANNEL_EXECUTE event) rather than after the DTMF is sent, which messes up my state machine. Also the IVR system does not react to the DTMF. I made a test call to an x-lite instead of the IVR, and could hear the DTMF but it was distorted. Any help greatly appreciated. I am using 1.6.9 (installed from rpm’s) on centos 7. Thanks Phil

2 1

WebRTC(VertoJS) to SIP Call Issue
by Murugan Pandian 22 Aug '16

22 Aug '16

HI, I have two FS Accessing Same database(PSQL in CORE and Sofia odbc-dsn) 1.FS-verto(WebRTC) Vertojs in single Machine DNS EX:verto.yyyyy.com 2.FS-sip(SIP) in single Machine DNS EX:sip.yyyyy.com Client 1 (VertoJS) register successfully with FS-verto(verto.yyyyy.com) Client 2 (Softfone)Register successfully with FS-sip(sip.yyyyy.com) Issue: When i make call from Client 1(WebRTC) to Client 2 (SIP) its always say extension not available . But when i try this in single system it works,I stuck here Any one faced this kind of issue pls help me here

4 15

BugHunt 8/23/2016 2PM Central
by Brian West 22 Aug '16

22 Aug '16

FreeSWITCHers, I invite EVERYONE to get involved in this bug hunt, we'll be going over the FreeSWITCH 1.8 configs, auditing modules and config files to ensure every option of every module is at the very least in every config file, While this isn't the final form, you can review what we have here https://freeswitch.org/stash/projects/FS/repos/fs18configs/browse Please get involved, help out, this is a long tedious task of checking the code against the configs and making sure everything is correct. Example there are 208 Sofia Profile params, 130 of them are were in the vanilla internal.xml, Thats 78 params missing SHEESH, we have to fix this. :) Come help... -- *Brian West* brian(a)freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com https://www.gofundme.com/freeswitch_ubuntu Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest

1 0

[VBR]: Asynchronous PTIME supported on Speex16
by Stephen Dame 22 Aug '16

22 Aug '16

Have an application that uses SPEEX@20ms@16000, everything works fine in 1.4, 1.5 and FreeSWITCH Version 1.7.0+git~20160219T153438Z~3bd26eaa6b~64bit (git 3bd26ea 2016-02-19 15:34:38Z 64bit) We bring a user into echo, then transfer them to a conference after they confirm they can hear themselves. We connect to audio fine at the 20ms and confirm. But the transfer is setting on VBR since updating freeswitch? I built FreeSWITCH Version 1.7.0+git~20160706T181946Z~8c6b2657bf~64bit (git 8c6b265 2016-07-06 18:19:46Z 64bit) 2016-08-03 19:34:43.901960 [DEBUG] switch_rtp.c:6711 Correct audio ip/port confirmed. 2016-08-03 19:34:43.901960 [WARNING] switch_core_media.c:2568 [VBR]: Asynchronous PTIME supported, adjusting JB size. Remote PTIME changed from [20] to [36] 2016-08-03 19:34:43.921964 [NOTICE] switch_core_media.c:2977 Deactivating write resampler 2016-08-03 19:34:43.921964 [DEBUG] switch_core_media.c:2984 Changing Codec from SPEEX@20ms@16000hz to SPEEX@36ms@16000hz 2016-08-03 19:34:43.921964 [NOTICE] switch_core_io.c:1202 Activating write resampler 2016-08-03 19:34:43.961958 [WARNING] switch_core_codec.c:721 Codec SPEEX Exists but not at the desired implementation. 16000hz 36ms 1ch 2016-08-03 19:34:43.961958 [ERR] switch_core_media.c:3021 Can't load codec? The VBR is setting ptime to 36, 77, etc, varies every call coming in, which fails to find a match on speex implementation . Both opus and speex16 calls come in to echo, depending on if the browser is web-rtc capable to support fallback. We send send into echo, they press 1 to transfer here root@ip-10-0-0-69:/opt/freeswitch/conf/dialplan/default# cat bbb_echo_test.xml <include> <extension name="bbb_echo_test_direct"> <condition field="${bbb_authorized}" expression="true" break="on-false"/> <condition field="destination_number" expression="^9196$|^9196(\d{5})$"> <action application="set" data="vbridge=$1"/> <action application="answer"/> <action application="bind_digit_action" data="direct_from_echo,1,exec:execute_extension,${vbridge} XML default"/> <action application="sleep" data="1500"/> <action application="echo"/> </condition> </extension> </include> Then they are transferred. root@ip-10-0-0-69:/opt/freeswitch/conf/dialplan/default# cat bbb_conference.xml <include> <extension name="bbb_conferences"> <condition field="${bbb_authorized}" expression="true" break="on-false"/> <condition field="destination_number" expression="^(\d{5})$"> <action application="set" data="jitterbuffer_msec=20:400"/> <action application="answer"/> <action application="conference" data="$1@cdquality"/> </condition> </extension> </include> So master from 7/06 currently after setting the jitterbuffer on speex call changes the PTIME to some number that doesn't match. Opus calls work fine. If I comment out the jitterbuffer in dialplan the calls work for both opus and speex. Any help on how to get speex to stay fixed at 20ms like it had worked in previous with the jitterbuffer setting. Can we set jitter buffer defaults for opus another way? Thanks for the help. Regards, Stephen HostBBB - Online Learning Solutions 207 Technology Group Inc. 1-888-229-9756 skype: Stephen_Dame

4 5