Hi guys, I am currently using kamailio v5.2.5 and running it inside a
container. I already attempted to upgrade the kamailio to the latest
version however the problem persists.
This is the core dump that I got from using gdb:
Core was generated by `/usr/sbin/kamailio -f
> /etc/kazoo/kamailio/kamailio.cfg -m 512 -M 64 -x tlsf -w'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x000000000071c63c in select_cfg_var (res=0x7ffd57d49b10,
> s=0x7f2649395040, msg=0x7ffd57d4c340) at core/cfg/cfg_select.c:211
> 211 i = *(int *)p;
It seems that the problem is with this line:
modparam("dmq", "notification_address", "sip:DMQ_NOTIFY_ADDRESS")
>
Also, I only have this issue while running on an AWS instance, I have the
same setup on my local computer, however kamailio is able to start
correctly.
While kamailio is starting, I have this line
#!substdef "!DMQ_NOTIFY_ADDRESS!10.10.10.10:5090!g"
It seems that after DMQ is able to obtain the IP address, when it comes to
actually sending the message, it is interpreting the ip address of the
DMQ_NOTIFY_ADDRESS as an integer and then it gives out a segmentation fault
and the module stops.
Another interesting thing is that if the DMQ_NOTIFY_ADDRESS is the
MY_IP_ADDRESS variable instead of the 10.10.10.10, it seems to work
properly.
#!substdef "!DMQ_NOTIFY_ADDRESS!MY_IP_ADDRESS:5090!g"
It also doesn't seem related to the ip being in a variable, since I already
tried using a DNS record, and once again, it is able to obtain the IPs from
the DNS record, and the same issue applies.
Has anyone ever seen anything like this? I can't find any evidence of this
actually happening.
Thank you kindly for your time.
Best Regards,
José Santos
Hello,
We are thinking to use kamailio to fully support our current voip service.
I would like to know what is the best practice to use kamailio for several
thousands for clients that connect to us via TLS. We would like to have a
front "cluster" to be able to handle all these connections in balanced way.
All clients register to us and the do calls that we statefully forward to
the provider. On our test we have already created a single kamailio that
successfully accepts and handles registration, do the control and routing
to next provider with dispatcher and also do the accounting with cdrs. We
want to separate this controlling, routing, accounting and dispatching from
the front end and create a front "cluster" to offload the TLS and also be
redundant to as many connections by adding more kamailio's. What would be
the best kamailio module and topology as solution to this requirement?
Thank you in advance.
Kind Regards,
Angelo
Hi,
This is partially related to a previous thread -
https://lists.kamailio.org/pipermail/sr-users/2021-August/113128.html
We are using the TSILO module to suspend transactions whilst we wait for
mobile app users to register after receiving a push notification.
In the time we are waiting for the app to register, other UAs might reject
the call (DND, Busy, etc). To avoid this failure response being relayed to
the caller, we use t_drop_replies in the failure_route.
Eventually if all devices have rejected the call Kamailio times out and
sends a 408 Request Timeout. Is there any way we can catch this error, and
replace it with the last response we got from an actual UA?
t_is_expired() and t_branch_timeout() don't seem to apply as they're on the
*called* side. Is there another option to catch this overall timeout?
As a side note, failure_route is quite limited in the actions that can take
place there. Is it safe to access variables and update a htable?
Thanks
Matthew
Hello,
please keep the list in CC.
Let’s look into the two issues one by one:
1) I had to explicitly configure the parameter:
modparam("permissions", "mask_col", "mask")
Although the documentation suggests "mask" is the default - the JSON output from "kamctl address dump" did not output this value on K5.5. (On K5.3 it outputted properly)
Do you get an error if you do not specify the mask_col like this, or something else? From the source code the default should be “mask”.
When I run the "kamcmd permissions.subnetDump" on Kamailio 5.3, it returns everything as expected - including the 0.0.0.0/0<http://0.0.0.0/0> subnets.
However, when running the same commands on Kamailio 5.5, it only returns a small subset (of only 20) subnets/groups - and the selection does not appear to follow a logical selection criteria.
Additionally, it does not return any groups with a 0.0.0.0/0<http://0.0.0.0/0> subnet either.
It seems that the behaviour has changed regarding the “0” subnet, checkout the docs:
https://kamailio.org/docs/modules/devel/modules/permissions.html#permission…
It will convert them to 32/128 respectively. Can you see a 0.0.0./32 in your dump?
This was changed in commit f376c82a9f8 during an extension for text files. Maybe Daniel can comment here if this was done by purpose.
Otherwise, you can open an issue on our tracker about it.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: Tom Dworakowski <dworakowski.tom(a)gmail.com>
Sent: Tuesday, September 14, 2021 5:00 PM
To: Henning Westerholt <hw(a)skalatan.de>
Subject: Re: [SR-Users] Empty Subnets in Permissions Module
Hello Henning,
Thank you for looking into this for me.
I made two interesting discoveries this morning:
1) I had to explicitly configure the parameter:
modparam("permissions", "mask_col", "mask")
Although the documentation suggests "mask" is the default - the JSON output from "kamctl address dump" did not output this value on K5.5. (On K5.3 it outputted properly)
2)
When I run the "kamcmd permissions.subnetDump" on Kamailio 5.3, it returns everything as expected - including the 0.0.0.0/0<http://0.0.0.0/0> subnets.
However, when running the same commands on Kamailio 5.5, it only returns a small subset (of only 20) subnets/groups - and the selection does not appear to follow a logical selection criteria.
Additionally, it does not return any groups with a 0.0.0.0/0<http://0.0.0.0/0> subnet either.
From my logs - I have noted this:
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4353, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <3769, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4355, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4359, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <1955, 84.XX.XX.66, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.231, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.33, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.34, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 80.X.X.25, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 85.X.X.124, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 212.X.X.19, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4365, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4367, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4371, 0.0.0.0, 0> inserted into address hash table
Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <3991, 0.0.0.0, 0> inserted into address hash table
At the moment of querying group id 3983 (where there is only 0.0.0.0/0<http://0.0.0.0/0>), the function returns false:
DEBUG: permissions [address.c:671]: allow_source_address(): looking for <3983, [IPv4 in hex, reversed octet order], 62281>
However, None of those addresses appear in the "kamcmd permissions.subnetDump" output.
Moreover, if "my" group has the address 0.0.0.0/0<http://0.0.0.0/0> listed as an approved address - it will fail the test; but if I register 0.0.0.0/1<http://0.0.0.0/1> it will let me through (as my IP is < 128.0.0.0), kamcmd permissions.subnetDump will display this address.
My thoughts are that there might be another table that is not being populated - or there is a filter during the import that either drops 0.0.0.0/0<http://0.0.0.0/0> or filters it out completely?
Regards, Tom
On Tue, Sep 14, 2021 at 4:10 AM Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> wrote:
Hello Tom,
I’ve done a quick comparison of the main function and the called function. On a first view it looked identically, but I looked only a few levels deep.
Do you have maybe some means to reproduce this on a test system? Then it would be probably interesting to look to the DEBUG logging of this cases. Maybe you can compare if you spot some obvious differences from the logic.
Cheers,
Henning
From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Tom Dworakowski
Sent: Tuesday, September 14, 2021 4:10 AM
To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Subject: [SR-Users] Empty Subnets in Permissions Module
Greetings all!
I have two deployments of Kamailio: one running version 5.3 and one 5.5 with practically identical configurations, same (MySQL and REDIS) data sources.
We have customers that we assign an ACL "group" to, where the ID of this group resolves to records in the "address" table in our MySQL database - using the "grp" field.
On the box running Kamailio 5.5, we have noticed that if a group has ip_addr=0.0.0.0, mask=0, port=0 - and we try to run the allow_source_address() - it will return false, thus failing this phase of the authentication process.
However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer is assigned a group where the ACL is 0.0.0.0/0<http://0.0.0.0/0> - it will let him through.
Has something changed that I'm not aware of?
Any suggestions on how to resolve this?
My best, Tom
Hi,
What's the best way to capture the response from REGISTER requests automatically initiated by the uac_reg module?
I was looking to use event_route[uac:reply] {} but that is only triggered if the evroute flag is set on the initial call made to uac_req_send()
Is there a way to set this globally so that uac:reply is called for all requests initiated for peers in the uacreg table or a better way to capture the response?
Best,
Ross
Hello.
Kamailio 5.4.3 crashes at CentOS 7 with following error logs
Sep 13 13:15:11 /usr/local/sbin/kamailio[44592]: ERROR: <core>
[core/tcp_read.c:1500]: tcp_read_req(): ERROR: tcp_read_req: error
reading - c: 0x7f3b93734cf8 r: 0x7f3b93734e20 (-1)
Sep 13 13:15:12 /usr/local/sbin/kamailio[44594]: NOTICE: tls
[tls_domain.c:747]: sr_ssl_ctx_info_callback(): SSL handshake started
Sep 13 13:15:12 kernel: traps: kamailio[44594] general protection
ip:7f3ba8fb3c09 sp:7ffe2c3aff70 error:0 in
libssl.so.1.0.2k[7f3ba8f87000+67000]
Sep 13 13:15:12 /usr/local/sbin/kamailio[44597]: CRITICAL: <core>
[core/pass_fd.c:277]: receive_fd(): EOF on 38
Sep 13 13:15:12 /usr/local/sbin/kamailio[44597]: CRITICAL: <core>
[core/pass_fd.c:85]: recv_all(): 1st recv on 41 failed: Connection reset
by peer
Sep 13 13:15:12/usr/local/sbin/kamailio[44597]: CRITICAL: <core>
[core/tcp_main.c:3543]: handle_tcp_child(): read from tcp child 2 (pid
44594, no 19) Connection reset by peer [104]
Sep 13 13:15:12/usr/local/sbin/kamailio[44561]: ALERT: <core>
[main.c:777]: handle_sigs(): child process 44594 exited by a signal 11
Sep 13 13:15:12/usr/local/sbin/kamailio[44561]: ALERT: <core>
[main.c:780]: handle_sigs(): core was generated
Sep 13 13:15:12 /usr/local/sbin/kamailio[44561]: INFO: <core>
[main.c:802]: handle_sigs(): terminating due to SIGCHLD
I'm pretty sure these logs are mostly not usable, but maybe they will
point to some bugs.
To add, this happened just occasionally and I can't reproduce it at the
moment.
--
Regards,
Igor
Hello!
I have a simple config for routing requests with failover and blacklisting
on 408, 480 and 503 codes from servers.
This is a part of config:
# Wrapper for relaying requests
route[RELAY] {
# the base event routes
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
t_on_failure("MANAGE_FAILURE");
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Manage incoming replies
onreply_route[MANAGE_REPLY] {
xlog("L_NOTICE", "$rr ($rs) [$cs] ($ci) $si:$sp - $ua\n");
if ( t_check_status("(503)|(408)|(480)") ) {
xlog("L_WARN", "Server will be blacklisted: $si:$sp ($rs)\n");
}
}
# Manage failure routing cases
failure_route[MANAGE_FAILURE] {
if ( !t_check_status("(503)|(408)|(480)") ) {
exit;
}
ds_mark_dst("IP"); # blacklist
if (t_is_canceled()) exit;
if (!ds_next_domain()) {
send_reply("503", "Service Unavailable");
exit;
}
route(RELAY);
}
If there is a timeout or network error on the server side, it is
blacklisted. How can such cases be managed and how can they be logged?
I didn't find this on the module page:
https://www.kamailio.org/docs/modules/stable/modules/tm.html
Hi,
I am suspecitng presence module might be having a memory leak on a
production server used by an end user (not have access to it).
The output of command kamcmd mod.stats presence shm is
Module: presence
{
mem_copy_subs(148): 25720
mem_copy_subs_noc(214): 1672201904
mem_copy_subs_noc(251): 678406560
add_event(181): 88
shm_copy_event(57): 40
shm_copy_event(50): 312
add_event(156): 40
add_event(149): 456
new_shtable(66): 5767168
new_shtable(53): 262144
init_evlist(289): 16
Total: -1938302848
}
I am not sure what mem_copy_subs_noc is meaning. And final output is
negative, SHM is incfreasing all the time but not sure of the root cause
is this a reasonable hint that a memory leak is related to presence?
Greetings all!
I have two deployments of Kamailio: one running version 5.3 and one 5.5
with practically identical configurations, same (MySQL and REDIS) data
sources.
We have customers that we assign an ACL "group" to, where the ID of this
group resolves to records in the "address" table in our MySQL database -
using the "grp" field.
On the box running Kamailio 5.5, we have noticed that if a group has
ip_addr=0.0.0.0, mask=0, port=0 - and we try to run
the allow_source_address() - it will return false, thus failing this phase
of the authentication process.
However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer
is assigned a group where the ACL is 0.0.0.0/0 - it will let him through.
Has something changed that I'm not aware of?
Any suggestions on how to resolve this?
My best, Tom
Hi list! :-)
I'm a total newbie in Kamailio. Trying to study)
Sorry for lots of text, I'm simply don't know how to explain my questions
shorter :-D
I want to configure Kamailio as dispatcher, registrar and NAT traversal in
front of FS farm.
I've managed to set up Kamailio and Fswitches.
Now I need to handle "special cases" with confs, REFER transfers etc
Giovanni Maruzzelli once presented solution for this, with following logic:
-------------------------------------------------------------------------------------------------------
1) Kamailio by default distribute calls to various FSs - dispatch or
load_balance
2) Each time Kamailio sends a call to a FS, it writes down which
destination "number" is going to which FS
server and from which UserID
3) if another call comes for the same (or related) destination, or is
originated from the same UserID
then Kamailio sends the call to that same FS server, bypassing default
distribution algorithm
-------------------------------------------------------------------------------------------------------
Sounds good and helpful, but I'm stuck :-(
*Can someone please share an example or point me how and in what form
should I write down call info,and how can I control it (delete on BYE or
CANCEL)?*
Actually there are 2 questions
It seems to me that recordings can be made using HTABLEs but here's a
problem:
=====================================================================================
=============================================================================================
1) PROBLEM WITH WRITING TO HTABLE ON ATT TRANSFER
After the dispatcher sets $du - I write an htable entry
$sht(fsdest=>$fU:$rU) = $du;
Existing entries are removed on catching 'BYE' for normal clearing, and
with failure_route for all failures.
BYE logic is:
IN WITHINNDLG route
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
if (sht_match_name("fsdest", "eq", "$fU:$rU")) {
$sht(fsdest=>$fU:$rU) = $null; //BYE A->B
} else {
$sht(fsdest=>$rU:$fU) = $null; //BYE A<-B
}
}
handle_ruri_alias();
route(RELAY);
}
}
Another entry is setting up if blind transfer is made.
If INVITE is coming from one of FSs, and have 'Referred-By' field.
IN DIALOG route:
if (is_present_hf("Referred-By")) {
$sht(fsdest=>$fU:$rU) = $si;
}
For now it's working. Entries are written and deleted properly.
*Problem with Attended transfer.*
1) A --> B = htable entry A:B=xxxx
2) A --> C = htable entry A:C=xxxx(checked and set same FS addr because $fU
is present (If only it's worked as it should))
3) Att transfer (Refer $rU B, referred-by - A. Refer-To - C) B --> C = all
related entries deleted from table over BYE logic.
4) No entry B --> C (no INVITE was sent, bridged by REFER)
So, logic for check active calls in htable is broken now, because we don't
have entry B-->C
*How can I handle writing to htable in Attended transfer case?*
If another Invite will come FROM or TO B or C = there will be no htable
entry.
I'm not sure this is even a correct way. Surely missing something.
=============================================================================================
=============================================================================================
2) PROBLEM WITH IDENTIFYING TABLE ENTRIES
Anyway, the main problem is with identifying those htables to set proper
$du.
If INVITE is coming TO FSs I need to check if caller ID ($fU) or dest ($rU)
is present in htables.
Form I need to write to hash must be like $fU:$rU
Entry must be unique or it will be:
1) rewrited anytime a new invite is going to the same dest.
2) deleted anytime BYE or failure will come
eg:
If $sht(fsdest=>$rU) = $dd
1) 1000 --> 3200 = htable entry 3200 = xxxx
2) 1005 --> 3200 = htable entry rewriten to the same 3200 = xxxx
When 1000 or 1005 leaving conf, it sends BYE and removes entry.
So, next call to 3200 may be sent to the wrong FS.
Ok, we have a unique entry ($fU:$rU). Checking for active destination:
if (sht_match_name("fsdest", "re", ":$rU")) {}
If there's an htable with $rU in key - we got a match.
Now we need to assign a value from htable to $du.
But, I don't know how to get the name of this entry.
There's always different $fU: (or $rU if we check for the same caller ID
($fU)).
eg:
1000 --> 3200 = htbale 1000 --> 3200
New call 1005 --> 3200
Check sht_match name ":3200" - got match
We need to set: $du = $sht(fsdest=>$fU:$rU)
But it will be $sht(fsdest=>1005:3200) and we don't have this entry.
We need (fsdest=>1003:3200) But i don't see any way to get needed $fU.
*Is there any way to search or identify these tables?*
=============================================================================================
=============================================================================================
Can someone help me with this, please? :-)
Or maybe there is a better way to do this?
*My kamailio.cfg routing block in pastebin, if
neededhttps://pastebin.com/1PZ0QSDW <https://pastebin.com/1PZ0QSDW>*
Thank you!
Regards, Tim