14 Aug
2018
14 Aug
'18
7:44 p.m.
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/
14 Aug
14 Aug
7:52 p.m.
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:
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/
8:19 p.m.
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@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 
8:36 p.m.
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.
Hope this helps.
Thank you.
--
M. S
On Tue, Aug 14, 2018 at 7:19 PM, Alex Balashov <abalashov(a)evaristesys.com>
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/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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:
> 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
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
15 Aug
15 Aug
12:40 a.m.
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(a)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:
--
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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=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@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:
>
> > 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
1:51 a.m.
On Tue, Aug 14, 2018 at 11:40:09PM +0200, M S wrote:
It would be good if you can provide the full sip trace
that includes the
initial INVITE processing of both call legs.
That's not going to be (easily) possible in this case, due to one leg
being TLS.
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.
Yes. My question was about the inconsistency between the apparent RURI
and the message attributes logged.
-- 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/
1:43 p.m.
At a quick glance, it looks like a mixture of strict/loose route
processing due to previous hop not setting proper URI.
If R-URI is local address, then it means the previous hop was a strict
router. Kamailio tries to switch to loose routing, due to lr parameter,
doing the logic of:
- last Route becomes R-URI, overwriting the incoming R-URI (which was
local address) and last Route header is deleted
- send to top Route header
In strict routing, R-URI is the address of next hop and the last Route
is the far end. In loose routing, R-URI is the far end and top Route is
next hop. Here seems to be the moment of switching from strict to loose
routing.
The UA building the request (or the previous hop) seems to be rather
broken, because it adds lr even to the contact address (last Route),
even it acts as a strict router.
If you use dialog module in that instance, there is a function to push
to R-URI the contact for that side, as saved in the dialog structure.
You can do that before calling loose_route(), if R-URI host is your IP
(I would avoid using myself on R-URI received from the UA, because if it
is messing with the ports/protocols, there can be a mismatch of myself).
Cheers,
Daniel
On 15.08.18 00:51, Alex Balashov wrote:
On Tue, Aug 14, 2018 at 11:40:09PM +0200, M S wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
It would be good if you can provide the full sip
trace that includes the
initial INVITE processing of both call legs.
That's not going to be (easily)
possible in this case, due to one leg
being TLS.
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.
Yes. My question
was about the inconsistency between the apparent RURI
and the message attributes logged.
-- Alex
5:38 p.m.
Daniel,
Thank you for this interpretation. I suspected this might be the cause,
but didn't know enough about how non-LR works to merit that speculation.
Strict routing mostly exists for 2543 compatibility, right?
On Wed, Aug 15, 2018 at 12:43:57PM +0200, Daniel-Constantin Mierla wrote:
At a quick glance, it looks like a mixture of
strict/loose route
processing due to previous hop not setting proper URI.
If R-URI is local address, then it means the previous hop was a strict
router. Kamailio tries to switch to loose routing, due to lr parameter,
doing the logic of:
- last Route becomes R-URI, overwriting the incoming R-URI (which was
local address) and last Route header is deleted
- send to top Route header
In strict routing, R-URI is the address of next hop and the last Route
is the far end. In loose routing, R-URI is the far end and top Route is
next hop. Here seems to be the moment of switching from strict to loose
routing.
The UA building the request (or the previous hop) seems to be rather
broken, because it adds lr even to the contact address (last Route),
even it acts as a strict router.
If you use dialog module in that instance, there is a function to push
to R-URI the contact for that side, as saved in the dialog structure.
You can do that before calling loose_route(), if R-URI host is your IP
(I would avoid using myself on R-URI received from the UA, because if it
is messing with the ports/protocols, there can be a mismatch of myself).
Cheers,
Daniel
On 15.08.18 00:51, 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/
On Tue, Aug 14, 2018 at 11:40:09PM +0200, M S
wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
It would be good if you can provide the full sip
trace that includes the
initial INVITE processing of both call legs.
That's not going to be (easily)
possible in this case, due to one leg
being TLS.
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.
Yes. My question
was about the inconsistency between the apparent RURI
and the message attributes logged.
-- Alex
5:56 p.m.
On 15.08.18 16:38, Alex Balashov wrote:
Daniel,
Thank you for this interpretation. I suspected this might be the cause,
but didn't know enough about how non-LR works to merit that speculation.
Strict routing mostly exists for 2543 compatibility, right?
Yes.
The strange thing here is that the UA adds ';lr' to contact address it
puts in Route, although it acts (or tries to) as a strict router, so if
it is a very old implementation, should not know about adding ';lr' if
not present (if present, should be preserved as any URI param).
So I would assume someone did a quick/ugly hack for a strict router to
'claim' it is updated for rfc3261, thinking that just adding ';lr' where
it is not would be all needed...
On Wed, Aug 15, 2018 at 12:43:57PM +0200, Daniel-Constantin Mierla wrote:
> At a quick glance, it looks like a mixture of strict/loose route
> processing due to previous hop not setting proper URI.
>
> If R-URI is local address, then it means the previous hop was a strict
> router. Kamailio tries to switch to loose routing, due to lr parameter,
> doing the logic of:
>
> - last Route becomes R-URI, overwriting the incoming R-URI (which was
> local address) and last Route header is deleted
> - send to top Route header
>
> In strict routing, R-URI is the address of next hop and the last Route
> is the far end. In loose routing, R-URI is the far end and top Route is
> next hop. Here seems to be the moment of switching from strict to loose
> routing.
>
> The UA building the request (or the previous hop) seems to be rather
> broken, because it adds lr even to the contact address (last Route),
> even it acts as a strict router.
>
> If you use dialog module in that instance, there is a function to push
> to R-URI the contact for that side, as saved in the dialog structure.
> You can do that before calling loose_route(), if R-URI host is your IP
> (I would avoid using myself on R-URI received from the UA, because if it
> is messing with the ports/protocols, there can be a mismatch of myself).
>
> Cheers,
> Daniel
>
> On 15.08.18 00:51, Alex Balashov wrote:
>> On Tue, Aug 14, 2018 at 11:40:09PM +0200, M S wrote:
>>
>>> It would be good if you can provide the full sip trace that includes the
>>> initial INVITE processing of both call legs.
>> That's not going to be (easily) possible in this case, due to one leg
>> being TLS.
>>
>>> 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.
>> Yes. My question was about the inconsistency between the apparent RURI
>> and the message attributes logged.
>>
>> -- Alex
>>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
>
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
2294
days inactive
2295
days old
9 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
M S