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 _______________________________________________ Devel mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/devel
