Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VPN tunnel & telephone fault tolerance

Status
Not open for further replies.

michbsd

IS-IT--Management
Nov 9, 2010
23
BE
Hi,


I have several 1616's and 1608's connecting to a call server (IPO500v2) through site-to-site VPN.

Whenever we see a little packetloss on the line (>2%) - the phones restarte/re-register.

Is there a way I can tweak the threshold / tolerance of the phone registration - so even if it loses contact to the callserver for 1 second, it does not reboot?

Many thanks,

Mike
 

You can tweak the settings for QoS alarms in System->System Events tab. Not sure if this will fix your problem though.

How is your site-2-site setup? Do u use keepalives?
 
Thanks for your reply..

Well - as I read it, the QoS settings will only generate an alarm, it should not provoke a restart??

My L2L VPN - is standard Cisco stuff - and yes, I send keep-alives.

Thanks,

 
there is quite a lot you can change / configure in the 46xxsettings.txt file. Ive had a quick scan and there are a lot of networking related setting.

ACSS - SME
 
Yeah - I can see the TCP KEEP-ALIVES settings.. might be worth tweaking them - not sure it is the culprit though..

Per default - it sends keep-alives every 60 seconds - and if it fails, it will re-transmit every 10 seconds.. though it doesn't say, how many times it will re-transmit - and what happens after re-transmittal failure.

Lastly, there's a setting called "SET REREGISTER" unde H.323 settings - though it does not say what it does and it is not encouraged to change it.

 
I would have to ask have you investigated the cause of the packet loss & what is being done to resolve it?

adjusting the phones would just be masking the simptoms rather than fixing the real fault.


I do not Have A.D.D. im just easily, Hey look a Squirrel!
 
I totally agree with IPGuru.
You need to sort out the network and nto try to solve it in the IPO.
You will have speech problems when you have packet loss.


When you pay peanuts, you get monkeys!

I'm not insane, my mother had me tested!
 
Thanks for the answers.

The network issue has been dealt with - and this does not happen often.

But fx- recently (last night) I had some packet-loss on my server-side (callserver) - and all telephones unregistered and rebooted.

Looking at smokeping/mrtg for all links both server and CPE side - I could not see any service interruption - so I was wondering if I could make the phones less "agressive" in un-registering from the call server..

Again, thank for your feedback.

 
As far as i know you can't
The phones send a keep a live packet and when the ipo doesn't respond then the phones reboot to get the connection working.


When you pay peanuts, you get monkeys!

I'm not insane, my mother had me tested!
 
OK.

So best effort, would be to increase TCP_KEEP_ALIVE_TIME and TCP_KEEP_ALIVE_INTERVAL to higher values - then the delay before reboot would be greater.

 
No it should not.
The network should be alright!
The phone tries a couple of time and then it reboots.
This is normal behaviour.



When you pay peanuts, you get monkeys!

I'm not insane, my mother had me tested!
 
When this happens in a "normal" network then the same thing happens.
This can be a tough one to solve by the way but i am sure it is a network problem.


When you pay peanuts, you get monkeys!

I'm not insane, my mother had me tested!
 
The IPO Gatekeeper sends keep alive packets to the phones, the phones have to respond with a acknoledge. The Gatekeeper accepts a maximum of 9 missing acks in a row and then it unregister the phone. It works the other way around too, if the phone misses 9 acks in a row it will reboot itself trying to get problems solved.
In average every 10 seconds there are keep alive packets send, if you have packet loss longer then 90 seconds then it is very likely the phones will reboot.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top