I’m experiencing intermittent lockups on all four 480i CTs at one of our sites.
There is no way around having to unplug the phone and reboot. They stop responding to network traffic (no web ui) and the keypads are dead.
They don’t all go into lockup at the same time either. It can sometimes be 1 or 2 days between lockups on a particular phone.
Nothing back from Aastra yet, despite two emails to their support address.
could it be PoE related? this sounds like something that could happen if you have flaky PoE…
also there is an option ‘ring splash tone’ that as i recall is a confirmed bug in 1.4, will cause problems…
Two are powered via PoE. The PoE switch is plugged into a UPS. I was hoping good, clean power would fix the issue.
The other two use the wall warts.
“Play a Ring Splash” is disabled.
I’m getting REALLY beat up over the number of times these phones need a hard reboot, so I implemented some automated checks.
I’m running:
/usr/local/bin/sipsak -s $url -vv -r 5060via Nagios every one minute to check status and it appears to have exacerbated the problem. Does that help?
hmmm…
I’d suggest flash the phones with older (1.3) firmware. Factory reset, then upgrade to a known good copy of 1.4 again. Another factory reset. See if that helps.
Also what you can do that may help- have a cron job which runs at 3am and reboots the phones, you can do this via SIP NOTIFY… this is a temporary measure tho.
Two 480i sets locked up this morning. The first at 4:49AM and the second 4:55AM.
Still no word from Aastra.
Firmware v1.4.0 appears to log over TCP/IP on a single port. Anyone know what daemon it wants to see running on that particular host/port?
probably syslog… you can get a free app to read it at www.kiwisyslog.com (windows) or Linux has its own syslog facilities if you enable them…
Yep, it’s syslog. I needed to make sure the syslog daemon was set up for remote logging and point the phone at the right IP/port 514 and it started dumping. It uses the phone’s mac address to identify which phone is logging the message.
Maybe the logs will tell me something. We’ll see.
No lockups for three days now…I think I may be through the woods.
It appears Aastra’s firmware (for both the 480i and 9133i) doesn’t like
having multiple registrations with a single proxy. The phones behave
much more predictably when every line appearance (and the global
values) is given the same SIP identity/credentials.
I set them up initially to register each line appearance as a distinct
sip peer. This done, I then managed rolling over to line 2 if line 1
was busy, line 3 if line 2 was busy, etc. from Asterisk. It appears
Aastra has done most of their testing on scenarios in which the phone
itself manages these rollovers. This makes sense, as the way I was
doing it is far less common. I had managed other phones from Asterisk
in a similar fashion and simply used the same dial plan with Aastra
phones expecting the same result. My bad.
Here’s a snippet of what I was doing in Asterisk (not anymore):
# SIP/100, SIP/200, SIP/300, & SIP/400 are all the same phone
exten => 1,1,ChanIsAvail(SIP/100&SIP/200&SIP/300&SIP/400,sj)
exten => 1,n,Dial(${AVAILCHAN:0:7},r)now it’s just:
exten => 1,n,Dial(SIP/100,r)The moral to the story: if you are using a single proxy, set up each
line on your 480i and 9133i to be the same peer. Let the phone decide
which line appearance will respond to incoming calls.
I am having the exact same issue. We have 2 480i CT’s, 2 480i’s, and 8 9133i’s, and I am having lockup issues with the CT’s. All the phones are pluged into a POE switch, so I have swapped the CT’s to ports that other phones where in, but the problem follows the CT’s. I can tell when it is happening, because the time is not getting updated unless the headset is picked up. Then within an hour or so the phone will just lockup. I have only one sip registration per phone. Please keep me updated as to any findings that you have. Thanks!
We had one lock up today. The symptoms are almost exactly as you describe.
An interesting thing about the issue I’m seeing is it appears to happen on the phone that’s most used first. Then, subsequently on phones that are used less often. They all end up doing it eventually.
I’ve talked with Aastra about the problem being somehow related to time and volume of activity the phone sees. Nothing conclusive back from them yet.
When you say “time is not getting updated”, do you mean the minutes stop incrementing? That is, it says 12:34 PM until it locks up at about 1:34 PM?
I will look over at my phone and it will say some time in the past, like 1:32 pm, which I presume is the time that I finished my last call. It maybe 2:04pm, so if I pick up the headset, then the time will update to 2:04pm. It will do this off & on a bit, and then I will pick it up but no update & then, lockup.
I think Aastra’s firmware has a memory leak within code that processes SIP envelopes. I can get my phones to hang like clockwork with the following test…
Download and compile sipsak. Register your Aastra phone with Asterisk. Make sure it’s working okay. Then, create this script:
#!/bin/bash
#replace IP address with that of one of your phones
COUNTER=0
while [ $COUNTER -lt 10000 ]; do
echo count is $COUNTER
sipsak -s sip:test@192.168.5.60 -vv -r 5060
let COUNTER=COUNTER+1
done
Run the script. At somewhere between 400 and 600 calls, you’ll see:
[code]…
…
…
** reply received after 64.968 ms **
SIP/2.0 200 OK
final received
count is 405
message received:
SIP/2.0 200 OK
Call-ID: 1107796064@127.0.0.1
CSeq: 1 OPTIONS
From: sip:sipsak@127.0.0.1:32933;tag=4207a060
To: sip:test@192.168.5.60;tag=d62e43e378fa843
Via: SIP/2.0/UDP 127.0.0.1:32933;received=192.168.5.10;branch=z9hG4bK.12c43d9e;r
port;alias
Content-Length: 0
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Contact: sip:test@192.168.5.60
Supported: replaces
User-Agent: Aastra 480i Cordless/1.4.0.1048 Brcm Callctrl/1.5 MxSF/v3.2.6.26
** reply received after 16.491 ms **
SIP/2.0 200 OK
final received
count is 406
message received:
SIP/2.0 200 OK
Call-ID: 1722295724@127.0.0.1
CSeq: 1 OPTIONS
From: sip:sipsak@127.0.0.1:32933;tag=66a825ac
To: sip:test@192.168.5.60;tag=27768c44ea8cacf
Via: SIP/2.0/UDP 127.0.0.1:32933;received=192.168.5.10;branch=z9hG4bK.137079d0;r
port;alias
Content-Length: 0
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Contact: sip:test@192.168.5.60
Supported: replaces
User-Agent: Aastra 480i Cordless/1.4.0.1048 Brcm Callctrl/1.5 MxSF/v3.2.6.26
** reply received after 62.572 ms **
SIP/2.0 200 OK
final received
count is 407
message received:
SIP/2.0 200 OK
Call-ID: 1424949142@127.0.0.1
CSeq: 1 OPTIONS
From: sip:sipsak@127.0.0.1:32933;tag=54eeff96
To: sip:test@192.168.5.60;tag=790656ba7105ed4
Via: SIP/2.0/UDP 127.0.0.1:32933;received=192.168.5.10;branch=z9hG4bK.7a84f7d3;r
port;alias
Content-Length: 0
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Contact: sip:test@192.168.5.60
Supported: replaces
User-Agent: Aastra 480i Cordless/1.4.0.1048 Brcm Callctrl/1.5 MxSF/v3.2.6.26
** reply received after 64.684 ms **
SIP/2.0 200 OK
final received
count is 408
** timeout after 500 ms**
** timeout after 1000 ms**
** timeout after 2000 ms**
** timeout after 4000 ms**
** timeout after 4000 ms**
** timeout after 4000 ms**
** timeout after 4000 ms**
[/code]
When you see sipsak timing out, pick up the phone and attempt to dial any extension. Does your phone hang, too?
The 9133i sets have the same problem, they lock up too. The only difference is, it takes an order of magnitude more iterations of the above script to get them to tank. I ran the test three times after reboots and the number of iterations required hovered between 27,000 and 28,000.
This means, depending on the usage in your environment, you can expect the 9133i to lock up far less often than the 480i, but to lock up just the same.
I haven’t pulled one of these phones apart yet, but if they use the same chipset, the 480i has far less memory as breathing room than does the 9133i. I’d guess the amount of memory free in the 480i at startup is 1/56 of that available in the 9133i at startup.
Regular reboots will likely keep the phones from locking up. However, I’ve found this to be problematic when scripted. The phones don’t always come back to life predictably. So, only reboot them if you’re on-site to handle it when one doesn’t wake back up immediately.
puckett_jw,
Let me know whether you can run the test I describe above. I’m curious whether you’ll get the same result.
Replaced all Aastra hardphones, 12 of them, at this site with Polycoms. I’ll take a look at Aastra again when this bug is fixed.
Amen
I’m currently replacing all my Aastra with Snom and Polycom ( 22 of them ) man this cost me an arm and a leg .
Also check this
With you on the arm and a leg part! 
No luck with the A200, huh? Funny, I’ve got an A200 with HEC at the same location. No problems, really. I’m even using two of the 12 channels for faxing.