Wrong Route header order in called party re-INVITE when using topos

[jmontorosf]

Hi There,

We found a situation where topos seems to break, let me explain... Assuming the following scenario where topos is enabled in the callee:

Caller ---- Callee(topos)
A: ------INVITE----->	Record-Route:A.A.A.A, Record-Route:B.B.B.B
B: <-----200 OK------	

C: <-----INVITE------ 	Route: A.A.A.A, B.B.B.B
D: ------200 OK----->	Record-Route:B.B.B.B, Record-Route:A.A.A.A (reversed order)

E: <======INVITE===== 	Route: B.B.B.B, A.A.A.A (wrong)

A and B establish the connection from caller to callee, and topos works fine.

C (re-INVITE from callee) sends the Route header according to the Record-Routes from the original INVITE (A)

D is the 200 OK sent from the caller to the first re-INVITE (C) coming from the callee, with the Record-Route headers reversed, because is the order in which the caller received them; and according to the RFC it's working as intended:

When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values.

[...] 

[When a UAC receives a response...]
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters.

E takes the Route order from the last 200 OK ignoring they are in reversed order and assuming the top one is the first one, when it should be the other way around, sending to an IP address not reachable from the callee. And I think here is the issue, topos should not update the path on the Record-Routes from a 200 OK but if it does, it should take the reverse order

When disabling topos, everything works fine, or with topos enabled, by setting rr_update=0 works for us, but what if there is a real path update, rr_update=0 wouldn't work for us anymore. The Kamailio version is 5.8.0-rc0

Let me know if you need more information.

Thanks a lot,
Javi

[miconda]

Can you attach a pcap with SIP traffic from such a call?

Also, provide the kamailio version and the operating system you are using.

[jmontorosf]

pcaps.zip
Hi Daniel, Thanks for your reply.

Please find attached 2 pcaps, one with rr_update=1 and the other one with rr_update=0 ....

Kamailio version:

# kamailio -v
version: kamailio 5.8.0 (x86_64/linux) 19ce56
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_SEND_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: 19ce56 
compiled on 21:04:39 Mar 13 2024 with gcc 10.2.1

And it's compiled in a Docker container with debian 11.9

I noticed redoing the test to get the pcaps, that in the problematic case (rr_update=1) there isn't a route header anymore... So is not the situation described above anymore, but still failing when rr_update=1.

[github-actions]

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.