11 Aug
2010
11 Aug
'10
8:48 p.m.
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.
Regards,
Ovidiu Sas
11 Aug
11 Aug
8:57 p.m.
2010/8/11 Ovidiu Sas <osas(a)voipembedded.com>om>:
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(a)aliax.net>
9:59 p.m.
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(a)aliax.net> wrote:
2010/8/11 Ovidiu Sas <osas(a)voipembedded.com>om>:
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(a)aliax.net>
15 Aug
15 Aug
9:15 p.m.
2010/8/11 Ovidiu Sas <osas(a)voipembedded.com>om>:
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).
Sure. I also agree that your proposed split is a good idea. Perhaps in
a future it would be great to merge the new nathelper module (just
signalling) and nat_traversal module, but that is a different subject.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5200
days inactive
5204
days old
4 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Juha Heinanen -
Ovidiu Sas