20 May
2014
20 May
'14
7:37 p.m.
I am trying to diagnose a SIP issue between our carrier and our network. The carrier has a
CARRIER_IP and a different CARRIER_MEDIA_IP, and it submits an INVITE packet to
MY_PUBLIC_IP using MY_DID. The firewall at our public IP (where the attached traffic
sample was taken) redirects it to a particular Kamailio server at 192.168.10.10 inside the
LAN, and it in turn routes it to the Asterisk instance in localhost. The issue is that the
INVITE is received, then the SIP/2.0 100 Trying and then SIP/2.0 200 OK
are routed back (or so I think), and then the expected ACK from is never received, even
though the caller already hears the media from the Asterisk IVR. After a timeout, our
Asterisk closes the call, in the middle of the conversation.
I am trying to explain the situation to our carrier, but I want to rule out possible
misconfigurations on our side. Are there common misconfigurations that produce the
symptoms described here? Are there any issues evident from the attached traffic?
21 May
21 May
1:52 a.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
Alex Villacís Lasso writes:
I am trying to explain the situation to our carrier,
but I want to
rule out possible misconfigurations on our side. Are there common
misconfigurations that produce the symptoms described here? Are there
any issues evident from the attached traffic?
200 ok matches invite if from tag matches, call id matches and cseq is
the same as in invite.
-- juha
11:28 a.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
El 21/05/14 00:52, Juha Heinanen escribió:
Alex Villacís Lasso writes:
All of these look like a match from my side, between the received INVITE and the
200 OK. Are there any other issues that could be picked up from the sample traffic?
I am trying to explain the situation to our
carrier, but I want to
rule out possible misconfigurations on our side. Are there common
misconfigurations that produce the symptoms described here? Are there
any issues evident from the attached traffic?
200 ok matches invite if from tag
matches, call id matches and cseq is
the same as in invite.
12:41 p.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
El 21/05/14 10:28, Alex Villacís Lasso escribió:
El 21/05/14 00:52, Juha Heinanen escribió:
For more information, the carrier has said that the remote device is a Nextone.
Alex Villacís Lasso writes:
All of these look like a match from my side, between the received INVITE and the
200 OK. Are there any other issues that could be picked up from the sample traffic?
I am trying to explain the situation to our
carrier, but I want to
rule out possible misconfigurations on our side. Are there common
misconfigurations that produce the symptoms described here? Are there
any issues evident from the attached traffic?
200 ok matches invite if from tag
matches, call id matches and cseq is
the same as in invite.
23 May
23 May
8:02 p.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
El 21/05/14 11:41, Alex Villacís Lasso escribió:
El 21/05/14 10:28, Alex Villacís Lasso escribió:
My current working theory is that the Record-Route headers are incorrect in the original
trace. The trace, as captured in the firewall, looks like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=b18bbcc394bb5dae43946b12f5d5fe0e
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
The first value is 127.0.0.1 and the second one is 192.168.10.10 . I believe that when
received by 38.126.208.41, this is interpreted as a request to send the ACK to the remote
server's idea of 192.168.10.10, which breaks routing back to my server.
Now a bit of background. The firewall is a Linux (Zentyal) system that is rewriting the
SIP traffic before routing it between the Kamailio (inside the LAN) and the carrier IP
(38.126.208.41). This rewrite (kernel modules nf_conntrack_sip, nf_nat_sip)
affects the Via and To headers but leaves the Record-Route header unchanged, which causes
the issue. I think I have to force a Record-Route header that shows my public IP where the
192.168.10.10 is currently shown. However, this is becoming difficult.
When I use record_route() (original situation), I get the following set of headers:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=b18bbcc394bb5dae43946b12f5d5fe0e
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
If I figure out that the SIP dialog is crossing the NAT firewall, and use
record_route_advertised_address(), I end up with the following headers at the firewall:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=a54dd5cb61364e93c84315902262fab8
Record-Route:
<sip:201.234.196.171;ftag=3609873405-620577;lr=on;vsf=AAAAAGhZVFtaUHNUW1lMRAAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
Please note that record_route_advertised_address() is inserting just one value (not two,
despite relying on the rr parameter enable_double_rr to remain at its default value of
ON), with the value of my public IP. This results in the ACK packet being sent
from the carrier IP, and routed through the firewall and to the Kamailio server. However,
once there, it is not further routed to the Asterisk instance at 127.0.0.1:5080, which
results in the same situation as before.
If I try to call both record_route() and record_route_advertised_address() , in any order,
I get the behavior matching the first call, and the second call is ignored with a message
in the logs stating "Double attempt to record-route".
If I try using record_route() along with set_advertised_address(), I get the following set
of headers:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=d7bd9bac7e62d56026365e5aa7b257f7
Record-Route:
<sip:201.234.196.171;r2=on;lr=on;ftag=3609874172-119227;vsf=AAAAAGhZVl9aUXtSUllBRQAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609874172-119227;vsf=AAAAAGhZVl9aUXtSUllBRQAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
That is, I get 127.0.0.1 replaced with the public IP, and the private IP remains in place
as the last value. This again results in ACK never reaching the firewall, much less the
Kamailio server.
What I think is needed is a way to *conditionally* make Kamailio emit, from inside the
LAN, a packet like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=blah
Record-Route: <sip:127.0.0.1;r2=on;lr=on;blah...>
Record-Route: <sip:201.234.196.171;r2=on;lr=on;blah...>
The network administrator is reluctant to expose the Kamailio server directly to the
internet, but that setup does work for the short time it was tried. That setup resulted in
a 200 OK packet exactly like what I show above.
Is this analysis sensible? If so, is there a way to do what I want? If not, could this
work if the kernel SIP modules at the firewall are blacklisted and Kamailio is made to do
all the heavy lifting itself?
Is there an equivalent of the Asterisk "localnet" configuration keyword that
disables the "externip" setting for packets from select networks, but that works
with Kamailio? The internal LAN holds all the phones and they break if they see the
advertised
external IP instead of a local one.
El 21/05/14 00:52, Juha Heinanen escribió:
For more information, the carrier has said that the remote device is a Nextone. Alex Villacís Lasso writes:
All of these look like a match from my side, between the received INVITE and the
200 OK. Are there any other issues that could be picked up from the sample traffic? I am trying to explain the situation to our
carrier, but I want to
rule out possible misconfigurations on our side. Are there common
misconfigurations that produce the symptoms described here? Are there
any issues evident from the attached traffic?
200 ok matches invite if from tag
matches, call id matches and cseq is
the same as in invite.
11:23 p.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
>>>> "AVL" == Alex Villacís
Lasso <a_villacis(a)palosanto.com> writes:
AVL> could this work if the kernel SIP modules at the firewall are
AVL> blacklisted and Kamailio is made to do all the heavy lifting itself?
There has been quite a bit of advice on various sip-related lists over
the last decade to avoid the sip conntrack module, everything from low
key to hyperbolic.
So having kamailio do the rewriting is a good thing to test.
I'd also test having asterisk use the 192.168 ip rather than the 127/8.
Give it a port other than 5060, of course. Or you can give the box a
second 192.168 address, one each for kama and ast.
It may make a difference. Or not. But it seems worth a test.
What you describe matches a deployment I'm planning, but it is still in
the planning stage. (A remote outside the nat handles things for now.)
SO I'm interested in what is needed to make it work.
-JimC
--
James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
26 May
26 May
12:05 p.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
My current working theory is that the Record-Route
headers are incorrect in the original trace. The trace, as captured in the firewall, looks
like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=b18bbcc394bb5dae43946b12f5d5fe0e
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
The first value is 127.0.0.1 and the second one is 192.168.10.10 . I believe that when
received by 38.126.208.41, this is interpreted as a request to send the ACK to the remote
server's idea of 192.168.10.10, which breaks routing back to my server.
Now a bit of background. The firewall is a Linux (Zentyal) system that is rewriting the
SIP traffic before routing it between the Kamailio (inside the LAN) and the carrier IP
(38.126.208.41). This rewrite (kernel modules nf_conntrack_sip, nf_nat_sip)
affects the Via and To headers but leaves the Record-Route header unchanged, which causes
the issue. I think I have to force a Record-Route header that shows my public IP where the
192.168.10.10 is currently shown. However, this is becoming difficult.
When I use record_route() (original situation), I get the following set of headers:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=b18bbcc394bb5dae43946b12f5d5fe0e
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
If I figure out that the SIP dialog is crossing the NAT firewall, and use
record_route_advertised_address(), I end up with the following headers at the firewall:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=a54dd5cb61364e93c84315902262fab8
Record-Route:
<sip:201.234.196.171;ftag=3609873405-620577;lr=on;vsf=AAAAAGhZVFtaUHNUW1lMRAAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
Please note that record_route_advertised_address() is inserting just one value (not two,
despite relying on the rr parameter enable_double_rr to remain at its default value of
ON), with the value of my public IP. This results in the ACK packet being sent
from the carrier IP, and routed through the firewall and to the Kamailio server. However,
once there, it is not further routed to the Asterisk instance at 127.0.0.1:5080, which
results in the same situation as before.
If I try to call both record_route() and record_route_advertised_address() , in any
order, I get the behavior matching the first call, and the second call is ignored with a
message in the logs stating "Double attempt to record-route".
If I try using record_route() along with set_advertised_address(), I get the following
set of headers:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=d7bd9bac7e62d56026365e5aa7b257f7
Record-Route:
<sip:201.234.196.171;r2=on;lr=on;ftag=3609874172-119227;vsf=AAAAAGhZVl9aUXtSUllBRQAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609874172-119227;vsf=AAAAAGhZVl9aUXtSUllBRQAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
That is, I get 127.0.0.1 replaced with the public IP, and the private IP remains in place
as the last value. This again results in ACK never reaching the firewall, much less the
Kamailio server.
What I think is needed is a way to *conditionally* make Kamailio emit, from inside the
LAN, a packet like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=blah
Record-Route: <sip:127.0.0.1;r2=on;lr=on;blah...>
Record-Route: <sip:201.234.196.171;r2=on;lr=on;blah...>
The way I am trying to build the Record-Route headers is with this block:
# Value of $var(rr_advertise_address) is set in route(MHOMED_ELASTIX)
route[MHOMED_RR] {
if ($var(rr_advertise_address) != 0) {
xlog("L_ALERT", "MHOMED_RR using rr advertised address
$var(rr_advertise_address)\n");
record_route_advertised_address("$var(rr_advertise_address)");
} else {
record_route();
}
}
The idea is that, for calls that do not route to internal addresses in the LAN, I have to
set $var(rr_advertise_address), otherwise it remains as $null. If I do this, I get the
single Record-Route with the advertised address instead of two values (one with
the advertised address, the other with 127.0.0.1) as I would like it to run. However, if I
invoke record_route() unconditionally, I get the two header values.
Why the difference in behavior?
27 May
27 May
4:44 p.m.
New subject: Possible causes of calls being terminated (ACK packet never received)
El 26/05/14 11:05, Alex Villacís Lasso escribió:
Is there any additional information I might provide
to solve this?
My current working theory is that the
Record-Route headers are incorrect in the original trace. The trace, as captured in the
firewall, looks like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=b18bbcc394bb5dae43946b12f5d5fe0e
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
The first value is 127.0.0.1 and the second one is 192.168.10.10 . I believe that when
received by 38.126.208.41, this is interpreted as a request to send the ACK to the remote
server's idea of 192.168.10.10, which breaks routing back to my server.
Now a bit of background. The firewall is a Linux (Zentyal) system that is rewriting the
SIP traffic before routing it between the Kamailio (inside the LAN) and the carrier IP
(38.126.208.41). This rewrite (kernel modules nf_conntrack_sip, nf_nat_sip)
affects the Via and To headers but leaves the Record-Route header unchanged, which causes
the issue. I think I have to force a Record-Route header that shows my public IP where the
192.168.10.10 is currently shown. However, this is becoming difficult.
When I use record_route() (original situation), I get the following set of headers:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=b18bbcc394bb5dae43946b12f5d5fe0e
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609590102-643763;vsf=AAAAAGhZVlxTUnJZUllGSQAAAAAAAAAAAAAAAAAAOjEzNTI-;nat=yes>
If I figure out that the SIP dialog is crossing the NAT firewall, and use
record_route_advertised_address(), I end up with the following headers at the firewall:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=a54dd5cb61364e93c84315902262fab8
Record-Route:
<sip:201.234.196.171;ftag=3609873405-620577;lr=on;vsf=AAAAAGhZVFtaUHNUW1lMRAAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
Please note that record_route_advertised_address() is inserting just one value (not two,
despite relying on the rr parameter enable_double_rr to remain at its default value of
ON), with the value of my public IP. This results in the ACK packet being
sent from the carrier IP, and routed through the firewall and to the Kamailio server.
However, once there, it is not further routed to the Asterisk instance at 127.0.0.1:5080,
which results in the same situation as before.
If I try to call both record_route() and record_route_advertised_address() , in any
order, I get the behavior matching the first call, and the second call is ignored with a
message in the logs stating "Double attempt to record-route".
If I try using record_route() along with set_advertised_address(), I get the following
set of headers:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=d7bd9bac7e62d56026365e5aa7b257f7
Record-Route:
<sip:201.234.196.171;r2=on;lr=on;ftag=3609874172-119227;vsf=AAAAAGhZVl9aUXtSUllBRQAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
Record-Route:
<sip:192.168.10.10;r2=on;lr=on;ftag=3609874172-119227;vsf=AAAAAGhZVl9aUXtSUllBRQAAAAAAAAAAAAAAAAAAOjEwMzE-;nat=yes>
That is, I get 127.0.0.1 replaced with the public IP, and the private IP remains in place
as the last value. This again results in ACK never reaching the firewall, much less the
Kamailio server.
What I think is needed is a way to *conditionally* make Kamailio emit, from inside the
LAN, a packet like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 38.126.208.41:5060;rport=5060;branch=blah
Record-Route: <sip:127.0.0.1;r2=on;lr=on;blah...>
Record-Route: <sip:201.234.196.171;r2=on;lr=on;blah...>
The way I am trying to build the Record-Route headers is with this block:
# Value of $var(rr_advertise_address) is set in route(MHOMED_ELASTIX)
route[MHOMED_RR] {
if ($var(rr_advertise_address) != 0) {
xlog("L_ALERT", "MHOMED_RR using rr advertised address
$var(rr_advertise_address)\n");
record_route_advertised_address("$var(rr_advertise_address)");
} else {
record_route();
}
}
The idea is that, for calls that do not route to internal addresses in the LAN, I have to
set $var(rr_advertise_address), otherwise it remains as $null. If I do this, I get the
single Record-Route with the advertised address instead of two values (one
with the advertised address, the other with 127.0.0.1) as I would like it to run.
However, if I invoke record_route() unconditionally, I get the two header values.
Why the difference in behavior?
3886
days inactive
3893
days old
7 comments
3 participants
participants (3)
-
Alex Villacís Lasso -
James Cloos -
Juha Heinanen