[Users] NAT ping types

[harry gaillac]

Hello,

What about Maxim Sobolev and its MOH support !??

Harry
--- Bogdan-Andrei Iancu <bogdan at voice-system.ro> a
écrit :

> 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 at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 



	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com