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