Hi,
We are using kamailio 5.3 latest version with the topos module. We have added Homer 7 latest version to consolidate traces from all kamailios and we have enabled siptrace module on kamailio to send data to homer. What we have seen up today is that traces on homer have sip headers before topos changes. So if I look at the same call on sngrep on the kamailio machine, I see the correct topos changed headers. If I check the same call on Homer I see headers without topos changes. Also we get duplicate headers on ACKs on homer.
I was wondering what we have done wrong in the config and we have these results on homer. Any help will be much appreciated!
Our config has: ===========- #!substdef "!MY_HOMER_CAPTURE!sip:MY_HOMER_IP_ADDR:MY_HOMER_PORT!g" #!substdef "!MY_LOCAL_SENDSOCK!sip:MY_KAMAILIO_IP:MY_LOCAL_SEND_PORT!g"
loadmodule "topos.so" loadmodule "siptrace.so"
modparam("siptrace", "force_send_sock", "MY_LOCAL_SENDSOCK") modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_mode", 0) modparam("siptrace", "hep_capture_id", NODE_ID)
modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3)
request_route { sip_trace_mode("t"); ........ }
onsend_route { if (is_method("ACK")) { sip_trace(); } } ==============
Thank you!
Kind regards, Angelo
Hello,
try loading siptrace module before topos.
Cheers, Daniel
On 23.09.21 19:57, Angelo Sipper wrote:
Hi,
We are using kamailio 5.3 latest version with the topos module. We have added Homer 7 latest version to consolidate traces from all kamailios and we have enabled siptrace module on kamailio to send data to homer. What we have seen up today is that traces on homer have sip headers before topos changes. So if I look at the same call on sngrep on the kamailio machine, I see the correct topos changed headers. If I check the same call on Homer I see headers without topos changes. Also we get duplicate headers on ACKs on homer.
I was wondering what we have done wrong in the config and we have these results on homer. Any help will be much appreciated!
Our config has:
#!substdef "!MY_HOMER_CAPTURE!sip:MY_HOMER_IP_ADDR:MY_HOMER_PORT!g" #!substdef "!MY_LOCAL_SENDSOCK!sip:MY_KAMAILIO_IP:MY_LOCAL_SEND_PORT!g"
loadmodule "topos.so" loadmodule "siptrace.so"
modparam("siptrace", "force_send_sock", "MY_LOCAL_SENDSOCK") modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_mode", 0) modparam("siptrace", "hep_capture_id", NODE_ID)
modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3)
request_route { sip_trace_mode("t"); ........ }
onsend_route { if (is_method("ACK")) { sip_trace(); } } ==============
Thank you!
Kind regards, Angelo
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello all,
I'm having some interesting problems with our Freeswitch system.
I have found Tim's posting at https://lists.freeswitch.org/pipermail/freeswitch-users/2012-February/080422...
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@domain.com" - the lights turns red then after a few seconds, I run manually "luarun /etc/freeswitch/scripts/off.lua *8896@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.
Any information that would be helpful?
Thanks, Jerry
Hello,
was this message addressed by mistake to Kamailio users list instead of the one for FreeSwitch?
Cheers, Daniel
On 24.09.21 17:58, Jerry Kendall wrote:
Hello all,
I'm having some interesting problems with our Freeswitch system.
I have found Tim's posting at https://lists.freeswitch.org/pipermail/freeswitch-users/2012-February/080422...
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
- One acting as an SBC of sorts - process SIP/RTP
- 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@domain.com" - the lights turns red then after a few seconds, I run manually "luarun /etc/freeswitch/scripts/off.lua *8896@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.
Any information that would be helpful?
Thanks, Jerry
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi Daniel,
I did this change but unfortunately no change. Anything more I could check?
Kind regards, Angelo
Στις Παρ, 24 Σεπ 2021 στις 9:11 π.μ., ο/η Daniel-Constantin Mierla < miconda@gmail.com> έγραψε:
Hello,
try loading siptrace module before topos.
Cheers, Daniel On 23.09.21 19:57, Angelo Sipper wrote:
Hi,
We are using kamailio 5.3 latest version with the topos module. We have added Homer 7 latest version to consolidate traces from all kamailios and we have enabled siptrace module on kamailio to send data to homer. What we have seen up today is that traces on homer have sip headers before topos changes. So if I look at the same call on sngrep on the kamailio machine, I see the correct topos changed headers. If I check the same call on Homer I see headers without topos changes. Also we get duplicate headers on ACKs on homer.
I was wondering what we have done wrong in the config and we have these results on homer. Any help will be much appreciated!
Our config has:
#!substdef "!MY_HOMER_CAPTURE!sip:MY_HOMER_IP_ADDR:MY_HOMER_PORT!g" #!substdef "!MY_LOCAL_SENDSOCK!sip:MY_KAMAILIO_IP:MY_LOCAL_SEND_PORT!g"
loadmodule "topos.so" loadmodule "siptrace.so"
modparam("siptrace", "force_send_sock", "MY_LOCAL_SENDSOCK") modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_mode", 0) modparam("siptrace", "hep_capture_id", NODE_ID)
modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3)
request_route { sip_trace_mode("t"); ........ }
onsend_route { if (is_method("ACK")) { sip_trace(); } } ==============
Thank you!
Kind regards, Angelo
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone)
Hello,
ahh, just noticed you are tracing from the config at transaction layer, meaning that traffic is sent during config processing when the content is without topos changes.
To get the traffic as seen on the network, set modparam trace_mode=1 and remove the use of sip_trace()/sip_trace_mode() in routing blocks. You can still filter what is sent out using event_route blocks, if you do not want all the traffic to be mirrored.
Cheers, Daniel
On 24.09.21 18:19, Angelo Sipper wrote:
Hi Daniel,
I did this change but unfortunately no change. Anything more I could check?
Kind regards, Angelo
Στις Παρ, 24 Σεπ 2021 στις 9:11 π.μ., ο/η Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> έγραψε:
Hello, try loading siptrace module before topos. Cheers, Daniel On 23.09.21 19:57, Angelo Sipper wrote:
Hi, We are using kamailio 5.3 latest version with the topos module. We have added Homer 7 latest version to consolidate traces from all kamailios and we have enabled siptrace module on kamailio to send data to homer. What we have seen up today is that traces on homer have sip headers before topos changes. So if I look at the same call on sngrep on the kamailio machine, I see the correct topos changed headers. If I check the same call on Homer I see headers without topos changes. Also we get duplicate headers on ACKs on homer. I was wondering what we have done wrong in the config and we have these results on homer. Any help will be much appreciated! Our config has: ===========- #!substdef "!MY_HOMER_CAPTURE!sip:MY_HOMER_IP_ADDR:MY_HOMER_PORT!g" #!substdef "!MY_LOCAL_SENDSOCK!sip:MY_KAMAILIO_IP:MY_LOCAL_SEND_PORT!g" loadmodule "topos.so" loadmodule "siptrace.so" modparam("siptrace", "force_send_sock", "MY_LOCAL_SENDSOCK") modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_mode", 0) modparam("siptrace", "hep_capture_id", NODE_ID) modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3) request_route { sip_trace_mode("t"); ........ } onsend_route { if (is_method("ACK")) { sip_trace(); } } ============== Thank you! Kind regards, Angelo __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
-- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>