<div dir="ltr"><div>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:</div><div><br></div><div style="margin-left:40px">grep 2a859fcc4e1c8f840191a81d7c16e76d kamailio.log | egrep 'check_ruri_scheme|w_sanity_check' | grep ACK<br>Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com">2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com</a> - sanity [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered<br>Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com">2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com</a> - sanity [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed<br>Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com">2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com</a> - sanity [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos <<a href="mailto:georgediam@gmail.com">georgediam@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello all,</div><div><br></div><div>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 <span><span></span>17895<span> in REQINIT</span></span>) 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:<br></div><div><br></div><div>Call 1: INVITE <a href="http://sip:voip-test-gd@172.17.173.14:5063" target="_blank">sip:voip-test-gd@172.17.173.14:5063</a> SIP/2.0</div><div>Call 2: INVITE sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0</div><div><br></div><div>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:</div><div><br></div><div>Call 1: ACK <a href="http://sip:voip-test-gd@172.17.173.14:5063" target="_blank">sip:voip-test-gd@172.17.173.14:5063</a> SIP/2.0</div><div>Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0</div><div><br></div><div>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:</div><br><div><div style="margin-left:40px">DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:08679c4228983f9e65f3b47f767b6e07@voip.domain.com" target="_blank">08679c4228983f9e65f3b47f767b6e07@voip.domain.com</a> - sanity [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered<br>DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:08679c4228983f9e65f3b47f767b6e07@voip.domain.com" target="_blank">08679c4228983f9e65f3b47f767b6e07@voip.domain.com</a> - sanity [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0</div><div><br></div><div>whereas Call 1 seems OK:</div><div><br></div><div style="margin-left:40px">DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com" target="_blank">2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com</a> - sanity [sanity.c:305]: check_required_headers(): check_required_headers entered<br>DEBUG: {1 <null> 172.30.154.189 102 ACK <a href="mailto:2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com" target="_blank">2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com</a> - sanity [sanity.c:313]: check_required_headers(): check_required_headers passed</div><div><br></div><div>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...<br></div><div><br></div><div>Thank you. Best regards,<br></div><div>George</div></div></div>
</blockquote></div>