sr-users

sr-users@lists.kamailio.org

23 participants
37378 discussions

SIP Question: B2BUA not ACKing 200 OK response
by Ghulam Mustafa 11 Jul '24

11 Jul '24

Hi Community, We are setting up a new provider in our VoIP setup for outgoing calls (FreeSWITCH --> Kamailio --> Provider). When the provider sends a 200 OK in response to our INVITE, FreeSWITCH's SIP stack discards the message, and we are unable to determine the cause of this behavior. I am sharing the SIP message exchange below. Could any SIP experts assist us in understanding why FreeSWITCH is not sending an ACK in response to the 200 OK message? We understand that the issue is not related to Kamailio but seems to be within the SIP stack or FreeSWITCH itself. Below are the actual INVITE and its response, which was discarded by FreeSWITCH: send 1203 bytes to tcp/[10.xxx.x.30]:5060 at 15:48:23.001054: ------------------------------------------------------------------------ INVITE sip:+86xxxxxxxxxxx@35.xxx.xxx.xxx;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.xxx.x.10:5080;rport;branch=z9hG4bKD8p0KmvB8ZKma Max-Forwards: 69 From: "+1xxxxxxxxxx" <sip:+1xxxxxxxxxx@10.xxx.x.10>;tag=ZSvBBtypKypDS To: <sip:+86xxxxxxxxxxx@35.xxx.xxx.xxx> Call-ID: 21b7b9b5-b8a5-123d-63a6-ecf4bbd64f6c CSeq: 85714459 INVITE Contact: <sip:gw+commsgroup@10.xxx.x.10:5080;transport=tcp;gw=commsgroup> User-Agent: FreeSWITCH-mod_sofia/1.10.11-release~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 347 X-FS-Support: update_display,send_info Remote-Party-ID: "+1xxxxxxxxxx" <sip:+1xxxxxxxxxx@10.xxx.x.10 >;party=calling;screen=yes;privacy=off v=0 o=Z 5395246197255529491 693195311 IN IP4 10.xxx.x.225 s=Z c=IN IP4 10.xxx.x.225 t=0 0 m=audio 55319 RTP/AVP 106 9 98 101 0 8 3 a=rtpmap:106 opus/48000/2 a=fmtp:106 sprop-maxcapturerate=16000; minptime=20; useinbandfec=1 a=rtpmap:98 telephone-event/48000 a=fmtp:98 0-16 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-mux tport.c:2316 tport_set_secondary_timer() tport(0x150e6c0291c0): reset timer nta.c:8400 outgoing_send() nta: sent INVITE (85714459) to tcp/10.xxx.x.30:5060 tport.c:4191 tport_pend() tport_pend(0x150e6c0291c0): pending 0x150e6c0c52f0 for tcp/10.xxx.x.30:5060 (already 2) nua_session.c:4131 signal_call_state_change() nua(0x150d9c107460): call state changed: init -> calling, sent offer soa.c:1268 soa_get_local_sdp() soa_get_local_sdp(static::0x150e6c0c0210, [0x150e91772798], [0x150e91772790], [(nil)]) called nua_stack.c:299 nua_stack_event() nua(0x150d9c107460): event i_state INVITE sent nua_stack.c:389 nua_application_event() nua: nua_application_event: entering nua.c:1170 nua_handle_unref_user() nua nua_handle_unref_user(0x150d9c107460): entering nua.c:365 nua_handle_magic() nua: nua_handle_magic: entering nua_stack.c:558 nua_signal() nua(0x150d9c107460): sent signal r_handle_unref nua.c:1157 nua_unref_user() nua: nua_unref_user: entering 2024-07-09 15:48:22.985772 100.00% [DEBUG] sofia.c:7493 Channel sofia/external/+86xxxxxxxxxxx entering state [calling][0] nua_stack.c:599 nua_stack_signal() nua(0x150d9c107460): recv signal r_handle_unref nua.c:365 nua_handle_magic() nua: nua_handle_magic: entering nua_stack.c:558 nua_signal() nua((nil)): sent signal r_unref nua.c:1170 nua_handle_unref_user() nua nua_handle_unref_user(0x150d9c107460): entering nua_stack.c:599 nua_stack_signal() nua((nil)): recv signal r_unref nua_stack.c:558 nua_signal() nua(0x150d9c107460): sent signal r_handle_unref nua_stack.c:599 nua_stack_signal() nua(0x150d9c107460): recv signal r_handle_unref nua.c:1157 nua_unref_user() nua: nua_unref_user: entering nua_stack.c:558 nua_signal() nua((nil)): sent signal r_unref nua_stack.c:599 nua_stack_signal() nua((nil)): recv signal r_unref 2024-07-09 15:48:22.985772 100.00% [DEBUG] switch_core_state_machine.c:659 (sofia/external/+86xxxxxxxxxxx) State CONSUME_MEDIA 2024-07-09 15:48:22.985772 100.00% [DEBUG] switch_core_state_machine.c:659 (sofia/external/+86xxxxxxxxxxx) State CONSUME_MEDIA going to sleep tport.c:2796 tport_wakeup() tport_wakeup(0x150e6c0291c0): events IN tport.c:2900 tport_recv_event() tport_recv_event(0x150e6c0291c0) tport.c:3237 tport_recv_iovec() tport_recv_iovec(0x150e6c0291c0) msg 0x150e6c0cb390 from (tcp/10.xxx.x.30:5060) has 352 bytes, veclen = 1 recv 352 bytes from tcp/[10.xxx.x.30]:5060 at 15:48:23.004029: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/TCP 10.xxx.x.10:5080;rport=37555;branch=z9hG4bKD8p0KmvB8ZKma;received=10.xxx.x.10 From: "+1xxxxxxxxxx" <sip:+1xxxxxxxxxx@10.xxx.x.10>;tag=ZSvBBtypKypDS To: <sip:+86xxxxxxxxxxx@35.xxx.xxx.xxx> Call-ID: 21b7b9b5-b8a5-123d-63a6-ecf4bbd64f6c CSeq: 85714459 INVITE Server: Kamailio 5.8 Content-Length: 0 tport.c:3055 tport_deliver() tport_deliver(0x150e6c0291c0): msg 0x150e6c0cb390 (352 bytes) from tcp/10.xxx.x.30:5060/sip next=(nil) nta.c:3378 agent_recv_response() nta: received 100 Trying for INVITE (85714459) nta.c:3445 agent_recv_response() nta: 100 Trying is going to a transaction nta.c:9697 outgoing_estimate_delay() nta_outgoing: RTT is 3.038 ms tport.c:4253 tport_release() tport_release(0x150e6c0291c0): 0x150e6c0c52f0 by 0x150e6c0be9a0 with 0x150e6c0cb390 (preliminary) tport.c:2316 tport_set_secondary_timer() tport(0x150e6c0291c0): reset timer nta.c:5904 incoming_reclaim_queued() incoming_reclaim_all((nil), (nil), 0x150e91973a50) nta.c:7270 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 0/0 term, 2/3 free nta.c:1310 agent_timer() nta: timer not set tport.c:2796 tport_wakeup() tport_wakeup(0x150e6c0291c0): events IN tport.c:2900 tport_recv_event() tport_recv_event(0x150e6c0291c0) tport.c:3237 tport_recv_iovec() tport_recv_iovec(0x150e6c0291c0) msg 0x150e6c0c9d90 from (tcp/10.xxx.x.30:5060) has 1195 bytes, veclen = 1 recv 1195 bytes from tcp/[10.xxx.x.30]:5060 at 15:48:27.070278: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/TCP 10.xxx.x.10:5080;received=10.xxx.x.10;rport=37555;branch=z9hG4bKD8p0Km From: "+1xxxxxxxxxx" <sip:+1xxxxxxxxxx@10.xxx.x.10>;tag=ZSvBBtypKypDS To: <sip:+86xxxxxxxxxxx@35.xxx.xxx.xxx >;tag=7bQ0OSl9Dl-39455-57712329-1057554-14 Call-ID: 21b7b9b5-b8a5-123d-63a6-ecf4bbd64f6c CSeq: 85714459 INVITE Contact: <sip:127.0.0.8;line=sr-H46V9.fbsXNDlkfEJjGbujK3J4aDo1GzP5GOJ8hcsXwV9LAWw1abHkqWlXczwL7*> Record-Route: <sip:13x.xxx.xxx.xx;transport=tcp;lr;ftag=ZSvBBtypKypDS;did=cbd.e581;nat=yes> Supported: sdp-anat Allow: INVITE,PRACK,ACK,UPDATE,CANCEL,BYE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY Require: timer Session-Expires: 2000;refresher=uas Server: Mediant VE SBC/v.7.40A.250.265 P-Asserted-Identity: <sip:4006100666@hk.chinatelecom.com;user=phone> Accept: application/sdp, application/isup, multipart/mixed, application/dtmf, application/dtmf-relay Content-Type: application/sdp Content-Length: 219 User-Agent: Kamailio 5.8 v=0 o=- 846721169 1919912032 IN IP4 13x.xxx.xxx.xx s=- c=IN IP4 13x.xxx.xxx.xx t=0 0 m=audio 49708 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:49709 tport.c:3055 tport_deliver() tport_deliver(0x150e6c0291c0): msg 0x150e6c0c9d90 (1195 bytes) from tcp/10.xxx.x.30:5060/sip next=(nil) nta.c:3378 agent_recv_response() nta: received 200 OK for INVITE (85714459) nta.c:3494 agent_recv_response() nta: 200 OK was discarded Any insights or suggestions would be greatly appreciated, Specifically, why is the 200 OK response being discarded?. Thank you! Regards, Mustafa

2 2

Re: Possible Kamailio memmory leak - version 5.8.2
by Vanderlei Torres Batistela 11 Jul '24

11 Jul '24

Hi, Daniel. Thank you for the quick response! I will update you after testing the fix. Regards, Vanderlei

1 0

Re: Possible Kamailio memmory leak - version 5.8.2
by Vanderlei Torres Batistela 10 Jul '24

10 Jul '24

Hello Henning, Thank you for your quick response. The increase happens in the core module (create-avp). See bellow: [root@labcom070 kamailio]# kamcmd mod.stats all shm Module: core { create_avp(178): 52257504 <---------------------------- counters_prefork_init(211): 53760 cfg_clone_str(132): 112 cfg_shmize(221): 832 main_loop(1381): 16 init_pt(104): 16 init_pt(103): 16 init_pt(102): 6224 cfg_register_ctx(47): 96 init_tcp(5197): 8192 init_tcp(5191): 32768 init_tcp(5182): 16 init_tcp(5175): 16 init_tcp(5167): 16 init_tcp(5161): 16 init_tcp(5149): 16 init_avps(92): 16 init_avps(91): 16 init_dst_blocklist(435): 16384 init_dst_blocklist(427): 16 timer_alloc(494): 96 init_dns_cache(368): 16 init_dns_cache(359): 16384 init_dns_cache(351): 16 init_dns_cache(343): 16 init_timer(264): 16 init_timer(263): 16384 init_timer(262): 16 init_timer(261): 16 init_timer(250): 16 init_timer(218): 16 init_timer(207): 278544 init_timer(206): 16 init_timer(194): 16 cfg_child_cb_new(832): 64 sr_cfg_init(371): 16 sr_cfg_init(364): 16 sr_cfg_init(356): 16 sr_cfg_init(344): 16 sr_cfg_init(332): 16 ksr_shutdown_phase_init(123): 16 rpc_hash_add(118): 16 qm_shm_lock_init(1463): 16 Total: 52687808 <------------------ } [root@labcom070 kamailio]# kamctl stats shmem { "jsonrpc": "2.0", "result": [ "shmem:fragments = 900", "shmem:free_size = 6180368", "shmem:max_used_size = 66980272", "shmem:real_used_size = 60928496", "shmem:total_size = 67108864", "shmem:used_size = 54884944" ], "id": 393115 } These reports above are shown after the end of calls (4000) where the outgoing INVITE is not answered. In normal calls the issue does not occur and the reports are shown below: [root@labcom070 kamailio]# kamcmd mod.stats all shm Module: core { counters_prefork_init(211): 53760 cfg_clone_str(132): 112 cfg_shmize(221): 832 main_loop(1381): 16 init_pt(104): 16 init_pt(103): 16 init_pt(102): 6224 cfg_register_ctx(47): 96 init_tcp(5197): 8192 init_tcp(5191): 32768 init_tcp(5182): 16 init_tcp(5175): 16 init_tcp(5167): 16 init_tcp(5161): 16 init_tcp(5149): 16 init_avps(92): 16 init_avps(91): 16 init_dst_blocklist(435): 16384 init_dst_blocklist(427): 16 timer_alloc(494): 96 init_dns_cache(368): 16 init_dns_cache(359): 16384 init_dns_cache(351): 16 init_dns_cache(343): 16 init_timer(264): 16 init_timer(263): 16384 init_timer(262): 16 init_timer(261): 16 init_timer(250): 16 init_timer(218): 16 init_timer(207): 278544 init_timer(206): 16 init_timer(194): 16 cfg_child_cb_new(832): 64 sr_cfg_init(371): 16 sr_cfg_init(364): 16 sr_cfg_init(356): 16 sr_cfg_init(344): 16 sr_cfg_init(332): 16 ksr_shutdown_phase_init(123): 16 rpc_hash_add(118): 16 qm_shm_lock_init(1463): 16 Total: 430304 } [root@labcom070 kamailio]# kamctl stats shmem { "jsonrpc": "2.0", "result": [ "shmem:fragments = 6", "shmem:free_size = 64143184", "shmem:max_used_size = 4070816", "shmem:real_used_size = 2965680", "shmem:total_size = 67108864", "shmem:used_size = 2627856" ], "id": 683948 } Regars, Vanderlei

2 1

Intercepting OPTIONS from nathelper
by Denys Pozniak 10 Jul '24

10 Jul '24

Hello! I need advice on how to intercept local SIP OPTIONS requests from the nathelper module for some adjustments? As far as I tested, it does not fall into the *event_route[tm:local-request]* Thanks in advance! # kamailio -v version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty -- BR, Denys Pozniak

2 5

handle_subscribe(), handle_publish() and DB usage
by Володимир Іванець 04 Jul '24

04 Jul '24

Hello everyone! According to the documentation functions handle_subscribe() and handle_publish() update information not only in memory but also in the database. Isn't there a way to disable database usage for this functionality? Setting subs_db_mode to 0 does not make a change. Thank you!

1 0

Contact does not exist in PCSCF usrloc error in log
by Shantanu K Roy 03 Jul '24

03 Jul '24

Hello, We are trying to integrate Kamailio as the IMS server with our 5G core emulator by following the steps listed out at https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/. In our case, we have our own 5G core emulator instead of the Open5GS core. We are using sipp scripts to generate the SIP calls. The PCRF component of the 5G core is emulated by us and is capable of handling Diamater calls from Kamailio over the Rx interface. We have got the setup working to the point where the SIP Register calls are landing on the PCSCF which in turn is sending out AA Requests to PCRF and the PCRF is responding. However there is an internal error in the Kamailio log "4(3682133) ERROR: ims_qos [ims_qos_mod.c:1305]: w_rx_aar_register(): This contact does not exist in PCSCF usrloc - error in cfg file" Please help us in identifying if we are missing anything in the Kamailio set up. The packet capture and syslog excerpts from the VM where Kamailio is running are attached; here we are trying to perform SIP Registration for three SIP endpoints 001010123456791, 001010123456792 and 001010123456793. If there is any additional information required, please let us know. Regards, Shantanu Kumar Roy

3 6

Kamailio v5.6.6 Released
by Daniel-Constantin Mierla 03 Jul '24

03 Jul '24

Hello, Kamailio SIP Server v5.6.6 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.6. Note that 5.6 is now the third last stable branch, v5.6.6 being the last planned released in 5.5.x series. The latest two stable branch are 5.7 and 5.8, with v5.8.2 being released a while ago. For more details about version 5.6.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2024/07/kamailio-v5-6-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training -- asipto.com

1 0

Releasing v5.6.6
by Daniel-Constantin Mierla 03 Jul '24

03 Jul '24

Hello, I am considering to release Kamailio v5.6.6 (out of branch 5.6) later this week (likely on Wednesday, July 3, 2024). If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. This is going to be the last release out of branch 5.6 to mark the end of official/packaging maintenance. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

1 1

Extracting and Handling Via Headers in failure_route
by sadik.oualla.mohamed＠gmail.com 02 Jul '24

02 Jul '24

Hello, I am currently working on a scenario where I need to use Kamailio in the failure_route to process SIP responses, specifically handling negative SIP replies (e.g., 486 Busy Here) that Kamailio may receive. Here is the topology: ##B2BUA (acts as a UAC with the Kamailio, because it sends the INVITE) -> Kamailio -> Callee## In my setup, Kamailio needs to extract all Via headers from the received SIP response in the failure_route, focusing particularly on the bottom Via header (from the B2BUA' UAC part). However, I am encountering difficulties in achieving this. Here is what I have tried so far: 1. To extract the Via headers, I used the following line of code in the failure_route: ```$var(viaHeaderValues) = $T_rpl($hdr(Via));``` However, this only returns the topmost Via header. 2. I attempted to get the first and last Via headers values with: ```$var(viaHeaderValueFirst) = $T_rpl($hdr(Via)[0]); $var(viaHeaderValueLast) = $T_rpl($hdr(Via)[1]);``` Unfortunately, this also only returns the topmost Via header, which contains the address of Kamailio. My goal is to make sure that when Kamailio sends the SIP reply to the UAC with send_reply method on the failure_route, it uses the extracted *Via header* of the incoming SIP response (only the bottom one). Here is an example scenario: - Received SIP Response in kamailio: ``` SIP/2.0 486 Busy Here Via: SIP/2.0/UDP 200.200.200.4;branch=z9hG4bK9157.090080a91105c0ec6279bb56882d1dc8.0 Via: SIP/2.0/UDP 200.200.200.3;received=200.200.200.3;rport=5060;branch=z9hG4bKF1aaZ7ea7yc2m From: <sip:caller@200.200.200.3>;tag=222222 To: <sip:callee@200.200.200.4:5060>;tag=4545454 Call-ID: 65695DSQ(a)200.200.200.3 CSeq: 1 INVITE Content-Length: 0 ``` - Desired SIP Response from kamailio: ``` SIP/2.0 486 Busy Here Via: SIP/2.0/UDP 200.200.200.3;received=200.200.200.3;rport=5060;branch=z9hG4bKF1aaZ7ea7yc2m From: <sip:caller@200.200.200.3>;tag=222222 To: <sip:callee@200.200.200.4:5060>;tag=4545454 Call-ID: 65695DSQ(a)200.200.200.3 CSeq: 1 INVITE Content-Length: 0 ``` The current issue is that Kamailio modifies the Via header when sending the reply with send_reply method, resulting in: ``` SIP/2.0 486 Busy Here Via: SIP/2.0/UDP 200.200.200.3;rport=5060;branch=z9hG4bKF1aaZ7ea7yc2m;received=200.200.200.3 From: <sip:caller@200.200.200.3>;tag=222222 To: <sip:callee@200.200.200.4:5060>;tag=4545454 Call-ID: 65695DSQ(a)200.200.200.3 CSeq: 1 INVITE Content-Length: 0 ``` Due to this change, the UAC does not correctly react to or understand the SIP response "SIP Reply follows the RFC standards, but my current UAC waits for a Via that looks like Via of the previous SIP messages in the structure of parameters.". It is crucial for the Via header to maintain the same important order such as the branch, received, and rport values as the previous exchanged SIP messages. Could you please provide guidance on how to force Kamailio to send the SIP reply using send_reply method with the extracted bottom Via header from the incoming SIP response? Any advice or examples on handling this situation would be greatly appreciated. Thank you for your time and assistance.

1 0

Kamailio v5.7.6 Released
by Daniel-Constantin Mierla 02 Jul '24

02 Jul '24

Hello, Kamailio SIP Server v5.7.6 stable release is out. This is a maintenance release of the latest stable branch, 5.7, that includes fixes since the release of v5.7.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.7.x. Deployments running previous v5.7.x versions are strongly recommended to be upgraded to v5.7.6. For more details about version 5.7.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2024/07/kamailio-v5-7-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 5.7.x is currently the previous stable release series, the latest is 5.8.x and v5.8.2 was released on June 12, 2024. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

1 0

Jump to page:

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