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

George Diamantopoulos georgediam at gmail.com
Wed Jul 8 09:48:13 CEST 2020


Hello Daniel,

Thanks for the reply. Indeed there is, not sure how I managed to miss that.
And it wasn't about the schema after all:
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
<null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 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[909]: DEBUG: {1
<null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - <core>
[core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<BC><EA><8F>>
(3)
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
<null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - <core>
[core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<BC><EA><8F>>
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING: {1
<null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - sanity [sanity.c:282]:
check_ruri_scheme(): failed to parse request uri [<BC><EA><8F>]
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
<null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
<null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07 at voip.domain.com - <script>: Malformed SIP
request from 172.30.154.189:5060

Still, not sure what the problem is though...

BR,
George

On Wed, 8 Jul 2020 at 09:30, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> 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 - 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 - 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 - 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>
> 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 at 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 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 - 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 - 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 - 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 - 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 Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.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/413ffc7b/attachment.html>


More information about the sr-users mailing list