8 Jul
2009
8 Jul
'09
12:10 a.m.
On 07/07/2009 10:30 PM, Iñaki Baz Castillo wrote:
.. right, if destination is not behind nat, otherwise won't do it since
the call does not complete.
IMHO it's clear that the only requests requiring NAT keepalive are:
- REGISTER: to receive calls.
- INVITE: to receive in-dialog requests.
- SUBSCRIBE: to receive in-dialog requests.
but these are application level decisions. You can use REGISTER to
publish a CPL documents(cpl-c support it), in that case you don't need
keepalive.
(note that in this case I mean using "nathelper").
UA wouldn't receive that call even if it arrives to server 2 since server 2 (a
different IP) has no way to communicate with UA.
I was refering to the cases when you have shared IP HA or a load
balancer in front with path extension.
ok, then should do it only for those cases.
Well, I promise to investigate more about it. Most probably I needed this
thread :)
I think with next next stable release, we need some order in the nat
handling. Right now there are too many things that bring confusion due
to poor documentation or overlapping functionality.
Over the years I used only the nathelper module, without hitting some
limitation, the only annoying thing from my point of view is the complex
config, issue addressed earlier in this thread, which can be solved nicely.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
First of all, I love these kind of discussions, the
best way to learn :)
:-)
[...]
Ok, I get you now.
However, if you don't use db_mode=0 in usrloc, then there is a MySQL query
retrieving the natted contacts from usrloc table.
This happens only on db mode only. Otherwise, usrloc records are stored
in memory and sync'ed to db from time to time. A restart of same
instance or a start of another one on a different server, will get
up-to-date data.
nat_traversal store them always in memory (not sure if
it's a better
approach).
the 'socket' column in usrloc table.
From what seems here, definitely does not deal
with PATH extension.
Not 100% sure, but I read this in the doc:
----------------
1.7.1. $keepalive.socket(nat_endpoint)
As you
won't use nathelper, nat pings are performed only by
nat_traversal, so if to cope with crashes of the box, you need a
replication mechanism to a backup, so registered users are reachable
when backup becomes alive, in the case of shared IP HA.
With usrloc and nathelper, that is solved, as data is stored in db or
replicated with t_replicate().
With nat_traversal there is other approach:
Use nat_keepalive() for REGISTER and INVITE. When the server 1 crashes and
server 2 begin running, it has no NAT keepalive information, but if it's
receives a call from a natted UA, it will keepalive it (INVITE).
However, it's true that it couldn't receive
calls from server 2... hum...
presence server has anything needed to rich the UA within the subscribe
dialog. It uses it for sending notifies. It needs to send some messages
periodically.
Also, note that you need to do nat pinging from
the presence server only
when you allow subscriptions from non-registered UA (again, very corner
case). Otherwise, just having it done only by registrar is enough.
Perhaps I miss something, but how could a presence server (running behind the
proxy) perform nat keepalive just for natted users? note that SIP signalling
is NAT fixed on the proxy. Perhaps using a custom header or paremter
"nat=yes"? In any case, how would Kamailio presence server mantain the
keepalive for non registered natted subscribers?
NAT keepalive should not
be performed by an application (SIP presence) IMHO.
SIP is an application level protocol. So the special handling should be
done by the end point that understands the message. What happens if I
send a custom request? Should the proxy perform pinging? If it is not
creating a dialog, the case of MESSAGE? Or it does, case of SUBSCRIBE?
IMO, it is
totally broken to assume things in a router/proxy. Do it on
endpoints, like it is now with registrar.
Well, I can assume that there will not appear a new SIP method creating a
dialog in the next 5 years XD
[...]
What happens if someone calls that UA right now?
[...]
OK, probably still limited in a way. usrloc does immediate or periodic
db updates (depending on parameter value), so if there is "unexpected"
crash, none or very limited data is lost. And you have path support.
It is not clear to me that it supports proxy
restart -- I admit I havent
investigated the code nor used the module.
Yes, it does.
I simply fail
to see the reason of one extra place to store data to be
able to do to nat pings.
Well, it extends the cases in which keepalive could be required (not just
registration).
Sincerely, I think nat_traversal provides much better
NAT solutions than
the limited nathelper module.
Just your opinion. I think it is the opposite. nat_traversal limits you
to one box for good servicing, otherwise no scalability and no HA for
proper voip servicing.