June 2026 - sr-dev - kamailio.org

[kamailio/kamailio] IMS_REGISTRAR_PCSCF: Features-Device-specific call routing (GRUU),Multiple phone numbers per user, Barred identity, Reliable return path to the user handling, Survives restarts (PR #4784)
by Harish S 14 Jul '26

14 Jul '26

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] Code is formatted with `clang-format` using the config file `.clang-format` from source code folder - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  ###Features added 1. Device-specific call routing (GRUU) — The proxy can route calls to one specific phone or app on a user’s account, instead of ringing every registered device. Standards: RFC 5627, 3GPP TS 24.229, 3GPP TS 23.228 2. Multiple phone numbers per user — Supports IMS users who have several public identities (e.g. a SIP address and a mobile number). Calls to any of those identities find the right registration. Standards: 3GPP TS 23.228, 3GPP TS 23.003, 3GPP TS 24.229, RFC 3966 3. Barred identity handling — Remembers which identities are “barred” (not allowed for certain services) and keeps that list updated when the network sends notifications. Standards: 3GPP TS 24.229, 3GPP TS 23.008, RFC 3680 4. Reliable return path to the user — Stores the routing path from registration so the proxy can reach the user correctly when someone calls them (mobile-terminated traffic).Standards: RFC 3327, 3GPP TS 24.229,RFC 3608 5. Survives restarts — GRUU and related registration data are saved in the database, so registrations are not lost after a server restart or reload. 3GPP TS 23.228, 3GPP TS 24.229, 3GPP TS 33.203 You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4784 -- Commit Summary -- * lib: srdb1 - add GRUU fields to pcscf location schema * ims_usrloc_pcscf: GRUU storage, multi-IMPU lookup and path persistence * ims_registrar_pcscf: GRUU lookup, NOTIFY sync and Path write-back * test: add P-CSCF GRUU verification tests [skip ci] * ims_registrar_pcscf: restore admin XML docs removed by mistake -- File Changes -- M .gitignore (2) M src/lib/srdb1/schema/kamailio-ims_usrloc_pcscf.xml (1) M src/lib/srdb1/schema/location_pcscf.xml (38) A src/lib/srdb1/schema/pcscf_temp_gruu_history.xml (69) M src/modules/ims_registrar_pcscf/doc/ims_registrar_pcscf_admin.xml (49) A src/modules/ims_registrar_pcscf/gruu.c (243) A src/modules/ims_registrar_pcscf/gruu.h (38) M src/modules/ims_registrar_pcscf/ims_registrar_pcscf_mod.c (10) M src/modules/ims_registrar_pcscf/ims_registrar_pcscf_mod.h (1) M src/modules/ims_registrar_pcscf/notify.c (285) A src/modules/ims_registrar_pcscf/path.c (51) A src/modules/ims_registrar_pcscf/path.h (11) M src/modules/ims_registrar_pcscf/save.c (47) A src/modules/ims_usrloc_pcscf/impu_match.c (62) A src/modules/ims_usrloc_pcscf/impu_match.h (27) M src/modules/ims_usrloc_pcscf/ims_usrloc_pcscf_mod.c (3) M src/modules/ims_usrloc_pcscf/pcontact.c (20) A src/modules/ims_usrloc_pcscf/pcontact_index.c (342) A src/modules/ims_usrloc_pcscf/pcontact_index.h (56) A src/modules/ims_usrloc_pcscf/pcontact_serialize.c (87) A src/modules/ims_usrloc_pcscf/pcontact_serialize.h (11) A src/modules/ims_usrloc_pcscf/pcscf_db_layout.h (16) A src/modules/ims_usrloc_pcscf/timer.c (17) M src/modules/ims_usrloc_pcscf/udomain.c (534) M src/modules/ims_usrloc_pcscf/udomain.h (8) M src/modules/ims_usrloc_pcscf/ul_rpc.c (146) M src/modules/ims_usrloc_pcscf/usrloc.c (6) M src/modules/ims_usrloc_pcscf/usrloc.h (28) M src/modules/ims_usrloc_pcscf/usrloc_db.c (236) M src/modules/ims_usrloc_pcscf/usrloc_db.h (20) A test/modules/ims_registrar_pcscf/.gitignore (8) A test/modules/ims_registrar_pcscf/Makefile (24) A test/modules/ims_registrar_pcscf/integrate_gruu.sh (126) A test/modules/ims_registrar_pcscf/kamailio_gruu_e2e.cfg (54) A test/modules/ims_registrar_pcscf/sipp/invite_gruu.xml (32) A test/modules/ims_registrar_pcscf/sipp/register_gruu.xml (22) A test/modules/ims_registrar_pcscf/test_common.h (47) A test/modules/ims_registrar_pcscf/test_gruu_extract.c (164) A test/modules/ims_registrar_pcscf/test_path_build.c (37) A test/modules/ims_usrloc_pcscf/.gitignore (12) A test/modules/ims_usrloc_pcscf/Makefile (30) A test/modules/ims_usrloc_pcscf/integrate_sqlite.sh (192) A test/modules/ims_usrloc_pcscf/kamailio_integ.cfg (33) A test/modules/ims_usrloc_pcscf/kamailio_nodb.cfg (28) A test/modules/ims_usrloc_pcscf/sql/seed_gruu.sql (46) A test/modules/ims_usrloc_pcscf/test_common.h (22) A test/modules/ims_usrloc_pcscf/test_db_layout.c (24) A test/modules/ims_usrloc_pcscf/test_impu_match.c (114) A test/modules/ims_usrloc_pcscf/test_parse_uri_stub.c (43) A test/modules/ims_usrloc_pcscf/test_pcontact_index.c (63) A test/modules/ims_usrloc_pcscf/test_pcontact_serialize.c (90) A test/modules/ims_usrloc_pcscf/test_temp_gruu_lru.c (66) A test/modules/verify_gruu.sh (31) M utils/kamctl/db_redis/kamailio/pcscf_location (4) A utils/kamctl/db_redis/kamailio/pcscf_temp_gruu_history (2) M utils/kamctl/db_sqlite/ims_usrloc_pcscf-create.sql (23) M utils/kamctl/dbtext/kamailio/pcscf_location (2) A utils/kamctl/dbtext/kamailio/pcscf_temp_gruu_history (2) M utils/kamctl/mongodb/kamailio/pcscf_location.json (24) A utils/kamctl/mongodb/kamailio/pcscf_temp_gruu_history.json (31) M utils/kamctl/mysql/ims_usrloc_pcscf-create.sql (23) M utils/kamctl/oracle/ims_usrloc_pcscf-create.sql (31) M utils/kamctl/postgres/ims_usrloc_pcscf-create.sql (23) M utils/kamctl/xhttp_pi/ims_usrloc_pcscf-mod (56) M utils/kamctl/xhttp_pi/ims_usrloc_pcscf-table (14) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4784.patch https://github.com/kamailio/kamailio/pull/4784.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4784 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4784(a)github.com>

3 4

[kamailio/kamailio] ims_rdn: new experimental module for IMS RDNs (PR #4786)
by luca-nardin-kontron 14 Jul '26

14 Jul '26

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] Code is formatted with `clang-format` using the config file `.clang-format` from source code folder - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  We (Kontron Transportation) are issuing this pull request with a new experimental module, which is called ims_rdn, hopeful that this module might be useful for at least some users of Kamailio IMS (I-CSCF and S-CSCF). This module is most useful for terminating unregistered services that are triggered by the I/S-CSCF and that are identified by hierarchical address ranges of E.164 addresses and of EIRENE addresses (in the Request-URI), not unlike wildcarded PSIs. By configuring these address ranges at the I/S-CSCF, one can save one SAR/SAA exchange with the HSS per call. EIRENE addresses are railway specific telephone numbers, which have been defined by the UIC. This explains the name of the module RDN = Railway Dedicated Networks. Additionally, this module defines kamailio transformations, which are tailored for the use in RDNs, e.g. for the transformation of functional numbers and of MCData SDS into instant messages and vice versa. This module is even more useful, when implementing an IWF according to ETSI TS 103 792, in which case some specific routing scripts will be needed. We will be glad to help with those. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4786 -- Commit Summary -- * ims_rdn: new experimental module for IMS RDNs -- File Changes -- A src/modules/ims_rdn/Makefile (40) A src/modules/ims_rdn/README (600) A src/modules/ims_rdn/doc/Makefile (8) A src/modules/ims_rdn/doc/ims_rdn.xml (86) A src/modules/ims_rdn/doc/ims_rdn_admin.xml (709) A src/modules/ims_rdn/ims_rdn.c (2327) A src/modules/ims_rdn/ims_rdn.h (191) A src/modules/ims_rdn/rdn_trans.c (847) A src/modules/ims_rdn/rdn_trans.h (93) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4786.patch https://github.com/kamailio/kamailio/pull/4786.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4786 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4786(a)github.com>

3 4

[kamailio/kamailio] htable dmqreplicate=1 causes all AVP to be deleted (Issue #4760)
by Benoît Panizzon 14 Jul '26

14 Jul '26

hb9eue created an issue (kamailio/kamailio#4760) Hi @miconda and @abalashov Issue as described in [SR-Users]: All AVP get deleted when a htable entry is added which is to be replicated to a peer via dmq. When dmqreplicate is set to 0 the issue does not happen. The issue is present no matter if the DMQ peer is reachable or not. Running Kamailio 6.1.2 from the Kamailo Repo for Ubuntu Noble. Issue was not observed with Kamailio 5.8 not tested with 6.0. Config to reproduce: ``` modparam("htable", "htable", "custprof=>size=8;autoexpire=3600;dmqreplicate=1") xlog("L_INFO", "0 testing is not yet set, value: $avp(testing) \n"); $avp(testing) = "I am a value"; xlog("L_INFO", "1 testing has value: $avp(testing) \n"); avp_print(); $sht(custprof=>"HTKEY") = "HTVALUE"; xlog("L_INFO", "2 testing has value: $avp(testing) \n"); avp_print(); xlog("L_INFO", "After avp_print\n"); ``` Log Output showing Issue: ``` 517228636 INVITE]<script>: 0 testing is not yet set, value: <null> 517228636 INVITE]<script>: 1 testing has value: I am a value 517228636 INVITE]avpops [avpops_impl.c:1333]: ops_print_avp(): p=0x7e27041e94b0, flags=0x0113 517228636 INVITE]avpops [avpops_impl.c:1336]: ops_print_avp(): #011#011#011name=<testing> 517228636 INVITE]avpops [avpops_impl.c:1342]: ops_print_avp(): #011#011#011val_str=<I am a value / 12> 517228636 INVITE]avpops [avpops_impl.c:1333]: ops_print_avp(): p=0x7e27041e7d20, flags=0x0113 [...] 517228636 INVITE]<script>: 2 testing has value: <null> 517228636 INVITE]<script>: After avp_print ``` After: $sht(custprof=>"HTKEY") = "HTVALUE"; there are not a single AVP remaining to be printed. debug level 3 shows xavp_destroy_list() being called a lot, possibly for each AVP? -Benoît- -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4760 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4760(a)github.com>

3 11

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 10 Jul '26

10 Jul '26

### Description We are using Kamailio 5.7.4 on Debian 12 (from http://deb.kamailio.org/kamailio57) with rtpengine as an Edgeproxy for our clients. The instance terminates SIP/TLS (with Cliencertificates) and forwards the SIP Traffic to internal systems. After some days we are getting errors like this `tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=7318616 threshold1=8912896` First we thought Kamailio just doesnt have enough memory, so we doubled it.. But after some days the Logmessage (and Userissues) occured again. So we monitored the shmmem statistics and found that used and max_used are constantly growing til it reaches the limit. As i mentioned we are using client-certificates and so we are also using the CRL feature. We do have a systemd-timer which fetches the CRL every hour and runs 'kamcmd tls.reload' when finished. Our tls.cfg looks like this: ``` [server:default] method = TLSv1.2+ private_key = /etc/letsencrypt/live/hostname.de/privkey.pem certificate = /etc/letsencrypt/live/hostname.de/fullchain.pem ca_list = /etc/kamailio/ca_list.pem ca_path = /etc/kamailio/ca_list.pem crl = /etc/kamailio/combined.crl.pem verify_certificate = yes require_certificate = yes [client:default] verify_certificate = yes require_certificate = yes ``` After testing a bit we found that every time tls.reload is executed Kamailio consumes a bit more memory which eventually leads to all the memory being consumed which leads to issues for our users. See following example: ``` [0][root@edgar-dev:~]# while true ; do /usr/sbin/kamcmd tls.reload ; /usr/sbin/kamcmd core.shmmem ; sleep 1 ; done Ok. TLS configuration reloaded. { total: 268435456 free: 223001520 used: 41352552 real_used: 45433936 max_used: 45445968 fragments: 73 } Ok. TLS configuration reloaded. { total: 268435456 free: 222377960 used: 41975592 real_used: 46057496 max_used: 46069232 fragments: 78 } Ok. TLS configuration reloaded. { total: 268435456 free: 221748664 used: 42604992 real_used: 46686792 max_used: 46698080 fragments: 77 } Ok. TLS configuration reloaded. { total: 268435456 free: 221110832 used: 43242408 real_used: 47324624 max_used: 47335608 fragments: 81 } ^C [130][root@edgar-dev:~]# ``` ### Troubleshooting #### Reproduction Everytime tls.reload is called the memory consumptions grows.. #### Debugging Data  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### Log Messages  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### SIP Traffic SIP doesnt seem to be relevant here ### Possible Solutions Calling tls.reload less often or restart kamailio before memory is consumed ;) ### Additional Information ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` * Debian GNU/Linux 12 (bookworm) * Linux edgar-dev 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3823 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3823(a)github.com>

12 55

[kamailio/kamailio] Contact mode 3 naming logic is inverted in respect to contact mode 2 (Issue #4725)
by Matteo 08 Jul '26

08 Jul '26

xadhoom created an issue (kamailio/kamailio#4725)  ### Description The new contact mode introduced in https://github.com/kamailio/kamailio/commit/8fed4c27a323e3b7fdc61381e06ac26… has an "inverted" logic regarding A/B naming (downstream/upstream) directions. In contact_mode 2: xavu_field_a_contact and xavu_field_b_contact refers to the downstream / upstream direction. In contact mode 3: xavu_field_a_contact_host and xavu_field_b_contact_host refers to the upstream / downstream direction, which is the opposite of the previous. While you cannot use 2&3 at same time (...for now) I think proper naming helps in understanding. Probably this cannot fixed anymore, but maybe worth documenting this behaviour? ### Possible Solutions At least add documentation for that difference. Ideally the meaning of A/B should be aligned. ### Additional Information * **Kamailio Version** ``` 6.1.x ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4725 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4725(a)github.com>

3 2

[kamailio/kamailio] rtpengine: update documentation for rtp_inst_pvar variable (PR #4558)
by Michal Popovič 08 Jul '26

08 Jul '26

#### Type Of Change - [X] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Variable rtp_inst_pvar stores URI which can be IP address and port or DNS name or port. Description is getting false sense that this variable holds IP address received by RTPengine NG protocol. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4558 -- Commit Summary -- * rtpengine: update documentation for rtp_inst_pvar variable -- File Changes -- M src/modules/rtpengine/doc/rtpengine_admin.xml (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4558.patch https://github.com/kamailio/kamailio/pull/4558.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4558 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4558(a)github.com>

6 5

[kamailio/kamailio] Kamailio change rtpengine after reINVITE (Issue #4756)
by Jakihiko 07 Jul '26

07 Jul '26

Jakihiko created an issue (kamailio/kamailio#4756) I am encountering an issue regarding how Kamailio handles rtpengine node failures mid-call, and I would like to clarify the expected behavior. The Scenario: I have a setup with multiple rtpengines (e.g., 4 nodes) all configured in the same pool with setid=0. 1. An initial INVITE arrives, and Kamailio successfully selects **rtpengine-A** for the call. 2. Later in the dialog, a re-INVITE occurs. 3. Coincidentally, **rtpengine-A** is unavailable at that exact moment. 4. Kamailio then automatically switches to a different rtpengine node in the set, eg: **rtpengine-B** The Question: Based on my reading of an older issue ([#2713](https://github.com/kamailio/kamailio/issues/2713)), my understanding was that Kamailio should not change the rtpengine node mid-call, as a new node will not have the media state for the ongoing session. Could you please confirm if my understanding is correct, or if Kamailio’s default failover behavior for mid-call transactions has changed recently? Note: I don't setup or trying to do anything with High availability. All rtpengine are run independently without knowing others -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4756 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4756(a)github.com>

4 5

[kamailio/kamailio] Grumvalski/jwt3 verify key imprv (PR #4797)
by Federico Cabiddu 06 Jul '26

06 Jul '26

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [x] Code is formatted with `clang-format` using the config file `.clang-format` from source code folder - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Few small improvements on the jwt3 module mostly over jwt3_verify_key function: - added CMakeList.txt file - add RSA support in PEM->JWK conversion - fallback to first key when kid not found in static JWKS (the same fallback as for jwt3_verify() I've also noticed that jwt3 module is not in https://kamailio.org/docs/modules/devel/index.html. Can we add it there? You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4797 -- Commit Summary -- * jwt3: add CMakeLists.txt for cmake build support * jwt3: add RSA key support in PEM-to-JWKS conversion * jwt3: support inline JWKS JSON string as key parameter * jwt3: fall back to first key when kid not found in static JWKS -- File Changes -- A src/modules/jwt3/CMakeLists.txt (13) M src/modules/jwt3/jwt3_mod.c (133) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4797.patch https://github.com/kamailio/kamailio/pull/4797.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4797 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4797(a)github.com>

2 8

[kamailio/kamailio] Allow customizing the contact user in uac reg requests (Issue #4653)
by Flavio Grossi 04 Jul '26

04 Jul '26

flaviogrossi created an issue (kamailio/kamailio#4653) ### Description Currently the uac module uses the value of the `l_uuid` variable as the user part in the contact header for the REGISTER request. Some providers, especially when registering trunks, requires the user part to be the registration username though, and, while it is possible to do it using the config, it may get cumbersome and error prone to remap the contact back in the reply. ### Expected behavior To be able to customize the contact in the register #### Actual observed behavior The register hardcodes the `l_uuid` value in the register, see [here](https://github.com/kamailio/kamailio/blob/d9a05f9781d2d9cddf485e938ea… This causes the registration to never be in the registered status when it is queried via the reg_dump rpc, unless the contact is rewritten via config both in the request (to make the SIP provider happy) and in the reply (to replace it back to use the uuid so that the check [here](https://github.com/kamailio/kamailio/blob/d9a05f9781d2d9cddf485e938ea… matches). ### Possible Solutions I'm currently testing a patch which: - adds an optional new field `contact_user` which, if present, is used in the contact user part instead of the uuid; - adds to the outgoing REGISTER the contact parameter `line=<l_uuid>` (only when `contact_user` is configured, returns an error if `contact_addr` already contains a line parameter to avoid it to be silently overwritten) - the REGISTER reply match is extended to check the uuid in the line parameter instead of the user part (only if `contact_user` is configured) to select the correct binding. This means that if the new parameter is configured, the contact will be in the form `sip:<contact_user>@<contact_addr>;line=<l_uuid>`. If not, the usual `sip:<l_uuid>@<contact_addr>` is sent. This should allow the new feature while also being retro compatible. Do you think this is correct? Any feedback? If it is, i can send a PR for review. ### Additional Information This applies to the latest develop version of kamailio and is OS independent -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4653 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4653(a)github.com>

5 8

[kamailio/kamailio] Runtime addition of SIP listen interfaces via kamcmd (Issue #4772)
by ahbresaa 04 Jul '26

04 Jul '26

ahbresaa created an issue (kamailio/kamailio#4772)  ### Description Kamailio currently requires a restart when adding new transport listeners (listen= lines). This makes dynamic operational changes in production environments difficult or risky. This feature request proposes enabling runtime addition of SIP listen sockets via kamcmd, without restarting Kamailio or disrupting existing traffic. Proposed command example: ``` text kamcmd core.add_listen 192.168.10.10 5070 udp ``` Use Cases This capability would be useful in production environments where downtime is unacceptable or where SIP topology changes frequently. Other examples include: - Dynamic SIP trunk onboarding - Moving traffic gradually from one IP to another without restart. - Dynamically assigning per-customer SIP listeners. - Cloud / autoscaling environments - Maintenance operations - Temporarily adding listeners for testing or debugging without reload cycles.  ### Expected behavior - Kamailio accepts a runtime command via kamcmd. - A new listener is created and bound immediately. - All worker processes become aware of the new socket and are able to send SIP traffic on it. - No restart or full reload is required. - Existing traffic is unaffected. ### Actual observed behavior Kamailio does not currently support runtime modification of listening sockets. Changes to 'listen=' require restart. ### Possible Solutions  To support runtime addition of listeners, a coordinated multi-process update mechanism is required: 1. IPC mechanism - Introduce IPC between main process and workers (e.g., Unix domain socket). - Workers must be notified when a new endpoint added(e.g. epoll, singal, ...). 2. Socket distribution - Main process creates new socket. - File descriptor is passed to worker processes using SCM_RIGHTS. 3. Runtime state update - Update internal structures(udp_listen, tcp_listen, ...) While investigating the TCP transport implementation, I observed that Kamailio already uses a multi-process TCP architecture with a dedicated TCP main process and worker processes, communicating via Unix domain sockets and SCM_RIGHTS file descriptor passing(src/core/pass_fd). ### Concerns Modules and parts such as: - counters/stats(dns, blocklist, ...) - topoh - rr - path - NAT handling logic - ... may assume static transport bindings. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4772 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4772(a)github.com>

2 1