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
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@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:
- Why does Kamailio think the request URI of this re-invite is
something other than what $mb reveals it to be?
Is that, presumably, why it does not match 'myself'?
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@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=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@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:
- Why does Kamailio think the request URI of this re-invite is
something other than what $mb reveals it to be?
Is that, presumably, why it does not match 'myself'?
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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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:
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@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:$spto 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:
- Why does Kamailio think the request URI of this re-invite is
something other than what $mb reveals it to be?
Is that, presumably, why it does not match 'myself'?
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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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:
- Why does Kamailio think the request URI of this re-invite is
something other than what $mb reveals it to be?
Is that, presumably, why it does not match 'myself'?
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@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@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/
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@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@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@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:$spto 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:
- Why does Kamailio think the request URI of this re-invite is
something other than what $mb reveals it to be?
Is that, presumably, why it does not match 'myself'?
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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
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,
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:
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
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
-
Alex Balashov -
Daniel-Constantin Mierla -
M S