<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 class="gmail-pl-s"><span class="gmail-pl-pds"></span>17895<span class="gmail-pl-pds"> 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">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">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">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">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">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">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>