### Description All kamailio versions on the 5.7.x train and additionally point release 5.6.5 break early dialog transactions, at least when the following conditions are (cumulatively) met: * topos-redis is enabled (haven't tested other storage backends yet, let me know if needed) * kamailio is multihomed * enable_double_rr is enabled (the default)
### Troubleshooting #### SIP Traffic Here's an exchange demonstrating the problem:
``` kamailio instance ──────────┬──────────────────┬───────── internal external peer 172.30.154.1:5060 185.73.43.241:5060 195.167.21.66:5060 ──────────┬──────────────────┬───────── ──────────┬───────── │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ INVITE (SDP) │ │ │ ──────────────────────────> │ │ │ 100 Trying │ │ │ <────────────────────────── │ │ │ 183 Session Progress (SDP) │ │ │ <────────────────────────── │ │ │ PRACK │ │ │ ──────────────────────────> │ │ │ 200 OK │ │ │ <────────────────────────── │ │ │ UPDATE (SDP) │ UPDATE (SDP) │ │ <─────────────────────────── │ │ ``` Whereas the expected behaviour should be: ``` │ │ UPDATE (SDP) │ | <────────────────────────── │ UPDATE (SDP)│ │ │ <───────── │ │ │
``` This is also exemplified by examining the Via headers as rewritten by kamailio. Not working (>= 5.6.5, 5.7.x): * Inbound Via: `Via: SIP/2.0/UDP 195.167.21.66:5060;branch=z9hG4bKtjlwcpvfh03epe0thhtjhq3qg;Role=3;Hpt=8e58_16` * Oubound Via: `Via: SIP/2.0/UDP 185.73.43.241;branch=z9hG4bK66c4.3453dd9a219858819d528b9da671e39e.0`
Working (5.6.4): * Inbound Via: `Via: SIP/2.0/UDP 195.167.21.66:5060;branch=z9hG4bK8lj1ahz6npz65khd8jkzl1ohh;Role=3;Hpt=8e68_16` * Oubound Via: `Via: SIP/2.0/UDP 172.30.154.1;branch=z9hG4bK4dce.4f5448efd64465fa5dbaf5eef0dc35b7.0` ### Possible Solutions Only solution I have found so far is to downgrade to kamailio 5.6.4 <!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
### Additional Information
``` version: kamailio 5.7.4 (x86_64/linux) 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1
``` But I have also tested all 5.7.x versions, which are all affected, as well 5.6.5. * **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `lsb_release -a` and `uname -a`) -->
``` Linux host 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux ```
This seems to be fixed in `5.8.1~bpo11.20240319013115.16`. I haven't been able to test with 5.8.0 because of #3785. Has anything changed and are there any plans to backport to 5.7.x and 5.6.x? Thanks!
Changes to topos in 5.8 were related to contact mode 1, when a contact uri had no username. Do you use that mode?
5.7 branch should have those changes.
Hello,
No, contact_mode is not defined so it's the default (0). I'll try to investigate a little bit more during the week...
Hello,
I can confirm that issue is fixed. Version: 5.8.1~bpo10.20240327013111.19 in my case.
Are v5.4 and v5.5 concerned too ?
Are v5.4 and v5.5 concerned too ?
In my testing, all versions higher than 5.6.5 inclusive are affected. The first to work for me was `5.8.1~bpo11.20240319013115.16` although I couldn't test `5.8.0 GA` due to https://github.com/kamailio/kamailio/issues/3785
I don't remember seeing this particular issue with `5.4.x` or `5.5.x` but bear in mind that topos has been introducing failures with early-dialog transactions (or even in-dialog transactions sometimes) in several kamailio releases, depending on how one uses it. `5.6.4` is the latest version which I can confirm works for my use case in every way (I only use it for INVITE-initiated dialogs, however, SUBSCRIBE-initiated dialogs are skipped when it comes to topology stripping). `5.8.1-nightly` works too, but I haven't tested it extensively, I only investigated the issue described here with this version.
`5.8.1+bpo11` was released and the issue is gone. Hope it stays that way. @miconda feel free to close this if you feel there is nothing else to be done.
Closed #3757 as completed.
Thanks for testing and reporting back!