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

[Anthony Alba]

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 at 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 at voice.example.com;tag=i1acAHsitf2gcN9uHH-ZSyJ5OdT8O5M0
To: <sip:charles at 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 at 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 at voice.example.com;tag=i1acAHsitf2gcN9uHH-ZSyJ5OdT8O5M0
To: sip:charles at 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 at 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 at voice.example.com>;tag=6zOt.H7w8NL5njV7klwGLlSJy.U5yBC9
To: <sip:david at 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