[sr-dev] modules_k: nathelper split

Ovidiu Sas osas at voipembedded.com
Wed Aug 11 19:59:59 CEST 2010


nat_traversal and then new nathelper will be somehow redundant to each
other (nat_traversal is a little bit more advanced by taking advantage
of the dialog module to keep NAT pinholes alive for incoming calls
from subscribers that does not register).
At this point in time I don't want to affect the existing
functionality.  The split is a noop from a functionality point of
view.
All I want is to separate the two major tasks: handling of NATed
subscribers and rtpproxy communication.  This will provide a cleaner
design and hopefully a simpler approach in merging the two versions of
the nathelper module (s and k).

Regards,
Ovidiu Sas

On Wed, Aug 11, 2010 at 12:57 PM, Iñaki Baz Castillo <ibc at aliax.net> wrote:
> 2010/8/11 Ovidiu Sas <osas at voipembedded.com>:
>> Hello all,
>>
>> I would like to propose a split of the k nathelper module in two:
>>  - nathelper module - will keep functionality related only to NAT handling;
>>  - rtpproxy module - a new module that will handle rtpproxy protocol
>> communication between kamailio and rtpproxy.
>>
>> The config will require the load of the new rtpproxy module and all
>> the rtpproxy config params will be moved from nathelper to rtpproxy.
>> All functions will remain the same inside the routing blocks.
>>
>> Before proceeding with this task, I would like to know if there are
>> any objections to this split.
>
> IMHO it makes lot of sense. There should be a module to deal with NAT
> in signalling and other module to deal with media.
> Anyhow, note that there is already other specific module for NAT in
> signalling: nat_traversal, but it's a different approach than
> nathelper (I think nat_traversal provides useful stuff to mantain NAT
> keepalives without requiring registration, which makes it very
> suitable when using an outbound proxy).
>
> Regards.
>
> --
> Iñaki Baz Castillo
> <ibc at aliax.net>
>



More information about the sr-dev mailing list