April 2015 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Compile Error with mod_lua
by SamyGo 27 Apr '15

27 Apr '15

Hi all, I'm having bit of a trouble installing freeswitch on CentOS7 with lua5.2 installed from source. When I compile FS it gives me the following output. making all mod_lua make[5]: Entering directory `/usr/src/freeswitch.git/src/mod/languages/mod_lua' CXX mod_lua_la-mod_lua.lo CXX mod_lua_la-freeswitch_lua.lo CXX mod_lua_la-mod_lua_wrap.lo mod_lua_wrap.cpp: In function 'int* SWIG_get_int_num_array_fixed(lua_State*, int, int)': mod_lua_wrap.cpp:1379:47: error: array bound forbidden after parenthesized type-id #define SWIG_ALLOC_ARRAY(TYPE,LEN) new (TYPE)[LEN] ^ mod_lua_wrap.cpp:1433:9: note: in expansion of macro 'SWIG_ALLOC_ARRAY' array=SWIG_ALLOC_ARRAY(TYPE,size);\ ^ mod_lua_wrap.cpp:1470:1: note: in expansion of macro 'SWIG_DECLARE_TYPEMAP_ARR_FN' SWIG_DECLARE_TYPEMAP_ARR_FN(int,int); ^ mod_lua_wrap.cpp:1379:47: note: try removing the parentheses around the type-id #define SWIG_ALLOC_ARRAY(TYPE,LEN) new (TYPE)[LEN] ^ mod_lua_wrap.cpp:1433:9: note: in expansion of macro 'SWIG_ALLOC_ARRAY' array=SWIG_ALLOC_ARRAY(TYPE,size);\ ^ mod_lua_wrap.cpp:1470:1: note: in expansion of macro 'SWIG_DECLARE_TYPEMAP_ARR_FN' SWIG_DECLARE_TYPEMAP_ARR_FN(int,int); ^ mod_lua_wrap.cpp: In function 'int* SWIG_get_int_num_array_var(lua_State*, int, int*)': mod_lua_wrap.cpp:1379:47: error: array bound forbidden after parenthesized type-id #define SWIG_ALLOC_ARRAY(TYPE,LEN) new (TYPE)[LEN] ^ Any help would be greatly appreacited. Thanks, Sammy

5 8

Dialplan ARRAYs - how to check size
by DanB 27 Apr '15

27 Apr '15

Hey Guys, I was wondering if you could help me figuring out how to check the size of a channel variable of type ARRAY (as per documentation here: https://wiki.freeswitch.org/wiki/Dialplan_ARRAYS) Ta for any kind of tip! DanB

1 0

Client gets hang-up after 32 seconds
by Charles Bujold 27 Apr '15

27 Apr '15

We have an extension that we can call and can talk with no problems. However if the extension calls us, he gets connected and we can only talk for 32 seconds before the call gets terminated. We looked at the log and are unable to identify the reason why he cannot call us but that we can call him. The error seems to be that when he calls Freeswitch for some reason sets a timeout of 30 seconds (Setting leg timeout to 30) See log below. Please help. How can we fix this? Thanks Charles 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 o=FreeSWITCH 1430114648 1430114650 IN IP4 156.34.240.101 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 s=FreeSWITCH 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 c=IN IP4 156.34.240.101 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 t=0 0 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 m=audio 25974 RTP/AVP 0 101 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=rtpmap:0 PCMU/8000 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=rtpmap:101 telephone-event/8000 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=fmtp:101 0-16 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=ptime:20 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=sendrecv 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:908 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:1053 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [NOTICE] switch_ivr_originate.c:3522 Channel [sofia/internal/425(a)192.168.20.153] has been answered 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_channel.c:3689 (sofia/internal/425(a)192.168.20.153) Callstate Change EARLY -> ACTIVE 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] sofia.c:6614 Channel sofia/internal/425(a)192.168.20.153 entering state [completed][200] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_originate.c:3580 Originate Resulted in Success: [sofia/internal/sip:200@192.168.20.150:5060] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_originate.c:2847 sofia/internal/sip:200@192.168.20.150:5060 Setting leg timeout to 30 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_originate.c:3580 Originate Resulted in Success: [sofia/internal/sip:200@192.168.20.150:5060] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:908 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:908 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_bridge.c:1465 (sofia/internal/sip:200@192.168.20.150:5060) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/sip:200@192.168.20.150:5060) Running State Change CS_EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_state_machine.c:538 (sofia/internal/sip:200@192.168.20.150:5060) State EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] mod_sofia.c:594 SOFIA EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.845827 [DEBUG] switch_rtp.c:5853 Correct ip/port confirmed. 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.785826 [DEBUG] switch_core_session.c:1053 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.785826 [DEBUG] switch_core_session.c:1053 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] sofia.c:6614 Channel sofia/internal/425(a)192.168.20.153 entering state [terminating][0] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [NOTICE] sofia.c:7530 Hangup sofia/internal/425(a)192.168.20.153 [CS_EXECUTE] [NORMAL_UNSPECIFIED] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] switch_channel.c:3222 Send signal sofia/internal/425(a)192.168.20.153 [KILL] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] mod_hash.c:298 Usage for 192.168.20.153_200 is now 0 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] switch_ivr_bridge.c:660 BRIDGE THREAD DONE [sofia/internal/425(a)192.168.20.153] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.805822 [DEBUG] switch_ivr_bridge.c:690 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:579 sofia/internal/425(a)192.168.20.153 ending bridge by request from write function b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:660 BRIDGE THREAD DONE [sofia/internal/sip:200@192.168.20.150:5060] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:690 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [NOTICE] switch_ivr_bridge.c:754 Hangup sofia/internal/sip:200@192.168.20.150:5060 [CS_EXCHANGE_MEDIA] [NORMAL_CLEARING] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_channel.c:3222 Send signal sofia/internal/sip:200@192.168.20.150:5060 [KILL] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:538 (sofia/internal/sip:200@192.168.20.150:5060) State EXCHANGE_MEDIA going to sleep b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/sip:200@192.168.20.150:5060) Running State Change CS_HANGUP b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:735 (sofia/internal/sip:200@192.168.20.150:5060) Callstate Change ACTIVE -> HANGUP b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:1563 sofia/internal/sip:200@192.168.20.150:5060 skip receive message [UNBRIDGE] (channel is hungup already) 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:1566 sofia/internal/425(a)192.168.20.153 skip receive message [UNBRIDGE] (channel is hungup already) b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:737 (sofia/internal/sip:200@192.168.20.150:5060) State HANGUP b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] mod_sofia.c:413 Channel sofia/internal/sip:200@192.168.20.150:5060 hanging up, cause: NORMAL_CLEARING 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.825829 [DEBUG] switch_core_session.c:2893 sofia/internal/425(a)192.168.20.153 skip receive message [APPLICATION_EXEC_COMPLETE] (channel is hungup already)

2 1

Need cluster architecture suggestion
by Samir Doshi 27 Apr '15

27 Apr '15

Hi Guys, What will be the best setup architecture to handle 50k subscriber registration and approximate 30k concurrent calls? We are planning to use opensips/kamailio proxy server for load balance & to handle registration and multiple freeswitch servers to handle media. Database will be MySQL. Is this good way? OR anybody have any other proposed architecture which can be helpful? Moreover Is there any way we can change codec realtime based on internet connectivity speed? Please let us know your thoughts. Thanks in advance.

8 16

Confirmation of ICE connectivity check success
by Oleg Stolyar 27 Apr '15

27 Apr '15

Hi guys, Is there something in FreeSWITCH logs or events I can use to confirm whether the ICE connectivity check ( https://tools.ietf.org/html/rfc5245#section-2.2) succeeded and what candidate pair was chosen? If it did not succeed, is there a way to see the attempted candidate pair and most importantly to determine for each pair what direction the connectivity failed? This is for WebRTC, if it makes a difference.

1 1

Re: [Freeswitch-users] Need cluster architecture suggestion
by Luis Azedo 27 Apr '15

27 Apr '15

take a look at kazoo https://github.com/2600hz/kazoo Best

1 0

[Warning][switch_core_media.c:1945 Changing current codec to PCMU (payload type 0)]
by Bilal Abbasi 27 Apr '15

27 Apr '15

Hi Brain, Actully i am calling through SIPP, i will take tcpdump and will let you that actually voice works or not, But i am planing to get rid of this warning, i am assuming that this will not make a better stress testing results. Regards Bilal Abbasi

1 0

transfer aleg via ${dial-string}
by Sergey Safarov 26 Apr '15

26 Apr '15

I want emulate REFER message from bleg via ${dial-string}. Please help me find how to do it. I try 1) originate sofia/internal/sip:1000@8.8.8.8 &bridge({execute_on_ring='transfer 1001 XML default'}loopback/9180/default) 2) originate sofia/internal/sip:1000@8.8.8.8 &bridge({execute_on_ring='transfer 1001 XML default'}sofia/internal/ sip:1002@8.8.8.8) In both cases all leg hangup. Also two question: 1) can be lua or other scripting language used to emulate endpoint (implement endpoint interface)? 2) how can be realized "execute_on_channel_create_failure" logic similarity "execute_on_ring". Sergey

1 1

Music on Hold working only in one direction
by Paul Atreides 26 Apr '15

26 Apr '15

Hi, my music on hold is only working in one direction. When I call someone everything is working. But when I get called from the gateway over PSTN the music just gets alluded and then stops. The debug messages are not really helping. Is there a way how to figure this out? Oddly the transfer_ringback music is working in both ways vars.xml <X-PRE-PROCESS cmd="set" data="hold_music=$${sounds_dir}/music/output.mp3"/> <X-PRE-PROCESS cmd="set" data="transfer_ringback=$${sounds_dir}/music/output.mp3"/> dialplan/default.xml <action application="bridge_export" data="hold_music=$${sounds_dir}/music/output.mp3"/> Thank you

1 0

Re: [Freeswitch-users] Random Freeswitch Crash
by Jai Rangi 24 Apr '15

24 Apr '15

I see some replies, on archive, but not getting emails. Checked my spam also. Reply yo my own post, apology if this creates a new thread. I am using 1.4.18,. This is the first thing I did. Update from 1.4.11 Anthony suggest latest master branch, should I update to 1.5.1. I did not go for that as it was not recommended. I cant not reproduce the issue, if happens by itself and I have no idea. I will try to get as much information I can from this list https://freeswitch.org/confluence/display/FREESWITCH/Reporting+Bugs+to+JIRA I dont get any core dump, so I cant get backtrace. Do I have to enable something to get the code dump. I have this enabled in switch.conf.xml <param name="dump-cores" value="yes"/> On Fri, Apr 24, 2015 at 2:25 PM, Jai Rangi <jprangi(a)gmail.com> wrote: > FS Server has been running fine for last 5 months, suddenly since > yesterday it started crashing every few hours. Checked the log files and > did not see any error message. > > I made few changes recently: > > Enabled Shared line in sip_profile/internal > > <param name="presence-probe-on-register" value="true"/> > <param name="manage-shared-appearance" value="true"/> > > Using a LUA script for group call, change the originate to enterprise > originate. > > From > bridge(user/101@domainname,user/102@domainname) > > To > > bridge(<all_threads=true>user/101@domainname:_:user/102@domainname) > > The reason I did this, was that, if shared line is registered on more > than one device, we want all the devices to ring and other people should be > able to take call by just pressing the line numbers. > > Changes the debug to level to 10 and still no information in the log file. > No core dump was generated for me to share or look at. > > FS is running a server with decent specs. Dual CPU, Quad Core, 48 GB Ram. > SSD Hard drive. > > Wondering if anyone else had the smiler issue and if I can get a hint > where I can look for more hints on why FS dies all of a sudden. > > Thank you, > -Jai > >

1 0