@Fr-Soltanzadeh pushed 1 commit.

c565d5f321ae21dce31df93b73eb12df31c4ee64 hide all record routes except last one in reply messages

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.

Closed #4170.

Reopened #4170.

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?

miconda left a comment (kamailio/kamailio#4170)

The masking/unmasking cannot be done using the last one corresponding to Topoh-Server, because it has to be done in the way that the intermediary nodes see the same Record-Route as for the INVITE.

Lets take the example:

``` UA1 <=> P1 <=> P2(TH) <=> P3 <=> P4 <=> P3 <=> P2(TH) <=> P1 <=> UA2 ```

When INVITE goes to UA2, the Record-Route headers leaving a proxy are:

- at UA1 - at P1: P1 - at P2(TH): P2, X1 - at P3: P3, P2, X1 - at P4: P4, P3, P2, X1 - at P3: P3, P4, P3, P2, X1 - at P2(TH): P2, X3, X4, X3, X2, Y1 - at P1: P1, P2, X3, X4, X3, X2, Y1 - at UA2: P1, P2, X3, X4, X3, X2, Y1

The P is clear address, X is encoded address, Y is double encoded address.

When the response goes the opposite direction, it has to be:

- at UA2: P1, P2, X3, X4, X3, X2, Y1 - at P1: P1, P2, X3, X4, X3, X2, Y1 - at P2(TH): X1, P2, P3, P4, P3, P2, X1 - at P3: X1, P2, P3, P4, P3, P2, X1 - at P4: X1, P2, P3, P4, P3, P2, X1 - at P3: X1, P2, P3, P4, P3, P2, X1 - at P2(TH): Y1, X2, X3, X4, X3, P2, P1 - at P1: Y1, X2, X3, X4, X3, P2, P1 - at UA1: Y1, X2, X3, X4, X3, P2, P1

Using the last route matching the TH-Server is not correct, I assume that you set mask ip to be P2, so all the X and Y record-routes have P2 address. If the mask ip is different that P2 (it can be any address, say 127.0.0.2), then it should work as it is now. If mask ip is P2 address, then when response comes first to it, it has to encode the record-routes towards UA2 via P1 and decode those towards UA1 via P3. When it comes second time, it has to encode those towards UA2 via P3 and decode those via UA1 via P1.