[asterisk-users] Cisco 7940 phones become unreachable over VPN after a time

2009-05-06 Thread i...@comtek.co.uk
Hi.

I have a working internal Asterisk setup with 35 phones. Around 5-10 of 
these phones are physically located in a remote office via a VPN. I am 
completely happy with Asterisk and would be able to set up external 
calls but for one serious problem. After a period of time (perhaps a 
couple of days) the phones over the VPN cease to work. 'sip show peers' 
returns lines like:
   3057/3057  172.16.254.2 D  5060 
UNREACHABLE

In this case 3057 will be able to make calls but it will not be able to 
hear the callee at the other end (though the callee can hear 3057). 
Other phones get 'The person at extension ... is unavailable' and then 
voicemail. We have tried out a software SIP client and this never goes 
into an UNREACHABLE state. Phones that don't go over the VPN are also fine.

Rebooting the physical asterisk server will not make 3057 work again. 
Rebooting the phones is similarly useless. The only way I know of to fix 
the problem is to release the phone's ip and allow it to get a new one. 
This makes me suspect that either the phones or Asterisk is saving 
enough state to come back up in a non-working state or that there is a 
VPN issue. I've included a packet trace of 3057 while it is in a 
non-working state (below). The trace was done from the ASA.

The Asterisk server is behind a Cisco ASA 5520 and the remote sites have 
Cisco 837s. I see a long list of SIP related issues resolved by 
http://www.cisco.com/en/US/docs/security/asa/asa80/release/notes/arn804n.html 
(which I applied), however this still doesn't seem to have solved the 
problem. Is a Asterisk = Cisco-VPN = 7940 setup known to work?

Can anybody provide any suggestions to help debug this? If I'm unable to 
isolate/resolve the problem then its likely we'll have to drop the 
Asterisk solution and I've already grown rather attached to it.

Thanks for any help,

Ian


No. TimeSourceDestination   Protocol 
Info
460 2.561806172.16.254.2  10.4.4.102SIP  
Request: REGISTER sip:10.4.4.102
462 2.56250810.4.4.102172.16.254.2  SIP  
Status: 100 Trying(1 bindings)
467 2.58754610.4.4.102172.16.254.2  SIP  
Status: 200 OK(1 bindings)
489 2.713287172.16.254.2  10.4.4.102SIP  
Request: REGISTER sip:10.4.4.102
492 2.71395910.4.4.102172.16.254.2  SIP  
Status: 100 Trying(1 bindings)
501 2.72482210.4.4.102172.16.254.2  SIP  
Status: 200 OK(1 bindings)
685 3.711883172.16.254.2  10.4.4.102SIP  
Request: REGISTER sip:10.4.4.102
687 3.71258510.4.4.102172.16.254.2  SIP  
Status: 100 Trying(1 bindings)
694 3.74462710.4.4.102172.16.254.2  SIP  
Status: 200 OK(1 bindings)
838 4.86591310.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
853 4.95787310.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
981 5.87056710.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
   1004 5.96257210.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
   1135 6.674684172.16.254.2  10.4.4.102SIP  
Request: REGISTER sip:10.4.4.102
   1137 6.67608810.4.4.102172.16.254.2  SIP  
Status: 100 Trying(1 bindings)
   1143 6.70683310.4.4.102172.16.254.2  SIP  
Status: 200 OK(1 bindings)
   1155 6.769650172.16.254.2  10.4.4.102SIP  
Request: REGISTER sip:10.4.4.102
   1157 6.77015410.4.4.102172.16.254.2  SIP  
Status: 100 Trying(1 bindings)
   1159 6.77605910.4.4.102172.16.254.2  SIP  
Status: 200 OK(1 bindings)
   1179 6.87064310.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
   1195 6.96197710.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
   1844 7.771771172.16.254.2  10.4.4.102SIP  
Request: REGISTER sip:10.4.4.102
   1847 7.77256510.4.4.102172.16.254.2  SIP  
Status: 100 Trying(1 bindings)
   1849 7.80468310.4.4.102172.16.254.2  SIP  
Status: 200 OK(1 bindings)
   1857 7.87071910.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp
   1871 7.96272510.4.4.102172.16.254.2  SIP  
Request: OPTIONS sip:3...@172.16.254.2:5060;transport=udp





Re: [asterisk-users] Cisco 7940 phones become unreachable over VPN after a time

2009-05-06 Thread David Backeberg
On Wed, May 6, 2009 at 12:48 PM, i...@comtek.co.uk i...@comtek.co.uk wrote:
 Can anybody provide any suggestions to help debug this? If I'm unable to
 isolate/resolve the problem then its likely we'll have to drop the
 Asterisk solution and I've already grown rather attached to it.

I have a number of ideas of what could be happening, and most involve
routing issues over your VPN, or your VPN dropping packets. Here's a
suggestion:

* put another asterisk server on the remote side, and have the two
asterisk servers do SIP or IAX trunks back and forth.

If you don't want to invest in a server, at least pull an old computer
off the curb and do some tests using that computer.

If your phones come unregistered but your SIP trunk is fine, change
your branch office phones to register to their local asterisk instead,
and set your remote server accordingly. You might need to do some
prefixing, or redirects, or other tricks to make the trunking
transparent to the users if you don't want to reassign extensions.

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Cisco 7940 phones become unreachable over VPN after a time

2009-05-06 Thread David Backeberg
On Wed, May 6, 2009 at 12:48 PM, i...@comtek.co.uk i...@comtek.co.uk wrote:
 Hi.

 I have a working internal Asterisk setup with 35 phones. Around 5-10 of
 these phones are physically located in a remote office via a VPN. I am

There are a number of other reasons you want a remote phone server at
that other location:
*911 or name-the-emergency-service of your country
*how do you call the other employees at the branch office when the WAN
link is down?
*this multiplies your options for future growth / expansion /
flexibility / when you decide that you would rather have a dedicated
telco link joining the offices.

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Cisco 7940 phones become unreachable over VPN after a time

2009-05-06 Thread i...@comtek.co.uk

 I have a number of ideas of what could be happening, and most involve
 routing issues over your VPN, or your VPN dropping packets. Here's a
 suggestion:

 * put another asterisk server on the remote side, and have the two
 asterisk servers do SIP or IAX trunks back and forth.
Thanks for the suggestion.

An additional server in our 'main' remote location is likely to happen
anyway at some stage, but there are still a couple of users who have a
permanent VPN at home with a single phone and it just isn't
practical to run Asterisk at every such location.

999 calls and 'WAN down' aren't really a big deal since every
location has at least a couple of alternate means of communication
(old fashioned landline or mobile).

Ian

___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users