[Users] NAT ping types - sr-users

12 Jul 2005

Hi folks,

I extended nathelper (and some depending modules) to allow NAT pinging 
with SIP request. The main benefit of using SIP request instead of UDP 
package is the fact that there is a bidirectional traffic through the 
NAT - since each PING request from OpenSER (inbound traffic) will force 
the SIP client to generate a SIP reply (outbound traffic); so, even for 
NATs which updates the bind timeout only on outbound traffic, the NAT 
bind will be surely kept open - this couldn't be guaranteed by UDP 
package ping since the traffic was  unidirectional (inbound - from 
outside to inside).

The two type of pings can be use in the same time - mixed combination of 
contacts pinged with UDP packages and contacts pinged with SIP requests. 
What kind of ping will be used for each contact will be set at 
registration time via flags: if the REGISTRAR flag "sip_natping_flag" is 
set, the contact will be marked in USRLOC for SIP request pinging - 
NATHELPER will use default UDP package ping; for the marked contacts, 
the SIP request pinging will be used.

To enable SIP request pinging in NATHELPER, you have to set the 
"sipping_from" parameter -default NULL- (FROM URI to be used for 
generating the SIP pings). Also you may change the "sipping_method" 
parameter to select a SIP method to be used (default is OPTIONS).

The pinging SIP requests are statelessly generated by NATHELPER; the 
replies are automatically filtered out by the module. I preferred not to 
use TM to generate statefull replies from performance reasons:
    if you have 2000 nated contacts, at each 20 seconds (pinging 
interval), 2000 new transactions will be created, transactions witch 
will leave in memory for 5 (wait timer) + 2 (delete timer) = 7 seconds; 
I find this penalty (like huge shared memory consumption and transaction 
lookup slowness) not paying the purpose;
    I think the lack of retransmissions (in the stateless version) is 
something comfortable in a pinging scenario.

One more thing - it's really not important the code of the replies 
(that's 200 or not) - the important idea is to make the client to send 
something out to refresh the bind.
There is a small limitation of the current version - since 
get_all_ucontacts() returns the received URI instead of contact URI 
(when nated contact), the SIP pinging requests will have in RURI a 
different URI that the registered contact. Most of the clients doesn't 
care about this, but some - like SIPURA- replies with 404 NOT FOUND :).

Any comments, suggestions, questions are welcomed. Docs are updated both 
on CVS and web (for registrar and nathelper modules)

regards,
Bogdan