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

[George Diamantopoulos]

Sorry, I realised I copy pasted wrong log messages for Call 1. Here's the
relevant part showing success for call 1 in contrast with Call 2:

grep 2a859fcc4e1c8f840191a81d7c16e76d kamailio.log | egrep
'check_ruri_scheme|w_sanity_check' | grep ACK
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1
<null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1
<null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com - sanity [sanity.c:297]:
check_ruri_scheme(): check_ruri_scheme passed
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1
<null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1

On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos <georgediam at gmail.com>
wrote:

> 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/abb25438/attachment.html>