[SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Hello all,

I'm not 100% sure this is the only culprit in an issue I'm investigating,
but superficially it appears that RURI scheme sanity module checks from the
default config (flags 17895 in REQINIT) fail if the RURI in an ACK
following a 487 includes parameters. Example from two calls from a kamailio
instance acting as registrar/usrloc server, INVITE RURIs are after usrloc
lookup:

Call 1: INVITE sip:voip-test-gd at 172.17.173.14:5063 SIP/2.0
Call 2: INVITE sip:voip-test-user-02 at 10.2.24.142:32768;line=moo62e08 SIP/2.0

These INVITEs produce no complaints. Later, the same registrar produces
ACKs to acknowledge 487 (thus, same transaction ACKs) responses from the
next proxy in the path following a CANCEL:

Call 1: ACK sip:voip-test-gd at 172.17.173.14:5063 SIP/2.0
Call 2: ACK sip:voip-test-user-02 at 10.2.24.142:32768;line=moo62e08 SIP/2.0

The next proxy (which produced/relayed the 487) processes the ACK for Call
1 successfully, but sanity_check at the proxy drops the request for Call 2
with:

DEBUG: {1 <null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
DEBUG: {1 <null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0

whereas Call 1 seems OK:

DEBUG: {1 <null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com - sanity [sanity.c:305]:
check_required_headers(): check_required_headers entered
DEBUG: {1 <null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com - sanity [sanity.c:313]:
check_required_headers(): check_required_headers passed

Could this be a bug in sanity module? Is there anything one can do in
config which could result in illegal ACKs being produced for hop-by-hop
transactions? schema appears to be sip: in both cases...

Thank you. Best regards,
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200707/c685983e/attachment.html>