- sr-users - kamailio.org

OT: Client DNS resolver crashing on NAPTR lookup
by Benoit Panizzon 28 Apr '25

28 Apr '25

Hi List I hope it is OK to post a slightly off topic question. I have not found any similar reports via google. During testing of our development platform, I found two independent clients whose resolver process crashes randomly, when performing NAPTR lookups. Mitel/Aastra 68XXi Phones with Firmware >= 6.4 up to most recent. Inalp/Patton SNXX (Trinity OS) SIP Gateway with Firmware >= 3.14.X up to most recent. Both vendors reply they have no prior reports of this issue. The hostname used as registrar / proxy points to a NAPTR entry, which in turn points to 3 SRV entries für SIP+D2T, SIP+D2U, SIPS+D2T Each SRV entry then points to 4 IP Addresses (2x ipv4 and 2x ipv6) So quite a complex lookup and quite large replies. Anyone else observed this issue? When using a hostname that merely points to the A and AAAA records, no crashes. 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 ______________________________________________________

1 0

rtpengine module does not detect new nodes in table
by David Cunningham 28 Apr '25

28 Apr '25

Hello, We are using Kamailio 5.8.2 with the rtpengine module on Ubuntu 22.04. The "rtpengine" table is used to define nodes, with a configuration like this: modparam( "rtpengine", "db_url", DB_URL ) modparam( "rtpengine", "table_name", "rtpengine" ) modparam( "rtpengine", "setid_default", 1 ) It works fine if Kamailio is restarted after entries in the "rtpengine" table are inserted or deleted, but new entries in the table aren't detected automatically. Is there a way to configure Kamailio to detect them? Thank you, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

4 5

Kamailio Redis integration
by Timothy Delin 28 Apr '25

28 Apr '25

Hey team, I am facing an issue where my Kamailio and Redis are not integrated. I am using a VM with RHEL 9 OS, Kamailio in 5.4.7 version, and Redis DB in 7.2.7 version. Both my Kamailio and Redia are using Docker. We have installed the libhiredis and the ndb_redis in Kamailio When we tried to do a simple print "Hello World" from the Redis in Kamailio, we are receiving this error "ERROR: could not open module, missing loadmodule" even though we have confirmed in kamcmd Best regards, Timothy

3 2

Authentication qop auth-int
by 13715209697＠139.com 28 Apr '25

28 Apr '25

Hello! Kamailio 5.7.6 Debian 10.12 Here is my authentication route: ``` route[AUTH] { if (is_method("REGISTER") || from_uri==myself) { if (!auth_check("$fd", "subscriber", "0")) { auth_challenge("$fd", "2"); # flag not 0 exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } ... } ``` start eyebeam Version 1.5.14.4 ``` eyebeam --->REGISTER ----> kamailio <--401 (WWW-Authenticate: Digest realm="192.168.3.10", nonce=..., qop="auth-int") --->REGISTER (Authorization: Digest username="08001",realm="192.168.3.10",nonce=...,uri=...,response=...,cnonce=...,nc=00000001,qop=auth-int,algorithm=MD5) <--401 (auth_challenge() return -2 ) ``` OpenSIPS 3.4.12 register to kamailio, got the same result as eyebeam Any suggestions? Thanks!

4 8

Re: SIP Call Drops After 0.32 Seconds – Asterisk on Kubernetes with Kamailio + RTPengine
by airsay＠duck.com 28 Apr '25

28 Apr '25

I will let the more experienced Kamailio folks comment on the technical/Kamailio/RTP modifications that you need to make. The SIP standard requires an ACK to a 200 OK to be sent within that 32 second window. If an ACK is not received, the session is torn down. You would need to do a packet capture to review the Contact header in the SIP and the c: in the SDP. I'm just getting bedded in with SIP, reading Alan B Johnston's "SIP: Understanding the Session Initiation Protocol". Excellent introduction to understanding SIP. Best regards Sent from my iPhone > On 23 Apr 2025, at 16:35, Fernando Lopes via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > Hello everyone, > I'm running into an issue with SIP calls in my current setup and would really appreciate some help. > > Setup: > I have a machine named sip00 (IP: 192.168.1.75) running Kamailio + RTPengine. > Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This IP points to another machine running Asterisk inside a Kubernetes cluster. > RTPengine is configured with an RTP port range of 10000–20000, and my router is set to allow that same range. > > Asterisk Kubernetes Service Configuration: > yaml > Copy > Edit > spec: > ports: > - name: tcp-port > protocol: TCP > port: 5060 > targetPort: 5060 > nodePort: 32210 > - name: udp-port > protocol: UDP > port: 5060 > targetPort: 5060 > nodePort: 32210 > > Problem: > When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190. > Everything seems fine initially, but at exactly 0.32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I'm still receiving and sending audio. Then, at around 01:04, I get a 408 Request Timeout. > > Questions: > Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well? > Why is Asterisk sending a BYE so early if audio is still flowing? > Could it be a signaling timeout or an issue with SIP dialog tracking? > Any help or pointers would be greatly appreciated! > > Thanks in advance! > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender!

5 4

Kamailio TLS Listener Not Binding to Port (5061 or 10061)
by steven.muchwe 28 Apr '25

28 Apr '25

Hello Kamailio Community, I’ve been troubleshooting an issue with Kamailio where the TLS listener fails to bind to any specified ports (5061, 10061, etc.), despite valid configurations and certificates. Here’s a summary of my setup and steps taken: 1. *Environment Details*: - Kamailio version: 5.7.4 - OpenSSL version: 3.0.13 - Operating System: Ubuntu (Noble Release) - TLS module (tls.so) is installed and loaded. 2. *Issue Details*: - Configurations validate successfully (config file ok). - OpenSSL works perfectly when testing certificates and keys with s_server, binding to ports (5061 and others). - Kamailio fails to bind TLS listeners (ss -tulnp shows no activity on the specified ports). 3. *Steps Already Taken*: - Simplified TLS configuration (minimal_tls.cfg) with: plaintext listen=tls:10.14.202.39:5061 loadmodule "tls.so" modparam("tls", "certificate", "/home/localtech/vicissl/868a963bc33d5eae.crt") modparam("tls", "private_key", "/home/localtech/vicissl/private.key") - Tested multiple ports (5061, 10061, 15061). - Checked firewall settings (iptables) and confirmed no restrictions. - Rebuilt Kamailio from source and ensured TLS modules are linked to OpenSSL. - Ran Kamailio with maximum debugging (-ddd) to examine logs—no binding-related errors appeared. 4. *Log Excerpts*: (Attach relevant logs showing TLS initialization or lack of binding activity.) 5. *Question*: What additional steps or configurations should I explore to resolve this issue? Could this be a compatibility problem between Kamailio 5.7.4 and OpenSSL 3.0.13? Any guidance or insights would be greatly appreciated! Best regards, Steven Muchwe Njoroge

2 1

Kamailio v6.0.1 and SUBSCRIBE processing
by Blair, Steve 26 Apr '25

26 Apr '25

I’m coming back to Kamailio after about a 10 year absence. I have v6.0.1 running handling registrations (unique devices) and inbound/outbound PSTN calling correctly. What I need is to process subscribe requests. I’m looking for direction on the correct configuration to 1. Authenticate subscribe messages. This appears to be working with following snippet. #eDevice: Need to authenticate subscribes before proceeding xlog("L_INFO", "eDevice: Start initial SUBSCRibe check. \n"); if (is_method("SUBSCRIBE")) { record_route(); if (!auth_check("$fd", "subscriber", "1")) { auth_challenge("$fd", "0"); } # eDevice SUB Change consume_credentials(); route(PRESENCE); } 1. After authenticating forward any subscribe to an external presence server 2. Relay any response from external presence server to client device. Only the above authentication is working so direction on proper processing of subscribes when Kamailio is not the presence server will be appreciated. Thanks

1 0

Re: RTPengine media starts for intiating caller only
by airsay＠duck.com 23 Apr '25

23 Apr '25

Again, not super skilled yet with Kamailio/RTPEngine, but my first instinct is: "why you are advertising myproxyname.domain.net which is possibly a public IP". Your entire setup is in your LAN so you don't need to advertise any public IP. Look forward to others contributing and clarifying that Sent from my iPhone > On 23 Apr 2025, at 20:42, smh2017--- via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > Hello, > > I have a problem with my basic Kamailio setup using RTPengine. I'm testing initially with two client UAs in the same LAN as the SIP server behind the firewall. The initiating UA starts the media proxy as soon as the receiving UA accepts the call, indicated by the call timer starting. But after accepting the call the receiving UA's timer doesn't start and after 10-15 secs hangs up with a NO ACK error message. > > I am using the kamailio default config file that comes with the Debian package and have made minimal changes recommended by various How-Tos for using Kamailio behind a firewall. Because the clients can successfully register over TLS, I'm assuming the problem is in the rtpengine configuration. The two rtp listen parameters I've tried are: > > interface = internal/192.168.1.100;external/192.168.1.100!myproxyname.domain.net > --or-- > interface = internal/192.168.1.100;external/myproxyname.domain.net > listen-ng = localhost:2223 > > I'm not sure why some example rtpengine configs list both the private and public addresses as external. > > Any suggestions where to start troubleshooting? > > Thanks, > > Steve > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender!

2 1

RTPengine media starts for intiating caller only
by smh2017＠zoho.com 23 Apr '25

23 Apr '25

Hello, I have a problem with my basic Kamailio setup using RTPengine. I'm testing initially with two client UAs in the same LAN as the SIP server behind the firewall. The initiating UA starts the media proxy as soon as the receiving UA accepts the call, indicated by the call timer starting. But after accepting the call the receiving UA's timer doesn't start and after 10-15 secs hangs up with a NO ACK error message. I am using the kamailio default config file that comes with the Debian package and have made minimal changes recommended by various How-Tos for using Kamailio behind a firewall. Because the clients can successfully register over TLS, I'm assuming the problem is in the rtpengine configuration. The two rtp listen parameters I've tried are: interface = internal/192.168.1.100;external/192.168.1.100!myproxyname.domain.net --or-- interface = internal/192.168.1.100;external/myproxyname.domain.net listen-ng = localhost:2223 I'm not sure why some example rtpengine configs list both the private and public addresses as external. Any suggestions where to start troubleshooting? Thanks, Steve

1 0

SIP Call Drops After 0.32 Seconds – Asterisk on Kubernetes with Kamailio + RTPengine
by Fernando Lopes 23 Apr '25

23 Apr '25

Hello everyone, I'm running into an issue with SIP calls in my current setup and would really appreciate some help. Setup: I have a machine named sip00 (IP: 192.168.1.75) running Kamailio + RTPengine. Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This IP points to another machine running Asterisk inside a Kubernetes cluster. RTPengine is configured with an RTP port range of 10000–20000, and my router is set to allow that same range. Asterisk Kubernetes Service Configuration: yaml Copy Edit spec: ports: - name: tcp-port protocol: TCP port: 5060 targetPort: 5060 nodePort: 32210 - name: udp-port protocol: UDP port: 5060 targetPort: 5060 nodePort: 32210 Problem: When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190. Everything seems fine initially, but at exactly 0.32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I'm still receiving and sending audio. Then, at around 01:04, I get a 408 Request Timeout. Questions: Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well? Why is Asterisk sending a BYE so early if audio is still flowing? Could it be a signaling timeout or an issue with SIP dialog tracking? Any help or pointers would be greatly appreciated! Thanks in advance!

1 0

404 sent from Kamailio NOT from the script
by Richard Robson 23 Apr '25

23 Apr '25

I have a problem where a call comes in and causing a 404 Not Found to be replied. the script does not have a 404 reply set in it anywhere unfortunately I cannot get the script to produce logs, hence my other post. But its making it tricky to find the source of the 404. following the script it should not be producing a 404, but doing a relay. I suspect there is something wrong with the tm or its not getting a result it needs. It looks like the transaction module is triggering thge 404 somehow and Its showing up in debug below. Does anyone have any ideas why i'm getting a 404? version 5.6.6 Regards, Richard Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1100]: t_check_msg(): msg (0x7faf977b64b0) id=4/28700 global id=3/28700 T start=0xffffffffffffffff Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:503]: t_lookup_request(): start searching: hash=60776, isACK=0 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:463]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-2e6a90ab-1bfb9be-d4ed8e5d-7f0300025430] Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:703]: t_lookup_request(): no transaction found Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1172]: t_check_msg(): msg (0x7faf977b64b0) id=4/28700 global id=4/28700 T end=(nil) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1394]: t_newtran(): msg (0x7faf977b64b0) id=4/28700 global id=4/28700 T start=(nil) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:503]: t_lookup_request(): start searching: hash=60776, isACK=0 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:463]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-2e6a90ab-1bfb9be-d4ed8e5d-7f0300025430] Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:703]: t_lookup_request(): no transaction found Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:385]: qm_malloc(): qm_malloc(0x7faf9301f000, 8336) called from tm: h_table.c: build_cell(336) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_hooks.c:342]: run_reqin_callbacks_internal(): trans=0x7faf932f42c0, callback type 1, id 0 entered Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:385]: qm_malloc(): qm_malloc(0x7faf9301f000, 40) called from tm: t_hooks.c: insert_tmcb(134) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1100]: t_check_msg(): msg (0x7faf977b64b0) id=4/28700 global id=4/28700 T start=0x7faf932f42c0 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1176]: t_check_msg(): T (0x7faf932f42c0) already found for msg (0x7faf977b64b0)! Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:385]: qm_malloc(): qm_malloc(0x7faf9301f000, 626) called from tm: t_reply.c: _reply_light(488) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_reply.c:1768]: cleanup_uac_timers(): RETR/FR timers reset Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_hooks.c:252]: run_trans_callbacks_internal(): DBG: trans=0x7faf932f42c0, callback type 512, id 0 entered Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} acc [acc_logic.c:721]: tmcb_func(): acc callback called for t(0x7faf932f42c0) event type 512, reply code 404 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_reply.c:625]: _reply_light(): reply sent out - buf=0x7faf977bf7f8: SIP/2.0 404 Not Foun... shmem=0x7faf932f0468: SIP/2.0 404 Not Foun Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_funcs.c:122]: put_on_wait(): put T [0x7faf932f42c0] on wait Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:495]: qm_free(): qm_free(0x7faf976b5010, 0x7faf977bf7f8), called from tm: t_reply.c: _reply_light(635) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_reply.c:636]: _reply_light(): finished Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} sl [sl.c:288]: send_reply(): reply in stateful mode (tm)

4 7

Kamailio docker with missing modules
by Martin Nyström 23 Apr '25

23 Apr '25

Hi, I’m using the docker ghcr.io/kamailio/kamailio:5.8.6-xenial but it appears to be missing the app_python modules. How can I add it, together with other missing modules? /M

1 2

Behaviour of suspended transactions
by Alex Balashov 18 Apr '25

18 Apr '25

Hello! Two questions about suspended transactions: 1) What is the lifetime of a suspended INVITE transaction? Can I change it? 2) While a transaction is suspended, its event hooks (e.g. onreply_route, failure_route) do not run, of course, even if replies that match the transaction are received. Is there a way to intercept these replies externally and resume the transaction upon the receipt of the reply, and prior to the processing of the reply? For example, can the replies be captured in a stateless route, and mapped Call-ID => index/label to t_continue() the transaction, then have the transaction state machine process that very same reply too? t_is_retr_async_reply() seems to hint at this intention, but its scope is more narrow, if I understood the documentation correctly: it seems to deal with retransmissions only. The code path I'm interested in is more akin to a t_is_reply_to_async() function. As you might guess, the driver for this inquiry is a mobile workflow where, in the vast majority of cases, one is contacting a stale registration and should just suspend the transaction, but where occasionally, in a small minority of cases, the endpoint does respond on the existing contact. The standard tsilo workflow of trickling parallel branches into a pending transaction doesn't work here because of the behaviour of Apple's CallKit; we have to try the existing contact _before_ we send a push notification. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 2

XLOG not writing to local0
by Richard Robson 17 Apr '25

17 Apr '25

I have setup the kamailio.log file to receive the logs from kamailio and I am receiving some, but I do mot see any logs from xlog commands in the script. I see logs like this on startup and various others, but none from xlog no matter how I format them. can anyone advise where I may be going wrong? current logs: Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 12 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 12 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 13 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 13 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 14 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 14 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9118]: INFO: jsonrpcs [jsonrpcs_sock.c:453]: jsonrpc_dgram_process(): a new child 0/9118 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9120]: INFO: ctl [io_listener.c:217]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) config: debug=4 log_stderror=no log_facility=LOG_LOCAL0 log_prefix="[$mt $hdr(CSeq) $ci] " example xlogs that do not print (they are the start of request route): xlog("LOG_LOCAL0","L_ERR","RIK: Start route\n"); xlog("TRACE: Start Route [Main] for [Call-ID: $ci]\n");

2 2

IPv6 bind wrong IP. #4199
by Vu Nguyen 17 Apr '25

17 Apr '25

*Dear Sir,* I have opened an issue on GitHub: *"IPv6 bind wrong IP. #4199 <https://github.com/kamailio/kamailio/issues/4199>"*. *System Details:* - *Kamailio (5.8.x)* – SIP Proxy - *FreeSWITCH* – Media Server - *OS* – Debian 12 - *Gateway* – aaaa:bbb:cccc:20::1 - *IPv6 Address* – aaaa:bbb:cccc:20::41e ------------------------------ *kamailio.cfg:* #!define ADDR_IPV4 xxx.xxx.xxx.xxx #!define ADDR_IPV6 [aaaa:bbb:cccc:20::41e] listen=ADDR_IPV4 listen=ADDR_IPV6 ------------------------------ *netstat Output:* tcp6 0 0 aaaa:bbb:cccc:20:::5060 :::* LISTEN 1691274/kamailio tcp6 0 0 aaaa:bbb:cccc:20:::5061 :::* LISTEN 1691274/kamailio udp6 0 0 aaaa:bbb:cccc:20:::5060 :::* 1691222/kamailio As shown, although I explicitly set the listen IP to aaaa:bbb:cccc:20::41e, Kamailio strips the last part of the address and binds to aaaa:bbb:cccc:20:: I also upgraded to *version 6.0* with default cfg and set auto_bind_ipv6=1 or changed ipv6 address, but the issue still persists. ------------------------------ *IPv6 Interface Configuration:* auto eth1 iface eth1 inet6 static address aaaa:bbb:cccc:20::41e netmask 64 gateway aaaa:bbb:cccc:20::1 I can successfully ping in and out using this IPv6 address. ------------------------------ Do I need to configure anything else in Kamailio or the system to ensure it binds to the full IPv6 address aaaa:bbb:cccc:20::41e as expected? Currently I can register with ipv4, but ipv6 does not. Thank you for your assistance.

3 2

Handling NAT Keepalive in IMS PCSCF Configuration: Bypassing NATHelper Module
by f.soltanzade72＠gmail.com 16 Apr '25

16 Apr '25

Hi All, In the default Kamailio configuration, keepalive handling for NAT is typically managed through the NATHelper module. However, in the IMS PCSCF configuration, the NATPING route is used to send SIP OPTIONS messages for keepalive, which bypasses the NATHelper module. This approach makes it impossible to send raw UDP packets for keepalive handling. Can any one help me configuring that? Thank you.

1 0

How to place a delay between cancelling branch and retrying next one on timer expiry?
by Alex A 15 Apr '25

15 Apr '25

Hi All, I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one. *Background: * Running Kamailio 5.6.x Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2 On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged… ) *Script config: * onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } } route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif } route[RELAY] { if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); } if (!t_relay()) { sl_reply_error(); } exit; } route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); } failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER"); } *Call Flows: * The above fix works well when an explicit error reply is received back. *error reply SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected. however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch I am looking to CANCEL branch0 before the sleep delay runs Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408). Any suggestions on how to handle this would be greatly appreciated. TIA

6 11

RTPEngine pool selection for in-dialog requests
by Ben Kaufman 15 Apr '25

15 Apr '25

I'm looking for information on the correct way to handle calls to RTPEngine when processing in-dialog requests. I currently have several setid's configured for varying usages. During processing of an initial INVITE, a determination is made as to if the call will require the use of RTPEngine, and if so, which of the sets should be used. The following is done in code: * setid is assigned to AVP $avp(rtpengine_pool_num) * set_rtpengine_set("$avp(rtpengine_pool_num)") is called, * rtpengine_offer is then called. * Additionally, a record-route parameter of proxy_media=yes is added. * The flag PROXY_MEDIA is set In the reply route, the PROXY_MEDIA flag is checked, and if set, set_rtpengine_set("$avp(rtpengine_pool_num)") is called, followed by rtpengine_answer. When handling an in-dialog message my code didn't have anything to evaluate for the setid. rtpengine_offer was just called. Looking at the debug from the rtpengine module, I can see that the record is found in the hashtable, however the node indicated in that result is not necessarily used - rtpengine will select an entry from the default setid instead. From the rtpengine module logs, IP addresses redacted: 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine_funcs.c:139]: check_content_type(): type <application/sdp> found valid 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:2249]: build_rtpp_socks(): same rtpengines list version: 1 (1744651613) 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3818]: select_rtpp_node_old(): rtpengine hash table lookup find node=udp:A.B.C.D:1234 for calllen=36 callid=ac66f56b-93f8-123e-1b99-0242ac120002 viabranch= 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3702]: select_rtpp_node_new(): sum is = 210 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3198]: rtpp_function_call(): proxy reply: d3:sdp288:v=0 o=FreeSWITCH 1744611570 1744611571 IN IP4 W.X.Y.Z s=FreeSWITCH c=IN IP4 W.X.Y.Z My question is really: **SHOULD** rtpengine_offer (and rtpengine_manage, etc) use the node that it finds in the hash table lookup automatically, or should I have to explicitly set the setid? For now I've solved the problem by adding the setid to the record-route headers so I can easily retrieve it in dialog, but it seems that if the module finds a record for a node that there should be some way to rely on that explicitly. Kaufman Senior Voice Engineer E: bkaufman(a)bcmone.com SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us> [img]<https://www.siptrunk.com> [img]<https://www.flowroute.com> NOTE: This e-mail and any attachments are from BCM One, Inc. and are intended solely for the use and review of the individual(s) to whom it is addressed. If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail (and any attachments) from your computer and do not copy or disclose it to anyone else.

2 2

Thank you Guys
by Fernando Lopes 15 Apr '25

15 Apr '25

Just want to say thank you for the support. I spent two weeks working on a config, and even though it didn’t work out, I really appreciate the learning process. Today, I found a config that worked here: 🔗 https://github.com/altanai/kamailioexamples/tree/master/RTPEngine_media_pro…

1 0

Nat Problems Kamailio
by Fernando Lopes 14 Apr '25

14 Apr '25

Hello Everyone, I'm having some trouble getting my SIP setup to work properly. 📞 My Call Flow: SIP Client initiates a call The call reaches my router, which forwards it to Kamailio + RTPengine running on 192.168.1.75:5060, which then forwards it to A Kubernetes machine at 192.168.1.190:32210, where Asterisk is running 🔧 Network Setup: Router has the following ports forwarded: UDP 5060 UDP 10000–20000 (for RTP) STUN is enabled on the SIP client ✅ What Works: When I’m connected through a VPN (i.e., inside the local network), everything works fine — both incoming and outgoing audio. ❌ The Problem: When calling from outside the network, signaling works and the call connects, but I can’t receive or send any audio. Here is a little of my config of kamailio modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223") modparam("rtpengine", "setid_avp", "$avp(setid)") listen=udp:192.168.1.75:5060 advertise 62.2x.xxx.xxx:5060 listen=tcp:192.168.1.75:5060 advertise 62.2x.xxx.xxx:5060 listen=udp:127.0.0.1:5060 #Nat Helper modparam("nathelper", "force_socket", "192.168.1.75:5060") modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 0) modparam("nathelper", "nat_addr_mode", 1) request_route{ ... route(init); ... if(is_method("INVITE|ACK|BYE|CANCEL|OPTIONS|INFO|UPDATE|PRACK"))\{ route(handle_sip); exit; } } route[init]{ ... if (nat_uac_test("19")){ setflag(FLT_NAT); fix_nated_contact(); force_rport(); } } route[handle_sip]{ if ($rm == "INVITE"){ if (isflagset(FLT_NAT)){ route(natmanage); } if (!ds_select_dst("1", "4")){ sl_send_reply("500", "No destination"); exit; } $ru = "sip:" + $rU + "@" + $rd; # Keeps sip:100@domain $du = "sip:192.168.1.190:32210"; # Matches your dispatcher list route(relay); } if ($rm == "BYE" || $rm == "CANCEL"){ if (isflagset(FLT_NAT)){ rtpengine_delete(); } route(relay); } if ($rm == "ACK"){ if (isflagset(FLT_NAT)){ route(natmanage); } route(relay); } route(relay); } route[natmanage]{ if (is_request()){ if (has_body("application/sdp")){ rtpengine_offer("replace-origin replace-session-connection ICE=remove"); } force_rport(); fix_nated_contact(); }else{ rtpengine_answer("replace-origin replace-session-connection ICE=remove"); } } rtpengine.conf [rtpengine] table = 0 interface = internal/192.168.1.75 listen-ng = 127.0.0.1:2223 log-level = 7 timeout = 60 silent-timeout = 3600 tos = 184 port-min = 10000 port-max = 40000 And here are some logs when I call from outside 2025/04/13 15:58:33.407265 2.8x.xx.xxx:59396 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.116:59396;rport;branch=z9hG4bKPj92490d6b6d0c4cd88dac9f0043b1642e Max-Forwards: 70 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@192.168.1.116:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8963 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.5 Content-Type: application/sdp Content-Length: 537 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.116 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4032 RTP/AVP 8 0 101 c=IN IP4 192.168.1.116 b=TIAS:64000 a=rtcp:4017 IN IP4 192.168.1.116 a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1567952351 cname:73284f1717045a81 a=ice-ufrag:37e51dc0 a=ice-pwd:49f7442b5078148140877b44 a=candidate:Hc0a80174 1 UDP 2130706431 192.168.1.116 4032 typ host a=candidate:Hc0a80174 2 UDP 2130706430 192.168.1.116 4017 typ host 2025/04/13 15:58:33.412683 192.168.1.75:5060 -> 192.168.1.190:32210 INVITE sip:100@192.168.1.75 SIP/2.0 Via: SIP/2.0/UDP 62.2x.2xx.xxx:5060;branch=z9hG4bK6362.26a75297a4ccf4984dd1f68644c2148f.0 Via: SIP/2.0/UDP 192.168.1.116:59396;received=2.8x.xx.xxx;rport=59396;branch=z9hG4bKPj92490d6b6d0c4cd88dac9f0043b1642e Max-Forwards: 69 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@2.8x.xx.xxx:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8963 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.5 Content-Type: application/sdp Content-Length: 322 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.75 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 12156 RTP/AVP 8 0 101 c=IN IP4 192.168.1.75 b=TIAS:64000 a=ssrc:1567952351 cname:73284f1717045a81 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:12157 2025/04/13 15:58:33.428169 2.8x.xx.xxx:59396 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.116:59396;rport;branch=z9hG4bKPj14c6f24b814e4d158014cc80b1fa5f8f Max-Forwards: 70 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@192.168.1.116:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8964 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.5 Authorization: Digest username="6005", realm="asterisk", nonce="1744559913/dab8894e3f31e038d7a969a6349a11c2", uri="sip:100@62.2x.2xx.xxx", response="2ce500d6a1583f05f6344bdf1f712fc7", algorithm=MD5, cnonce="808fc766135d40589dd68032bcaab5c6", opaque="2232aa9c42080f12", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 537 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.116 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4032 RTP/AVP 8 0 101 c=IN IP4 192.168.1.116 b=TIAS:64000 a=rtcp:4017 IN IP4 192.168.1.116 a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1567952351 cname:73284f1717045a81 a=ice-ufrag:37e51dc0 a=ice-pwd:49f7442b5078148140877b44 a=candidate:Hc0a80174 1 UDP 2130706431 192.168.1.116 4032 typ host a=candidate:Hc0a80174 2 UDP 2130706430 192.168.1.116 4017 typ host 2025/04/13 15:58:33.430593 192.168.1.75:5060 -> 2.8x.xx.xxx:59396 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.1.116:59396;rport=59396;branch=z9hG4bKPj14c6f24b814e4d158014cc80b1fa5f8f;received=2.8x.xx.xxx From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8964 INVITE Server: kamailio (5.7.4 (x86_64/linux)) Content-Length: 0 2025/04/13 15:58:33.461894 192.168.1.75:5060 -> 192.168.1.190:32210 INVITE sip:100@192.168.1.75 SIP/2.0 Via: SIP/2.0/UDP 62.2x.2xx.xxx:5060;branch=z9hG4bK3362.72f5db87deeeccee7fea924753af3da0.0 Via: SIP/2.0/UDP 192.168.1.116:59396;received=2.8x.xx.xxx;rport=59396;branch=z9hG4bKPj14c6f24b814e4d158014cc80b1fa5f8f Max-Forwards: 69 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@2.8x.xx.xxx:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8964 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.5 Authorization: Digest username="6005", realm="asterisk", nonce="1744559913/dab8894e3f31e038d7a969a6349a11c2", uri="sip:100@62.2x.2xx.xxx", response="2ce500d6a1583f05f6344bdf1f712fc7", algorithm=MD5, cnonce="808fc766135d40589dd68032bcaab5c6", opaque="2232aa9c42080f12", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 322 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.75 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 12156 RTP/AVP 8 0 101 c=IN IP4 192.168.1.75 b=TIAS:64000 a=ssrc:1567952351 cname:73284f1717045a81 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:12157 Please Help me, Thank you.

4 8

TCP timeout
by Pyry Aaltonen 11 Apr '25

11 Apr '25

Hello, I´ve googled around about tcp timeout in kamailio tcp connections when the tcp connection is broken. Found this old question and to me it feels like I’m having that same situation as original question https://www.mail-archive.com/sr-users@lists.kamailio.org/msg15020.html Also found this https://kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kamailio.org/thr… and it seems to be the same description pretty much that I´m seeing. When the tcp connection (or tls) is interrupted in the network it takes around 15min for kamailio to reset the outgoing tcp connection. I see in the logs that when restarting kamailio process it logs 2025-03-27 12:25:18.697 { "level": "INFO", "module": "core", "file": "core/tcp_main.c", "line": 3282, "function": "tcp_init", "logprefix": "", "message": "Set TCP_USER_TIMEOUT=10000 ms" } So I think the fix from this https://github.com/kamailio/kamailio/commit/d893f3af1444c8c4c5db6cd53fb5777… is applied. This is tested with 5.8.5 and I have tested this by setting up with dispatcher tcp connection to external host Then with iptables drop traffic to that host, waiting kamailio to notice that destination is down, removing the iptables input and it takes around 15min to recover. (also restarting the kamailio helps and resolves the connection) And this is what kamailio prints during the test: Apr 4 08:29:15 kamailio[156947]: { "level": "ERROR", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": "", "message": "Destination down: OPTIONS sip:ext-host;transport=tcp (<null>)" } Apr 4 08:44:43 kamailio[156957]: { "level": "ERROR", "module": "core", "file": "core/tcp_read.c", "line": 267, "function": "tcp_read_data", "logprefix": "", "message": "error reading: Connection timed out (110) ([]:5060 -> []:47492)" } Apr 4 08:44:43 kamailio[156957]: { "level": "ERROR", "module": "core", "file": "core/tcp_read.c", "line": 1524, "function": "tcp_read_req", "logprefix": "", "message": "error reading - c: 0x7f8625dea9b0 r: 0x7f8625deaad8 (-1)" } Apr 4 08:45:05 kamailio[156957]: { "level": "ERROR", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": "Source:[ext-host]:5060, Call-id:4d0e1ccd315c817f-156947@int-host, CSeq:10", "message": "Destination up: OPTIONS sip:ext.host;transport=tcp (<null>)" } Any advice how to lower the timeout to be quicker in such event? -Pyry

5 6

leave
by Mihail D. 11 Apr '25

11 Apr '25

leave

1 0

STUN Server vs. NAT Configuration with Kamailio + RTPengine Setup
by Fernando Lopes 11 Apr '25

11 Apr '25

Previous Thread: https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… Hello everyone, Should I use a STUN server, or can I just configure NAT properly? Here’s my current setup: arduino Copy Edit Router (NAT device) ↓ Kamailio + RTPengine machine ↓ Virtual machine running Kubernetes ↓ Asterisk container Kamailio and RTPengine are sitting behind the NAT (the router), and they handle SIP and media. Do I need a STUN server in this case, or can I manage everything with NAT configuration alone? And what is the better approach? Any insights or best practices would be appreciated! Thank you.

2 1

IPv6 bind wrong IP. #4199
by vunm.allsign＠gmail.com 11 Apr '25

11 Apr '25

Hi guys, I opened issue on github: https://github.com/kamailio/kamailio/issues/4199 - Description: Kamailio (5.8.x): SIP proxy FreeSWITCH: Media - OS: Debian 12 gateway: aaaa:bbb:cccc:20::1 ipv6: aaaa:bbb:cccc:20::41e - kamailio.cfg: #!define ADDR_IPV4 xxx.xxx.xxx.xxx #!define ADDR_IPV6 [aaaa:bbb:cccc:20::41e] listen=ADDR_IPV4 listen=ADDR_IPV6 - I execute netstat -nlutp: tcp6 0 0 aaaa:bbb:cccc:20:::5060 :::* LISTEN 1691274/kamailio tcp6 0 0 aaaa:bbb:cccc:20:::5061 :::* LISTEN 1691274/kamailio udp6 0 0 aaaa:bbb:cccc:20:::5060 :::* 1691222/kamailio Why I set listen ip is aaaa:bbb:cccc:20::41e but kamailio stripped the last part of the address aaaa:bbb:cccc:20:: I have tried many ways but it does not work.Is there any additional configuration required regarding the Debian network interface? - Here is interfaces(of course i can ping from/to ipv6 address): # Additional interfaces, just in case we're using # multiple networks allow-hotplug eth1 iface eth1 inet6 static address aaaa:bbb:cccc:20::41e netmask 64 gateway aaaa:bbb:cccc:20::1 autoconf 0 Thank you.

2 1

Load multiple geoip2 databases (City + ASN)
by Joel Serrano 10 Apr '25

10 Apr '25

Hi guys, Is there a way to have multiple geoip2 databases loaded into Kamailio and then point the geoip2_match to them? If I understand correctly the docs I can only load one: https://www.kamailio.org/docs/modules/6.0.x/modules/geoip2.html#geoip2.p.pa… Is my assumption correct? Thanks, Joel.

3 5

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