Mitel Sip Firmware Download

[Bran Bast]

Sincethe Mitel 5235 I own was BNIB (brand new in box), I started by installing the first firmware version 4.0.0.13 and proceeded through to 8.0.0.4. Each version of the firmware allowed me to use the Web Configuration Tool (i.e, the IP address of the phone) to successfully register the 5235 as an extension on FreePBX, using a procedure very similar to what was described when I configured the Mitel 5330e. For reference the default password is admin/5235 .

If you are running Rel 3 software, you will need to upgrade to Rel 4 prior to going to 5.0.0.21. It is strongly recommended not to upgrade through the GUI. Only the Boot (Set) upgrade should be performed if you are running software lower than 6.0.0.19.

Although account settings tend to be saved between firmware upgrades, it is recommended that a factory reset is performed at the end of the process. Phones not reset might suffer from miscellaneous issues, such as random SIP re/registration failures and phone setup Web pages not showing.

For all SIP Phone types running any software previous to Rel 7.2, this includes Rel 3.0, Rel 3.1, Rel 4.0, Rel 5.0 MUST upgrade to Rel 5.0.0.21 prior to upgrading to Rel 7.2.

Rel 5.0.0.21 MINIMUM is required as a stepping point up to Rel 7.2. Any other method of upgrade could result in corrupted Flash Memory on the SIP Phone resulting in a permanently dead phone.

When upgrading to Rel 7.2 from any previous software through the Rel 5.0.0.21, not all SIP Phone Feature/Parameters are carried forward. The Key Definition such as Shared Line, Menu Items, Feature Keys, etc. are not carried forward. (The only exception is Speed Dials, which are carried forward.) And Call Logs are not carried forward.

To view the firmware version using the Web Configuration Tool:

Access the Home Page of the Web Configuration Tool and click Firmware Updates.

To view the firmware version using the Superkey Menu Interface

These phones are now supported on RC with autoprovision phone per ( -supported-deskphones-ringcentral.html#mitel). However, the instructions given by the RC admin portal wizard and also on -provisioning-mitel-deskphones.html will not work if your phones are on older shoretel firmware. I spoke with Mitel SIP phone support and here are the steps that worked. Sharing for anyone who is trying to convert these phones to RC.

If you get "No service" after entering the config server and rebooting, try this instead: after the phone reboots in step 3, watch the phone boot up. When it says something like "press any key to enter setup", press any key. Then continue from step 5 and enter the config server address.

We are having an issue on our network where the Mitel 5624 wireless phones will have dead air the first time you try to call someone after sitting idle for about 5 minutes or more. We have worked with both Mitel and Meraki support and haven't been able to find the root cause or a fix. Wanted to throw it out there in case others have possibly seen something similar. I believe the Mitel phones are based on the Ascom i62 chip set.

We have tried setting a few phones to b/g only with no results. We also tested a standalone AP on a different SSID with no luck. We are going to test a couples phones today on b/g only and connected to a standalone AP/SSID to see if the combination has any results. Thanks for the feedback!

I'm not extremely familiar with Mitel myself. I've only had to muddle through the system a few times. There should be a maintenance or diagnostic area. The command would be something like "LOCATE EXTENSION " then "STATE EXTENSION "

Setup a packet capture as close as you can to the Mitel system. Reset the phone or do whatever you normally do that makes it work and check the extension state so you know how it should look. Wait your usual 5 minutes or so then check for dial tone again. Once dial tone fails, check extension state to see if it has changed.

In my mind, one of 2 things are happening. Either communication is being lost or mis-routed during the process resulting in the phones inability to communicate with the ICP. Or the phone is communicating fine but the ICP isn't updating the extension.

That is a lot of what we have tried to. Gone through the settings that Meraki has provided we should be using but it just doesn't seem to be working well. We did get a SpectraLink phone to do some testing with and it does do a little better than the 5624 phones, but still has a few blips here and there. Interesting enough though, there is now an i62 (ascom) and Meraki guide released that shows what should be done to be setup correctly. I have my network admin checking on this to make sure everything is in place, which I believe at first glance they are but doesn't hurt to double check.

You mention you got a SpectraLink phone, which one. We purchase 2 SpectraLink 8440 phones at the recommendation of our Mitel value added reseller, but could found out later that the SpectraLink 8440 phones were NOT certified to run on a Meraki MR16 AP devices, which comprises 99+% of our AP devices.

We tested the SpectraLink 8440 and had better luck with them than the Mitel 5624's right now. We are working with Mitel and Meraki still on figuring out the issues as it is a certified solution now. Right now we are gathering packet captures for Mitel from various access points with the same device.

Nothing new yet, we still experience what you are seeing. We have a Cisco ASA firewall, Meraki Switches, Meraki MR52/84 and Mitel 5624 phones. The issues describe are basically what we are seeing as well. We are working with Mitel and Meraki on this still, but no solutions

We had similar problems, using Cisco VoIP phones.. 7921, 7925, 8821.. no one work well after we update version on APs. I mean, we had good performance on 25.9, but when we update on 25.11, we lost that good performance on VoIP phones. after a 10, 15 secs, we lost voice on phones, we saw the dashboard, we could see good level and equipment connected, but no service.

Thought it was just me.

We have a 5624 and it just falls off the network randomly - despite being on the Wifi and ping-able at all times and nothing showing unusual on the device / wifi, it sometimes suddenly decides that it can't connect to the server (i.e. the Mitel appliances... but they are up for literally everyone else for 100+ IP phones that are wired in). IP traffic to it passes fine but it thinks it's not there.

Turn off, turn on, it reconnects works absolutely fine again.

We literally have it as one of the only devices in a room with a Meraki MR33 for most of the time and it only seems to do it when it's in that room - when it's roaming between points it appears to work just fine. It's when it's sitting in the office, and is there for a long time, it decides to just fall off. So it sounds sleep-related somehow.

Very frustrating, given that there isn't another piece of kit on site that exhibits such symptoms and we are Meraki for all switching and wireless.

We also have MR16 and MR18 devices, and most importantly it *never used to do that* - it didn't start at any given point (e.g. immediately after a firmware upgrade, or when we swapped to an MR33, etc.).

That is interesting as well. We haven't made any new progress up to this point. It is frustrating considering that those devices are supported on the Meraki wireless, but we can't get them to work even with the recommended settings.

Background: When the Power constraint IE is present and when the device is configured for reg domain US the device defaults to 0dBm Tx power. (Most likely happens to all modes except "world mode") This is especially a problem with Aerohive and Meraki as this IE is present by default and cannot be removed. With Cisco this IE only appears when DTPC is unchecked and local power constraint is configured under Wireless>>802.11a/n/ac>>802.11h in the WLC. Other platforms impact unknown at the moment. Due to FCC regulations reg domain "world mode" is no longer allowed as only source to determine geographic location. Meaning using "World mode" is not a solution. See IEEE 802.11h section 7.3.2.15 for details

Appreciate the continued feedback. We tried this today and we are still having failures. We have done some packet captures and testing with Meraki and Mitel and right now it appears that our phone system is not getting a 180 packet from the phone which is causing the dead air the first time.

Just wanted to provide the latest feedback and status on this as we troubleshoot. We have done quite a bit of packet captures all the way from the vMware distributed switch that the Mitel virtual machine runs on to the AP that the wireless VOIP phone is connected to. What we have found and are able to replicate very easily is the issue lies in a dropped 401 Unauthorized SIP packet not getting to the phone from the phone system. The packet gets from our Mitel virtual machine through the distributed vMware switch and to our 425 Meraki core. However, it doesn't get from the 425 core to our 325 switch stack that our AP is plugged into. So somewhere between the 425 core and the 325 switch stack it is getting dropped it appears right now.

Ok, wanted to update with the solution we have found for this issue. It turns out that the Meraki switches flush the ARP table every 5 minutes. The SIP registration expiration was set to 6 minutes on the 5624 phones. So we had to change that setting (VOIP-SIP-SIP Registration Expiration) on the 5624 to be less than 5 minutes. This way they let the Meraki switches know they are still alive on the network. Hope this helps anyone that might need it in the future!

That indeed sounds like a reasonable diagnosis.

My question: Where do you change that? Presumably in the Mitel system itself, not the phone? If on the phone, do you know where? The VOIP menu on my handset doesn't have anything but SIP login options. The Mitel controller has a bunch of records for that handset that indeed have timeouts for 3600 seconds, but I can't change them.

3a8082e126