<div dir="ltr">The problem is caused by the second IF in your script block. You called loose_route which parses the Route headers and change RURI. So move the code block above second IF. Also you have already filtered method for INVITE so no need to apply method filter again in last IF.<div><br></div><div>Hope this helps.</div><div><br></div><div>Thank you.</div><div><br><div>--</div><div>M. S</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 14, 2018 at 7:19 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One curiosity is that the reinvite does not appear to have the Via from<br>
the UAC that sent the initial invite. But certainly that would not cause<br>
this behaviour?<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Aug 14, 2018 at 12:52:50PM -0400, Alex Balashov wrote:<br>
<br>
> Another aspect of this mystery: <br>
> <br>
> Here is the route set in the reinvite:<br>
> <br>
> Route: <sip:1.1.1.1:5061;transport=<wbr>tls;r2=on;lr=on;ftag=<wbr>gK00253981;vsf=<wbr>AAAAACERAR0RHQYQJVJ3GAUdAx0EAA<wbr>QfATEw;dlgcor=4411.f183;proxy_<wbr>media=yes><br>
> Route: <sip:1.1.1.1;r2=on;lr=on;ftag=<wbr>gK00253981;vsf=<wbr>AAAAACERAR0RHQYQJVJ3GAUdAx0EAA<wbr>QfATEw;dlgcor=4411.f183;proxy_<wbr>media=yes><br>
> Route: <<a href="http://sip:Restricted@3.3.3.3:5060">sip:Restricted@3.3.3.3:5060</a>;<wbr>lr><br>
> <br>
> The expectation would be that Kamailio would strip off its two Routes<br>
> and then relay this request to <a href="http://3.3.3.3:5060" rel="noreferrer" target="_blank">3.3.3.3:5060</a>, even if the RURI says to<br>
> relay the request to itself. <br>
> <br>
> But that's not what actually happens. Kamailio clearly forwards the<br>
> request to itself, as per the RURI, because the next log message we see<br>
> is:<br>
> <br>
> [R-MAIN:...] Re-INVITE received from <a href="http://1.1.1.1:5060" rel="noreferrer" target="_blank">1.1.1.1:5060</a> to RURI sip:Restricted@3.3.3.3:5060;lr<br>
> <br>
> Um, what?<br>
> <br>
> Here is the full logged reinvite, for reference:<br>
> <br>
> ---<br>
> <br>
> INVITE sip:<a href="http://1.1.1.1:5061" rel="noreferrer" target="_blank">1.1.1.1:5061</a> SIP/2.0<br>
> CSeq: 2 INVITE<br>
> To: <<a href="mailto:sip%3Astricted@3.3.3.3">sip:stricted@3.3.3.3</a>>;tag=<wbr>gK00253981<br>
> From: <<a href="mailto:sip%3A%2B17023880118@1.1.1.1">sip:+17023880118@1.1.1.1</a>>;<wbr>tag=8812465_1533349860<br>
> Call-ID: <a href="mailto:992000768_14572846@3.3.3.3">992000768_14572846@3.3.3.3</a><br>
> Via: SIP/2.0/TLS 4.4.4.4:5061;rport;branch=<wbr>z9hG4bK845565_1533349860<br>
> Route: <sip:1.1.1.1:5061;transport=<wbr>tls;r2=on;lr=on;ftag=<wbr>gK00253981;vsf=<wbr>AAAAACERAR0RHQYQJVJ3GAUdAx0EAA<wbr>QfATEw;dlgcor=4411.f183;proxy_<wbr>media=yes><br>
> Route: <sip:1.1.1.1;r2=on;lr=on;ftag=<wbr>gK00253981;vsf=<wbr>AAAAACERAR0RHQYQJVJ3GAUdAx0EAA<wbr>QfATEw;dlgcor=4411.f183;proxy_<wbr>media=yes><br>
> Route: <<a href="http://sip:Restricted@3.3.3.3:5060">sip:Restricted@3.3.3.3:5060</a>;<wbr>lr><br>
> User-Agent: ClownCar WhoKnows<br>
> Max-Forwards: 32<br>
> ASupportedCodec: 0 8<br>
> Contact: <<a href="http://sip:MyTrunk@4.4.4.4:5061">sip:MyTrunk@4.4.4.4:5061</a>;<wbr>transport=tls><br>
> Supported: em,timer,replaces,path,<wbr>resource-priority<br>
> Allow: REGISTER,OPTIONS,INVITE,ACK,<wbr>CANCEL,BYE,NOTIFY,PRACK,REFER,<wbr>INFO,SUBSCRIBE,UPDATE<br>
> Content-Type: application/sdp<br>
> Content-Length: 303<br>
> <br>
> v=0<br>
> o=ClownCar 1534262664 1534262665 IN IP4 4.4.4.4<br>
> s=SIP Call<br>
> c=IN IP4 4.4.4.4<br>
> t=0 0<br>
> m=image 50104 udptl t38<br>
> a=T38FaxVersion:0<br>
> a=T38FaxMaxBuffer:1024<br>
> a=T38FaxMaxDatagram:238<br>
> a=T38FaxRateManagement:<wbr>transferredTCF<br>
> a=T38FaxUdpEC:t38UDPRedundancy<br>
> a=T38MaxBitRate:14400<br>
> a=sendrecv<br>
> <br>
> -- Alex<br>
> <br>
> On Tue, Aug 14, 2018 at 12:44:21PM -0400, Alex Balashov wrote:<br>
> <br>
> > Hi,<br>
> > <br>
> > We have a scenario like this:<br>
> > <br>
> > ITSP -----> Kamailio -----> Endpoint<br>
> > (UDP) (TLS)<br>
> > <br>
> > So, TLS is only being used on the last hop, and the upstream interaction<br>
> > with the ITSP is plain-old UDP.<br>
> > <br>
> > Kamailio has the following listeners:<br>
> > <br>
> > listen=udp:<a href="http://1.1.1.1:5060" rel="noreferrer" target="_blank">1.1.1.1:5060</a><br>
> > listen=udp:<a href="http://1.1.1.2:5060" rel="noreferrer" target="_blank">1.1.1.2:5060</a><br>
> > listen=tcp:<a href="http://10.0.0.1:5060" rel="noreferrer" target="_blank">10.0.0.1:5060</a><br>
> > listen=tls:<a href="http://1.1.1.1:5061" rel="noreferrer" target="_blank">1.1.1.1:5061</a><br>
> > <br>
> > At some point, 'Endpoint' sends a reinvite which has the following RURI:<br>
> > <br>
> > INVITE sip:<a href="http://1.1.1.1:5061" rel="noreferrer" target="_blank">1.1.1.1:5061</a> SIP/2.0<br>
> > <br>
> > This is clearly improper, and caused a loop that led to the rtpengine<br>
> > SDP loop issue I previously reported in another thread.<br>
> > <br>
> > So, in an effort to stop this, I added the following:<br>
> > <br>
> > if(has_totag()) {<br>
> > if(loose_route()) {<br>
> > ...<br>
> > <br>
> > if(is_method("INVITE")) {<br>
> > xlog("L_INFO", "[R-MAIN:$ci] Re-INVITE received from $si:$sp to RURI $ru\n");<br>
> > xlog("L_INFO", "[R-MAIN:$ci] Reinvite body: $mb\n");<br>
> > <br>
> > if(!is_method("ACK") && uri == myself) { <br>
> > sl_send_reply("400", "Bad Request");<br>
> > exit;<br>
> > }<br>
> > }<br>
> > }<br>
> > <br>
> > But it doesn't work. It appears that the '400 Bad Request' rejection<br>
> > never happens, presumably because the this domain doesn't match<br>
> > 'myself'.<br>
> > <br>
> > Another perplexing mystery: the log message containing the reinvite's<br>
> > '$ru' does not show a RURI of 'sip:<a href="http://1.1.1.1:5061" rel="noreferrer" target="_blank">1.1.1.1:5061</a>', but rather the remote<br>
> > target in the initial inbound INVITE, which we also logged:<br>
> > <br>
> > Contact: "Anonymous" <<a href="http://sip:Restricted@3.3.3.3:5060" rel="noreferrer" target="_blank">sip:Restricted@3.3.3.3:5060</a>><br>
> > <br>
> > The log message says:<br>
> > <br>
> > [R-MAIN:...] Re-INVITE received from <a href="http://4.4.4.4:5060" rel="noreferrer" target="_blank">4.4.4.4:5060</a> to RURI <a href="http://sip:Restricted@3.3.3.3:5060">sip:Restricted@3.3.3.3:5060</a>;<wbr>lr.<br>
> > <br>
> > Note a subtle detail here: the ';lr' parameter is present, which is an<br>
> > attribute of the Record-Route inserted by the sending ITSP (3.3.3.3).<br>
> > It's at the bottom of the Route set, of course, below Kamailio's two RRs<br>
> > (inserted for the ingress UDP interface and the egress TLS interface):<br>
> > <br>
> > Route: <<a href="http://sip:Restricted@3.3.3.3:5060">sip:Restricted@3.3.3.3:5060</a>;<wbr>lr><br>
> > <br>
> > This leads to two questions whose causes seem to be related:<br>
> > <br>
> > 1. Why does Kamailio think the request URI of this re-invite is<br>
> > something other than what $mb reveals it to be?<br>
> > <br>
> > 2. Is that, presumably, why it does not match 'myself'?<br>
> > <br>
> > 3. Why would Kamailio think it is actually set to the far-end<br>
> > Record-Route URI?<br>
> > <br>
> > This is version: kamailio 4.4.5 (x86_64/linux) d48094.<br>
> > <br>
> > Thanks,<br>
> > <br>
> > -- Alex<br>
> > <br>
> > -- <br>
> > Alex Balashov | Principal | Evariste Systems LLC<br>
> > <br>
> > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
> > Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
> > <br>
> > ______________________________<wbr>_________________<br>
> > Kamailio (SER) - Users Mailing List<br>
> > <a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
> > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
> <br>
> -- <br>
> Alex Balashov | Principal | Evariste Systems LLC<br>
> <br>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
> Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
> <br>
> ______________________________<wbr>_________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
______________________________<wbr>_________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
</div></div></blockquote></div><br></div>