7 Jul
2009
7 Jul
'09
11 p.m.
On 07/07/2009 08:33 PM, Iñaki Baz Castillo wrote:
El Martes, 7 de Julio de 2009, Daniel-Constantin
Mierla escribió:
so it duplicated info stored by the usrloc module. It is what I meant by
keeping twice information. Nathelper fetches the contact details from
usrloc.
From what seems here, definitely does not deal with PATH extension.
On 07/07/2009 07:27 PM, Iñaki Baz Castillo
wrote:
--------
REGISTER - called before save_location() or t_relay() (depending on whether
the proxy that received the REGISTER is also handling registration for that
subscriber or not). It will determine from either the stateless reply
generated by save_location() or the TM relayed reply if the registration was
successful and what is its expiration time. If the registration was successful
it will mark the given NAT endpoint for keepalive for the registration
condition using the detected expiration time. If the REGISTER request is
discarded after nat_keepalive() was called or if it intercepts a negative
reply it will have no effect and the registration condition will not be
activated for that endpoint.
--------
2009/7/7 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
it does not bind to usrloc, so I think it has no idea who is registered
or not, unless it is done via some parameters.
> I use nat-traversal module and it's MUCH
MUCH more powerful than
> nathelper, for sure.
>
I do not agree at all with this, when comes to flexibility.
nat_traversal main problem is the relying on dialog module, which adds
lot of overhead to a proxy.
Not sure now if dialog module is fully required for all the cases...
It's just required if you want to mantain nat keepalive for calls
initiated by non registered users.
The INVITE case uses dialog module, but in order to
avoid it, just don't
invoke "nat_keepalive()" funtion for INVITE (the caller is already being
pinged id it was registered behind NAT).
First I think that is not a typical use case, but more than that,
imagine you have 100 000 presence sessions spread across couple presence
servers and about the same number of calls going through your proxy.
Do you think it will deals nicely doing pings? While for calls, nat
pinhole is handled by the registrars, same can be done by the presence
servers.
Architectural point of view, it is even better doing so, as once there
is no reply, the presence dialog can be destroyed and resources freed on
server side. With nat_traversal approach, you consume twice resources in
the server side, as you keep dialog attributes on proxy and presence
server, therefore you double the scalability issues.
Not true, just *one* keep alive is performed per *source* (public IP:port):
Well, again, maybe you misunderstood me in the first place. Because it
is a duplication of data about endpoints in memory (in usrloc and
nat_traversal, or presence server and dialog module), you get problems
in scalability.
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().
For presence, like for registration, the keepalive
should be done by the
endpoint (registrar, presence server), otherwise you get into
scalability issues.
Imagine a presence agent machine (behind NAT) subscribing to the
presence of some users without registering.
----------
A user agent's NAT entry point may be kept alive for one or multiple of the
conditions listed above.
I understood that an endpoint is pinged only once if you call nat
traversal for register, invite and subscribe. It not about this king of
duplicated resources. It is about storing info about the endpoint in
nat_traversal, usrloc and presence server. While the last two already
have it and need it for normal behavior, the first is doing it at extra
expenses.
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.
Even when a NAT endpoint is kept alive for more than
one condition, only one keepalive message is sent to that NAT endpoint. The
presence of multiple conditions for a NAT endpoint, only guarantees that the
network visibility for a user agent based on a certain condition will be
available while that condition is true, independently of the other conditions.
When all the conditions to keepalive a NAT endpoint will disappear, that
endpoint will be removed from the list with the NAT endpoints that need to be
kept alive.
----------
------------
SUBSCRIBE - called before handle_subscribe() or t_relay() (depending on
whether the proxy that received the SUBSCRIBE is also handling subscriptions
for that subscriber or not). It will determine from either the stateless reply
generated by handle_subscribe() or the TM relayed reply if the subscription
was successful and what is its expiration time. If the subscription was
successful it will mark the given NAT endpoint for keepalive for the
subscription condition using the detected expiration time. If the SUBSCRIBE
request is discarded after nat_keepalive() was called or if it intercepts a
negative reply it will have no effect and the subscription condition will not
be activated for that endpoint. It should be called for every SUBSCRIBE
received, not only the ones that start a subscription (do not have a to tag),
because it needs to update (extend) the expiration time for the subscription.
---------------
I think this is much better than decreasing notifications interval just
because there could be users registered behind NAT.
If they are registered, then
registrar will take care, you do not need
any other nat pinging. We talk about non registered users.
How to
mantain the
keepalivee in Kamailio (without using nat_traversal module)? The dirty
solution would be decrease the notification interval, that of course
would be a wrong choice.
Why would be that more wrong than sending keepalives from a stateful
proxy? See above, you keep the dialog only once on server side.
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.
Also, imagine other typical case:
a) Using nathelper:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2).
- It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive.
- Proxy 1.1.1.1 crashes.
What happens if someone calls that UA right now?
- UA sends an INVITE and since 1.1.1.1 doesn't
respond it sends it to 2.2.2.2.
If I am not wrong, in this case should register again, since the
previous proxy is no longer available.
What happens if proxy 1.1.1.1 is restarted. Does it restore the hash
table of natted endpoints?
- The call is established.
- After 3 minutes the calleed sends a BYE.
- This BYE wont reach the UA since proxy 2.2.2.2 is not mantaining NAT
keepalive => Problems
b) Using nat_traversal:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2).
- It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive (REGISTER).
- Proxy 1.1.1.1 crashes.
UA is no longer reachable, maybe called party was also on 1.1.1.1.
In case of shared IP, or load balancer+PATH, it is reachable and there
is no problem with calling or being called.
For me looks like you try to argument that nat_traversal is better for a
bad designed voip platform. Sometimes, if you are lucky (ua1 registered
on .1 and ua2 registered on .2), you get ability to call, but never to
be called.
It is not clear to me that it supports proxy restart -- I admit I havent
investigated the code nor used the module.
I simply fail to see the reason of one extra place to store data to be
able to do to nat pings.
- UA sends an INVITE and since 1.1.1.1 doesn't
respond it sends it to 2.2.2.2.
- The call is established.
- Proxy 2.2.2.2 mantains keepalive for the call duration.
- After 3 minutes the calleed sends a BYE.
- This BYE will reach the UA since proxy 2.2.2.2 is mantaining NAT keepalive
=> OK.
Other solutions to make the above escenario working with nathelper module
would be:
1) The UA mantains the keepalive with the registrar server and *with* the
definitive server it sent the INVITE to (after SRV failover). How many UA's do
it?
2) The UA mantain the keepalive with the registar. When detecting server
failure it sends a new REGISTER to the following server (SRV).
3) Decrease the registration expiration in the server (bad idea).
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.
Cheers,
Daniel
Using dialgo module is not required at all (as I
explained above), it is required just in the case you want to mantain
keepalive for calls initiated by non registered users.
Regards.
--
Daniel-Constantin Mierla
http://www.asipto.com/