On Dienstag, 7. Juli 2009, Alex Balashov wrote:
I somewhat object to the idea that rtpproxy control
socket functions
should be exposed in the nathelper module. Why does mediaproxy get its
own module? What if I want to relay media for some purpose other than
far-end NAT traversal (for example, passive in-line tap / monitor-port
based call recording)?
AFAIK NAT signalling functions are now handled by nat-traversal
module, more powerful than nathelper of mediaproxy (for signalling,
not for media).
So nathelper module remains just to control RtpProxy. Yes, it could be
renamed to "rtpproxy" and NAT signalling functions be dropped from the
module.
Just what is the superior merit of nat-traversal vs. nathelper? I have
continued to use nathelper, believing nat-traversal to be an artifice of
the OpenSIPS camp since it was put out by AG Projects...
Hi Alex,
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.
Cheers,
Henning