[SR-Users] Very strange reinvite behaviour
Alex Balashov
abalashov at evaristesys.com
Tue Aug 14 22:11:36 CEST 2018
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:Restricted at 3.3.3.3: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:Restricted at 3.3.3.3: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:stricted at 3.3.3.3>;tag=gK00253981
> > From: <sip:+17023880118 at 1.1.1.1>;tag=8812465_1533349860
> > Call-ID: 992000768_14572846 at 3.3.3.3
> > 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:Restricted at 3.3.3.3:5060;lr>
> > User-Agent: ClownCar WhoKnows
> > Max-Forwards: 32
> > ASupportedCodec: 0 8
> > Contact: <sip:MyTrunk at 4.4.4.4: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:Restricted at 3.3.3.3:5060>
> > >
> > > The log message says:
> > >
> > > [R-MAIN:...] Re-INVITE received from 4.4.4.4:5060 to RURI sip:Restricted at 3.3.3.3: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:Restricted at 3.3.3.3: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
> > > sr-users at lists.kamailio.org
> > > 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
> > sr-users at lists.kamailio.org
> > 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/
More information about the sr-users
mailing list