ian at comtek.co.uk
2009-May-06 16:48 UTC
[asterisk-users] Cisco 7940 phones become unreachable over VPN after a time
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. Time Source Destination Protocol
Info
460 2.561806 172.16.254.2 10.4.4.102 SIP
Request: REGISTER sip:10.4.4.102
462 2.562508 10.4.4.102 172.16.254.2 SIP
Status: 100 Trying (1 bindings)
467 2.587546 10.4.4.102 172.16.254.2 SIP
Status: 200 OK (1 bindings)
489 2.713287 172.16.254.2 10.4.4.102 SIP
Request: REGISTER sip:10.4.4.102
492 2.713959 10.4.4.102 172.16.254.2 SIP
Status: 100 Trying (1 bindings)
501 2.724822 10.4.4.102 172.16.254.2 SIP
Status: 200 OK (1 bindings)
685 3.711883 172.16.254.2 10.4.4.102 SIP
Request: REGISTER sip:10.4.4.102
687 3.712585 10.4.4.102 172.16.254.2 SIP
Status: 100 Trying (1 bindings)
694 3.744627 10.4.4.102 172.16.254.2 SIP
Status: 200 OK (1 bindings)
838 4.865913 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3557 at 172.16.254.2:5060;transport=udp
853 4.957873 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3057 at 172.16.254.2:5060;transport=udp
981 5.870567 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3557 at 172.16.254.2:5060;transport=udp
1004 5.962572 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3057 at 172.16.254.2:5060;transport=udp
1135 6.674684 172.16.254.2 10.4.4.102 SIP
Request: REGISTER sip:10.4.4.102
1137 6.676088 10.4.4.102 172.16.254.2 SIP
Status: 100 Trying (1 bindings)
1143 6.706833 10.4.4.102 172.16.254.2 SIP
Status: 200 OK (1 bindings)
1155 6.769650 172.16.254.2 10.4.4.102 SIP
Request: REGISTER sip:10.4.4.102
1157 6.770154 10.4.4.102 172.16.254.2 SIP
Status: 100 Trying (1 bindings)
1159 6.776059 10.4.4.102 172.16.254.2 SIP
Status: 200 OK (1 bindings)
1179 6.870643 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3557 at 172.16.254.2:5060;transport=udp
1195 6.961977 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3057 at 172.16.254.2:5060;transport=udp
1844 7.771771 172.16.254.2 10.4.4.102 SIP
Request: REGISTER sip:10.4.4.102
1847 7.772565 10.4.4.102 172.16.254.2 SIP
Status: 100 Trying (1 bindings)
1849 7.804683 10.4.4.102 172.16.254.2 SIP
Status: 200 OK (1 bindings)
1857 7.870719 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3557 at 172.16.254.2:5060;transport=udp
1871 7.962725 10.4.4.102 172.16.254.2 SIP
Request: OPTIONS sip:3057 at 172.16.254.2:5060;transport=udp
David Backeberg
2009-May-06 18:14 UTC
[asterisk-users] Cisco 7940 phones become unreachable over VPN after a time
On Wed, May 6, 2009 at 12:48 PM, ian at comtek.co.uk <ian at 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.
David Backeberg
2009-May-06 18:17 UTC
[asterisk-users] Cisco 7940 phones become unreachable over VPN after a time
On Wed, May 6, 2009 at 12:48 PM, ian at comtek.co.uk <ian at 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 amThere 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.