Yes, there is a typoed brace that is in reality located elsewhere. That is not the salient feature of this scenario. The if blocks are separate, as you'd expect them to be.
loose_route() will parse the Route headers and remove the local ones, and may set the destination set appropriately, but will _not_ change the RURI. The RURI stays the same. On Tue, Aug 14, 2018 at 01:19:54PM -0400, Alex Balashov wrote: > One curiosity is that the reinvite does not appear to have the Via from > the UAC that sent the initial invite. But certainly that would not cause > this behaviour? > > On Tue, Aug 14, 2018 at 12:52:50PM -0400, Alex Balashov wrote: > > > Another aspect of this mystery: > > > > Here is the route set in the reinvite: > > > > Route: > > <sip:1.1.1.1:5061;transport=tls;r2=on;lr=on;ftag=gK00253981;vsf=AAAAACERAR0RHQYQJVJ3GAUdAx0EAAQfATEw;dlgcor=4411.f183;proxy_media=yes> > > Route: > > <sip:1.1.1.1;r2=on;lr=on;ftag=gK00253981;vsf=AAAAACERAR0RHQYQJVJ3GAUdAx0EAAQfATEw;dlgcor=4411.f183;proxy_media=yes> > > Route: <sip:[email protected]:5060;lr> > > > > The expectation would be that Kamailio would strip off its two Routes > > and then relay this request to 3.3.3.3:5060, even if the RURI says to > > relay the request to itself. > > > > But that's not what actually happens. Kamailio clearly forwards the > > request to itself, as per the RURI, because the next log message we see > > is: > > > > [R-MAIN:...] Re-INVITE received from 1.1.1.1:5060 to RURI > > sip:[email protected]:5060;lr > > > > Um, what? > > > > Here is the full logged reinvite, for reference: > > > > --- > > > > INVITE sip:1.1.1.1:5061 SIP/2.0 > > CSeq: 2 INVITE > > To: <sip:[email protected]>;tag=gK00253981 > > From: <sip:[email protected]>;tag=8812465_1533349860 > > Call-ID: [email protected] > > Via: SIP/2.0/TLS 4.4.4.4:5061;rport;branch=z9hG4bK845565_1533349860 > > Route: > > <sip:1.1.1.1:5061;transport=tls;r2=on;lr=on;ftag=gK00253981;vsf=AAAAACERAR0RHQYQJVJ3GAUdAx0EAAQfATEw;dlgcor=4411.f183;proxy_media=yes> > > Route: > > <sip:1.1.1.1;r2=on;lr=on;ftag=gK00253981;vsf=AAAAACERAR0RHQYQJVJ3GAUdAx0EAAQfATEw;dlgcor=4411.f183;proxy_media=yes> > > Route: <sip:[email protected]:5060;lr> > > User-Agent: ClownCar WhoKnows > > Max-Forwards: 32 > > ASupportedCodec: 0 8 > > Contact: <sip:[email protected]:5061;transport=tls> > > Supported: em,timer,replaces,path,resource-priority > > Allow: > > REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE > > Content-Type: application/sdp > > Content-Length: 303 > > > > v=0 > > o=ClownCar 1534262664 1534262665 IN IP4 4.4.4.4 > > s=SIP Call > > c=IN IP4 4.4.4.4 > > t=0 0 > > m=image 50104 udptl t38 > > a=T38FaxVersion:0 > > a=T38FaxMaxBuffer:1024 > > a=T38FaxMaxDatagram:238 > > a=T38FaxRateManagement:transferredTCF > > a=T38FaxUdpEC:t38UDPRedundancy > > a=T38MaxBitRate:14400 > > a=sendrecv > > > > -- Alex > > > > On Tue, Aug 14, 2018 at 12:44:21PM -0400, Alex Balashov wrote: > > > > > Hi, > > > > > > We have a scenario like this: > > > > > > ITSP -----> Kamailio -----> Endpoint > > > (UDP) (TLS) > > > > > > So, TLS is only being used on the last hop, and the upstream interaction > > > with the ITSP is plain-old UDP. > > > > > > Kamailio has the following listeners: > > > > > > listen=udp:1.1.1.1:5060 > > > listen=udp:1.1.1.2:5060 > > > listen=tcp:10.0.0.1:5060 > > > listen=tls:1.1.1.1:5061 > > > > > > At some point, 'Endpoint' sends a reinvite which has the following RURI: > > > > > > INVITE sip:1.1.1.1:5061 SIP/2.0 > > > > > > This is clearly improper, and caused a loop that led to the rtpengine > > > SDP loop issue I previously reported in another thread. > > > > > > So, in an effort to stop this, I added the following: > > > > > > if(has_totag()) { > > > if(loose_route()) { > > > ... > > > > > > if(is_method("INVITE")) { > > > xlog("L_INFO", "[R-MAIN:$ci] Re-INVITE received from $si:$sp to > > > RURI $ru\n"); > > > xlog("L_INFO", "[R-MAIN:$ci] Reinvite body: $mb\n"); > > > > > > if(!is_method("ACK") && uri == myself) { > > > sl_send_reply("400", "Bad Request"); > > > exit; > > > } > > > } > > > } > > > > > > But it doesn't work. It appears that the '400 Bad Request' rejection > > > never happens, presumably because the this domain doesn't match > > > 'myself'. > > > > > > Another perplexing mystery: the log message containing the reinvite's > > > '$ru' does not show a RURI of 'sip:1.1.1.1:5061', but rather the remote > > > target in the initial inbound INVITE, which we also logged: > > > > > > Contact: "Anonymous" <sip:[email protected]:5060> > > > > > > The log message says: > > > > > > [R-MAIN:...] Re-INVITE received from 4.4.4.4:5060 to RURI > > > sip:[email protected]:5060;lr. > > > > > > Note a subtle detail here: the ';lr' parameter is present, which is an > > > attribute of the Record-Route inserted by the sending ITSP (3.3.3.3). > > > It's at the bottom of the Route set, of course, below Kamailio's two RRs > > > (inserted for the ingress UDP interface and the egress TLS interface): > > > > > > Route: <sip:[email protected]:5060;lr> > > > > > > This leads to two questions whose causes seem to be related: > > > > > > 1. Why does Kamailio think the request URI of this re-invite is > > > something other than what $mb reveals it to be? > > > > > > 2. Is that, presumably, why it does not match 'myself'? > > > > > > 3. Why would Kamailio think it is actually set to the far-end > > > Record-Route URI? > > > > > > This is version: kamailio 4.4.5 (x86_64/linux) d48094. > > > > > > Thanks, > > > > > > -- Alex > > > > > > -- > > > Alex Balashov | Principal | Evariste Systems LLC > > > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > > > > > _______________________________________________ > > > Kamailio (SER) - Users Mailing List > > > [email protected] > > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > > Alex Balashov | Principal | Evariste Systems LLC > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
