sr-users November 2021

sr-users@lists.kamailio.org

48 participants
53 discussions

Problem with 302
by nathan Kirk 24 Nov '21

24 Nov '21

Hello, First time poster and I am stuck. I am using K as a mid registar to several AST boxes. The problem I am having is if AST or the END USER DEVICE sends a 302 for some reason I am getting a 500 THEN the 302 to the END USER DEVICE or AST depending which direction the call flow is. Example END USER DEVICE -> CALLS 700 -> K -> AST AST -> 302 -> K -> 500 & 302 -> END USER DEVICE What I would like to happen is when K receives the 302 it deals with it directly and it is not handed off to either end. I am using a configuration I found online with some base modifications to dip into the database real time to get the AST box IPS Any direction would be helpful. Thank you, Nathan

1 0

LCR Module not loading all rules from DB
by M Arqum CH 24 Nov '21

24 Nov '21

Hi all, lcr.reload command not loading all rules from rules table. More than 73K rules row in table, lcr.dump_rules only print 4096 rules. lcr module config : modparam("lcr", "db_url", "cluster://k1") modparam("lcr", "lcr_gw_table","lcr_gateways") modparam("lcr", "lcr_rule_table", "lcr_rules") modparam("lcr", "lcr_rule_target_table", "lcr_rule_targets") modparam("lcr", "gw_name_column", "gw_name") modparam("lcr", "ip_addr_column", "ip") modparam("lcr", "lcr_id_column", "lcr_id") modparam("lcr", "gw_uri_avp", "$avp(gw_uri_avp)") modparam("lcr", "ruri_user_avp", "$avp(ruri_user_avp)") modparam("lcr", "flags_avp", "$avp(s:cSId)") modparam("lcr", "flags_column", "cSId") modparam("lcr", "defunct_capability", 1) modparam("lcr", "lcr_id_avp", "$avp(lcr_id_avp)") modparam("lcr", "defunct_gw_avp", "$avp(defunct_gw_avp)") modparam("lcr", "lcr_rule_hash_size", 1024) modparam("lcr", "lcr_gw_count", 1024) modparam("lcr", "fetch_rows", 3000) modparam("lcr", "ping_interval", 15) # Ping every 15 seconds modparam("lcr", "ping_inactivate_threshold", 1) # Mark as inactive at first call of inactivate_gw() modparam("lcr", "ping_valid_reply_codes", "403,404,405,501") # Mark as active when 2XX or these reply codes modparam("lcr", "ping_from", "sip:lcr@mydomain.com") modparam("lcr", "lcr_count", 1) modparam("lcr", "dont_strip_or_prefix_flag", 1) modparam("lcr", "rule_id_avp", "$avp(lcr_rule_id)") modparam("lcr", "priority_ordering", 1) modparam("lcr", "ping_socket", "10.16.16.16:5060") Thanks & Regards -- Regards M Arqum

3 5

t_suspend() / t_continue() create new branches
by Sebastian Damm 24 Nov '21

24 Nov '21

Hi, I have the following weird problem. A Kamailio (5.4.x) with some asynchronous permission logic suspends outgoing INVITEs and resumes them after the answer of the permission system. Everything works as expected when the call is answered. However, when the called party rejects the call (with a 486 for example), the call doesn't get torn down immediately (it is rejected with a 408 eventually) because Kamailio logs the following: Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: app_python [apy_kemi.c:106]: sr_kemi_config_engine_python(): execution of route type 4 with name [ksr_onreply_manage] returned 1 Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=183, new_code=486 Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: tm [t_reply.c:1448]: t_should_relay_response(): store - other branches still active Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: tm [t_reply.c:1926]: relay_reply(): reply status=3 branch=2, save=1, relay=-1 icode=0 msg status=486 I don't do any forking, the call is just forwarded. I put the following line immediately after t_suspend() and in the beginning of the route specified in t_continue(): KSR.info("We're at branch index %d" % KSR.pv.get("$T(branch_index)")) This produces the following output: Nov 23 16:30:13 host /usr/sbin/kamailio[2745]: INFO: <core> [core/kemi.c:104]: sr_kemi_core_info(): We're at branch index 0 Nov 23 16:30:13 host /usr/sbin/kamailio[2725]: INFO: <core> [core/kemi.c:104]: sr_kemi_core_info(): We're at branch index 2 So apparently, the suspend and continue introduce new branches. (Other option: I'm doing something completely different creating those branches, but I don't have any append_branch() or similar in my code.) I assume, I just missed a configuration parameter. Can I get Kamailio somehow to behave as if there was just one branch and forward the negative reply? Thanks, Sebastian

2 3

KEMI Golang
by Eugeniu Istrati 24 Nov '21

24 Nov '21

Hello, Is there any plans to add golang into the KEMI framework? Thank you -- Eugeniu Istrati

2 1

[uac] How to force outbound registration?
by Denys Pozniak 24 Nov '21

24 Nov '21

Hello! In some cases, I need to forcibly unregister a remote SIP account through uac module, and then immediately register. To unregister I can use the command: *kamcmd uac.reg_unregister l_uuid <account>* But it's not clear how to immediately register back. For example, these commands do not give the desired effect: *kamcmd uac.reg_enable l_uuid <account>* *kamcmd uac.reg_reload* [root@kamailio]# kamailio -V version: kamailio 5.5.2 (x86_64/linux) 55e232 -- BR, Denys Pozniak

2 3

Kamailio v5.5.3 Released
by Daniel-Constantin Mierla 24 Nov '21

24 Nov '21

Hello, Kamailio SIP Server v5.5.3 stable release is out. This is a maintenance release of the latest stable branch, 5.5, that includes fixes since the release of v5.5.2. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.5.x. Deployments running previous v5.5.x versions are strongly recommended to be upgraded to v5.5.3. For more details about version 5.5.3 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2021/11/kamailio-v5-5-3-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Releasing Kamailio v5.5.3
by Daniel-Constantin Mierla 24 Nov '21

24 Nov '21

Hello, I am considering to release Kamailio v5.5.3 sometime next week, likely on Wednesday or Thursday (Nov 24/25, 2021). This is the usual heads up notification to see if anyone is aware of issues not yet reported to bug tracker and if yes, do it as soon as possible to give them a chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

2 3

UDP packets lost - tuning Linux system configuration - Kamailio using default for SO_RCVBUF ?
by Chaigneau, Nicolas 23 Nov '21

23 Nov '21

Hello, I'm using Kamailio 5.5.2 with UDP sockets, configured with 32 children processes. During load tests, some packets seem to be dropped. I'm trying to figure out why, and how to solve (or mitigate) the issue. >From what I understand : < the SIP messages send on UDP/SCTP are received directly from the buffer in kernel one by one, each being processed once read. > (this is a message from Daniel-Constantin Mierla, posted on the mailing list back in 2014 - I assume this is still accurate) So Kamailio does not handle its own buffers for incoming messages, but simply pulls one message from the kernel queue whenever a process is available for processing. (Correct me if this is not true) Hereafter some system parameters that seem interesting to me. In particular, < net.core.rmem.default > seem very low (0,33 MB). But < net.core.rmem.max > is much higher (16 MB). Looking at the code in function probe_max_receive_buffer (src\core\udp_server.c), it seems Kamailio is trying to increase the buffer size from the default. However this does not seem to be working, seeing the following logs upon startup : 0(7602) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 349520 0(7602) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 349520 0(7602) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 349520 0(7602) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 349520 0(7602) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 349520 0(7602) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 349520 Is there something I don't understand ? could it be a bug ? One quick fix I can think of would be to increase < net.core.rmem.default >. Considering that I don't have many sockets (3 used by Kamailio), I think I could set this to 16 MB (my VMs have 8 GB of allocated RAM). What do you think ? Thanks in advance for your help. My system parameters : net.core.rmem_default = 349520 net.core.rmem_max = 16777216 # => 0,33 MB / 16 MB respectively * net.core.rmem_default, net.core.rmem_max - default and max socket receive buffer size in bytes. Each socket gets rmem_default reveive buffer size by default, and can request up to rmem_max with setsockopt<http://man7.org/linux/man-pages/man2/setsockopt.2.html> option SO_RCVBUF. net.ipv4.udp_mem = 188856 251809 377712 * net.ipv4.udp_mem = "min pressure max" - these are numbers of PAGES (4KB) available for all UDP sockets in the system. min, pressure and max controls how memory is managed, but main point is that max is maximum size in PAGES for all UDP bufers in system. These values are set on boot time (if sysctls are not explicitly set) according to available RAM size. # 377712 x 4 KB => 1475 MB net.ipv4.udp_rmem_min = 4096 * net.ipv4.udp_rmem_min, net.ipv4.udp_wmem - minimal size for receive/send buffers (in bytes), guaranteed for each socket, even if if buffer size of all UDP sockets exceeds pressure parameter in net.ipv4.udp_mem. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

2 2

Custom info in Contact header
by Igor Olhovskiy 23 Nov '21

23 Nov '21

Hello! On REGISTER I have a Contact header like Contact: <sip:90002@192.168.0.26:48579;transport=TLS>;some_id=90002-21080 But on calling fix_nated_register() -> save(), param some_id is lost from info, so, on INVITE to this account, some_id not appears in RURI. Is this a bug or a feature and I do need to find some workaround? -- Best regards, Igor

4 6

Help with Async transaction responses
by Michael Friesen 19 Nov '21

19 Nov '21

Hello, I am attempting to perform some asynchronous lookup upon receiving an INVITE and then reply with a 3xx response with a modified From header. My workflow now is to create a transaction when receiving the INVITE, suspend the transaction, perform the asynchronous lookup, continue the transaction upon response, and then modify the From header and reply. The ONLY problem I am having is modifying the From header! How can I modify the From header in this scenario? function ksr_request_route() if KSR.is_INVITE() then if KSR.tm.t_newtran() then cache_transaction_info() KSR.tmx.t_suspend() --perform async loookup end end return 1 end --This function called on response from async lookup. Equivalent of ONREPLY_ROUTE function ksr_reply_route() --Finds the transaction_index and transaction_label from a cache KSR.tmx.t_continue(transaction_index, transaction_label, "redirect_transaction"); KSR.x.drop() return 1 end function redirect_transaction() KSR.pv.sets("$fU", "Jenny") --Doesn't actually modify the from username for 302 response! KSR.tm.t_reply(302, "Redirecting") return 1 end Thank you much! -Michael

2 2

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 November 2021