### Description
[track_cseq_updates](http://kamailio.org/docs/modules/4.4.x/modules/dialog.html#dialog.p.track_cs...) of _dialog_ module seems to fail in cseq number adaptation of subsequent ACK once [uac_auth()](http://kamailio.org/docs/modules/4.4.x/modules/uac.html#uac.f.uac_auth()) function of _uac_ module transaction fails:
1. INVITE sent by UAC (CSeq 100). 1. 407 from UAS. 1. INVITE generated by uac_auth (CSeq 101). 1. 500 from UAS. 1. INVITE to another carrier (CSeq 100) 1. 200 OK from carrier. 1. ACK (CSeq 101 instead of 100).
ACK CSeq is increased by one but it shouldn't as it is acknowledging INVITE in step 5.
### Troubleshooting
#### Reproduction
The issue can be reproduced with the logic mentioned above (track_cseq_updates=1):
- Initial INVITE - INVITE generated by uac_auth in failure_route - INVITE to another destination in failure_route - CSeq in ACK is increased by one
#### SIP Traffic
See attached pcap file ([cseq_tracking_wrong_ack.pcap.gz](https://github.com/kamailio/kamailio/files/1548079/cseq_tracking_wrong_ack.p...)) that involves following parties: - 155.179.229.105: UAC that sends the INVITE. - 155.179.229.109: Kamailio - 202.165.186.162: Initial carrier (the one that asks for SIP auth) - 9.189.124.97: Second carrier
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 4.4.6 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 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 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`) -->
``` Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux ```
Is there any way to disable CSeq mangling triggered by uac_auth once this transaction fails to prevent this mangling from breaking the subsequent ACK transaction?
Thank you and regards,
Can you try to use:
``` msg_iflag_reset("UAC_AUTH"); ``` inside failure_route before sending to the second carrier?
I have made some tests with those two lines and the case I reported gets fixed, but I get cseq_tracking disabled for following eventual transactions.
I mean:
- First carrier needs authentication but once authenticated it answers >300 code. - The call is sent to another carrier: - If it doesn't need authentication (the case I reported), the ACK and everything is fine now. - If this carrier also needs authentication, the cseq is not updated even though _uac_auth()_ function is called again.
It seams that once cseq tracking is reset with those two lines, the cseq adaptation mechanism gets disabled for new calls to _uac_auth()_ function.
I will do more tests to figure out what is happening and update this issue.
Thank you and regards,
If still a problem, open a new issue with the details of the case that doesn't work. I looked at the code and uac_auth() should set back the internal flag for authentication, so the eventual issue should not be related to the one reported here.
Closed #1359.
-
Carlos Cruz Luengo -
Daniel-Constantin Mierla