March 2014 - FreeSWITCH-users - FreeSWITCH Mailing Lists

make current failed on CENTOS 64 bit
by Sean Devoy 14 Mar '14

14 Mar '14

I have FreeSWITCH Version 1.2.18+git~20140129T015817Z~3307500e69~64bit (git 3307500 2014-01-29 01:58:17Z 64bit) I went to /usr/local/freeswitch and tried make current Here is the end of the log file, any ideas? Making all in tport make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/tport' make[10]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/tport' LTCOMPILE tport.lo LTCOMPILE tport_logging.lo LTCOMPILE tport_stub_sigcomp.lo LTCOMPILE tport_type_udp.lo LTCOMPILE tport_type_tcp.lo LTCOMPILE tport_type_sctp.lo LTCOMPILE tport_tag.lo LTCOMPILE tport_tag_ref.lo LTCOMPILE tport_type_connect.lo LTCOMPILE tport_type_tls.lo LTCOMPILE tport_tls.lo cc1: warnings being treated as errors tport_tls.c: In function 'tls_post_connection_check': tport_tls.c:573: warning: passing argument 1 of 'SSL_CIPHER_description' discards qualifiers from pointer target type make[10]: *** [tport_tls.lo] Error 1 make[10]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/tport' make[9]: *** [all] Error 2 make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/tport' Making all in nta make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nta' make[10]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nta' LTCOMPILE nta.lo LTCOMPILE nta_check.lo LTCOMPILE nta_tag.lo LTCOMPILE nta_tag_ref.lo LTCOMPILE sl_utils_print.lo LTCOMPILE sl_utils_log.lo LTCOMPILE sl_read_payload.lo LINK libnta.la make[10]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nta' make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nta' Making all in nth make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nth' make[10]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nth' LTCOMPILE nth_client.lo LTCOMPILE nth_server.lo LTCOMPILE nth_tag.lo LTCOMPILE nth_tag_ref.lo LINK libnth.la make[10]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nth' make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nth' Making all in nea make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nea' make[10]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nea' LTCOMPILE nea.lo LTCOMPILE nea_event.lo LTCOMPILE nea_server.lo LTCOMPILE nea_debug.lo LTCOMPILE nea_tag.lo LTCOMPILE nea_tag_ref.lo LINK libnea.la make[10]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nea' make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nea' Making all in iptsec make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/iptsec' make[10]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/iptsec' LTCOMPILE auth_client.lo LTCOMPILE auth_common.lo LTCOMPILE auth_digest.lo LTCOMPILE auth_module.lo LTCOMPILE auth_tag.lo LTCOMPILE auth_tag_ref.lo LTCOMPILE auth_plugin.lo LTCOMPILE auth_plugin_delayed.lo LTCOMPILE auth_module_sip.lo LTCOMPILE iptsec_debug.lo LTCOMPILE auth_module_http.lo LINK libiptsec.la make[10]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/iptsec' make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/iptsec' Making all in nua make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nua' make[10]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nua' LTCOMPILE nua.lo LTCOMPILE nua_common.lo LTCOMPILE nua_stack.lo LTCOMPILE nua_server.lo LTCOMPILE nua_client.lo LTCOMPILE nua_extension.lo LTCOMPILE nua_dialog.lo LTCOMPILE outbound.lo LTCOMPILE nua_params.lo LTCOMPILE nua_register.lo LTCOMPILE nua_registrar.lo LTCOMPILE nua_session.lo LTCOMPILE nua_options.lo LTCOMPILE nua_message.lo LTCOMPILE nua_publish.lo LTCOMPILE nua_subnotref.lo LTCOMPILE nua_notifier.lo LTCOMPILE nua_event_server.lo LTCOMPILE nua_tag.lo LTCOMPILE nua_tag_ref.lo LINK libnua.la make[10]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nua' make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/nua' make[9]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua' make[9]: *** No rule to make target `tport/libtport.la', needed by `libsofia-sip-ua.la'. Stop. make[9]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua' make[8]: *** [all-recursive] Error 1 make[8]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua' Making all in packages make[8]: Entering directory `/usr/local/src/freeswitch/libs/sofia-sip' make[8]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip' make[7]: *** [all-recursive] Error 1 make[7]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip' make[6]: *** [all] Error 2 make[6]: Leaving directory `/usr/local/src/freeswitch/libs/sofia-sip' make[5]: *** [/usr/local/src/freeswitch/libs/sofia-sip/libsofia-sip-ua/libsofia-sip-ua.la] Error 2 make[5]: Leaving directory `/usr/local/src/freeswitch/src/mod/endpoints/mod_sofia' make[4]: *** [mod_sofia-all] Error 1 make[4]: Leaving directory `/usr/local/src/freeswitch/src/mod' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/freeswitch/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/freeswitch' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/freeswitch' make: *** [current] Error 2 Is this supposed to be a jira item? Thanks, Sean

6 21

Media delay when calling FS from a WebRTC client
by Oleg Stolyar 14 Mar '14

14 Mar '14

Hi guys, does anyone know what is causing media delay after the call is connected in this case? Usually delays in WebRTC are caused by ICE candidate gathering and I am seeing that on my client (JsSip demo). However there is another delay in getting media after the call is connected. I found an old Jira ticket where Anthony mentioned that on FS demo servers there is a 2.5 sec delay in answering but I could not find info on what is causing this delay. It seems to me that FS does not need to gather ICE candidates since it can (and does) take the only candidate from the ext-rtp-ip variable. So, why the delay? Thank you Oleg

6 21

Friday Call
by Brian West 14 Mar '14

14 Mar '14

Don’t forget to join in… THE BUG HUNT HAS BEGUN! MAY THE JIRA BE EVER IN YOUR FAVOR! -- Brian West brian(a)freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)

1 0

Channel Variable Caller-Source is set to "..\..\src\switch_ivr_originate.c" for SIP calls
by Markus von Arx 14 Mar '14

14 Mar '14

Hi I just realized that the channel variable "Caller-Source" is set to "..\..\src\switch_ivr_originate.c" for SIP calls. I'm using FreeSwitch 1.2.22 on Windows. Is this a bug or intentional? I'm originating SIP calls through mod_event_socket with commands like this: > bgapi expand originate {origination_uuid=983e7a0a-cf65-4e86-8314-93222a65e8b8}sofia/${domain}/9972 1000 XML mydialplan 1000 1000 Btw: this also affect the XML dialplan builtin-in varible (caller profile field) "source". Regards, Markus

1 0

Trying to get my head around threads...
by Alex Lake 14 Mar '14

14 Mar '14

I'm in the process of tidying up the way in which our dialplans and scripts are constructed, but am slightly struggling to understand how threads relate to channels and stuff like that. For example, we have a call that comes in, a bridge is made to a recipient and at the same time, we bind ** to a "mid-call menu" so that the b-party can hit ** and then do stuff (eg. initiate a transfer). This has all been working fine using a basic dialplan approach, but as we add more features in, the dialplans are getting somewhat unreadable and hard to understand. I would like to adopt a more modular approach such that if we wanted (for example) an a-party mid-call menu, we would share the same code, but with flags to indicate the differences in call handling. So the idea of trying to go a little more lua-centric strikes me as a good one in theory. However, my first attempt at this seems to have fallen foul of the "defying physics" problem that Anthony has mentioned before - when the b-party hits **, the a-party doesn't get on-hold music (their line just goes quiet) until the b-party hangs up. I'll be looking into the differences between the working script (with dialplan) and the prototypical (lua-rich) version, but in the meantime there is something about the working script that seems to be using some undocumented feature - uuid_transfer with -aleg (not sure what this is doing, if indeed anything at all!). Also, I get the impression that bgapi doesn't really work from within lua. I've seen reference to running luarun within lua to start a new thread, but am unsure as to how to tame it.

1 1

Matching destination number
by mbo 14 Mar '14

14 Mar '14

Hello, I have the following dial plan: <extension name="international destination_number" continue="true"> <condition field="destination_number" expression="^00(\d+)$"> <action application="log" data="CONSOLE *** international number ${destination_number} ***"/> <action application="set_profile_var" data="destination_number=$1"/> </condition> </extension> <extension name="national destination_number" continue="true"> <condition field="destination_number" expression="^0(\d+)$"> <action application="log" data="CONSOLE *** international number ${destination_number}"/> <action application="set_profile_var" data="destination_number=49$1"/> </condition> </extension> If I dial number 001234567, I get the following output in the console: 2014-03-11 19:43:42.945392 [CONSOLE] mod_dptools.c:1569 *** international number 001234567 *** 2014-03-11 19:43:42.945392 [CONSOLE] mod_dptools.c:1569 *** international number 1234567 The second extension is matching, however in the first extension the destination_number has been overridden and does not have any leading zeros. Why is it matching anyway? Thanks Markus

5 13

uuid_exists in ESL (Perl)
by Ali Pey 13 Mar '14

13 Mar '14

Hello, What's the proper way to call uuid_exists in ESL using Perl or any other scripting language? Thanks, Ali Pey

3 8

Cannot Make any call [CS_NEW] [WRONG_CALL_STATE]
by crazygabry 13 Mar '14

13 Mar '14

Hello everybody, i cannot figure out this problem.. i have a multi tenant freeswitch installation. with every domain i can register users but when i try to make any call i get this behaviour: 2013-12-18 00:30:12.654751 [DEBUG] switch_core_session.c:1048 Send signal sofia/internal/1000@MYDOMAIN:9060 [BREAK] 2013-12-18 00:30:12.654751 [DEBUG] switch_core_session.c:1048 Send signal sofia/internal/1000@MYDOMAIN:9060 [BREAK] 2013-12-18 00:30:12.654751 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1000@MYDOMAIN:9060) Running State Change CS_NEW 2013-12-18 00:30:12.654751 [DEBUG] switch_core_state_machine.c:486 (sofia/internal/1000@MYDOMAIN:9060) State NEW 2013-12-18 00:30:12.654751 [DEBUG] switch_core_session.c:1048 Send signal sofia/internal/1000@MYDOMAIN:9060 [BREAK] 2013-12-18 00:30:12.654751 [DEBUG] sofia.c:1845 detaching session 8f2d7628-677b-11e3-af8c-a115136ede7e 2013-12-18 00:30:22.714696 [WARNING] switch_core_state_machine.c:567 8f2d7628-677b-11e3-af8c-a115136ede7e sofia/internal/1000@MYDOMAIN:9060 Abandoned 2013-12-18 00:30:22.714696 [NOTICE] switch_core_state_machine.c:570 Hangup sofia/internal/1000@MYDOMAIN:9060 [CS_NEW] [WRONG_CALL_STATE] 2013-12-18 00:30:22.714696 [DEBUG] switch_channel.c:3211 Send signal sofia/internal/1000@MYDOMAIN:9060 [KILL] 2013-12-18 00:30:22.714696 [DEBUG] switch_core_session.c:1383 Send signal sofia/internal/1000@MYDOMAIN:9060 [BREAK] 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1000@MYDOMAIN:9060) Running State Change CS_HANGUP 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:731 (sofia/internal/1000@tMYDOMAIN:9060) State HANGUP 2013-12-18 00:30:22.714696 [DEBUG] mod_sofia.c:413 Channel sofia/internal/1000@MYDOMAIN:9060 hanging up, cause: WRONG_CALL_STATE 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:58 sofia/internal/1000@MYDOMAIN:9060 Standard HANGUP, cause: WRONG_CALL_STATE 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:731 (sofia/internal/1000@MYDOMAIN:9060) State HANGUP going to sleep 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:744 (sofia/internal/1000@MYDOMAIN:9060) Callstate Change DOWN -> HANGUP 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/1000@MYDOMAIN:9060) State Change CS_HANGUP -> CS_REPORTING 2013-12-18 00:30:22.714696 [DEBUG] switch_core_session.c:1383 Send signal sofia/internal/1000@MYDOMAIN:9060 [BREAK] 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1000@MYDOMAIN:9060) Running State Change CS_REPORTING 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:816 (sofia/internal/1000@MYDOMAIN:9060) State REPORTING 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:102 sofia/internal/1000@MYDOMAIN:9060 Standard REPORTING, cause: WRONG_CALL_STATE 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:816 (sofia/internal/1000@MYDOMAIN:9060) State REPORTING going to sleep 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:493 (sofia/internal/1000@MYDOMAIN:9060) State Change CS_REPORTING -> CS_DESTROY 2013-12-18 00:30:22.714696 [DEBUG] switch_core_session.c:1383 Send signal sofia/internal/1000@MYDOMAIN:9060 [BREAK] 2013-12-18 00:30:22.714696 [DEBUG] switch_core_session.c:1591 Session 32 (sofia/internal/1000@MYDOMAIN:9060) Locked, Waiting on external entities 2013-12-18 00:30:22.714696 [NOTICE] switch_core_session.c:1609 Session 32 (sofia/internal/1000@MYDOMAIN:9060) Ended 2013-12-18 00:30:22.714696 [NOTICE] switch_core_session.c:1613 Close Channel sofia/internal/1000@MYDOMAIN:9060 [CS_DESTROY] 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:618 (sofia/internal/1000@MYDOMAIN:9060) Callstate Change HANGUP -> DOWN 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:621 (sofia/internal/1000@MYDOMAIN:9060) Running State Change CS_DESTROY 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:631 (sofia/internal/1000@MYDOMAIN:9060) State DESTROY 2013-12-18 00:30:22.714696 [DEBUG] mod_sofia.c:323 sofia/internal/1000@MYDOMAIN:9060 SOFIA DESTROY 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:109 sofia/internal/1000@MYDOMAIN:9060 Standard DESTROY 2013-12-18 00:30:22.714696 [DEBUG] switch_core_state_machine.c:631 (sofia/internal/1000@MYDOMAIN:9060) State DESTROY going to sleep i reloaded mod_sofia and xml. Can you also tell me if i have to reload sofia or just reload xml in order to add a domain? Thanks in advice -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Cannot-Make-any-call-CS-NEW-W… Sent from the freeswitch-users mailing list archive at Nabble.com.

5 4

Any way to block on "freeswitch.xml.fsxml" being generated?
by Nathan Neulinger 13 Mar '14

13 Mar '14

Right now, if you run reloadxml, it returns completion, but the merged config is often not fully written. Is there any way to wait for that to fully generate? Or alternatively, could this code be changed to have that file updated atomically (written to tmp file + renamed into place)? Seems like it would be a relatively trivial change to switch_xml_parse_file to do it atomically. -- Nathan ------------------------------------------------------------ Nathan Neulinger nneul(a)mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect

2 3

Lua variables
by Alex Lake 13 Mar '14

13 Mar '14

I'm looking into moving a more Lua-orientated view of call handling. An upshot of this is that some variables are more neatly (and efficiently) retained as Lua local or global variables instead of being channel variables. One of the things that would be very nice would be to have access from one Lua script to another to look at a master-leg's data. Is this at all possible? There are other options (eg. for the Lua script to export its data into channel variable(s) and then the other one to look at that).

1 0