Hello,
when the ruri scheme check fails, there should be another debug message
saying that. Have you pasted all log messages for the failure case?
Cheers,
Daniel
On 07.07.20 22:23, George Diamantopoulos wrote:
> 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
> [email protected]
> <mailto:[email protected]> - 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
> [email protected]
> <mailto:[email protected]> - 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
> [email protected]
> <mailto:[email protected]> - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1
>
> On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos
> <[email protected] <mailto:[email protected]>> 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 17895in
> 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
> <http://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
> <http://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]
> <mailto:[email protected]> - sanity
> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
> DEBUG: {1 <null> 172.30.154.189 102 ACK
> [email protected]
> <mailto:[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]
> <mailto:[email protected]> - sanity
> [sanity.c:305]: check_required_headers(): check_required_headers
> entered
> DEBUG: {1 <null> 172.30.154.189 102 ACK
> [email protected]
> <mailto:[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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
