Best practice for nat_keepalive

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practice for nat_keepalive

Thomas Gelf
I would like to share some thoughts/questions regarding nat_keepalive()
from the nat_traversal module. First thing I'm wondering whether I
should send keepalives only to clients with NAT issues (as reported by
client_nat_test) or to all of them (even clients without obvious NAT
issues).

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.

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.

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!

Best regards,
Thomas Gelf


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for nat_keepalive

Bogdan-Andrei Iancu
Hi Thomas,

Thomas Gelf wrote:
> I would like to share some thoughts/questions regarding nat_keepalive()
> from the nat_traversal module. First thing I'm wondering whether I
> should send keepalives only to clients with NAT issues (as reported by
> client_nat_test) or to all of them (even clients without obvious NAT
> issues).
>  
I think pinging everybody is a waste of bandwidth, CPU (especially if
you do SIP ping) and I/O.
> 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.
> 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.
> 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 :)..

Best regards,
Bogdan

> Best regards,
> Thomas Gelf
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for nat_keepalive

Thomas Gelf
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.

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

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

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

Best regards,
Thomas Gelf


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for nat_keepalive

Bogdan-Andrei Iancu
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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users