Meraki Wireless with Mitel 5624 VoIP phones

[Jim_LHS]

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.

Thanks!

[1UpTech]

Hi JIm,

Possibly try setting the phone to use 802.11b/g standard.

http://mitelforums.com/forum/index.php?topic=6927.msg35730#msg35730

Have you tried setting up a SSID on a single AP and connecting the phone directly to that AP? Just to see if it's a roaming issue.

[Jim_LHS]

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!

[PhilipDAth]

Is the phone radio going to sleep by chance?

Are you able to ping the phone before making a call with it (if it responds it is probably awake, otherwise it is probably asleep).

[Jim_LHS]

The last time we tested this, if we did a constant ping to a wireless phone that had just made a call and was active on the network it would remain active and we could call from it without issues.  But, if we let a phone sit for 5+ minutes and then started a constant ping it would reply but we would get dead air when making the first call from it.  So, it looks like the ping can keep it awake/connected but can’t wake it up after it has been disconnected.

[PhilipDAth]

If you can ping the phone but still experience dead air then it wont be the network. The ping shows their is constant connectivity.  So time to go back to Mitel on that one.

[1UpTech]

Is your phone system in the cloud or on premise?

What firewall are you using?

Does the phone have any type of keep alive options?

[Jim_LHS]

Phone system is on premise with a Cisco ASA firewall.  The phone does have like a keep alive setting that the network team has made sure is on.

[1UpTech]

I agree with PhilipDAth, with your ICP being internal and the phone remaining connected to the network then this must be an issue with Mitel.

Do you know how to use the System Admin tool to locate an extension and determine the state? I'm fairly certain the ICP provides the dial tone so it may be an issue with the state of the extension.

But also I think we should get a little more information about your setup.

Are you using VLAN's? If so, is the routing for the VLAN's provided by a L3 switch or the ASA?

[Jim_LHS]

Thanks for the further replies and info!  I talked with my network admin and here is what he let me know:

Yes, we do use vlans and our layer 3 switch is routing those vlans. I'm not sure where to see the status of the phone from the Mitel admin console. I would have to do some digging or check with VAR.

[1UpTech]

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 <extension number>" then "STATE EXTENSION <extension number>"

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.

Stop packet capture and filter by ip of the phone. Try to find the difference between when the phone worked and when it stopped working.

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.

[JohnKapadais]

Hello All

i am a Mitel certified engineer and i am experiencing the same problem with 5624 Wi-Fi phones.

pcap traces taken simultaneously on two phones and the ICP shows a significant delay in SIP messages from the pbx to the phones through the APs.

Contacting Mitel and Ascom (Ascom is the manufacturer of the telephones), after they examined the traces they said that somehow the SIP messages are buffered.

We are using Vlans the meraki infrastructure is on cloud. 

Checked DSCP values EF for voice packets AF for signaling, actually these are the default values.

It is very strange indeed.

We are using WPA2 security.

Does anyone know if Opportunistic Key Cashing is enabled by default or we need to disabled somehow?

To me the problem could be with authentication, after 5 minutes the AP believes that knows the location of the handset and actually does not know it.

802.11r is disabled, although it is supported by the handset.

We are using 802.11a (5GHz).

Any feedback will be much appreciated.

Thanks in advance.

    BR

John Kapadais

[Jim_LHS]

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.

https://www.ascom-ws.com/AscomPartnerWeb/Documents/Interop/_WLAN/Meraki/i62_Meraki_MR33-42_MR-25-9_f...

[JohnKapadais]

Yesi know

i have that guide but it did not help the problem still exists.

I am thinking to try Spectralink.

  BR

[PhilipDAth]

If the phones support 802.11r - then I would definitely enable it.

[JohnKapadais]

Hello

the funny part is that, they send me an ineterop quide, in which they state that 802.11r should be disabled on APs but enabled on phone devices.

Of course it does not solve the problem, even if i enabled on both APs and phone devices.

BR

[EDfromHH]

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.

If we cannot get the SpectraLink 8440 phones to work, what other VOIP wifi phones would anyone recommend using on a Meraki could based MR16 AP device installation?

[Jim_LHS]

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.

[EDfromHH]

What model of AP devices do you have that you are testing your SpectaLink against?

[Jim_LHS]

We utilize MR52's inside the facility and MR84's outside.

Thanks!

[Singy]

was any further progress made on this?

We have a very similar situation:

Meraki MX Firewall as Gateway

Meraki Switches

Meraki MR33/52

Mitel 5624 (Ascom i62)

We either get no channel found on the device when trying to make a call (second attempt usually works although sometimes third attempt) 

Inbound never work unless the device is "connected" recently.

When calls are established they seem reasonably stable, although while testing with various settings, we sometimes get 1 way audio which sometimes re-establishes again after 10-20 seconds.

[Jim_LHS]

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 😞

[JAAC]

Hi There!

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. 

At the end, we found version problems, so we made a downgrade, we returned from 25.11 to 25.9.

We are using APs MR42 and MR52. 

Now, net IP voice is working very well on 5 GHz Band.

[Ledow]

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.).

[Jim_LHS]

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.

[rcarter]

Mitel had this information on the subject for me. 

Mitel direct from ascom.

Problem with 802.11h "power constraint" IE

Components: All Products

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

Solution: Corrected the transmit power setting for regulatory domains when "World mode (802.11d)" is not used.

[MA-Technology]

We had this same issue and finally found a solution. The phone tech needed to adjust the VOIP codec In WinPDM. After adjusting the following, the phones started working. VOIP > General G.711 a-Law had to be changed to u-Law VOIP > SIP Registration ID = Endpoint ID Authentication ID = Endpoint number SIP Proxy ID = 'blank'

[Jim_LHS]

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.

[Jim_LHS]

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.

[Jim_LHS]

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!

[Ledow]

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.

[Ledow]

To answer my own question for a Mitel 5000 CP system:

In the Mitel DB Programming tool, enable "Online Monitor" under View (at this point it warns you about playing with things you shouldn't).

Then navigate to System, Devices and Feature Codes, SIP Peers, SIP Phone Groups, the group that the phone is in, Configuration, Timers.

You'll want to set "Default Registration Interval" and "Maximum Registration Interval" to something less than 3000 (the system default is 3600, I chose 2400, I believe they are 10ths of a second which gives me a 4 minutes re-registration time).

You probably want to do that for all your SIP Phone Groups.  I'm trying it now, will report any success.

[Jim_LHS]

For us with the Mitel 5624 phones, we had to use the WinPDM tool.  This is a tool that you can use to program more features on those phones.  It does require a special USB dock for the phone.

[Mike77]

Same problem as others, Mitel 5624 WiFi SIP phones, Meraki MR42 access points. Phones worked fine with our old Aruba AP105s but after "upgrading" to these new Meraki access points the phones would stop responding after a very short period of time (much less than the 5 min idle timeout).

Tried every suggestion given in this forum with no change. Solution that was finally found after going back and forth with Meraki/Cisco & Mitel support was to upgrade to the newest BETA firmware for the MR42 (26.2). The devices shipped with 25.13 which under knows issues in the release notes states "Condition under investigation that causes VoIP RTP packet loss (MR42/MR52/MR53)", problem has completely gone away after upgrading to 26.2.