[SR-Users] kamailio not absorbing ACK to CANCEL when behind a Path proxy

Folks, I have a weird situation, when I enable Path header, kamailio behind a Path proxy, that kamailio doesn't recognise the ACK to CANCEL and tries to forward it. Test scenario: - voice.example.com is a stateless proxy with TLS/UDP bridging to kamailio. - on the UDP leg to kamailio it will add a Path: header to REGISTER UA1 = david is calling UA2 = charles and UA2 is sending 603 1 . UA1: preloaded route set (outbound proxy) # this is the Path proxy Route: sip:voice.example.com;transport=tls;lr 2. UA2: sends CANCEL 603 - kamailio immediately sends its (per-hop?) ACK - kamailio forwards CANCEL to UA1 kamailio sent this (per-hop?) ACK - the Route header is the internal UDP interface of the Path proxy ACK sip:charles@192.168.1.7:37309;transport=TCP;ob SIP/2.0 Via: SIP/2.0/UDP 192.168.122.99:5064;branch=z9hG4bK735d.6b27c8d09e40462ef47eccf90eb10823.0 Max-Forwards: 70 From: sip:david@voice.example.com;tag=i1acAHsitf2gcN9uHH-ZSyJ5OdT8O5M0 To: <sip:charles@voice.example.com>;tag=LmUY79rIdBQiiSakML4F0lHl271VdUn8 Call-ID: qM3W-fMrzPsvcjRSD1okEp5nbgHCF5Hu CSeq: 16667 ACK Route: <sip:192.168.122.100;lr> Content-Length: 0 3. UA1 sends ACK kamailio sees this - top Via is path proxy - 2nd Via is UA (caller) - CSeq correctly matches the INVITE - kamailio does not recognise this ACK from UA1(caller), tries to forward it, and also resends 603 to UA1(caller) 3 times ACK sip:charles@voice.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.122.100:5060;branch=z9hG4bKb3c9a7a3b6ec9e78d0144cda709f7047 Via: SIP/2.0/TLS 192.168.1.17:44925;rport=44925;branch=z9hG4bKPjFM-9gpaJEghJvN19TjnvScCwCoAGzwEc;alias;received=192.168.1.17 Max-Forwards: 70 From: sip:david@voice.example.com;tag=i1acAHsitf2gcN9uHH-ZSyJ5OdT8O5M0 To: sip:charles@voice.example.com;tag=LmUY79rIdBQiiSakML4F0lHl271VdUn8 Call-ID: qM3W-fMrzPsvcjRSD1okEp5nbgHCF5Hu CSeq: 16667 ACK Route: <sip:voice.example.com;transport=tls;lr> Content-Length: 0 Now kamailio should absorb this ACK, as it has already sent its per-hop ACK. Instead I see ERROR: <core> [core/forward.c:541]: forward_request(): cannot forward to af 2, proto 3 no corresponding listening socket I don't expect kamailio to forward anything at this point. The route block is route[WITHINDLG] and it calls t_relay() normally. route[WITHINDLG] { if (!has_totag()) return; # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if ( is_method("ACK") ) { # ACK is forwarded statelessly route(NATMANAGE); } else if ( is_method("NOTIFY") ) { # Add Record-Route for in-dialog NOTIFY as per RFC 6665. record_route(); } route(RELAY); # we should absorb this ACK, no? exit; } 4. If I remove the Path proxy and kamailio is the TLS proxy at voice.example.com the call flow works perfectly. The ACK from caller (david) is absorbed. 5. Regular calls, when UA2 accepts the call, work fine. In-dialog requests for BYE, from both UAs, work correctly with this Path proxy. Each UA has the complete 5 element route set( 2 x Path proxy + kamailio + 2 x Path proxy). The working route set looks like this: BYE sip:david@192.168.1.17:44925;transport=TCP;ob SIP/2.0 Via: SIP/2.0/TLS 192.168.1.7:37309;rport;branch=z9hG4bKPjHdUtaUL5AfRcV-SX1Puya4niJKOOQ4VQ;alias Max-Forwards: 70 From: <sip:charles@voice.example.com>;tag=6zOt.H7w8NL5njV7klwGLlSJy.U5yBC9 To: <sip:david@voice.example.com>;tag=Pa0ORUxA-7lK0BnR4pLJ5n8rn2OvQrJy Call-ID: 3gWy4Q7O.-zQ-I07lRKHyFyX6azyCSwG CSeq: 12855 BYE Route: <sip:voice.example.com;transport=tls;lr;r2=on> Route: <sip:192.168.122.100;lr;r2=on> Route: <sip:192.168.122.99:5064;lr> Route: <sip:192.168.122.100;lr;r2=on> Route: <sip:voice.example.com;transport=tls;lr;r2=on> User-Agent: basesip 1.0.0 Content-Length: 0 Any ideas? Anthony Alba