[Users] NAT ping types

[Bogdan-Andrei Iancu]

Hi Harry,

this changes has nothing to do with MOH.

regards,
bogdan

harry gaillac wrote:

>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
>
>  
>