Hi There,
We found a situation where topos seems to break, let me explain... Assuming the following scenario:
``` Caller ---- Callee 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 callee 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
Can you attach a pcap with SIP traffic from such a call?
Also, provide the kamailio version and the operating system you are using.
[pcaps.zip](https://github.com/kamailio/kamailio/files/14652370/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.
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.
Closed #3778 as not planned.
Reopened #3778.
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.
Are you doing record_route() for re-INVITE? Default kamailio.cfg doesn't do it.
Trying to understand the SIP trace, are there two SIP servers in different locations that listen on `127.0.0.1:5060`, one of them being your kamailio with topos and the other one something different (not the same instance)?
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.
I have a similar problem. Topology: sip-ua -> kamailio (topos) -> kamailio -> freeswitch After setting the hold state on the client phone, the SIP BYE message from the freeswitch will have mixed-up Route headers. I also use record_route() for re-INVITES, can it be the source of the problem?
In my case the problem is only in the reverse order of the Route headers in the BYE message after topos processing.
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.
Closed #3778 as not planned.
Reopened #3778.
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.
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.
Closed #3778 as not planned.