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:[email protected]:5063 SIP/2.0 Call 2: INVITE sip:[email protected]: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:[email protected]:5063 SIP/2.0 Call 2: ACK sip:[email protected]: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 [email protected] - sanity [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered DEBUG: {1 <null> 172.30.154.189 102 ACK [email protected] - 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 [email protected] - sanity [sanity.c:305]: check_required_headers(): check_required_headers entered DEBUG: {1 <null> 172.30.154.189 102 ACK [email protected] - 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
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
