14 Aug
2018
14 Aug
'18
11:11 p.m.
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:
--
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/
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@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@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@3.3.3.3>;tag=gK00253981
From: <sip:+17023880118@1.1.1.1>;tag=8812465_1533349860
Call-ID: 992000768_14572846(a)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@3.3.3.3:5060;lr>
User-Agent: ClownCar WhoKnows
Max-Forwards: 32
ASupportedCodec: 0 8
Contact: <sip:MyTrunk@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:
--
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/ 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@3.3.3.3:5060>
The log message says:
[R-MAIN:...] Re-INVITE received from 4.4.4.4:5060 to RURI
sip:Restricted@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@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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users