Re: [Users] NAT ping types

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 _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users