### Description
When using a combination of TopoS+UACreg+Dialog, Kamailio fails to match received replies to a transaction in a dialog.
### Troubleshooting modparam("topos", "storage", "redis") modparam("topos", "sanity_checks", 0) modparam("topos", "contact_mode", 0)
modparam("dialog", "track_cseq_updates", 1)
#### Reproduction
Load Topos + UAC + Dialog modules. Enable dialog cseq tracking. Add some uacrec record. Register with remote peer. Make a call towards the remote peer.
INVITE
- Cseq: 1, Branch number: 0. Kamailio will receive a 401 challenge. - Cseq: 2, Branch number: 1, it will include the Digest auth and try again. . The mangled topos Contact username will be slightly different (supposed to be?) - Next, the UAS will reply with 100 Trying. In response to that, Kamailio keeps retransmitting the same INVITE with Cseq 2 over and over again, presumably because it fails to match that reply to an existing transaction.
#### Debugging Data
``` DEBUG: {2 2 INVITE a19dfac7c4a65} tm [t_lookup.c:1009]: t_reply_matching(): failure to match a transaction ```
#### Log Messages
<!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` (paste your log messages here) ```
#### SIP Traffic
<!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` 2021/02/26 12:10:16.213947 10.10.10.2:5060 -> 10.10.10.1:5060 INVITE sip:8882223333@mypbx.mydomain.net SIP/2.0 Via: SIP/2.0/UDP mysbc.mydomain.com:5060;branch=z9hG4bK4f81.97f17905fe7afced720300fea57ef462.0;i=6a FROM: Demo Fivesip:2385@mypbx.mydomain.net;tag=29e99c29147f425f914b73512fc13cf3 TO: sip:8882223333@mypbx.mydomain.net CSEQ: 1 INVITE CALL-ID: 33c9034c136e57de9c1278daef7d02fb MAX-FORWARDS: 69 CONTENT-LENGTH: 575 MIN-SE: 300 SUPPORTED: timer USER-AGENT: UA CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY SESSION-EXPIRES: 3600 Contact: sip:btpsh-603922bd-3db9-1@mysbc.mydomain.com:5060
2021/02/26 12:10:16.215650 10.10.10.1:5060 -> 10.10.10.2:5060 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP mysbc.mydomain.com:5060;branch=z9hG4bK4f81.97f17905fe7afced720300fea57ef462.0;i=6a;received=10.10.10.2;rport=5060 From: Demo Fivesip:2385@mypbx.mydomain.net;tag=29e99c29147f425f914b73512fc13cf3 To: sip:8882223333@mypbx.mydomain.net;tag=as7c952f5b Call-ID: 33c9034c136e57de9c1278daef7d02fb CSeq: 1 INVITE Server: B2B Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer, path WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4f8fcced" Content-Length: 0
2021/02/26 12:10:16.238191 10.10.10.2:5060 -> 10.10.10.1:5060 ACK sip:8882223333@mypbx.mydomain.net SIP/2.0 FROM: Demo Fivesip:2385@mypbx.mydomain.net;tag=29e99c29147f425f914b73512fc13cf3 To: sip:8882223333@mypbx.mydomain.net;tag=as7c952f5b CSEQ: 1 ACK CALL-ID: 33c9034c136e57de9c1278daef7d02fb MAX-FORWARDS: 69 Via: SIP/2.0/UDP mysbc.mydomain.com:5060;branch=z9hG4bK4f81.97f17905fe7afced720300fea57ef462.0;i=6a CONTENT-LENGTH: 0
2021/02/26 12:10:16.280455 10.10.10.2:5060 -> 10.10.10.1:5060 INVITE sip:8882223333@mypbx.mydomain.net SIP/2.0 Via: SIP/2.0/UDP mysbc.mydomain.com:5060;branch=z9hG4bK4f81.97f17905fe7afced720300fea57ef462.1.cs1;i=6a FROM: Demo Fivesip:2385@mypbx.mydomain.net;tag=29e99c29147f425f914b73512fc13cf3 TO: sip:8882223333@mypbx.mydomain.net CSEQ: 2 INVITE CALL-ID: 33c9034c136e57de9c1278daef7d02fb MAX-FORWARDS: 69 CONTENT-LENGTH: 575 MIN-SE: 300 SUPPORTED: timer USER-AGENT: UA CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY SESSION-EXPIRES: 3600 Authorization: Digest username="2385", realm="asterisk", nonce="4f8fcced", uri="sip:8882223333@mypbx.mydomain.net", response="ec1986d94b9a508c4e9761c3c1cb80eb", algorithm=MD5 Contact: sip:btpsh-603922bd-3db0-4@mysbc.mydomain.com:5060
2021/02/26 12:10:16.284672 10.10.10.1:5060 -> 10.10.10.2:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP mysbc.mydomain.com:5060;branch=z9hG4bK4f81.97f17905fe7afced720300fea57ef462.1.cs1;i=6a;received=10.10.10.2;rport=5060 From: Demo Fivesip:2385@mypbx.mydomain.net;tag=29e99c29147f425f914b73512fc13cf3 To: sip:8882223333@mypbx.mydomain.net Call-ID: 33c9034c136e57de9c1278daef7d02fb CSeq: 2 INVITE Server: B2B Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer, path Session-Expires: 900;refresher=uas Contact: sip:8882223333@10.10.10.1:5060 Content-Length: 0
2021/02/26 12:10:16.745320 10.10.10.2:5060 -> 10.10.10.1:5060 INVITE sip:8882223333@mypbx.mydomain.net SIP/2.0 Via: SIP/2.0/UDP mysbc.mydomain.com:5060;branch=z9hG4bK4f81.97f17905fe7afced720300fea57ef462.1.cs1;i=6a FROM: Demo Fivesip:2385@mypbx.mydomain.net;tag=29e99c29147f425f914b73512fc13cf3 TO: sip:8882223333@mypbx.mydomain.net CSEQ: 2 INVITE CALL-ID: 33c9034c136e57de9c1278daef7d02fb MAX-FORWARDS: 69 CONTENT-LENGTH: 575 MIN-SE: 300 SUPPORTED: timer USER-AGENT: UA CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY SESSION-EXPIRES: 3600 Authorization: Digest username="2385", realm="asterisk", nonce="4f8fcced", uri="sip:8882223333@mypbx.mydomain.net", response="ec1986d94b9a508c4e9761c3c1cb80eb", algorithm=MD5 Contact: sip:btpsh-603922bd-3db0-4@mysbc.mydomain.com:5060 ```
### Possible Solutions
<!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.5.0-dev4 (x86_64/linux) 5ad3bd flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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 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: 5ad3bd compiled on 15:35:01 Feb 11 2021 with gcc 4.9.2 ```
* **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 `uname -a`) -->
``` Debian GNU/Linux 8 (jessie) ```
Have you troubleshooted with debug=3 in kamailio.cfg? Any log messages printed that could give some leads?
The case should not be related to use of uac_reg records, but to authentication of INVITE and increase of CSeq.
I've added added some relevant debug logs to the case (if full log is required, I could send them in private). Note that logs are from a different CallID, same outcome as in the SIP traffic example.
It goes without saying that this doesn't happen when running same script with TopoS disabled.
Can you try with master branch or the patch from commit 80e812caf83a131c5f830b7d23de754136fd54f7?
Dialog module was looking for 2nd via to do cseq updates, while topos was skipping to restore 100 because is expected to be absorbed.
Thanks for the quick patch. Unfortunately, the problem persists.
``` kamailio -v version: kamailio 5.5.0-dev4 (x86_64/linux) 80e812 ```
### Logs: ``` DEBUG: {2 2 INVITE fde726e43b97} tm [t_lookup.c:907]: t_reply_matching(): poor reply ids - index 434 label 0 branch 16 loopl 32/32 DEBUG: {2 2 INVITE fde726e43b97} tm [t_lookup.c:1009]: t_reply_matching(): failure to match a transaction DEBUG: {2 2 INVITE fde726e43b97} tm [t_lookup.c:1105]: t_check_msg(): msg (0x7ff1b78fac08) id=9/26437 global id=9/26437 T end=(nil) DEBUG: {2 2 INVITE fde726e43b97} tm [t_reply.c:2350]: reply_received(): transaction not found - (branch -1) DEBUG: {2 2 INVITE fde726e43b97} <core> [core/forward.c:771]: do_forward_reply(): reply cannot be forwarded - no 2nd via DEBUG: {2 2 INVITE fde726e43b97} <core> [core/receive.c:596]: receive_msg(): reply-route executed in: 2041 usec ```
Is topos loaded before dialog module?
Can you get the 100 response from the network (e.g, ngrep) as well as print it inside `reply_route {}` (xlog of $mb) and paste both here?
Actually I just spotted another place where 100 was filtered out. Try adding the patch from commit 620194165e0c6c27dfe9dbe382dc2e7b58be13b5 and if still problem, then get the data requested in previous comment.
Worked like a charm on the 2nd attempt. Hope to see the patch pushed to stable branches as well.
Thanks again for the quick fix!
Thanks for testing, they will be pushed to 5.4.
Closed #2654.
-
Daniel-Constantin Mierla -
Sergiu Pojoga