[OpenSER-Devel] New module and some restructuring

[Dan Pascu]

I have a new module dealing with nat traversal that is in the work and 
testing for the last 6 months. The module initially started as a need to 
implement a better NAT keepalive functionality. While I was implementing 
that I realized that we can simplify the code structure and eliminate the 
code duplication we have between nathelper and mediaproxy. The idea would 
be to group all the functionality related to solving the NAT traversal 
problem for SIP signaling (which is pretty much common between nathelper 
and mediaproxy) in a standalone module. This module would deal with 
anything related to handle solving NAT traversal issues from the SIP 
signaling point of view, while leaving the nathelper and mediaproxy 
modules to only deal with handling media NAT traversal. This area is 
where nathelper and mediaproxy actually differ, all the other 
functionality they provide (like contact fixing or NAT detection) is 
pretty much similar and duplicated between the two.

The purpose would be to hear opinions on this especially because the time 
is short until the code freeze and I would like to see this in 1.4.

To this end, here is what is available to date:

1. A new module called nat_traversal which implements a fully featured NAT 
keepalive functionality for SIP signaling. This keepalive functionality 
offers the following features:

- the ability to keepalive registered devices
- the ability to keepalive presence sessions (SUBSCRIBE sessions) even if 
the device doing presence doesn't also register
- the ability to keepalive dialogs (INVITE sessions) even if the caller is 
not registered or the caller/callee stops registering during the call
- the ability to work in environments with multiple SIP proxies where the 
proxy used to enter the network (the border proxy) which has to keep NAT 
alive, is not necessarily the proxy servicing the subscriber.
- the ability to work in environments with multiple SIP proxies where the 
proxy used to register, the proxy used to establish a dialog (INVITE) and 
the proxy used for a presence session (SUBSCRIBE) are not necessary the 
same and may in fact be 3 different entities altogether.
- the ability to work in multi proxy environments where the proxy used as 
an entry point to register may change during a dialog (INVITE or 
SUBSCRIBE session).
- the ability to save keepalive endpoints over restarts

Some highlights of how it works:

- sending keepalive messages is distributed in time to avoid overloading 
the proxy/network with a spikes of requests.
- the interface is extremely simple. there is only one function named 
nat_keepalive, that should be called for REGISTER, SUBSCRIBE or the first 
INVITE if the caller was determined to be behind NAT. This can be done at 
any point before statelessly answering the request or before t_relay-ing 
it and the rest is automatic, including the removal of the keepalive 
endpoint when the dialog ends or the registration/subscriptions expires.
- it only sends 1 keepalive per endpoint, no matter for how many reasons 
the endpoint is kept alive (REGISTER, SUBSCRIBE, multiple INVITEs)
- in multiproxy environments, the nat_keepalive function should only be 
called on the border proxy; it will be able to automatically detect from 
the answer to the REGISTER or the SUBSCRIBE if the request was accepted 
and if the expire time was modified. It will also ignore negative 
replies, so everything is handled in the background.
- for dialogs, it is also able to automatically determine if the 
destination needs to be kept alive, even with parallel forking.

This module is tested in production environments and I can push it as soon 
as I finish the documentation.

2. There is a new mediaproxy which will be available soon, and it comes 
with a rewritten openser module. This module will also be available as 
soon as the external mediaproxy application is tested and ready for a 
release.

How I see this progressing from here:

1. I will commit the nat_traversal module as soon as I finish writing the 
docs for it.
2. I will commit the new mediaproxy module as soon as the new mediaproxy 
is done with the testing phase and can be released.
3. Common functionality between nathelper and mediaproxy which is related 
to handling NAT traversal for SIP signaling purposes (like contact 
fixing, nat detection, pinging) should be moved to the nat_traversal 
module (we should consider the most complete version of the 2 and port 
that). Pinging is already done by this new keepalive functionality.
4. We end up with a module for nat traversal for signaling and 2 modules 
that only deal with media relaying. The nathelper module should be 
probably renamed to rtpproxy or something similar to indicate it no 
longer handles anything NAT related, only media.

I wait for some comments/suggestions on this. 

P.S. Given that the new mediaproxy is completely rewritten, I would prefer 
it to no longer contain signaling related NAT functionality when it will 
be pushed, hopefully by that time we can reach an agreement and have that 
functionality already migrated to the nat_traversal module.

-- 
Dan