[OpenSIPS-Users] Best practice for nat_keepalive

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Jun 10 20:05:52 CEST 2009


Hi Thomas,

Thomas Gelf wrote:
> Bogdan-Andrei Iancu wrote:
>   
>> I think pinging everybody is a waste of bandwidth, CPU (especially if 
>> you do SIP ping) and I/O.
>>     
>
> I (mostly) agree on that - however, people calling our support desk,
> angrily complaining about being unreacheable "most of the time" waste
> even more valuable (human) resources.
>   

depends of which resource is most important :). If you want to ping 
everybody, you should consider using multiple processes for this (see 
the nathelper module params)
>   
>>> The former would save ressources, the latter would make sure that
>>> clients using STUN behind a non-symmetric NAT router would remain
>>> reacheable even if their own keepalive mechanism is not configured
>>> or implemented correctly.
>>>   
>>>       
>> if you do complex NAT tests (received port, etc) you should be able to 
>> receive the STUN clients from behind such routers.
>>     
>
> How can I distinct between a client on public IP (e.g. AVM VoIP DSL
> router directly connected to DSL) and a client behind a non-symmetric
> NAT router (the very same AVM router, but installed behind some other
> router), correctly doing STUN - but with keepalives not "aggressive
> enough" for the specific router sitting in front of him?
>   
you cannot - but a device with a proper STUN client implementation but 
without proper pinging is still a bugs device....But you as provider 
should do the best to make all kind of devices to work (be "the best" I 
mean following the SIP standards :) )
>   
>>> What I'm evaluationg to do is running nat_keepalive for each REGISTER
>>> and for each initial INVITE request, regardless of how they present
>>> themselves - but respecting a setting in usr_preferences, allowing me
>>> to switch keep_alives off per user. I would also put such a switch in
>>> their web-backend.
>>>   
>>>       
>> and how will this work ? what's the criteria for enabling/disabling the 
>> keep_alive for a user?  IMO, this is a network matter and the network 
>> props should decide on this.
>>     
>
> Default: enabled. Disabled: whenever a tecnician switches it of for a
> specific account in the account's backend - for one of the following
> reasons:
>
> a) he knows what he is doing
> b) he is trying out, if it would work with this setting switched off,
>    as he doesn't like my keepalives in his log
> c) he has been told to do so by our support desk
>
> Network matter: in a perfect world -> yes ;-)
>   
a bit dangerous the approach as the option is per user (if ping is 
required), but user can change the IP location and the device!


>   
>>> Next thing I was reflecting about is the keepalive_interval. I would
>>> like to set something like 57 seconds, as I've seen routers/firewalls
>>> closing ports after 60 seconds. Sure, in case one single keepalive is
>>> lost the port is lost - but hey, who cares ;-p I'm fine with 57 seconds
>>> as a pragmatic approach, but I'm really interested in your opinions!
>>>   
>>>       
>> It should be fine - whatever interval you set, you'll never be able to 
>> rule out the case of loosing the pings on the net :)..
>>     
>
> Yeah, I know. That's why I raised the thread "Feature-request: AVPs for
> nat_traversal" - this would allow me to ping ALL users with an interval
> of 170, saving a lot of resources. And if they face issues, themselves
> or our support team could change this setting to be more aggressive (if
> the UAC is not able to do so by itself) for this specific user.
>   
yes, it make sense.

Best regards,
Bogdan




More information about the Users mailing list