### Description [track_cseq_updates](http://kamailio.org/docs/modules/4.4.x/modules/dialog.h… 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.u… 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…) 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, -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1359