Hello, check your config operations, because the R-URI seems to be the next string (without quotes): "<BC><EA><8F>"
You can try to print $mb in such case to see the entire SIP message buffer. Cheers, Daniel On 08.07.20 09:48, George Diamantopoulos wrote: > 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 > 08679c4228983f9e65f3b47f767b6...@voip.domain.com > <mailto:08679c4228983f9e65f3b47f767b6...@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 > 08679c4228983f9e65f3b47f767b6...@voip.domain.com > <mailto:08679c4228983f9e65f3b47f767b6...@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 > 08679c4228983f9e65f3b47f767b6...@voip.domain.com > <mailto:08679c4228983f9e65f3b47f767b6...@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 > 08679c4228983f9e65f3b47f767b6...@voip.domain.com > <mailto:08679c4228983f9e65f3b47f767b6...@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 > 08679c4228983f9e65f3b47f767b6...@voip.domain.com > <mailto:08679c4228983f9e65f3b47f767b6...@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 > 08679c4228983f9e65f3b47f767b6...@voip.domain.com > <mailto:08679c4228983f9e65f3b47f767b6...@voip.domain.com> - <script>: > Malformed SIP request from 172.30.154.189:5060 > <http://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 > <mico...@gmail.com <mailto:mico...@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 >> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com >> <mailto: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 >> <mailto: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 >> <mailto: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 <mailto: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 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@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@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 >> <http://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 >> <mailto: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 >> <mailto: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 >> <mailto: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 >> <mailto: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 <mailto:sr-users@lists.kamailio.org> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> > www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > Funding: https://www.paypal.me/dcmierla > -- 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 sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users