[SR-Users] Very strange reinvite behaviour
M S
shaheryarkh at gmail.com
Tue Aug 14 23:40:09 CEST 2018
It would be good if you can provide the full sip trace that includes the
initial INVITE processing of both call legs.
Per SIP v2.0 RFCs (3261, 3665 & 6141), when callee needs to send a
sequential request e.g. a re-invite, it should use the Contact header it
received in initial INVITE as RURI. Since the RURI and top most Route
header(s), all point to kamailio itself, so kamailio sees it as strict
routing rather then loose routing, and as a result loop occurs.
So basically the callee needs to set correct RURI in re-invite (the
original Contact header in initial INVITE request from ITSP). If however
the callee can NOT fix this problem then you will have store the original
Contact header in initial INVITE from caller side somewhere in kamailio
script e.g. htable, and change RURI to this value BEFORE calling loose
route. Which should fix the problem.
Hope this helps.
Thank you.
--
M. S
On Tue, Aug 14, 2018 at 10:11 PM, Alex Balashov <abalashov at evaristesys.com>
wrote:
> 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=AAAAACERAR0RHQYQJVJ3GAUdAx0EAA
> QfATEw;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=AAAAACERAR0RHQYQJVJ3GAUdAx0EAA
> QfATEw;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/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180814/6c95a2cd/attachment.html>
More information about the sr-users
mailing list