September 2021 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Outbound event_socket memory usage
by Adrien Martin 30 Sep '21

30 Sep '21

Hello, I'm currently benchmarking an ESL program that use both outbound and inbound mode and notice a quite large memory usage for the FreeSWITCH process compared to a dialplan that has similar actions (8 set (half multiset), 1 sched_hangup, 1 bridge). The FreeSWITCH process use about 2 Mo per call and about 180 Ko without ESL. This does not look like a leak, the memory usage is stable and proportional to the current calls, Valgrind does not show anything special either. What was tested: - Pure dialplan while running only the inbound ESL subscribing to some events (CHANNEL_HANGUP, CHANNEL_HANGUP_COMPLETE, CHANNEL_EXECUTE_COMPLETE, SESSION_HEARTBEAT) for all channels, inbound ESL does not increase memory consumption, - Outbound ESL that just close the connection at the beginning of the dialplan, same memory usage as a complete ESL program, - Outbound ESL linger set/not set, no change, - Outbound ESL parameters async/full present or not, no change, - Versions 1.10.5~release~17 and 1.10.6~release~18, no change. Does this kind of resource penalty is to be expected? What could cause these differences? For those using outbound ESL, how much memory does your FreeSWITCH use per call?

2 6

SRTP negotiation on reinvite
by Alberto 30 Sep '21

30 Sep '21

Hi, I have 2 end users, connected to freeswitch and configured with optional SRTP. Both users can make and receive encrypted calls, but when one of them sends a reinvite to make a transfer, freeswitch replies with a 488. I've spotted these lines in the logs: 2021-09-15 14:37:45.880223 [WARNING] switch_core_media.c:4331 Declining invite with only SAVP because secure media is administratively disabled 2021-09-15 14:37:45.880223 [DEBUG] sofia.c:8007 Reinvite resulted in codec negotiation failure. What seems strange to me is that users are configured to use PCMA only, and are both able to use SRTP, so why would the codec negotiation fail? How do I enable optional SRTP for re-invites? Thanks

2 1

bridge to internal phone and cell through a gateway
by Sean Devoy 29 Sep '21

29 Sep '21

Hi All, I have searched for an answer and can't find anything to explain my problem. Underlying request/problem: The user wants to ring their desk and after 5 second leg delay (not shown) add their cell phone, then voicemail on the FS server. I did a test with this bridge and it works fine: <action application="bridge" data="{sip_from_uri=${outbound_caller_id_number}@64.136.173.30,sip_from_user=${outbound_caller_id_number},sip_from_host=64.136.173.30}sofia/gateway/voip-innovations-outbound/141nnnnnn99"/<mailto:%7bsip_from_uri=$%7boutbound_caller_id_number%7d@64.136.173.30,sip_from_user=$%7boutbound_caller_id_number%7d,sip_from_host=64.136.173.30%7dsofia/gateway/voip-innovations-outbound/141nnnnnn99"/>> And this one works: <action application="bridge" data={presence_id=220@fs.bizfocused.com}${sofia_contact(220@fs2.bizfocused.com)}<mailto:%7bpresence_id=220@fs.bizfocused.com%7d$%7bsofia_contact(220@fs2.bizfocused.com)%7d,> /> But I can't do both to work. Is it possible to bridge to internal and external phones? Thanks, Sean

4 10

how to queue multiple audio file to play in conference(for all members and for specific member )
by kunal kumar 28 Sep '21

28 Sep '21

Hi All, I am trying to play audio files into the conference for the following cases using freeswitch api. 1) play to all member in conference command = "conference <confname> play <file-path> async" 2) play to specific member command = "conference <confname> play <file-path> <member_id> nomux" Current Behaviour :- 1) if i play an audio file to all members in the conference it is getting played. Meanwhile I tried to play a new audio file to the specific member it was getting played without muxing. mean previous audio got stopped and then new audio file got played and after that when new audio file stopped and if previous audio file is still streaming then it will also play to this member. 2) If i play an audio file to a conference member and then if i try to play a new audio file to all members it is getting played to all members except the member who is already streaming another file. Expected Behaviour:- I don't want to miss any audio files. So is there any way to queue the audio files so that it would not miss any important notification audio in above cases. Any suggestion would be highly appreciated. Thanks!

1 0

High CPU usage and Slow BLFs with only 8 channels?
by Jerry Kendall 27 Sep '21

27 Sep '21

Hello all, I'm having some interesting problems with our Freeswitch system. I have found Tim's posting athttps://lists.freeswitch.org/pipermail/freeswitch-users/2012-February/080… It seems very similar but does not help me... Wish it did. Hardware: Dell R610, dual 6 core Xeon X5680 @ 3.3GHz with 10 Gig of RAM Network: Dual 10Gig Fiber to 40Gig fabric Databases: also Dell R610 with dual 10Gig and Mariadb 10.5.9 NO ISSUES - VERY FAST - ULTRA LOW LATENCY We have 2 different FS systems 1) One acting as an SBC of sorts - process SIP/RTP 2) One acting as a PBX - process SIP/RTP Providers are connected to SBC (public - context) PBX (sbc - context) connects to SBC (internal - context) End Points connect to PBX (device - context) picographically: ITSP --- SBC --- PBX --- EndPoints The machine running FreeSWITCH as an SBC is fine - 50 calls (100 sessions) and near zero load average - CPU idle 98% - ALL GREAT About 100 devices registered, all NAT'd, approx 50 subscription via BLF buttons Registration period is maxed to 60 minutes and most devices use the default of 60 minutes Typically, We see only a few CPS, maybe 5 if it's really busy All our trunks are SIP. Only using PCMU/8000 codec. We use MARIADB in the core - as well as for sofia, voicemail, and anything else that can use it. Config, Directory and dialplan are done using CURL and handled via apache2 on the same server over 127.0.0.1. I keep hearing about FS systems handling thousands of users on one box. I'm nowhere near that and it seems to be maxed out. Freeswitch on both systems is Version 1.10.6-release git 1ff9d0a 2021-03-25 13:16:09Z 64bit So... The problem The machine running FreeSWITCH as a PBX seems to be struggling during periods of any usage - even only 1 call (2 channels). Just a moment ago, load average is 4.5 - CPU Idle is 65% - 8 sessions active - 315 sessions since startup - 45 threads - 8 hours running The audio seems fine - no complaints reported.. There is a very noticable chocking on the BLFs though... Every few minutes, the BLFs just freeze - yes - freeze... Then they catch up for example, for testing this, I have programmed a BLF on one phone. I run manually "luarun /etc/freeswitch/scripts/on.lua *8896(a)domain.com" - the lights turns red then after a few seconds, I run manually "luarun /etc/freeswitch/scripts/off.lua *8896(a)domain.com" - the light turns green Sometimes, when I run these manually, the lights take 30 seconds to change - sometimes - usually, under a second. They change the state of the subscribe target Here is the LUA script to turn the light ON(RED) ############################################################## #!/lua local random = math.random math.randomseed(os.time()) local function uuid() local template ='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx' return string.gsub(template, '[xy]', function (c) local v = (c == 'x') and random(0, 0xf) or random(8, 0xb) return string.format('%x', v) end) end local function SendCallDirectorBLFevent() Uuid = uuid() local event = freeswitch.Event("PRESENCE_IN") event:addHeader("proto", "sip") event:addHeader("event_type", "presence") event:addHeader("alt_event_type", "dialog") event:addHeader("Presence-Call-Direction", "outbound") event:addHeader("from", argv[1]) event:addHeader("login", argv[1]) event:addHeader("unique-id", Uuid ) event:addHeader("answer-state", "confirmed") event:fire(); end SendCallDirectorBLFevent() ############################################################## The issue is the choking on the BLFs and the HIGH load avg for such small amounts of calls on the PBX - the SBC seems fine. SO..... I have been trying to resolve this for about a month - looking everywhere I could. I have monitored the network stats, disk IO stats, cpu usage, processes, etc.... I don't see anything different between the SBC and PBX stats... I would like the BLFs to show the correct state a little faster (more like half a second, not 10-60 seconds after the event) and would I like to know how to fix the high CPU load on the PBX. I have confirmed 2 things today: 1) it's not using mod_mariadb as I put back the ODBC and not help 2) this is seems most noticeable when new calls come in. The BLFs pause to 5-8 seconds and continue - there is a noticeable spike in load avg when calls keep coming in for 5 minutes... Any information that would be helpful? Thanks, Jerry

3 4

High CPU usage and Slow BLFs with only 8 channels?
by Jerry Kendall 27 Sep '21

27 Sep '21

Hello all, I'm having some interesting problems with our Freeswitch system. I have found Tim's posting athttps://lists.freeswitch.org/pipermail/freeswitch-users/2012-February/080… It seems very similar but does not help me... Wish it did. Hardware: Dell R610, dual 6 core Xeon X5680 @ 3.3GHz with 10 Gig of RAM Network: Dual 10Gig Fiber to 40Gig fabric Databases: also Dell R610 with dual 10Gig and Mariadb 10.5.9 NO ISSUES - VERY FAST - ULTRA LOW LATENCY We have 2 different FS systems 1) One acting as an SBC of sorts - process SIP/RTP 2) One acting as a PBX - process SIP/RTP Providers are connected to SBC (public - context) PBX (sbc - context) connects to SBC (internal - context) End Points connect to PBX (device - context) picographically: ITSP --- SBC --- PBX --- EndPoints The machine running FreeSWITCH as an SBC is fine - 50 calls (100 sessions) and near zero load average - CPU idle 98% - ALL GREAT About 100 devices registered, all NAT'd, approx 50 subscription via BLF buttons Registration period is maxed to 60 minutes and most devices use the default of 60 minutes Typically, We see only a few CPS, maybe 5 if it's really busy All our trunks are SIP. Only using PCMU/8000 codec. We use MARIADB in the core - as well as for sofia, voicemail, and anything else that can use it. Config, Directory and dialplan are done using CURL and handled via apache2 on the same server over 127.0.0.1. I keep hearing about FS systems handling thousands of users on one box. I'm nowhere near that and it seems to be maxed out. Freeswitch on both systems is Version 1.10.6-release git 1ff9d0a 2021-03-25 13:16:09Z 64bit So... The problem The machine running FreeSWITCH as a PBX seems to be struggling during periods of any usage - even only 1 call (2 channels). Just a moment ago, load average is 4.5 - CPU Idle is 65% - 8 sessions active - 315 sessions since startup - 45 threads - 8 hours running The audio seems fine - no complaints reported.. There is a very noticable chocking on the BLFs though... Every few minutes, the BLFs just freeze - yes - freeze... Then they catch up for example, for testing this, I have programmed a BLF on one phone. I run manually "luarun /etc/freeswitch/scripts/on.lua *8896(a)domain.com" - the lights turns red then after a few seconds, I run manually "luarun /etc/freeswitch/scripts/off.lua *8896(a)domain.com" - the light turns green Sometimes, when I run these manually, the lights take 30 seconds to change - sometimes - usually, under a second. They change the state of the subscribe target Here is the LUA script to turn the light ON(RED) ############################################################## #!/lua local random = math.random math.randomseed(os.time()) local function uuid() local template ='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx' return string.gsub(template, '[xy]', function (c) local v = (c == 'x') and random(0, 0xf) or random(8, 0xb) return string.format('%x', v) end) end local function SendCallDirectorBLFevent() Uuid = uuid() local event = freeswitch.Event("PRESENCE_IN") event:addHeader("proto", "sip") event:addHeader("event_type", "presence") event:addHeader("alt_event_type", "dialog") event:addHeader("Presence-Call-Direction", "outbound") event:addHeader("from", argv[1]) event:addHeader("login", argv[1]) event:addHeader("unique-id", Uuid ) event:addHeader("answer-state", "confirmed") event:fire(); end SendCallDirectorBLFevent() ############################################################## The issue is the choking on the BLFs and the HIGH load avg for such small amounts of calls on the PBX - the SBC seems fine. SO..... I have been trying to resolve this for about a month - looking everywhere I could. I have monitored the network stats, disk IO stats, cpu usage, processes, etc.... I don't see anything different between the SBC and PBX stats... I would like the BLFs to show the correct state a little faster (more like half a second, not 10-60 seconds after the event) and would I like to know how to fix the high CPU load on the PBX. I have confirmed 2 things today: 1) it's not using mod_mariadb as I put back the ODBC and not help 2) this is seems most noticeable when new calls come in. The BLFs pause to 5-8 seconds and continue - there is a noticeable spike in load avg when calls keep coming in for 5 minutes... Any information that would be helpful? Thanks, Jerry

3 3

Confused about codecs?
by Allan Kristensen 27 Sep '21

27 Sep '21

Hello, We are getting these weird log messages from FS and I'm a little uncertain what they are (there are thousands being logged), can someone clarify? September 23rd 2021, 10:35:40.849 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.844181 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0). September 23rd 2021, 10:35:40.749 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.744202 [WARNING] switch_core_media.c:3305 Changing current codec to PCMA (payload type 8). September 23rd 2021, 10:35:40.669 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.664168 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0). September 23rd 2021, 10:35:40.569 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.564190 [WARNING] switch_core_media.c:3305 Changing current codec to PCMA (payload type 8). September 23rd 2021, 10:35:40.489 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.484194 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0). September 23rd 2021, 10:35:40.389 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.384180 [WARNING] switch_core_media.c:3305 Changing current codec to PCMA (payload type 8). September 23rd 2021, 10:35:40.309 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.304190 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0). I'm thinking it's because we are receiving RTP packets with both types from remote? It only happens for a specific provider, so I'm thinking it's them, I just need to tell them the problem is. During codec negotiations we offered PCMA + PCMU and the SDP response from them also had PCMA + PCMU, that means we can choose what we want right? not that they should send us both? ;-) Thank you... Allan

3 3

How can verto tell FS to end the connection?
by David P 25 Sep '21

25 Sep '21

I had always assumed that verto's hangup method sent a msg to FS that its leg should be terminated, but when I looked in the verto source today I found that this method only changes local state. Should verto's unsubscribe method be used for this, or is there something like verto.sendMethod("verto.bye") ?

1 0

Call migration from box A to box B behind a proxy.
by David Villasmil 24 Sep '21

24 Sep '21

Hello all, Call migration (or recovery) is usually done with floating IPs, but i understand it is possible without any floating IPs. Can Sofia recover do that? in theory it already has all the info it needs to move the call from another box (i.e. the recovery table), it would just need to not try to bind the ip from the A-box, and simply send out a reINVITE to the client (via the proxt) is this possible? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

1 0

EOL Community FreeSWITCH Debian 8
by Len Graham 24 Sep '21

24 Sep '21

Hello, This is a notice about FreeSWITCH (Community) Debian 8 Jessie Packages. As you know, Debian 8 is well past EOL(June 30, 2020 <https://www.debian.org/News/2020/20200709>). FreeSWITCH (Community) Debian 8 "Jessie" packages will be removed from our public repo to promote Debian 11 "Bullseye". Removal date: Repo packages for FreeSWITCH (Community) Debian 8 Jessie packages will be September 29th 2021. Thank you for choosing FreeSWITCH! Sincerely, FreeSWITCH

2 1