sr-users October 2023

sr-users@lists.kamailio.org

47 participants
44 discussions

Inquiry Regarding Kamailio Behavior and Drop Requests
by satyaprakash ch 26 Oct '23

26 Oct '23

Hi, We possess a code within Kamailio, which specifically handles malformed SIP responses. Below is the code snippet: *reply_routeCopy code if(!sanity_check("17604", "6")) { xlog("Malformed SIP response from $si:$sp\n"); drop;* Additionally, we have Kamailio drop request statistics as follows: Command: *kamctl stats | grep core:drop_requests* Output of the command: *core:drop_requests = 5* My queries are: 1. Is the aforementioned "reply_route" related to the drop requests we are experiencing? 2. If it is not related, what could be the cause of the drop requests?

3 8

Information about Kamailio operating as an SBC
by Alvaro Escobar 24 Oct '23

24 Oct '23

Hello, I am looking information about Kamailio operating as an SBC. I saw this video of Kamailio World 2021: Kamailio As An SBC For Network Segregation: https://www.youtube.com/watch?v=UW6l3R4OnsY&t=1381s But where I can find more detailed technical information ? Regards

3 3

How to filter out xhttp request in event_route[siptrace:msg]
by Benoit Panizzon 24 Oct '23

24 Oct '23

Hi Further trying to eliminate every possible cause of UDP drops... We use Homer as HEP server in conjunction with the siptrace module. So to prevent DQM traffic to be sent to Homer I added: event_route[siptrace:msg] { if(is_method("KDMQ")) { drop(); } } And had a closer look to the traffic sent to homer. I noticed, also xhttp:requests, as far as I see the replies, not the requests, get mirrored to homer. xhttp is not a sip method I could match I guess. The event_route[siptrace:msg] docs state only method can be filtered. So I can not filter requests on the separate http port I listen on for xhttp json-rpc requests. How can I prevent xhttp traffic to be mirrored to homer by the siptrace module? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

4 5

STIR/SHAKEN with Kamailio
by Olle E. Johansson 23 Oct '23

23 Oct '23

Hello Kamailians! As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, I’m curious on how you’ve implemented it with Kamailio. I asked on our Matrix chat and got two responses that seems to not use the Kamailio STIR/SHAKEN support but rather a 3rd party service that they’ve integrated using restful APIs. Please help me and share how you’re implementing STIR/SHAKEN with Kamailio. I’m not shaken, nor stirred. yet. Regards, /O

7 9

How to configure ndb_redis sentinel
by mayamatakeshi 21 Oct '23

21 Oct '23

Hi, regarding ndb_redis, I have 3 sentinels like this: "192.168.88.155:26379" "192.168.88.156:26379" "192.168.88.157:26379" So was thinking that I would configure ndb_redis this way: modparam("ndb_redis", "server", "name=srvZ;sentinel_group=myredis;sentinel_master=1;sentinel= 192.168.88.155:26379") modparam("ndb_redis", "server", "name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel= 192.168.88.156:26379") modparam("ndb_redis", "server", "name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel= 192.168.88.157:26379") But the samples in the documentation show an extra sentinel key in the config lines: # sentinel (for a redis slave) modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=0;sentinel=1.2.3.4:26379 ;sentinel=1.2.3.5:26379") # sentinel (for a redis master) modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379 ;sentinel=1.2.3.5:26379") So I am not sure if my configuration is correct. Can someone clarify?

1 0

lookup() and database
by Jawaid Bazyar 20 Oct '23

20 Oct '23

Hi, I have an application as follows: Multiple Kamailio Nodes Shared Postgres database Auth information will be stored in DB and accessed with Authdb. Here is the behavior I seek: I would like all the Kamailo nodes to cooperate in updating the database, each updating data as appropriate: When a registration comes in to any Node, and it authenticated, create or update a database record in location table. When a registration expires on that Node, delete database record in location table. When INVITE comes in on any Node, ignore local cache and always lookup() record from database. #1 and #2 are used so that a third SIP system can query the database and look up the Node a NAT’d subscriber is ‘connected’ to. #3 is to let NON-NAT’d subscribers be contacted from any Node. Now I have something close to this now – using following settings: modparam("usrloc", "db_mode", 1) # immediately write registrations to the database. modparam("usrloc", "db_timer_clean", 0) # do not expire DB records separately modparam("usrloc", "db_check_update", 1) This takes care of #1 and #2 above. However, #3 seems to still be relying purely on local cache and does not hit the database. Is there a way to do #3? I can set db_mode to 3 but that would seem to have other effects besides merely making lookup() read from database. Thanks in advance, Jawaid

3 8

TOPOS + Forcing the send socket
by Marrold 19 Oct '23

19 Oct '23

Hi all, I am using Kamailio (5.7.2, Debian 11, Python KEMI) in a mutli-homed environment with the topos module to hide the topology. I have noticed that when I use `set_send_socket` or `$fsn` to force the socket it's sent from, it breaks topos and the ACK is not proxied to the other leg of the call. I am calling record_route() *after* forcing the socket. If I disable TOPOS the ACK works as expected, and the signalling looks correct. Or, with TOPOS enabled, if I comment out set_send_socket TOPOS works as expected. If I disable enable_double_rr, TOPOS works as expected and the ACK is forwarded, but without the double RR subsequent in-dialog requests use the wrong socket. One other observation, when I change the send socket I also see these warnings in the logs: 24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1348]: dlg_onroute(): tight matching failed for ACK with callid='!!:MByLMlFAM.NfWxFAM.cAMxyfWjyLz.yAO.y6MxF1MxVZWG4ZMy**'/55, ftag='2023101714101800015'/19, ttag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 and direction=0 24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1355]: dlg_onroute(): dialog identification elements are callid='2023101714101800015@2900-0601-0284-80'/37, caller tag='2023101714101800015'/19, callee tag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 Is anyone using TOPOS + forcing the socket, or could someone advise where I am going wrong? Thanks in advance Matthew

3 8

Kamailio SIP proxy role
by Ali Taher 18 Oct '23

18 Oct '23

Hello, I'm using Kamailio as SIP proxy between Session Manager and SBC So here is the scenario : Session Manager sends a call (Invite) to Kamailio, kamailio needs to relay it to SBC after doing some modification. (-----Session Manager-----) ----------- > (----Kamailio----) ----------- > (-----SBC-----) My routing logic is similar to the below: route{ if ((method==OPTIONS) && (! uri=~"sip:.*[@]+.*")) { options_reply(); } if (is_method("INVITE")) { sql_query("cb", "select number from pool1 order by random() limit 1", "ra"); $var(rand)=$dbr(ra=>[0,0]); uac_replace_from($var(rand),"sip:$var(rand)@192.168.1.1"); xlog("L_INFO","Random: $var(rand)"); $var(ip) = $(ct{s.select,1,(a)}{s.select,0,;}{s.replace,>,}); remove_hf("Contact"); insert_hf("Contact: $var(rand) <sip:$var(rand)@$var(ip)>\r\n"); remove_hf("P-Asserted-Identity"); remove_hf("Route"); insert_hf("Route: <sip: 192.168.1.10>\r\n","Route"); record_route(); t_relay(); $td = "192.168.1.10"; $rd = "192.168.1.10"; t_relay(); } } Where: 192.168.1.1 is Kamailio IP 192.168.1.10 is SBC IP My question here is that Kamailio handle all in dialog messages between Session Manager and SBC? For example, after forwarding the invite packet to SBC, SBC sends 183 Session Progress to Kamailio, which in its turn relay it to the session manager, knowing that this is not mentioned in my routing logic, so how Kamailio knew that it must relay it to session manager in this case? Also I need to add to the 183 Session Progress sent to session manager by Kamailio record route and Via headers , how to do it ? Regards,

1 0

Dispatcher HA:won't route headers be wrong if in-dialog request is sent to backup?
by Richard Chan 18 Oct '23

18 Oct '23

Hi sr-users, In the case of dispatcher-based HA such as the Wazo example ( https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq) won't the Route: headers be wrong for in-dialog requests if the request is sent to the backup proxy? front proxy -> proxy A, B, C, D,... -> network Suppose the INVITE goes through proxy A, then proxy A goes down. Based on the HA logic, an in-dialog request will go to a backup, say, proxy B. However, won't the Route headers be wrong (since they are placed by A) in the original transaction? How do you handle Route:, Record-Route: headers at the HA tier? 1. In the front proxy & HA tier don't use route headers at all ?? 2. Manually check and remove route headers (i.e proxy B treats route headers for proxy A as "myself") ?? I am curious as to what is your practice. Regards Shih-Ping

1 0

Restarts Kamailio after general protection fault
by Daian Conrad 17 Oct '23

17 Oct '23

Hi all, I have started using kamailio as a proxy register for asterisk's and works fine, but in some moment kamailio show WARNINGs, ALERTS and CRITICAL logs and restart. I don't no how debug correctly, but the crash show this log lines *Oct 16 21:34:26 proxy /usr/sbin/kamailio[2148]: CRITICAL: <core> [core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f14a27a5ab8 (address 0x7f14a27a5af0) beginning overwritten (7f14a27a8e58)! Memory allocator was called from uac: uac_send.c:860. Fragment marked by UH��AWAVAUATSH��:139726602009368. Exec from core/mem/q_malloc.c:511.* ------------------------------------------------------------- *Oct 16 21:39:46 proxy /usr/sbin/kamailio[2556]: CRITICAL: <core> [core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm. 0x7ff7ad456330 (address 0x7ff7ad456368) beginning overwritten (0)! Memory allocator was called from uac: uac_send.c:860. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:511.Oct 16 21:39:46 proxy /usr/sbin/kamailio[2578]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 19Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]: ALERT: <core> [main.c:774]: handle_sigs(): child process 2556 exited by a signal 6Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]: ALERT: <core> [main.c:777]: handle_sigs(): core was not generatedOct 16 21:39:46 proxy systemd[1]: kamailio.service: Main process exited, code=exited, status=1/FAILUREOct 16 21:39:46 proxy systemd[1]: kamailio.service: Failed with result 'exit-code'.Oct 16 21:39:46 proxy systemd[1]: kamailio.service: Service RestartSec=100ms expired, scheduling restart.Oct 16 21:39:46 proxy systemd[1]: kamailio.service: Scheduled restart job, restart counter is at 9.Oct 16 21:39:46 proxy systemd[1]: Stopped Kamailio - the Open Source SIP Server.* any advice is apreciated -- ================ **Daian Conrad** E-mail: daian.conrad(a)gmail.com OpenS Team (DaCoD) Linux user: #248912

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2023