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
2a859fcc4e1c8f840191a81d7c16e...@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
2a859fcc4e1c8f840191a81d7c16e...@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
2a859fcc4e1c8f840191a81d7c16e...@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 <georged...@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@172.17.173.14:5063 SIP/2.0
> Call 2: INVITE sip:voip-test-user-02@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@172.17.173.14:5063 SIP/2.0
> Call 2: ACK sip:voip-test-user-02@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
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
> check_ruri_scheme(): check_ruri_scheme entered
> DEBUG: {1 <null> 172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@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
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com - sanity [sanity.c:305]:
> check_required_headers(): check_required_headers entered
> DEBUG: {1 <null> 172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@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
>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
