[OpenSER-Devel] New module and some restructuring
Dan Pascu
dan at ag-projects.com
Tue May 6 18:02:01 CEST 2008
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
More information about the Devel
mailing list