7 Jul
2009
7 Jul
'09
8:16 p.m.
On 07/07/2009 07:09 PM, Iñaki Baz Castillo wrote:
2009/7/7 Henning Westerholt
<henning.westerholt(a)1und1.de>de>:
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.
Cheers,
Daniel
if i remember correctly one of the original ideas
behind the nat-traversal
module was to consolidate the helper functionality needed to support nat
traversal into one module, instead of having two more or less redundant
implementations in nathelper and mediaproxy modules. Not sure how the
current state of integration is at the moment.. I also think that a clear
separation of efforts would be a good thing.
If i understand the module docs correctly then nat_traversal seems to
support better and/ or more efficient nat keep alive, among others. Its not
restricted to only ping users from location table, for example.
I use nat-traversal module and it's MUCH MUCH more powerful than
nathelper, for sure.
It allows NAT keepalive for non registered users when
they are in a
INVITE or SUBSCRIBE dialog.
Alex, please, take a look to nat-traversal full documentation.
--
Daniel-Constantin Mierla
http://www.asipto.com/