<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] 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) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4170
-- Commit Summary --
* hide all record routes except last one in reply messages
-- File Changes --
M src/modules/topoh/th_msg.c (16)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4170.patch https://github.com/kamailio/kamailio/pull/4170.diff
@Fr-Soltanzadeh pushed 1 commit.
c565d5f321ae21dce31df93b73eb12df31c4ee64 hide all record routes except last one in reply messages
miconda left a comment (kamailio/kamailio#4170)
It is wrong to keep only the last one, because the topoh proxy can be in the middle. On the other hand, I am not sure where spiralling support was left at, the module was initially designed to spit the the signaling in two parts, not in many more. It has to be investigated, but the description of what PR does not seem to be a correct behaviour.
Fr-Soltanzadeh left a comment (kamailio/kamailio#4170)
@miconda Thank you for the feedback. I agree that my initial approach—only hiding up to the last Record-Route (RR) header—was incorrect, as it doesn’t account for scenarios where the Topoh proxy (e.g., P-CSCF) is not the last entity in the RR chain.
However, I believe there’s a misunderstanding about the specific issue in the IMS topology I’m working with. Let me clarify the problem more precisely.
Scenario In an IMS setup, due to spiraling behavior (e.g., S-CSCF -> I-CSCF -> S-CSCF), the same proxy (like P-CSCF) may appear multiple times in the Record-Route list. For example, in the 180 Ringing or 200 OK responses sent from the core network back to the UE, the RR headers might look like:
Record-Route: PCSCF Record-Route: SCSCF Record-Route: SCSCF Record-Route: PCSCF
Here, P-CSCF (which is running Topoh) appears twice—once at the beginning and once at the end. However, the current Topoh implementation works by scanning RRs top-down and stops at the first occurrence of its own IP. That means in this example, none of the RR headers are hidden, because the first occurrence of its IP is at the top of the list. In this case, Topoh fails to hide any RR headers, which results in exposing internal IPs (like those of S-CSCF). This breaks the topology hiding requirement expected in IMS.
Suggested Behavior Instead of stopping at the first match of its own IP in the RR headers, Topoh should: * First, scan all Record-Route headers to find the last occurrence of its own IP. * Then, hide all Record-Route headers up to that position.
This ensures that: All internal hop headers before and including the last instance of the Topoh proxy are hidden. Any legitimate Record-Route headers after the Topoh proxy (e.g., from a downstream proxy or UE) remain intact.
I'd appreciate your thoughts on whether this approach aligns with the original design goals of Topoh, especially with respect to spiraling.
Fr-Soltanzadeh left a comment (kamailio/kamailio#4170)
@miconda Hi again. I’d appreciate any feedback when you get a chance, as I’m pending your response to move forward.
Closed #4170.
@Fr-Soltanzadeh pushed 0 commits.
Reopened #4170.
Fr-Soltanzadeh left a comment (kamailio/kamailio#4170)
@miconda Hi again. I've implemented the solution I explained above. Could you please take another look and let me know whether the new solution properly implements the record‑route hiding logic in spiral behavior? Thanks!
miconda left a comment (kamailio/kamailio#4170)
Travelling lately because of the Easter holidays, I haven't had the chance to look much at it yet. Is it about un/masking the IPs in the SIP response, right?
Fr-Soltanzadeh left a comment (kamailio/kamailio#4170)
Yes. In Record-Route headers.
-
Daniel-Constantin Mierla -
Farzaneh Soltanzadeh