- sr-dev - kamailio.org

[kamailio/kamailio] TCP threaded receiver mode - v2 (PR #4825)
by space88man 15 Jul '26

15 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] LLM/AI Coding Assistants were involved in creating the C code or other included content - [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 ## Threaded TCP receiver (`tcp_main_threads = 2`) This PR adds a threaded TCP receiver — the TCP counterpart to the UDP `udp_receiver_mode = 1` setting. Unlike UDP, this mode also confines TCP writes to a single process. The mode is selected with `tcp_main_threads`: - `0` — classic multi-process TCP network I/O and TLS (unchanged). - `1` — multi-process TCP network I/O, but the read for TLS and all TLS run in a single process. This was previously `tcp_main_threads > 0`. - `2` (new) — all TCP network I/O and all TLS run in `PROC_TCP_MAIN`. ### What changes in mode 2 Transport is separated from SIP message handling. `PROC_TCP_MAIN` is the only process that holds network sockets, so sockets are no longer passed between processes with `sendmsg`/`SCM_RIGHTS`. That removes the fd book-keeping and the borrow/release handshake around TCP sockets. - Writes are always asynchronous. A worker never writes to a socket; it hands the payload to `PROC_TCP_MAIN` via `CONN_WRITE_REQ`. - Outbound connections with no existing `tcp_connection_t` are opened in `PROC_TCP_MAIN` (via `CONN_CONNECT_REQ`) instead of in a worker. - `PROC_TCP_MAIN` runs a thread pool for socket reads and async writes. The pool size is set with `tcp_reactor_threads` (default 8). ### Notes for reviewers - The `src/core` commits are not squashed, so each step is a smaller read. - HEP/HEP3, WS/WSS and MSRP are not wired up in the early commits; support is restored later, once plain TCP/TLS was tested. - `pkg_malloc` is lock-free and assumes one thread per process, which mode 2 breaks. If Kamailio is built against the system `malloc` (glibc, musl, …) this is a non-issue, since those are thread-safe. With Kamailio's own allocators, the `pkg` path is serialized inside `PROC_TCP_MAIN`; that serialization is confined to `PROC_TCP_MAIN` and touches nothing else. - Modes 0 and 1 are untouched. Every new code path is gated on `tcp_main_threads = 2`. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4825 -- Commit Summary -- * core: tcp reactor - TCP threaded receiver mode * core: tcp reactor - dispatch SIP messages to worker * core: tcp reactor - PROC_TCP_MAIN thread pool and plain-TCP reads * core: tcp reactor - offload writes and TLS to the pool * core: tcp reactor - outbound connect and partial-read reaper * core: tcp reactor - route HEP3 to hep3_process_msg * core: tcp reactor - route MSRP to msrp_process_msg * msrp: update to handle TCP mode = 2 * core: tcp reactor - WS/WSS support and reader-pool thread-safety * websocket: support the TCP mode 2 * core: tcp reactor - configure number of threads -- File Changes -- M cmake/lock_methods.cmake (36) M src/core/cfg.lex (2) M src/core/cfg.y (3) M src/core/globals.h (1) A src/core/tcp_cond.c (159) A src/core/tcp_cond.h (66) M src/core/tcp_conn.h (33) M src/core/tcp_main.c (1337) M src/core/tcp_mtops.c (57) M src/core/tcp_mtops.h (4) A src/core/tcp_reactor.c (79) A src/core/tcp_reactor.h (159) A src/core/tcp_reactor_mem.c (172) A src/core/tcp_reactor_mem.h (76) M src/core/tcp_read.c (118) M src/core/tcp_read.h (3) M src/core/tcp_server.h (6) M src/modules/msrp/msrp_cmap.c (7) M src/modules/websocket/ws_conn.c (8) M src/modules/websocket/ws_frame.c (33) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4825.patch https://github.com/kamailio/kamailio/pull/4825.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4825 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4825(a)github.com>

1 3

Avoiding the Common Mistakes in Crossy Road
by rishimaali6886＠gmail.com 15 Jul '26

15 Jul '26

Many players make the mistake of jumping too fast. They think speed is the only thing that matters. But speed often leads to mistakes. If you hop without looking, you will hit a car. You must find a balance between speed and caution. Look at the road before you move. Make sure there is a safe gap for you to land in. Another mistake is ignoring the sides of the screen. Sometimes the best path is not straight ahead. You can jump sideways to avoid a dangerous spot. Use the full width of the screen. This gives you more options. If you feel trapped, look for a way to move around the obstacle. Don't feel forced to stay in one lane if it looks too busy. Stay calm when things get chaotic. When the screen fills with cars and trains, it is easy to panic. Take a breath. Focus on your next hop. Ignore the rest of the board for a second. This helps you make better decisions. You will survive much longer if you stay focused. Remember that this is just a game. Have fun with the challenge. https://crossyroadonline.io

1 0

Heardle – The Viral Music Guessing Game Every Music Lover Should Try
by felixandreaim＠gmail.com 15 Jul '26

15 Jul '26

What Is Heardle? If you enjoy testing your music knowledge, heardle is a must-try. Inspired by the global success of Wordle, this music guessing game challenges players to identify songs from very short audio clips. It’s simple, engaging, and surprisingly addictive. https://heardleonline.io/ How the Heardle Game Works Each round starts with a one-second snippet of a song. Players can either guess immediately or skip to hear a longer clip. With every incorrect guess or skipped attempt, the audio expands—up to six total tries. Your goal is to correctly name both the song and artist before running out of chances. Why Heardle Is So Popular Heardle stands out because it combines nostalgia, challenge, and discovery. Whether you’re recognizing a favorite hit or learning a new track, each round feels rewarding. The minimalist interface and smart search suggestions make gameplay smooth and accessible. Key Features Six attempts per round Progressive audio hints Skip option for strategic play Unlimited modes for continuous fun Genre and decade variations Heardle offers a fresh twist on puzzle games by turning music into a daily challenge. If you’re looking for a fun and interactive way to engage with songs, it’s time to play Heardle online and test your ears.

3 2

[kamailio/kamailio] core: fix case-insensitive search in _strnistr (PR #4824)
by KartiK B Kenchi 15 Jul '26

15 Jul '26

While reviewing the string utilities in src/core/str.c, I noticed a bug in the implementation of `_strnistr()`. Although the function is meant to find case-insensitive occurrences of a substring, the inner loop that scans for the first character of the search pattern performs a case-sensitive check (`sc != c`). As a result, it completely skips matches if the first character of the target string has a different case than the search pattern (e.g., searching for "alias=" in a string starting with "Alias=" returns NULL). To fix this cleanly: 1. We compute the alternative ASCII case of the first character once outside of the loop. 2. The inner loop now checks `sc != c && sc != c_alt`, which maintains maximum performance (zero function calls in the loop). 3. The check is restricted to ASCII letters to avoid corrupting or misinterpreting multibyte UTF-8 sequences. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4824 -- Commit Summary -- * core: fix case-insensitive search in _strnistr -- File Changes -- M src/core/str.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4824.patch https://github.com/kamailio/kamailio/pull/4824.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4824 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4824(a)github.com>

2 1

The Scratch Program Sparks Exciting Creations
by kalejoyeux＠protonmail.com 15 Jul '26

15 Jul '26

Scratch has become one of the most popular programming tools for beginners, motivating millions of people worldwide to turn their ideas into interactive creations. Scratch, with its easy drag-and-drop interface, makes coding accessible to children, students, educators, and creative enthusiasts who wish to experience the world of programming without requiring sophisticated technical skills. One of the most intriguing parts of Scratch is its potential to inspire innovation. Colorful code blocks enable users to build games, animations, stories, simulations, and educational projects. Rather of emphasizing complicated grammar, Scratch enables students to experiment with logic, design, and problem solving. This independence enables creators to turn their inventive ideas into compelling digital experiences. The Scratch community also plays an important role in fostering creativity. Users can share their projects, receive feedback, and explore others' efforts. This collaborative environment encourages beginners to develop their talents while also learning new approaches and concepts. By remixing existing programs, students can better grasp programming ideas and build their own distinct approaches. Beyond creativity, Scratch promotes critical thinking, computational reasoning, and project planning. As users build and refine their inventions, they learn how to spot problems, test solutions, and think logically. These vital skills can be used not only in programming, but also in a variety of academic and professional settings. source: https://scratchgamesonline.io/roblox-clicker

1 0

[kamailio/kamailio] Missing `data.len` check before `get_4bytes()` on Unsigned32 answer AVPs across the IMS modules (Issue #4816)
by EV 14 Jul '26

14 Jul '26

Dongoing created an issue (kamailio/kamailio#4816) ### Description Several Kamailio IMS modules read a 4-byte Unsigned32 value out of a Diameter **answer** AVP with `get_4bytes(avp->data.s)` (`cdp/diameter.h:64`) after only a NULL check — they do not check `avp->data.len >= 4`. `get_4bytes` reads four bytes unconditionally, so an AVP whose value is shorter than 4 bytes is read past its declared length. The value comes off the wire from a Diameter peer (the HSS on Cx, the OCS on Ro/Gy, the PCRF on Rx), which controls the AVP's length. In the common case the extra bytes read are the AVP's 4-byte alignment padding (Diameter pads every AVP value, and CDP sizes the message buffer with that padding), so the module computes a **wrong integer value** rather than faulting — a robustness/correctness defect. If a peer sends the short AVP unpadded at the very end of the message the read goes past the message buffer, but even then it is a 1-3 byte read that does not reliably fault, and it is not observable in a running node because the received message lives in the shared-memory pool (`receiver.c`: `sp->msg = shm_malloc(...)`, and `msg->buf.s` points into it), where such a read is caught by neither AddressSanitizer nor `DBG_SR_MEMORY`. The point is simply that these sites read four bytes from a field that may be shorter, without checking — the fix is to add the length check. This is systemic — the same unchecked `get_4bytes(...->data.s)` appears across five modules and all four IMS Diameter interfaces: | Module | Interface / answer | Sites (Unsigned32 AVP) | |---|---|---| | `ims_icscf/cxdx_avp.c` | Cx UAA/LIA | `:326` Experimental-Result-Code, `:400`/`:402` Mandatory/Optional-Capability | | `ims_auth/cxdx_avp.c` | Cx MAA | `:337` Experimental-Result-Code | | `ims_registrar_scscf/cxdx_avp.c` | Cx SAA | `:333` Experimental-Result-Code | | `ims_charging/ccr.c` | Ro/Gy CCA | `:368`/`:372` CC-Request-Type/Number, `:392` CC-Time, `:404` Validity-Time, `:408` Time-Quota-Threshold, `:411` Result-Code, `:420` Final-Unit-Action, `:483` | | `ims_qos/rx_avp.c` | Rx AAA | `:1329`, `:1353` Result-Code, `:1361` Experimental-Result-Code | Representative (from `ims_icscf/cxdx_avp.c`, identical shape in the others): ```c avp = ...FindMatchingAVP(..., AVP_IMS_Experimental_Result_Code, ...); if(!avp || !avp->data.s) { ... return 0; } /* NULL check only, no length check */ *data = get_4bytes(avp->data.s); /* reads data.s[0..3] */ ``` `get_4bytes(_b)` expands to `_b[0]<<24 | _b[1]<<16 | _b[2]<<8 | _b[3]`. That this is an oversight is shown by the sibling readers in the same files that **do** check the length first: ```c /* ims_icscf/cxdx_avp.c:556, ims_auth:585, ims_registrar_scscf:581 -- SIP-Item-Number */ if(!avp || avp->data.len != 4) return 0; *item_number = get_4bytes(avp->data.s); ``` and by CDP's own getter `AAAGetUnsigned32` (`cdp_avp/avp_get_base_data_format.c:92`), which rejects `data.len < 4`. The listed sites bypass both. (CDP's wire parser also uses `get_4bytes`, but there each read is bounds-checked against the message buffer first — those are fine.) There is no XSD or module option in these paths; the modules parse these answer AVPs on every Cx/Ro/Gy/Rx transaction, so it applies in the default configuration. Expected: an Unsigned32 AVP shorter than 4 bytes should be rejected. Actual: `get_4bytes` reads 4 bytes regardless of `avp->data.len`. ### Troubleshooting #### Reproduction 1. Peer a Kamailio IMS node with the relevant Diameter peer (I-CSCF/S-CSCF ↔ HSS on Cx, a charging-enabled node ↔ OCS on Ro/Gy, or a P-CSCF ↔ PCRF on Rx). 2. Cause the corresponding transaction (register a subscriber → UAR/UAA, MAR/MAA, SAR/SAA; a charged session → CCR/CCA; a media session → AAR/AAA). 3. Answer with a message whose `Experimental-Result-Code` / `Result-Code` / a `Capability` / a CCA quota unit (`CC-Time`, `Validity-Time`, …) AVP carries fewer than 4 bytes of value. The module reads 4 bytes, i.e. past the AVP's declared value length. Without a full setup, the read past the value is shown by compiling the `get_4bytes` + check-then-read pattern verbatim under AddressSanitizer and feeding it a 1-byte AVP (`repro_icscf_get4bytes.c`, `gcc -fsanitize=address`). #### Debugging Data AddressSanitizer on the standalone reproducer (verbatim `get_4bytes` macro + the check-then-read from `cxdx_avp.c`), with a 1-byte AVP value: ``` ==ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1 at 0x... thread T0 #0 read_u32_avp repro_icscf_get4bytes.c:39 [== get_4bytes(avp->data.s): cxdx_avp.c:326 / ccr.c:411 / rx_avp.c:1353 ...] #1 main repro_icscf_get4bytes.c:57 0x... is located 0 bytes to the right of 1-byte region (the AVP value < 4 bytes) SUMMARY: AddressSanitizer: heap-buffer-overflow ``` (Full log: `evidence/asan-bug6-icscf-oob-read.log`. The mechanism is identical at every site listed above. This isolated harness — where the value is a plain `malloc()` allocation — is the evidence for the read; in a running node the received message is in the shared-memory pool, so the over-read is not observable by ASAN or `DBG_SR_MEMORY`, as noted in the Description.) #### Log Messages ``` (None — the read is silent; it does not fault on a normal allocator.) ``` #### SIP Traffic Not SIP — the trigger is a Diameter answer (UAA/LIA/MAA/SAA on Cx, CCA on Ro/Gy, AAA on Rx) carrying an Unsigned32 AVP with fewer than 4 bytes of value, e.g. an `Experimental-Result`(297) grouped AVP whose `Experimental-Result-Code`(298) child holds 3 bytes. ### Possible Solutions Check the length before every `get_4bytes(avp->data.s)` on wire data (or route them through `AAAGetUnsigned32`), mirroring the existing checked readers: ```c if(!avp || !avp->data.s || avp->data.len < 4) return 0; /* or skip this AVP */ *data = get_4bytes(avp->data.s); ``` Apply at all sites in the table above (`ims_icscf`, `ims_auth`, `ims_registrar_scscf`, `ims_charging`, `ims_qos`). ### Additional Information - [x] LLM/AI Assistants were involved in discovery, analysis or submission of the issue - [ ] It happened in a production deployment - [x] It happened in a testing or development deployment - [ ] Testing or fuzzing tools were used to generate SIP traffic when it happened * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.5.0 (x86_64/linux) d730fa-dirty compiled with gcc 11.4.0 ``` (Code paths unchanged on current `master`.) * **Operating System**: ``` Ubuntu 22.04 (jammy), x86_64, Linux — Docker container [bug1-scscf-crash.log](https://github.com/user-attachments/files/29854305/bu… -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4816 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4816(a)github.com>

3 4

[kamailio/kamailio] ims_*: check len before get4bytes() (PR #4823)
by Victor Seva 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) - [ ] LLM/AI Coding Assistants were involved in creating the C code or other included content - [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 - [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:  - [x] PR should be backported to stable branches - [ ] Tested changes locally - [x] Related to issue #4816 You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4823 -- Commit Summary -- * ims_auth: check len before get_4bytes() * ims_charging: check len before get_4bytes() -- File Changes -- M src/modules/ims_auth/cxdx_avp.c (27) M src/modules/ims_charging/ccr.c (19) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4823.patch https://github.com/kamailio/kamailio/pull/4823.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4823 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4823(a)github.com>

1 3

[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_registrar_scscf: check header length at parse_sip_header() (PR #4822)
by Victor Seva 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) - [ ] LLM/AI Coding Assistants were involved in creating the C code or other included content - [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 - [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:  - [x] PR should be backported to stable branches - [ ] Tested changes locally #### Description @Dongoing can you please confirm this fixes the issue? You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4822 -- Commit Summary -- * ims_registrar_scscf: check header length at parse_sip_header() -- File Changes -- M src/modules/ims_registrar_scscf/userdata_parser.c (9) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4822.patch https://github.com/kamailio/kamailio/pull/4822.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4822 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4822(a)github.com>

1 0

[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