[SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[Daniel-Constantin Mierla]

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
> 2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com
> <mailto:2a859fcc4e1c8f840191a81d7c16e76d at 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
> 2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com
> <mailto:2a859fcc4e1c8f840191a81d7c16e76d at 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
> 2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com
> <mailto:2a859fcc4e1c8f840191a81d7c16e76d at 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
> <georgediam at gmail.com <mailto:georgediam at 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 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:voip-test-gd at 172.17.173.14:5063
>     <http://sip:voip-test-gd@172.17.173.14:5063> SIP/2.0
>     Call 2: INVITE
>     sip:voip-test-user-02 at 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 at 172.17.173.14:5063
>     <http://sip:voip-test-gd@172.17.173.14:5063> SIP/2.0
>     Call 2: ACK sip:voip-test-user-02 at 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
>     08679c4228983f9e65f3b47f767b6e07 at voip.domain.com
>     <mailto:08679c4228983f9e65f3b47f767b6e07 at voip.domain.com> - sanity
>     [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>     DEBUG: {1 <null> 172.30.154.189 102 ACK
>     08679c4228983f9e65f3b47f767b6e07 at voip.domain.com
>     <mailto:08679c4228983f9e65f3b47f767b6e07 at 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
>     2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com
>     <mailto:2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com> - sanity
>     [sanity.c:305]: check_required_headers(): check_required_headers
>     entered
>     DEBUG: {1 <null> 172.30.154.189 102 ACK
>     2a859fcc4e1c8f840191a81d7c16e76d at voip.domain.com
>     <mailto:2a859fcc4e1c8f840191a81d7c16e76d at 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 at lists.kamailio.org
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200708/a1844a1a/attachment.html>