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@aliax.net wrote:
2010/8/11 Ovidiu Sas osas@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@aliax.net