8 Jul
2020
8 Jul
'20
9:30 a.m.
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(a)voip.domain.com
<mailto:2a859fcc4e1c8f840191a81d7c16e76d@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(a)voip.domain.com
<mailto:2a859fcc4e1c8f840191a81d7c16e76d@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(a)voip.domain.com
<mailto:2a859fcc4e1c8f840191a81d7c16e76d@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(a)gmail.com <mailto:georgediam@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
08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com
<mailto:08679c4228983f9e65f3b47f767b6e07@voip.domain.com> - sanity
[sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
DEBUG: {1 <null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com
<mailto:08679c4228983f9e65f3b47f767b6e07@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(a)voip.domain.com
<mailto:2a859fcc4e1c8f840191a81d7c16e76d@voip.domain.com> - sanity
[sanity.c:305]: check_required_headers(): check_required_headers
entered
DEBUG: {1 <null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com
<mailto:2a859fcc4e1c8f840191a81d7c16e76d@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(a)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