27 Feb
2015
27 Feb
'15
9:04 a.m.
Hi,
while testing IPv6 with customers, we fell over quite a few cases, where
customers aren't reachable on inbound calls most of the time. And digging
into this, we found the home router firewall as the cause for those
problems.
Normally, you would think, all the NAT problems cease when switching to
IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the registration,
and Kamailio would send NAT pings (those 4 bytes of UDP junk) every few
seconds to keep the firewall in the NAT router open. And that worked pretty
great.
Now we have IPv6. We don't have NAT. But we still have a home router in
front of SIP devices, with a firewall. And this firewall will allow
outbound traffic. But after a few seconds it won't allow incoming
connections anymore. And the routers I have seen so far don't have a
configurable firewall where you could allow inbound traffic from our server.
Unfortunately, only our load balancer is IPv6, our registrar is still IPv4
only. And the loadbalancer doesn't know anything about registrations and
which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks
in advance.
Best Regards,
Sebastian
9:53 a.m.
On Fri, Feb 27, 2015 at 9:35 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
how is it possible that a new sip phone that
implements ipv6 does not
implement tcp and ssl? or is it so that you don't want to use tcp?
Actually, it's the latter. Our current high availability setup reilies on
anycast. And with TCP, this would mean a huge change in our setup.
Best Regards,
Sebastian
--
Dipl.-Inf.
Sebastian Damm - VoIP-Engineer - damm(a)sipgate.de
Telefon: +49 (0)211-63 55 55-52
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.co.uk
9:59 a.m.
New subject: Registrations/TCP (new topic)
On 27 Feb 2015, at 09:53, Sebastian Damm <damm(a)sipgate.de> wrote:
Actually, it's the latter. Our current high
availability setup reilies on anycast. And with TCP, this would mean a huge change in our
setup.
That is in fact an interesting topic. Can you please elaborate a bit more on this
as I would like to see what we can
do in the software to make things easier.
I had a similar discussion a while ago and it seems like failover handling is easier in
UDP and we will need to fix this in order to be able to migrate more users to TLS.
I haven't tested how different clients behave in regards of TCP if the server close a
connection.
/O
11:15 a.m.
New subject: Registrations/TCP (new topic)
On Fri, Feb 27, 2015 at 9:59 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
Actually, it's the latter. Our current high
availability setup reilies on
anycast. And with TCP, this would mean a huge change in our setup.
That is in fact an interesting topic. Can you please elaborate a bit more
on this as I would like to see what we can
do in the software to make things easier.
I guess I can. Maybe the presentation of Krischan from last year's Kamailio
world will explain a lot:
http://www.kamailio.org/events/2014-KamailioWorld/day2/17-Krischan.Udelhove…
The setup on slide 9 is basically how our setup still looks like. We have a
few loadbalancers in different data centers sharing the same IP. And
depending on where the customer hits our network and how the call gets
routed, the loadbalancer handling the request and the one handling the
reply don't have to be the same. That's why UDP is so comfortable to work
with. We don't have a state, we don't care about the number of open TCP
sessions on one machine, and if one machine goes offline, OSPF makes sure,
the IP is still available.
When using TCP, we would have to make sure, every request leaves our
network on the same machine where it came in, because that's the machine
where the TCP session is open. That would mean to have a distinct OSPF
weight for each IP, so all packets always get routed to the same machine.
And that would mean, we probably would have to do a DNS round robin thing
to loadbalance the incoming traffic, since we wouldn't want to have all
traffic coming in on only one machine.
I had a similar discussion a while ago and it seems
like failover handling
is easier in UDP and we will need to fix this in order to be able to
migrate more users to TLS.
Yes, it for sure is a failover thing. We have a TCP and TLS server, too,
but this is not HA and only for test purposes right now. We probably would
use something with DNS RR, but aren't sure about how many clients we could
handle on one TCP or TLS machine. In our tests, we had about 16k sessions
open at the same time, but that would mean a lot of machines for all our
customers.
I haven't tested how different clients behave in
regards of TCP if the
server close a connection.
From what I saw with snom phones connected to the TLS
machine, when we
restart the Kamailio process, the clients aren't reachable for
inbound
calls until the next reregistration. They establish a new TCP connection
for an outbound call, but this connection can't be used for inbound calls.
After the next reregistration, everything is okay again.
Sebastian
3:11 p.m.
Hello,
On 27/02/15 09:26, Sebastian Damm wrote:
Hi,
On Fri, Feb 27, 2015 at 9:07 AM, Juha Heinanen <jh(a)tutpro.com
<mailto:jh@tutpro.com>> wrote:
Sebastian Damm writes:
I would use an extra branch flag here.
Keepalives are sent based on nat_bflag and sipping_bflag. You can set
both no matter it is actually a register from a natted phone or not.
The extra flag will be set to mark it is an IPv6 device.
When doing NAT handling inside the config file, if IPv6 branch flag is
set, you should not engage rtp relaying (unless it is gatewaying to
IPv4) or do other nat specific fixing to headers for the callee.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Does anyone have a hint, how to keep the IPv6
registrations
alive? Thanks
in advance.
use tcp.
Okay, should have added: UDP, please.
6:49 p.m.
On Fri, Feb 27, 2015 at 3:11 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
I would use an extra branch flag here.
Keepalives are sent based on nat_bflag and sipping_bflag. You can set both
no matter it is actually a register from a natted phone or not.
That's the solution we tried to implement this afternoon. We saved an
additional location entry on the loadbalancer (just as a proof of concept)
and then set the NAT flag configured for the nathelper module. Via kamcmd I
can see that the location entry is there. But I don't see any keepalives
being sent out. I even set the ping_nated_only parameter to 0 so that all
clients would get pings. On the proxy I can see them (for IPv4 cllients).
Is there anything special? This is what I did:
modparam("registrar", "max_contacts", 50)
modparam("registrar", "received_avp", "$(avp(i:801))")
modparam("registrar", "default_expires", 600)
modparam("registrar", "min_expires", 60)
modparam("registrar", "max_expires", 600)
modparam("registrar", "gruu_enabled", 0)
modparam("usrloc", "db_mode", 0)
modparam("usrloc", "nat_bflag", 4)
modparam("usrloc", "use_domain", 1)
modparam("usrloc", "hash_size", 14)
modparam("usrloc", "timer_interval", 180)
modparam("usrloc", "timer_procs", 4)
modparam("nathelper", "received_avp", "$(avp(i:801))")
modparam("nathelper", "natping_interval" , 14)
modparam("nathelper", "ping_nated_only" , 0)
modparam("nathelper", "sipping_bflag", 20)
modparam("nathelper", "sipping_from", "natping(a)sipgate.de")
And then in the onreply_route I added the following:
if (is_method("REGISTER") && $rs == 200) {
setbflag(4);
save("location");
}
(Again, this is just a proof of concept.)
Now I would expect to see NAT pings every 14 seconds to each registered
client. But I don't see any.
Does the NAT pinging work only for IPv4 maybe?
Best Regards,
Sebastian
9:33 a.m.
On 27 Feb 2015, at 09:04, Sebastian Damm <damm(a)sipgate.de> wrote:
Hi,
while testing IPv6 with customers, we fell over quite a few cases, where customers
aren't reachable on inbound calls most of the time. And digging into this, we found
the home router firewall as the cause for those problems.
Normally, you would think, all the NAT problems cease when switching to IPv6. But
actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the registration, and Kamailio
would send NAT pings (those 4 bytes of UDP junk) every few seconds to keep the firewall in
the NAT router open. And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router in front of SIP
devices, with a firewall. And this firewall will allow outbound traffic. But after a few
seconds it won't allow incoming connections anymore. And the routers I have seen so
far don't have a configurable firewall where you could allow inbound traffic from our
server.
Unfortunately, only our load balancer is IPv6, our registrar is still IPv4 only. And the
loadbalancer doesn't know anything about registrations and which customer needs an
IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive? Thanks in advance.
AARGH. Now I see. Thank you. (Disregard earlier e-mail).
In all modern standards, like SIP Outbound, the need to send keep-alives has been pushed
to the client. They need to open a network flow and keep it open - UDP or TCP or TCP/TLS.
As we can't trust device developers to stay up to date, we may need IPv6 keepalives.
/O
2:41 p.m.
Hi Sebastian,
maybe it could be a solution to lower the registration interval for ipv6
users to ~30 seconds. This would keep the NAT pinhole open.
Of course this will cause high traffic + registrar load. To reduce this,
you could only require a authentication every ~20 minutes. For the
registers in between you could simply send a OK.
regards,
moritz
On 02/27/2015 09:04 AM, Sebastian Damm wrote:
Hi,
while testing IPv6 with customers, we fell over quite a few cases,
where customers aren't reachable on inbound calls most of the time.
And digging into this, we found the home router firewall as the cause
for those problems.
Normally, you would think, all the NAT problems cease when switching
to IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the
registration, and Kamailio would send NAT pings (those 4 bytes of UDP
junk) every few seconds to keep the firewall in the NAT router open.
And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router
in front of SIP devices, with a firewall. And this firewall will allow
outbound traffic. But after a few seconds it won't allow incoming
connections anymore. And the routers I have seen so far don't have a
configurable firewall where you could allow inbound traffic from our
server.
Unfortunately, only our load balancer is IPv6, our registrar is still
IPv4 only. And the loadbalancer doesn't know anything about
registrations and which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive?
Thanks in advance.
Best Regards,
Sebastian
--
Moritz Graf
G-FIT Gesellschaft für innovative Telekommunikationsdienste
mbH & Co. KG, Kommanditgesellschaft, Sitz Regensburg,
Registergericht Regensburg, HRA 7626;
Geschäftsführer: Dipl.Inf. (FH) Alfred Rauscher
2:52 p.m.
s/NAT pinhole open/connection alive/g
On 02/27/2015 02:41 PM, Moritz Graf wrote:
Hi Sebastian,
maybe it could be a solution to lower the registration interval for ipv6
users to ~30 seconds. This would keep the NAT pinhole open.
Of course this will cause high traffic + registrar load. To reduce this,
you could only require a authentication every ~20 minutes. For the
registers in between you could simply send a OK.
regards,
moritz
On 02/27/2015 09:04 AM, Sebastian Damm wrote:
--
Moritz Graf, M.Sc.
Betrieb NGN-Plattform
G-FIT GmbH & Co. KG
Greflingerstr. 26, 93055 Regensburg
Telefon +49 (9 41) 46299 - 1 86
Telefax +49 (9 41) 46299 - 2 86
mailto:moritz.graf@g-fit.de
http://www.g-fit.de
G-FIT Gesellschaft für innovative Telekommunikationsdienste
mbH & Co. KG, Kommanditgesellschaft, Sitz Regensburg,
Registergericht Regensburg, HRA 7626;
Geschäftsführer: Dipl.Inf. (FH) Alfred Rauscher
Hi,
while testing IPv6 with customers, we fell over quite a few cases,
where customers aren't reachable on inbound calls most of the time.
And digging into this, we found the home router firewall as the cause
for those problems.
Normally, you would think, all the NAT problems cease when switching
to IPv6. But actually, right now I don't know how to fix that problem.
In IPv4 NAT scenarios, we would flag the customer during the
registration, and Kamailio would send NAT pings (those 4 bytes of UDP
junk) every few seconds to keep the firewall in the NAT router open.
And that worked pretty great.
Now we have IPv6. We don't have NAT. But we still have a home router
in front of SIP devices, with a firewall. And this firewall will allow
outbound traffic. But after a few seconds it won't allow incoming
connections anymore. And the routers I have seen so far don't have a
configurable firewall where you could allow inbound traffic from our
server.
Unfortunately, only our load balancer is IPv6, our registrar is still
IPv4 only. And the loadbalancer doesn't know anything about
registrations and which customer needs an IPv6 keepalive.
Does anyone have a hint, how to keep the IPv6 registrations alive?
Thanks in advance.
Best Regards,
Sebastian
3359
days inactive
3359
days old
12 comments
5 participants
participants (5)
-
Daniel-Constantin Mierla -
Juha Heinanen -
Moritz Graf -
Olle E. Johansson -
Sebastian Damm