7 Jul
2009
7 Jul
'09
8:47 p.m.
On 07/07/2009 07:27 PM, Iñaki Baz Castillo wrote:
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.
2009/7/7 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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.
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.
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. 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.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/