Aastra 9133i's Require multiple restarts
Many of my Aastra 9133i's require multiple restarts in order to register. Any ideas as to what would cause this. I am currently hosting 150 of these phones on a seperate VLAN.
system is TB 2.6 with the following specs:
dual Model Intel(R) Xeon(TM) CPU 3.00GHz
CPU Speed 2.99 GHz
BUS Speed
Cache Size 2048 KB
System Bogomips 11972.65.
the phones are as follows:
Firmware Information
Firmware Version 1.4.2.3000
Boot Version 1.1.0.10
As an additional note Many of the phone register on port 1033 and others vice 5060.
When I wrote "I'm hoping" it's because earlier today I ordered 2 9133i and not too long after I saw your post. I'm a bit surprised, last firmware for this phone was released a long time ago.
Anyone else around having this issue? Please *raise* your hand and post a reply.
Aastra, is there still development for the 9133i ???
Now I'm hoping to get a positive answer and a release fix (please!).
Pierre
Why don't you post the config file for your phone?
Since you are the only person reporting this problem there is either something wrong with the phones configuration, your network or the trixbox setup.
Why don't you tell us something other than your server specifications?
Tel us about how your network is setup, where the trixbox sits in the network, are you using VALN trunking to the phones or two drops per workstation?
Have you tried another type of phone to see if the problem is with the Aastra's or elsewhere?
Scott
.cfg file for phone
sip line1 screen name: Troy Joshua
sip line1 display name: Troy Joshua
sip line1 auth name: 5618
sip line1 user name: 5618
sip line1 password: 123
sip line1 vmail: *97
sip line1 mode: 0
astra.cfg
#aastra default config file
missed calls indicator disabled: 1
tos sip: 24
tos rtp: 32
tos rtcp:32
time server disabled: 0
time server1: 192.168.4.9
time zone name: US-Central
time zone code: CST
sip proxy ip: 192.168.4.9
sip proxy port: 5060
sip registrar ip: 192.168.4.9
sip registrar port: 5060
sip backup proxy: 192.169.4.10
sip backup proxy port: 5060
sip backup registrar ip: 192.168.4.10
sip backup registrar port: 5060
sip registration timeout retry timer: 30
auto resync mode: 1
auto resync time: 23:00
directory 1:aastradir.csv
sip digit timeout: 6
tagging enabled: 1
VLAN id: 2
directed call pickup: 1
handset tx gain -1
handset sidetone gain -8
prgkey1 type: speeddial
prgkey1 label: "Security"
prgkey1 value:
prgkey2 type: speeddial
prgkey2 label: "IT"
prgkey2 value:
we are using vlan trunking and we also have some polycom telephones on the network that are not experiencing this issue.
I am sure that somebody will let us know if they see anything in the Aastra config file. My only question is on the backup proxy.
I would like to focus on the network side.
Is there any chance that 'portfast' is not enabled on the interface? Cisco, Dell and Adtran switches all support this construct.
What I am thinking is the port on switch is not ina forwarding state however the phone is trying to register because it sees it's interface as 'up'
Is that a possibility?
Scott
the backup proxy entry was made after the onset of this problem.
Do you have the two servers running in a high availability configuration? Is the database being replicated between the two servers? If one phone registers to one server and the other 'orphans' out to the backup they won't be able to 'see' each other.
This is possible, are you asking about the port that the server is on or the one the phone is on.
I am asking about the ports the phones are on. The sever NIC and the switch interface must be set in 100/full mode. Auto-negotiate can cause all sorts of problems (including the one you describe).
Scott
There is nothing in the configuration file you posted that would cause the phone to even attempt to register to port 1033 - can you check the configuration of these phones from their WebUI.
I am asking about the ports the phones are on. The sever NIC and the switch interface must be set in 100/full mode. Auto-negotiate can cause all sorts of problems (including the one you describe).
If you try this, then you must manually configure the same settings on the phone from the options menu. Otherwise the autonegotiation from the phone-side will fail and it will fall back to half-duplex mode; and cause you all sorts of collision problems on your network (ie flaky connections).
any idea what would cause these phones to register on this port? I have sent packet captures to Aastra support and am awaiting feedback. I have the following Aastra.cfg file
#aastra default config file
missed calls indicator disabled: 1
tos sip: 24
tos rtp: 32
tos rtcp:32
time server disabled: 0
time server1: 192.168.4.9
time zone name: US-Central
time zone code: CST
sip proxy ip: 192.168.4.9
sip proxy port: 5060
sip registrar ip: 192.168.4.9
sip registrar port: 5060
sip backup proxy: 192.169.4.10
sip backup proxy port: 5060
sip backup registrar ip: 192.168.4.10
sip backup registrar port: 5060
sip registration retry timer: 30
sip registration timeout retry timer: 30
download protocol: tftp
tftp server: 192.168.4.9
alternative tftp server: 192.168.4.10
auto resync mode: 1
auto resync time: 23:00
directory 1:aastradir.csv
sip digit timeout: 6
tagging enabled: 1
VLAN id: 2
directed call pickup: 1
handset tx gain -1
handset sidetone gain -8
prgkey1 type: speeddial
prgkey1 label: "Security"
prgkey1 value:
prgkey2 type: speeddial
prgkey2 label: "IT"
prgkey2 value: 5821
When I look at the packet Capture I often see failed registration attempts "401 unauthorized" , how ever iI never see the phone retry the registration per the "sip registration retry timer: 30" I have several 57I phones and i can see then attempt the retry.
Using a backup registrar makes the phone send the messages from a different port number - but it doesn't make it change where it sends the messages to.
The reason for the different local ports, is to allow it to listen for ICMP errors and quickly failover to the backup server. In your traces which port do the Asterisk boxes send the response to? It should still be sending it to port 5060 on the phone.
I believe we have found the cause for this. I was asked to remove the references to the backup registrar and this has resolved the multiple restarts issue. This leave me with the question of how to configure the phones to utilized by backup server in the event of a failure the primary. I will table that issue for now in order to monitor this current configuration for stability. Can anyone describe for me the conditions that would cause the phone to drop the registration(no service), whether or not the phone should recover without manual intervention when the condition is corrected?



Member Since:
2007-02-15