sr-users

sr-users@lists.kamailio.org

21 participants
37199 discussions

routing call depending on which IP address SIP message reached Kamailio

by Sergio Charrua

Hi all! For a project under development, one requirement is to be able to forward/relay the call to a specific destination depending on which IP Address and Port the call was received by Kamailio. This also means that Kamailio will be listening on multiple IP Address and Ports listen=udp:IP_1:port_1 # trunkgroup 1 listen=udp:IP_2:port_2 # trunkgroup 2 listen=udp:IP_3:port_3 # trunkgroup 3 I know the pv $Ri and $Rp can be used to identify from which IP address and port the message reached Kamailio and having those details, depending on the value, I can define some conditions that allows Kamailio to relay the call to different destination endpoints. For example: - calls from +32 to + 39 received on trunkgroup1 needs to go to Italy SBC address A.B.C.D - but calls from +32 to +39 received on trunkgroup2 need to go to Germany on SBC address 1.2.3.4 (as it is cheaper) Is there a better way of doing this without using IF/THEN/ELSE or SWITCH blocks and "hard code" destination SBC addresses? I have read the DRouting module's documentation but not sure if it could help and how... Any suggestions? Atenciosamente / Kind Regards / Cordialement, *Sérgio *

1 month

(no subject)

by Sergio Charrua

Hi all! for a project under development, one requirement is to be able to forward/relay the call to a specific destination depending on which IP Address and Port the call was received by Kamailio. This also means that Kamailio will be listening on multiple IP Address and Ports listen=udp:IP_1:port_1 # trunkgroup 1 listen=udp:IP_2:port_2 # trunkgroup 2 listen=udp:IP_3:port_3 # trunkgroup 3 I know the pv $Ri and $Rp can be used to identify from which IP address and port the message reached Kamailio and having those details, depending on the value, I can define some conditions that allows Kamailio to relay the call to different destination endpoints. For example: - calls from +32 to + 39 received on trunkgroup1 needs to go to Italy SBC address A.B.C.D - but calls from +32 to +39 received on trunkgroup2 need to go to Germany on SBC address 1.2.3.4 (as it is cheaper) Is there a better way of doing this without using IF/THEN/ELSE or SWITCH blocks and "hard code" destination SBC addresses? I have read the DRouting module's documentation but not sure if it could help and how... Any suggestions? Atenciosamente / Kind Regards / Cordialement, *Sérgio *

1 month

deb package build error (v5.7.6) [error: debian/rules binary subprocess returned exit status 2]

by Denys Pozniak

Hello! I'm trying to build standard deb packages for Kamailio v5.7.6 for Debian 12.6, but I get an error. By the way, there are no problems with building v5.7.2 ... #git clone --single-branch --branch 5.7.6 https://github.com/kamailio/kamailio.git /usr/src/kamailio #cd /usr/src/kamailio && ln -s pkg/kamailio/deb/bookworm debian #make cfg && RADCLI=1 make deb .... Makefile.defs defs skipped make[6]: 'libkamailio_ims.so.0.1' is up to date. gcc -shared -g -m64 -Wl,-O2 -Wl,-E -Wl,-z,relro -pthread -rdynamic "-ldl" -Wl,-Bsymbolic-functions cmd.o ims_ipsec_pcscf_mod.o ipsec.o sec_agree.o spi_gen.o spi_list.o spi_list_tests.o -lm -lmnl -L../../lib/ims/ -lkamailio_ims -Wl,-rpath,/usr/src/kamailio/src/lib/ims -o ims_ipsec_pcscf.so make[4]: Leaving directory '/usr/src/kamailio/src' make[3]: Leaving directory '/usr/src/kamailio' make[2]: Leaving directory '/usr/src/kamailio' *dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2* make[1]: Leaving directory '/usr/src/kamailio/src' -- BR, Denys Pozniak

1 month

Disable topos for a specific peering IP

by Denys Pozniak

Hello! I need to disable topos for one specific SIP trunk (in-out), it looks like it’s enough to use event_route with IP address filtering. But for some reason, the incoming INVITE from the peer still gets processed by topos and I also don’t see a mention of [msg-incoming] in the logs, only this: WARNING: <script>: [msg-outgoing] OPTIONS/you/1.1.1.1 Code snippet: loadmodule "topos.so" modparam("topos", "db_url", DBURL) modparam("topos", "contact_mode", 1) modparam("topos", "header_mode", 1) modparam("topos", "methods_noinitial", "OPTIONS,SUBSCRIBE,PUBLISH") modparam("topos", "dialog_expire", 7210) modparam("topos", "rr_update", 1) modparam("topos", "event_mode", 5) /* 1 - execute event_route[topos:msg-outgoing] 2 - execute event_route[topos:msg-sending] 4 - execute event_route[topos:msg-incoming] 8 - execute event_route[topos:msg-receiving] */ request_route { .... event_route[topos:msg-outgoing] { if ( $sndto(ip) == "1.1.1.1" ) { xlog("L_WARN","[msg-outgoing] $rm/$rU/$sndto(ip) \n"); drop; } } } event_route[topos:msg-incoming] { if ( $si == "1.1.1.1" ) { xlog("L_WARN","[msg-incoming] $rm/$rU/$si \n"); drop; } } # kamailio -v version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty -- BR, Denys Pozniak

1 month

New Member Introduction

by Maria Jonas

Hi everyone, I am new to this forum and excited to be here. I'm eager to learn more about Kamailio and its features and I'm looking forward to participating in discussions here. Could someone please guide me on how to ask questions here ? Where should I post if I have a query ? Looking forward to your advice and connecting with you all. Thanks,

1 month

usrloc ka_interval timer is not correct in kamailio 5.8

by Michal Popovič

Hello everybody, I am using kamailio in AWS behind load balancer and after upgraded from version 5.7 to 5.8 kamailio is not able to keep connection open. After quick investigation I found out that usrloc module got new parameter ka_interval that replaced timer_interval. Change is here. https://github.com/kamailio/kamailio/commit/53ace443020075f7ecd12c72f154193… Problem is that this interval is not reliable, as it is most probably still called only when timer_interval is executed. If I set values to timer_interval = 30 ka_interval = 30 ka_randomize = 20 Maximum time for keep-alive is not 30+20 seconds but 30+30+20 seconds. That is too late for AWS load balancer. I have fixed it by enabling tcp keepalives on kernel level. Is there any way how to specify exact time in version 5.8? Thanks. Michal

1 month

HTTP Client configuration path

by Sergio Charrua

Hi all! I am using HTTP_CLIENT module, and have created a http configuration file. The module's config_file parameter is set as: modparam("http_client", "config_file", "/etc/kamailio/http_client.cfg") and it works OK on my DEV environment, because there is a symlink /etc/kamailio pointing to physical folder /usr/local/etc/kamailio/ (using Kamailio 5.7.4) However in our integration environment (also using Kamailio 5.7.4), which is identical to production, and due to limitations on access rights, we cannot create a symlink /etc/kamailio pointing /usr/local/etc/kamailio/, so all cfg files are in the installation folder. So I thought that the config_file parameter should be a relative path, starting with " ./ " or by just setting the config file name, without path (as per documentation at http_client (kamailio.org) <https://kamailio.org/docs/modules/5.1.x/modules/http_client.html#idp38265140> . The issue is that even though the file http_client.cfg is present in /usr/local/etc/kamailio/, as well as other cfg files, the cfg_parser fails to load it: Jul 11 09:32:09 lab-kamailio kamailio[44114]: ERROR: <core> > [core/cfg_parser.c:632]: cfg_parser_init(): cfg_parser: Unable to open file > './http_client.cfg' > Jul 11 09:32:09 lab-kamailio kamailio[44114]: ERROR: http_client > [curlcon.c:782]: http_client_load_config(): Failed to init http_client > config file parser > Jul 11 09:32:09 lab-kamailio kamailio[44114]: ERROR: http_client > [http_client.c:307]: mod_init(): Failed to load http_client connections > from [./http_client.cfg] > Jul 11 09:32:09 lab-kamailio kamailio[44114]: ERROR: <core> > [core/sr_module.c:1030]: init_mod(): Error while initializing module > http_client (/usr/local/lib64/kam > ailio/modules/http_client.so) I have set the parameter to > modparam("http_client", "config_file", "./http_client.cfg") and also to > modparam("http_client", "config_file", "http_client.cfg") but it only works if I add it as : > modparam("http_client", "config_file", > "/usr/local/etc/kamailio/http_client.cfg") or by adding > chroot="/usr/local/etc/kamailio" in the main cfg script, which was my final solution. Also checked for permissions, and all is fine. Note that this only seems to happen with http_client config_file parameter. I have other include commands in the main cfg file with relative paths and all works fine. I have also analysed the cfg_parser.so file, which loads the configuration file for http_client module, but could not find anything wrong with it (at 1st glance....) What am I doing wrong? Any clue? Atenciosamente / Kind Regards / Atentamente / Cordialement, *Sérgio *

1 month

SIP Question: B2BUA not ACKing 200 OK response

by Ghulam Mustafa

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

1 month

Re: Possible Kamailio memmory leak - version 5.8.2

by Vanderlei Torres Batistela

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

1 month

Re: Possible Kamailio memmory leak - version 5.8.2

by Vanderlei Torres Batistela

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

1 month

← Newer
1
2
3
4
5
6
7
8
9
...
3720
Older →

Jump to page:

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