- FreeSWITCH-users - FreeSWITCH Mailing Lists

ClueCon Slides: OpenSIPS 2.3 and beyond
by Bogdan-Andrei Iancu 11 Aug '17

11 Aug '17

Hi, Upon several requests, I'm sharing here the presentation about OpenSIPS 2.3 integration capabilities with FreeSWITCH, Homer, SIP-I, CGRates, OrecX and many other. https://docs.google.com/presentation/d/12K7raELwsv0hEypEu1XUyfA3nV9vOwQpsIC… Thank you ClueCon ! -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Bootcamp 2017, Houston, US http://opensips.org/training/OpenSIPS_Bootcamp_2017.html

1 0

How to export variable downstream on execute_on_answer?
by Lợi Đặng 11 Aug '17

11 Aug '17

Hi guys, I have a simple call scenario: *Caller -> FS -> Callee* Callee answer the call with an additional header called X-MyVar in 200 OK. I'm trying to store that value only for reporting via CHANNEL_HANGUP_COMPLETE - event socket. I'm retrieving that custom header by looking at ${sip_rh_X-MyVar} via *execute_on_answer* on B leg, and it's fine. But I'm unable to export it to the A leg. Here's my dialplan: *<extension name="logvar"> <condition field="destination_number" expression="^logvar$"> <action application="export" data="myvar=${sip_rh_X-MyVar}"/> </condition></extension><action application="bridge" data="{execute_on_answer=execute_extension logvar XML external}sofia/external/${destination_number}"/>* I don't want X-MyVar header to be passed to Caller, so I have to export the variable. But when CHANNEL_HANGUP_COMPLETE fires, the variable *variable_myvar* present only in the outbound B leg. Look like my export did not work. Note that I have some upstream exports from A leg to B leg in normal XML dialplan and they're all fine. Below is my fs_cli log: 192.168.1.100 is my FS. *Dialplan: sofia/external/400@192.168.1.100:5060 <http://400@192.168.1.100:5060> Action export(myvar=${sip_rh_X-MyVar})2017-08-10 17:27:29.958572 [NOTICE] switch_core_session.c:2913 Execute export(myvar=${sip_rh_X-MyVar})EXECUTE sofia/external/400@192.168.1.100:5060 <http://400@192.168.1.100:5060> export(myvar=598c35116ee949.25824485)2017-08-10 17:27:29.958572 [DEBUG] switch_channel.c:1296 EXPORT (export_vars) [myvar]=[598c35116ee949.25824485]* Not sure what I'm missing in this case. Any help would be appreciated. rgds, Loi Dang

3 4

[FreeBSD 11] FS 1.8.0 needs -KILL signal to stop after shutdown issued
by Eric Masson 10 Aug '17

10 Aug '17

Hi, I'm planning to upgrade an existing home FS setup to the latest available version. Version used : FreeSWITCH Version 1.8.0+git~20170802T153919Z~417639a1b1~64bit (git 417639a 2017-08-02 15:39:19Z 64bit) local_ip_v4 is setup in vars.xml as it seems autodetection doesn't fully work. When stopping FS by running "shutdown", FS goes through the whole stop sequence but doesn't exit in the end, I have to send -KILL signal to the process to stop it. freeswitch.log doesn't show any immediate reason. ptrace of the FS process while stopping shows what seems to be a loop : 17589 freeswitch RET select 0 17589 freeswitch CALL select(0,0,0,0,0x7fffdfeccf00) 17589 freeswitch RET _umtx_op -1 errno 60 Operation timed out 17589 freeswitch CALL _umtx_op(0x80062e098,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfe8fe28) 17589 freeswitch RET select 0 17589 freeswitch CALL select(0,0,0,0,0x7fffdfffdf10) 17589 freeswitch RET _umtx_op -1 errno 60 Operation timed out 17589 freeswitch CALL _umtx_op(0x80062e098,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfe8fe28) 17589 freeswitch RET select 0 17589 freeswitch CALL select(0,0,0,0,0x7fffdfeccf00) 17589 freeswitch RET _umtx_op -1 errno 60 Operation timed out 17589 freeswitch CALL _umtx_op(0x80062e098,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfe8fe28) Supplemental information : - 1.6.19 shows the same issue. - FS installed and ran as root or unprivileged user shows the same issue. Should I file a JIRA, please ? Thanks Éric Masson

3 5

ClueCon Slides: Industrial Grade FreeSWITCH, Scaling, Balancing, High Availability, SIP, WebRTC
by Giovanni Maruzzelli 10 Aug '17

10 Aug '17

*Industrial Grade FreeSWITCH Scaling, Balancing and High Availability for SIP and WebRTC* Scaling your FreeSWITCH platform to serve a growing user base is a critical challenge. We'll go through the best techniques, practices, and implementations for Voice and Video Calls, Conferencing, WebRTC, SIP, Chatting, Presence and Instant Messaging Slides can also be downloaded from http://opentelecom.it/cluecon2017.pdf Enjoy ClueCon! -giovanni -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18

1 0

defunct processes created by bgsystem / system
by Dave Horton 10 Aug '17

10 Aug '17

I have the following action in my dialplan: <action application="bgsystem" data = "/opt/scripts/push_handler.php ${uuid} ${sip_contact_user} ${host}"/> each time that command gets executed I see another defunct freeswitch process created: root@cor03-san:/usr/local/freeswitch/log# ps -ef | grep freeswitch root 23010 1 2 06:37 ? 00:00:25 /usr/local/freeswitch/bin/freeswitch -nc -nonat root 23209 23010 0 06:44 ? 00:00:00 [freeswitch] <defunct> root 23242 23010 0 06:45 ? 00:00:00 [freeswitch] <defunct> root 23300 23010 0 06:48 ? 00:00:00 [freeswitch] <defunct> I tried changing 'bgsystem' to 'system' and reloaded the dialplan, but it continued to drop defunct processes. I’ve entered Jira FS-10572 as it seems like this is a bug, but I am wondering if there is a workaround of some kind?

2 3

Persist outbound event socket after channel is destroyed
by Sean Ingham 09 Aug '17

09 Aug '17

I'm using the socket application in the dialplan to establish an outbound event socket to my app. I use the async and full flags to expose full api functionality. I currently use myevents to filter only events related to the current channel, I also use the linger command to ensure the socket stays up until all channel events have been sent to my app (after which FS then tears down the socket). However, what I'm trying to do is prevent FS closing the socket at all, and always leave it up to my app to close the socket when it's finished with it. Is this possible with ESL in outbound mode? In other words, I want the socket to linger longer :) Sean.

3 4

Watch ClueCon live on FaceBook
by Anthony Minessale 09 Aug '17

09 Aug '17

http://facebook.com/freeswitch -- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA

4 5

2017-08-09 06:06:29.494827 [CRIT] switch_core_session.c:1755 LUKE: I'm hit, but not bad.
by Jurijs Ivolga 09 Aug '17

09 Aug '17

Hi, I'm constantly getting following error after around 1 week running freeswitch on quite a low amount of traffic and freeswitch stops to replying to any traffic: 7fcf13e5-4529-464c-87af-67dca8a2eca8 2017-08-09 06:06:06.454889 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/xxxx@myip [7fcf13e5-4529-464c-87af-67dca8a2eca8] 2017-08-09 06:06:06.454889 [CRIT] switch_core_session.c:1799 Thread Failure! 83f02a66-630e-4f59-8716-12a107478059 2017-08-09 06:06:29.494827 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/xxxx@myip [83f02a66-630e-4f59-8716-12a107478059] 2017-08-09 06:06:29.494827 [CRIT] switch_core_session.c:1799 Thread Failure! 2017-08-09 06:06:29.494827 [CRIT] switch_core_session.c:1755 LUKE: I'm hit, but not bad. 2017-08-09 06:06:29.494827 [CRIT] switch_core_session.c:1756 LUKE'S VOICE: Artoo, see what you can do with it. Hang on back there.... Green laserfire moves past the beeping little robot as his head turns. After a few beeps and a twist of his mechanical arm, Artoo reduces the max sessions to 101 thus, saving the switch from certain doom. fs_cli stops to work and freeswitch replies with: SIP/2.0 503 Maximum Calls In Progress Cpu usage is 0. Any hints? Jurijs

2 4

Eavesdrop problems
by Tor Petterson 09 Aug '17

09 Aug '17

Hi I think I've run into a bug using eavesdrop. The scenario is that I setup a webRTC channel which I want to be able to eavesdrop on several calls in succession. I do this by starting eavesdrop then when I switch to eavesdrop on another call, I park the webRTC call before starting eavesdrop again. My problem is that I can only do this a few times before I lose audio on the webRTC call. When the problem occurs I get no entries in the log when I call the eavesdrop application. I tried to do some debugging on this and it seems that the channel thread gets stuck somewhere. Does anyone know a workaround or have an idea where in the code to look for the problem?

4 6

Why do inbound calls receive "invalid number"?
by Nate 09 Aug '17

09 Aug '17

Good day/evening everyone, Calls from my mobile are showing up in the logs, but they aren't ringing the extension I have configured for Destination. I've searched, purchased (and been reading) the eBook Freeswitch 1.8, but am still a bit perplexed by what the issue is. Can anyone please assist with interpreting of the following log? Many many thanks!!! [WARNING] sofia_reg.c:1792 SIP auth challenge (REGISTER) on sofia profile 'internal' for [204(a)newplymouth.poiema.org] from ip 192.168.1.93 2017-08-09 10:13:51.062063 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/64225551212(a)206.191.159.247 [64db53af-fa7b-4878-9bdd-fd45a2f8f312] 2017-08-09 10:13:51.062063 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/64225551212(a)206.191.159.247) Running State Change CS_NEW (Cur 1 Tot 7) 2017-08-09 10:13:51.062063 [DEBUG] sofia.c:9873 sofia/internal/ 64225551212(a)206.191.159.247 receiving invite from 206.191.159.247:5060 version: 1.6.19 -36-7a77e0b 64bit 2017-08-09 10:13:51.062063 [DEBUG] sofia.c:10044 IP 206.191.159.247 Rejected by acl "domains". Falling back to Digest auth. 2017-08-09 10:13:51.062063 [DEBUG] sofia.c:2334 detaching session 64db53af-fa7b-4878-9bdd-fd45a2f8f312 2017-08-09 10:13:51.062063 [WARNING] sofia_reg.c:1792 SIP auth challenge (INVITE) on sofia profile 'internal' for [6468808998(a)newplymouth.poiema.org] from ip 206.191.159.247 2017-08-09 10:13:51.062063 [DEBUG] switch_core_state_machine.c:603 (sofia/internal/64225551212(a)206.191.159.247) State NEW 2017-08-09 10:13:51.482817 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/64225551212(a)192.241.183.87 [8b74f385-3024-40fe-a83d-892e5ecd7bc3] 2017-08-09 10:13:51.482817 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/64225551212(a)192.241.183.87) Running State Change CS_NEW (Cur 2 Tot 8) 2017-08-09 10:13:51.482817 [DEBUG] sofia.c:9873 sofia/internal/ 64225551212(a)192.241.183.87 receiving invite from 192.241.183.87:5060 version: 1.6.19 -36-7a77e0b 64bit 2017-08-09 10:13:51.482817 [DEBUG] sofia.c:10044 IP 192.241.183.87 Rejected by acl "domains". Falling back to Digest auth. 2017-08-09 10:13:51.482817 [DEBUG] sofia.c:2334 detaching session 8b74f385-3024-40fe-a83d-892e5ecd7bc3 2017-08-09 10:13:51.482817 [WARNING] sofia_reg.c:1792 SIP auth challenge (INVITE) on sofia profile 'internal' for [6468808998(a)newplymouth.poiema.org] from ip 192.241.183.87 2017-08-09 10:13:51.482817 [DEBUG] switch_core_state_machine.c:603 (sofia/internal/64225551212(a)192.241.183.87) State NEW 2017-08-09 10:13:52.182503 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/64225551212(a)107.6.13.77 [af5c7dd9-7848-4b59-8672-d62181ee1933] 2017-08-09 10:13:52.182503 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/64225551212(a)107.6.13.77) Running State Change CS_NEW (Cur 3 Tot 9) 2017-08-09 10:13:52.182503 [DEBUG] sofia.c:9873 sofia/internal/ 64225551212(a)107.6.13.77 receiving invite from 107.6.13.77:5060 version: 1.6.19 -36-7a77e0b 64bit 2017-08-09 10:13:52.182503 [DEBUG] sofia.c:10044 IP 107.6.13.77 Rejected by acl "domains". Falling back to Digest auth. 2017-08-09 10:13:52.182503 [DEBUG] sofia.c:2334 detaching session af5c7dd9-7848-4b59-8672-d62181ee1933 2017-08-09 10:13:52.182503 [WARNING] sofia_reg.c:1792 SIP auth challenge (INVITE) on sofia profile 'internal' for [6468808998(a)newplymouth.poiema.org] from ip 107.6.13.77 2017-08-09 10:13:52.182503 [DEBUG] switch_core_state_machine.c:603 (sofia/internal/64225551212(a)107.6.13.77) State NEW 2017-08-09 10:14:01.182250 [WARNING] switch_core_state_machine.c:687 sofia/internal/64225551212(a)206.191.159.247 Abandoned 2017-08-09 10:14:01.182250 [NOTICE] switch_core_state_machine.c:690 Hangup sofia/internal/64225551212(a)206.191.159.247 [CS_NEW] [WRONG_CALL_STATE] 2017-08-09 10:14:01.182250 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/64225551212(a)206.191.159.247) Running State Change CS_HANGUP (Cur 3 Tot 9) 2017-08-09 10:14:01.182250 [DEBUG] switch_core_state_machine.c:850 (sofia/internal/64225551212(a)206.191.159.247) Callstate Change DOWN -> HANGUP 2017-08-09 10:14:01.182250 [DEBUG] switch_core_state_machine.c:852 (sofia/internal/64225551212(a)206.191.159.247) State HANGUP

4 7