April 2015 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Duplicate DTMF Issue
by Jeremy 23 Apr '15

23 Apr '15

Hi Giovanni, Thank you for your reply, sorry I didn't explain the problem very well. I am trying to detect a string of DTMF's with a short pulse duration (about 50ms) and the normal DTMF detection is not able to reliably do this (it seems to miss almost all of the tones). Spandsp appears to be able to reliably do this but when I enable spandsp, I get duplicate tones detected by both spandsp and gsmopen (I think its gsmopen, example below). You are correct. Is it possible for gsmopen not to recognize DTMF's and use only spandsp to analyze the audio? Thank you for your help in advance. Jeremy. P.S. Greatly appreciate the work you have put into GSMopen, brilliant work! Hello Jeremy, I've not understood the problem, and the solution you are looking for. You want gsmopen not to recognize DTMFs, so you can analyze the audio with spandsp? Can you give more info ? -giovanni On Wed, Apr 22, 2015 at 2:58 PM, jhorsburgh <jhorsburgh at gmail.com <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>> wrote: >* Hello All, *>* I am having some issues detecting DTMF tones and was hoping *>* someone could shed some light on the problem. *>>* *Background* *>* I am using Freeswitch (1.4.14~32bit) with GSMopen to receive calls and *>* process high-speed DTMF signal for use with Alarm Systems. Unfortunately *>* the *>* standard inband DTMF detection is not quite up to the task but spandsp *>* works *>* perfectly. *>>* *Problem* *>* The problem I am having is that the standard inband DTMF detection remains *>* enabled when spandsp is enabled producing duplicates of each detected tone. *>>* Is there a way of disabling DTMF detection with the exception of spandsp? *>>* Any help would be greatly appreciated. *>>* Kind regards, *>* Jeremy *>>>>* 2015-04-22 12:18:22.129468 [DEBUG] mod_gsmopen.cpp:919 rev 1.4.14~32bit *>* [(nil)|37 ][DEBUG_GSMOPEN 919 ][interface1][-1, 5, 5] *>* gsmopen/interface1 CHANNEL got *>* SWITCH_MESSAGE_INDICATE_TRANSCODING_NECESSARY *>* 2015-04-22 12:18:22.569494 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 *>* 2015-04-22 12:18:22.569494 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit *>* [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: *>* [5] new_dtmf_timestamp: 1652802529, delta_t: 515839955 *>* 2015-04-22 12:18:22.569494 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN *>* DETECTED: [5] *>* 2015-04-22 12:18:22.569494 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 *>* 2015-04-22 12:18:22.749457 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: *>* [5], duration = 178 ms *>* 2015-04-22 12:18:23.049446 [DEBUG] switch_channel.c:488 RECV DTMF 3:2000 *>* 2015-04-22 12:18:23.049446 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit *>* [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: *>* [3] new_dtmf_timestamp: 1653282480, delta_t: 479951 *>* 2015-04-22 12:18:23.049446 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN *>* DETECTED: [3] *>* 2015-04-22 12:18:23.049446 [DEBUG] switch_channel.c:488 RECV DTMF 3:2000 *>* 2015-04-22 12:18:23.229447 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: *>* [3], duration = 165 ms *>* 2015-04-22 12:18:23.529449 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 *>* 2015-04-22 12:18:23.529449 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit *>* [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: *>* [5] new_dtmf_timestamp: 1653762488, delta_t: 480008 *>* 2015-04-22 12:18:23.549464 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN *>* DETECTED: [5] *>* 2015-04-22 12:18:23.549464 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 *>* 2015-04-22 12:18:23.689495 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: *>* [5], duration = 140 ms *>* 2015-04-22 12:18:24.029440 [DEBUG] switch_channel.c:488 RECV DTMF 2:2000 *>* 2015-04-22 12:18:24.029440 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit *>* [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: *>* [2] new_dtmf_timestamp: 1654262471, delta_t: 499983 *>* 2015-04-22 12:18:24.029440 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN *>* DETECTED: [2] *>* 2015-04-22 12:18:24.029440 [DEBUG] switch_channel.c:488 RECV DTMF 2:2000 *>* 2015-04-22 12:18:24.169442 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: *>* [2], duration = 153 ms *>* 2015-04-22 12:18:24.489445 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 *>* 2015-04-22 12:18:24.489445 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit *>* [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: *>* [5] new_dtmf_timestamp: 1654722477, delta_t: 460006 *>* 2015-04-22 12:18:24.489445 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN *>* DETECTED: [5] *>* 2015-04-22 12:18:24.489445 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 *>* 2015-04-22 12:18:24.649447 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: *>* [5], duration = 153 ms *>* 2015-04-22 12:18:25.609450 [INFO] switch_cpp.cpp:1328 Failed to validate *>* Checksum - '5533552255' *>>>>>>>* -- *>* View this message in context: *>* http://freeswitch-users.2379917.n2.nabble.com/Duplicate-DTMF-Issue-tp759615… <http://freeswitch-users.2379917.n2.nabble.com/Duplicate-DTMF-Issue-tp759615…> *>* Sent from the freeswitch-users mailing list archive at Nabble.com. *>>* _________________________________________________________________________ *>* Professional FreeSWITCH Consulting Services: *>* consulting at freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> *>* http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> *>>* Official FreeSWITCH Sites *>* http://www.freeswitch.org <http://www.freeswitch.org/> *>* http://confluence.freeswitch.org <http://confluence.freeswitch.org/> *>* http://www.cluecon.com <http://www.cluecon.com/> *>>* FreeSWITCH-users mailing list *>* FreeSWITCH-users at lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> *>* http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> *>* UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> *>* http://www.freeswitch.org <http://www.freeswitch.org/> *> -- Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618

2 1

Loading phrases on demand via mod_xml_curl
by Ben Hood 23 Apr '15

23 Apr '15

Hi, It is possible to load a phrase on demand (and for every individual call) using mod_xml_curl? Currently my web server is returning: <document type="freeswitch/xml"> <section name="phrases"> <macros> <language> <macro name="vmg"> <input pattern="(.*)"> <match> <action function="play-file" data="voicemail/vm-goodbye.wav"/> </match> </input> </macro> </language> </macros> </section> </document> when the phrases section of mod_xml_curl is configured thusly: <binding name="phrases"> <param name="method" value="GET"/> <param name="enable-post-var" value="macro_name"/> <param name="enable-post-var" value="variable_sip_req_user"/> <param name="enable-post-var" value="variable_sip_from_user"/> <param name="gateway-url" value="127.0.0.1/phrase" bindings="languages"/> </binding> but when a dialplan tries to load to load the vmg phrase: <menu name="vmg_ivr" greet-long="phrase:vmg" invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav" exit-sound="voicemail/vm-goodbye.wav" confirm-macro="" confirm-key="" tts-engine="flite" tts-voice="slt" confirm-attempts="3" timeout="10000" inter-digit-timeout="2000" max-failures="3" max-timeouts="3" digit-len="1"> The execution cannot find the vmg macro: 2015-04-21 15:35:10.843131 [DEBUG] switch_ivr_menu.c:469 Executing IVR menu vmg_ivr 2015-04-21 15:35:10.843131 [DEBUG] switch_ivr_play_say.c:70 No language specified - Using [en] 2015-04-21 15:35:10.943130 [CONSOLE] mod_xml_curl.c:323 XML response is in /tmp/cbaaec2b-50ed-48ab-b5fa-68d3d7b34cb9.tmp.xml 2015-04-21 15:35:10.943130 [ERR] switch_ivr_play_say.c:145 Can't find macro vmg. The debug file that mod_xml_curl writes to disk (/tmp/cbaaec2b-50ed-48ab-b5fa-68d3d7b34cb9.tmp.xml) contains the macro called vmg. So I was wondering if phrase loading via mod_xml_curl is not supposed to work in this way, i.e. that a macro sourced remotely cannot be late bound to an IVR menu declaration? The following mailing list post http://lists.freeswitch.org/pipermail/freeswitch-users/2013-August/099239.h… seems to suggest this behavior. But if that is the case, then I'm a bit surprised that the HTTP request appears to be executed every time the macro is referenced by a dialplan. Am I missing the point some where? Many thanks, Ben

2 2

Internal and external ip addresses
by Kim Culhan 23 Apr '15

23 Apr '15

I've been running FS for some years with two nic's, one on the internal network which is configured on the FS internal profile, the other nic on the external network with an internet ip. Is this how internal and external were designed to be used? Most recently I've installed a new FS machine and noticed some problems with registering to a gateway on the external interface, which is why I ask these questions. thanks -kim

3 2

Stale channels with mod_callcenter in uuid-standby mode
by Saumar Hajjar 22 Apr '15

22 Apr '15

After a mod_callcenter member hangs up, its channel is still present in the system, and its uuid is unkillable. I believe FS team calls it a "stale channel". The uuid-standby agent won't receive any more calls, until he/she hangs up - what would make uuid-standby a "agent hangup and call again" mode. What I'm trying to do, is nothing fancy. Basically I'm following the mod_callcenter documentation without much tweaking. Here's the test case setup: - Freeswitch with default config, mod_callcenter enabled also with default config Tested with the following versions: 1.4.18+git~20150312T185523Z~4eed221b69~64bit (git 4eed221 2015-03-12 18:55:23Z 64bit) 1.5.15b+git~20150117T062211Z~46cf8a4dce~64bit (git 46cf8a4 2015-01-17 06:22:11Z 64bit) 1.5.15b+git~20150421T235828Z~a4d877c189~64bit (git a4d877c 2015-04-21 23:58:28Z 64bit) - Dialplan mod_callcenter entries:  <extension> <condition field="destination_number" expression="^\*91$"> <action application="callcenter" data="support@default"/> </condition> </extension>  <extension> <condition field="destination_number" expression="^(4099)$"> <action application="set" data="transfer_after_bridge=4099"/>  <action application="set" data="res=${callcenter_config(agent set uuid ${caller_id_number}@$default '${uuid}')}" /> <action application="set" data="res=${callcenter_config(agent set type ${caller_id_number}@$default 'uuid-standby')}" /> <action application="set" data="res=${callcenter_config(agent set status ${caller_id_number}@$default 'Available (On Demand)')}" /> <action application="set" data="res=${callcenter_config(agent set state ${caller_id_number}@$default 'Waiting')}" /> <action application="set" data="cc_warning_tone=tone_stream://%(200,0,500,600,700)"/> <action application="answer" /> <action application="playback" data="$${hold_music}"/> </condition> </extension> - Start FS and add a test agent: callcenter_config agent add 1002@default uuid-standby - Agent (extension 1002) dials 4099: The agent starts hearing music on hold. show channels uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,read_bit_rate,write_codec,write_rate,write_bit_rate,secure,hostname,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,sent_callee_name,sent_callee_num,initial_cid_name,initial_cid_num,initial_ip_addr,initial_dest,initial_dialplan,initial_context a1c9b1a4-7926-4da9-9041-100df3d1bbbb,inbound,2015-04-22 18:01:46,1429736506,sofia/internal/1002@192.168.0.136,CS_EXECUTE,1002,1002,192.168.0.103,4099,playback,local_stream://moh,XML,default,PCMU,8000,64000,PCMU,8000,64000,,hajjar-notebook,1002@192.168.0.136,,ACTIVE,,,,,,,1002,1002,192.168.0.103,4099,XML,default callcenter_config agent list name|system|uuid|type|contact|status|state|max_no_answer|wrap_up_time|reject_delay_time|busy_delay_time|no_answer_delay_time|last_bridge_start|last_bridge_end|last_offered_call|last_status_change|no_answer_count|calls_answered|talk_time|ready_time 1002@default|single_box|a1c9b1a4-7926-4da9-9041-100df3d1bbbb|uuid-standby||Available (On Demand)|Waiting|1|5|0|5|5|1429734669|1429735319|1429734669|1429736506|0|0|0|0 - Member (extension 1000) dials *91: The member gets bridged to the uuid-stand by agent. Great. show channels uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,read_bit_rate,write_codec,write_rate,write_bit_rate,secure,hostname,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,sent_callee_name,sent_callee_num,initial_cid_name,initial_cid_num,initial_ip_addr,initial_dest,initial_dialplan,initial_context a1c9b1a4-7926-4da9-9041-100df3d1bbbb,inbound,2015-04-22 18:01:46,1429736506,sofia/internal/1002@192.168.0.136,CS_EXCHANGE_MEDIA,1000,1000,192.168.0.103,4099,uuid_bridge,d298fa41-b855-4027-ba4a-ac112df641d5,XML,default,PCMU,8000,64000,PCMU,8000,64000,,hajjar-notebook,1002@192.168.0.136,,ACTIVE,1002,1002,SEND,d298fa41-b855-4027-ba4a-ac112df641d5,1000,1000,1002,1002,192.168.0.103,4099,XML,default d298fa41-b855-4027-ba4a-ac112df641d5,inbound,2015-04-22 18:04:47,1429736687,sofia/internal/1000@192.168.0.136,CS_SOFT_EXECUTE,1000,1000,192.168.0.120,*94000,uuid_bridge,a1c9b1a4-7926-4da9-9041-100df3d1bbbb,XML,default,PCMU,8000,64000,PCMU,8000,64000,,hajjar-notebook,1000@192.168.0.136,,ACTIVE,1002,1002,SEND,d298fa41-b855-4027-ba4a-ac112df641d5,1002,1002,1000,1000,192.168.0.120,*94000,XML,default 2 total. show calls uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,hostname,sent_callee_name,sent_callee_num,b_uuid,b_direction,b_created,b_created_epoch,b_name,b_state,b_cid_name,b_cid_num,b_ip_addr,b_dest,b_presence_id,b_presence_data,b_callstate,b_callee_name,b_callee_num,b_callee_direction,b_sent_callee_name,b_sent_callee_num,call_created_epoch d298fa41-b855-4027-ba4a-ac112df641d5,inbound,2015-04-22 18:04:47,1429736687,sofia/internal/1000@192.168.0.136,CS_SOFT_EXECUTE,1000,1000,192.168.0.120,*94000,1000@192.168.0.136,,ACTIVE,1002,1002,SEND,d298fa41-b855-4027-ba4a-ac112df641d5,hajjar-notebook,1002,1002,a1c9b1a4-7926-4da9-9041-100df3d1bbbb,inbound,2015-04-22 18:01:46,1429736506,sofia/internal/1002@192.168.0.136,CS_EXCHANGE_MEDIA,1000,1000,192.168.0.103,4099,1002@192.168.0.136,,ACTIVE,1002,1002,SEND,1000,1000,1429736687 1 total. callcenter_config agent list name|system|uuid|type|contact|status|state|max_no_answer|wrap_up_time|reject_delay_time|busy_delay_time|no_answer_delay_time|last_bridge_start|last_bridge_end|last_offered_call|last_status_change|no_answer_count|calls_answered|talk_time|ready_time 1002@default|single_box|a1c9b1a4-7926-4da9-9041-100df3d1bbbb|uuid-standby||Available (On Demand)|In a queue call|1|5|0|5|5|1429736687|1429735319|1429736687|1429736506|0|1|0|0 - Member hangs up show channels uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,read_bit_rate,write_codec,write_rate,write_bit_rate,secure,hostname,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,sent_callee_name,sent_callee_num,initial_cid_name,initial_cid_num,initial_ip_addr,initial_dest,initial_dialplan,initial_context a1c9b1a4-7926-4da9-9041-100df3d1bbbb,inbound,2015-04-22 18:01:46,1429736506,sofia/internal/1002@192.168.0.136,CS_EXECUTE,1002,1002,192.168.0.103,4099,playback,local_stream://moh,XML,default,PCMU,8000,64000,PCMU,8000,64000,,hajjar-notebook,1002@192.168.0.136,,ACTIVE,1000,1000,RECV,d298fa41-b855-4027-ba4a-ac112df641d5,,,1002,1002,192.168.0.103,4099,XML,default d298fa41-b855-4027-ba4a-ac112df641d5,inbound,2015-04-22 18:04:47,1429736687,sofia/internal/1000@192.168.0.136,CS_SOFT_EXECUTE,1000,1000,192.168.0.120,*94000,uuid_bridge,a1c9b1a4-7926-4da9-9041-100df3d1bbbb,XML,default,PCMU,8000,64000,PCMU,8000,64000,,hajjar-notebook,1000@192.168.0.136,,ACTIVE,1002,1002,SEND,d298fa41-b855-4027-ba4a-ac112df641d5,1002,1002,1000,1000,192.168.0.120,*94000,XML,default 2 total. show calls uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,hostname,sent_callee_name,sent_callee_num,b_uuid,b_direction,b_created,b_created_epoch,b_name,b_state,b_cid_name,b_cid_num,b_ip_addr,b_dest,b_presence_id,b_presence_data,b_callstate,b_callee_name,b_callee_num,b_callee_direction,b_sent_callee_name,b_sent_callee_num,call_created_epoch d298fa41-b855-4027-ba4a-ac112df641d5,inbound,2015-04-22 18:04:47,1429736687,sofia/internal/1000@192.168.0.136,CS_SOFT_EXECUTE,1000,1000,192.168.0.120,*94000,1000@192.168.0.136,,ACTIVE,1002,1002,SEND,d298fa41-b855-4027-ba4a-ac112df641d5,hajjar-notebook,1002,1002,a1c9b1a4-7926-4da9-9041-100df3d1bbbb,inbound,2015-04-22 18:01:46,1429736506,sofia/internal/1002@192.168.0.136,CS_EXECUTE,1002,1002,192.168.0.103,4099,1002@192.168.0.136,,ACTIVE,1000,1000,RECV,,,1429736687 1 total. callcenter_config agent list name|system|uuid|type|contact|status|state|max_no_answer|wrap_up_time|reject_delay_time|busy_delay_time|no_answer_delay_time|last_bridge_start|last_bridge_end|last_offered_call|last_status_change|no_answer_count|calls_answered|talk_time|ready_time 1002@default|single_box|a1c9b1a4-7926-4da9-9041-100df3d1bbbb|uuid-standby||Available (On Demand)|Waiting|1|5|0|5|5|1429736687|1429735319|1429736687|1429736990|0|1|0|0 Here the agent gets transfered back to uuid-standby extension and restarts hearing moh. It's state is "Waiting" - but he/she won't answer new calls. But the state is "Waiting" only because it got overridden by the dialplan. In my tests, removing the callcenter_config(agent set state..) from dialplan (and controlling agent state via CLI), I've noticed that the agent state never gets back to "Idle" (if On Demand) or "Waiting". It gets stuck in "In a queue call". Trying touuid_kill the member uuid, results in -ERR No such channel! - When agent finally hangs up: 2015-04-22 18:21:56.804183 [NOTICE] sofia.c:952 Hangup sofia/internal/1002(a)192.168.0.136 [CS_EXECUTE] [NORMAL_CLEARING] 2015-04-22 18:21:56.824219 [NOTICE] switch_core_session.c:1641 Session 6 (sofia/internal/1000(a)192.168.0.136) Ended 2015-04-22 18:21:56.824219 [NOTICE] switch_core_session.c:1645 Close Channel sofia/internal/1000(a)192.168.0.136 [CS_DESTROY] 2015-04-22 18:21:57.104198 [NOTICE] switch_core_session.c:1641 Session 4 (sofia/internal/1002(a)192.168.0.136) Ended 2015-04-22 18:21:57.104198 [NOTICE] switch_core_session.c:1645 Close Channel sofia/internal/1002(a)192.168.0.136 [CS_DESTROY] show channels, show calls return 0 If callcenter_config(agent set state...) is commented out in dialplan, callcenter_config agent list shows the agent as "Idle". Meaning mod_callcenter only perceives the call has been disconnected, after the agent hangs up... I'm not blaming mod_callcenter - maybe it's related to transfer_after_bridge. I already tried using exec_after_bridge_app/arg to a script that sleeps and transfer back to 4099. I also tried increasing the dialplan sleep. I'd appreciate any advice on how to make uuid-standby work. Thanks in advance, Saumar

1 0

FreeSWITCH 1.6 docs - pre-beta testing
by Ítalo Rossi 22 Apr '15

22 Apr '15

Hello Folks, FreeSWITCH 1.6 guide is open for pre-beta testing, you are welcome to give it a try and give your feedback to the team. Here is the doc link: https://freeswitch.org/confluence/display/FREESWITCH/FreeSWITCH+1.6+Video Thanks!

2 1

Capturing call time of IVR Menus
by Vishal Kakkar 22 Apr '15

22 Apr '15

Hi all, I got requirement to capture details about- how much time caller spent with each menu item in IVR, during his call. Any one please help, how can we capture this? I am already using mod-xml-cdr for call record capturing. Thanks Vishal.

2 1

Duplicate DTMF Issue
by jhorsburgh 22 Apr '15

22 Apr '15

Hello All, I am having some issues detecting DTMF tones and was hoping someone could shed some light on the problem. *Background* I am using Freeswitch (1.4.14~32bit) with GSMopen to receive calls and process high-speed DTMF signal for use with Alarm Systems. Unfortunately the standard inband DTMF detection is not quite up to the task but spandsp works perfectly. *Problem* The problem I am having is that the standard inband DTMF detection remains enabled when spandsp is enabled producing duplicates of each detected tone. Is there a way of disabling DTMF detection with the exception of spandsp? Any help would be greatly appreciated. Kind regards, Jeremy 2015-04-22 12:18:22.129468 [DEBUG] mod_gsmopen.cpp:919 rev 1.4.14~32bit [(nil)|37 ][DEBUG_GSMOPEN 919 ][interface1][-1, 5, 5] gsmopen/interface1 CHANNEL got SWITCH_MESSAGE_INDICATE_TRANSCODING_NECESSARY 2015-04-22 12:18:22.569494 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 2015-04-22 12:18:22.569494 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: [5] new_dtmf_timestamp: 1652802529, delta_t: 515839955 2015-04-22 12:18:22.569494 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN DETECTED: [5] 2015-04-22 12:18:22.569494 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 2015-04-22 12:18:22.749457 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: [5], duration = 178 ms 2015-04-22 12:18:23.049446 [DEBUG] switch_channel.c:488 RECV DTMF 3:2000 2015-04-22 12:18:23.049446 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: [3] new_dtmf_timestamp: 1653282480, delta_t: 479951 2015-04-22 12:18:23.049446 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN DETECTED: [3] 2015-04-22 12:18:23.049446 [DEBUG] switch_channel.c:488 RECV DTMF 3:2000 2015-04-22 12:18:23.229447 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: [3], duration = 165 ms 2015-04-22 12:18:23.529449 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 2015-04-22 12:18:23.529449 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: [5] new_dtmf_timestamp: 1653762488, delta_t: 480008 2015-04-22 12:18:23.549464 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN DETECTED: [5] 2015-04-22 12:18:23.549464 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 2015-04-22 12:18:23.689495 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: [5], duration = 140 ms 2015-04-22 12:18:24.029440 [DEBUG] switch_channel.c:488 RECV DTMF 2:2000 2015-04-22 12:18:24.029440 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: [2] new_dtmf_timestamp: 1654262471, delta_t: 499983 2015-04-22 12:18:24.029440 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN DETECTED: [2] 2015-04-22 12:18:24.029440 [DEBUG] switch_channel.c:488 RECV DTMF 2:2000 2015-04-22 12:18:24.169442 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: [2], duration = 153 ms 2015-04-22 12:18:24.489445 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 2015-04-22 12:18:24.489445 [DEBUG] mod_gsmopen.cpp:745 rev 1.4.14~32bit [(nil)|37 ][DEBUG_GSMOPEN 745 ][interface1][-1, 5, 5] DTMF DETECTED: [5] new_dtmf_timestamp: 1654722477, delta_t: 460006 2015-04-22 12:18:24.489445 [DEBUG] mod_spandsp_dsp.c:373 DTMF BEGIN DETECTED: [5] 2015-04-22 12:18:24.489445 [DEBUG] switch_channel.c:488 RECV DTMF 5:2000 2015-04-22 12:18:24.649447 [DEBUG] mod_spandsp_dsp.c:385 DTMF END DETECTED: [5], duration = 153 ms 2015-04-22 12:18:25.609450 [INFO] switch_cpp.cpp:1328 Failed to validate Checksum - '5533552255' -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Duplicate-DTMF-Issue-tp759615… Sent from the freeswitch-users mailing list archive at Nabble.com.

2 1

Re: [Freeswitch-users] patch for sofia_sip_i_invite to support replaces with action
by Luis Azedo 22 Apr '15

22 Apr '15

"Sometimes the call is authenticated, sometimes not. Regardless, do you want any autheticated call to be able to run any arbitrary application including "system" on your switch?" yes, if the control is on the proxy, that would be handy, but that's not the case. and i already refered that it could be configurable. anyway, i do agree the patch does opens the system to security issues. i actually have it harcoded with intercept:tp_call_id, just wanted to give some options without success. i opened a jira ticket and will work from there. Thanks

1 0

Broken pipe when calling WS SIP endpoint, while incoming call is ok
by Dmitry Sytchev 22 Apr '15

22 Apr '15

Hi all! I faced strange problem after upgrading to real SSL certs from startssl for WSS. When calling to WS endpoint (SIP.js 0.6.4), I get these strange messages, and call doesn't reach browser. tport.c:984 tport_base_connect() tport_base_connect(0x7f07dc005240): what(pf=2 ws/[1.2.2.94]:62846): Broken pipe tport.c:984 tport_base_connect() tport_base_connect(0x7f07dc005240): what(pf=2 ws/[1.2.2.94]:62846): Broken pipe nta.c:8496 outgoing_print_tport_error() nta: INVITE (74519703): Broken pipe (32) with ws/[1.2.2.94]:62846 Strange thing that inbound calls from WS endpoint work just fine! And setting certs back to self-signed doesn't fix problem. I'd appreciate any help, because I don't know how to debug it further. I really don't know what was the reason of the problem, does anybody have any suggestions? Here is log of calling to endpoint: 2015-04-22 17:05:34.771151 [DEBUG] mod_sofia.c:87 sofia/internal/sip:8vtik7g6@1.2.2.94:62846 SOFIA INIT 2015-04-22 17:05:34.771151 [DEBUG] sofia_glue.c:1203 sip:8vtik7g6@1.2.2.94:62846;transport=ws Setting proxy route to sofia/internal/sip:8vtik7g6@1.2.2.94:62846 2015-04-22 17:05:34.771151 [DEBUG] sofia_glue.c:1232 sofia/internal/sip:8vtik7g6@1.2.2.94:62846 sending invite version: 1.5.15b git 326289c 2014-12-20 06:25:59Z 64bit Local SDP: v=0 o=FreeSWITCH 1429686302 1429686303 IN IP4 3.4.90.23 s=FreeSWITCH c=IN IP4 3.4.90.23 t=0 0 a=msid-semantic: WMS Crr9GuLnR9pipW39wCmFv1EBDRcj6Iky m=audio 25232 RTP/SAVPF 9 0 8 3 101 13 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fingerprint:sha-256 FD:70:F0:83:A9:4E:C4:77:24:68:E3:75:0A:8D:D2:C9:F9:1D:ED:EC:5F:1B:B6:FE:1F:A0:27:33:37:FB:F2:9F a=rtcp-mux a=rtcp:25232 IN IP4 3.4.90.23 a=ssrc:1295801150 cname:0CyxWaKE90MpNGoa a=ssrc:1295801150 msid:Crr9GuLnR9pipW39wCmFv1EBDRcj6Iky a0 a=ssrc:1295801150 mslabel:Crr9GuLnR9pipW39wCmFv1EBDRcj6Iky a=ssrc:1295801150 label:Crr9GuLnR9pipW39wCmFv1EBDRcj6Ikya0 a=ice-ufrag:8AFtraVVSY5Pwgen a=ice-pwd:ICKvClZCbCRP86P6wkpOlbA4 a=candidate:3511026785 1 udp 659136 3.4.90.23 25232 typ host generation 0 a=candidate:3511026785 2 udp 659136 3.4.90.23 25232 typ host generation 0 a=ptime:20 a=sendrecv 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:40 sofia/internal/sip:8vtik7g6@1.2.2.94:62846 Standard INIT 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:48 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State Change CS_INIT -> CS_ROUTING 2015-04-22 17:05:34.771151 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/sip:8vtik7g6@1.2.2.94:62846 [BREAK] 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:512 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State INIT going to sleep 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) Running State Change CS_ROUTING 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:528 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State ROUTING 2015-04-22 17:05:34.771151 [DEBUG] mod_sofia.c:123 sofia/internal/sip:8vtik7g6@1.2.2.94:62846 SOFIA ROUTING 2015-04-22 17:05:34.771151 [DEBUG] switch_ivr_originate.c:67 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2015-04-22 17:05:34.771151 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/sip:8vtik7g6@1.2.2.94:62846 [BREAK] 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:528 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State ROUTING going to sleep 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) Running State Change CS_CONSUME_MEDIA 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:547 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State CONSUME_MEDIA 2015-04-22 17:05:34.771151 [DEBUG] switch_core_state_machine.c:547 (sofia/internal/sip:8vtik7g6@1.2.2.94:62846) State CONSUME_MEDIA going to sleep tport.c:984 tport_base_connect() tport_base_connect(0x7f07dc005240): what(pf=2 ws/[1.2.2.94]:62846): Broken pipe tport.c:984 tport_base_connect() tport_base_connect(0x7f07dc005240): what(pf=2 ws/[1.2.2.94]:62846): Broken pipe nta.c:8496 outgoing_print_tport_error() nta: INVITE (74519703): Broken pipe (32) with ws/[1.2.2.94]:62846 -- Best regards, Dmitry Sytchev, IT Engineer

2 3

Re: [Freeswitch-users] patch for sofia_sip_i_invite to support replaces with action
by Luis Azedo 22 Apr '15

22 Apr '15

> > Couldn't this be a huge security vulnerability used to inject arbitrary > commands into a session in FreeSWITCH? > > isn't the call authenticated first ? anyway, an option can be added to sip_profile to allow this. > why don't you pass the call to mod_perl or Lua, and do all the > necessary lookups in the script? This shpouldn;t be a big deal to > implement, and much more safe than patching mod_sofia. > > not an option, but thanks for suggesting > >>>

2 1