RingCentral Application Disconnecting (Mobile Devices)

[RubenG]

Hello,

Wanted to see if anyone is currently utilizing the RingCentral application for calling and experiencing similar issues.

Currently using RingCentral for calling. I have the issue where the application shows a "Reconnecting" screen stating it lost connection. This happens about every 5-8 minutes.

Currently I am seeing this issue only when my Firmware is on version 26 or higher.

I have tried on Version 25.13 and did not run into any issues on this version.

I also tried the following APs:

• MR52
  • No issues on version 25.13
  • "Reconnecting issue" on version 26.2
• MR33
  • No issues on version 25.13
  • "Reconnecting issue" on version 26.2
• MR42E
  • The APs minimum firmware version is 26, so when I put it on a network where the Firmware is 25.13 it shows as version 26 and sometimes as 25.13. I still have the "Reconnecting issue". I can't say I have tested on version 25.13

I Understand that anything above version 25.13 is considered Beta. However the APs that were purchased were MR42E and we weren't aware of this problem until after implementation. Does anyone know of any workaround?

Or will another AP Model have to be purchased?

I already contacted Meraki Support, the Tech claims he has tested it on a version 25.13 and still gets the reconnect issue on an MR52. However in my environment I have not seen the same issue on MR52 version 25.13. 

I have also tested the RingCentral Application on a different network running MR33, on both 25.13 and 26.2. I still only see the issue on version 26.2 the issues does not come up on version 25.13, therefore I don't think it can't be a configuration issue. Unless theirs some new configuration change I missed. 

Any help would be appreciated.

Thanks

[BrandonS]

Which RingCentral Application are you seeing this on?  I use RC and Meraki and have never seen this, but I am interested and might be able to help by trying to recreate some scenarios.

I suppose you have isolated this to wireless by testing on wired connections also (unless it is the mobile app)?

[RubenG]

I am using the RC Phone Application. We have tested it on a laptop and wired client. But only see it on Wireless Mobile devices when APs are on 26 or higher. Everything else is working fine. 

Noted that in order to recreate you would have to upgrade to 26.2 or use an AP whose minimum Firmware version is 26.

[NolanHerring]

Are you using the new DHCP Mandatory setting while on 26.2 version?

[RubenG]

I am not using that feature, Currently it is set to disable. Let me test with it on.

Is the prefered option Enabled? Is their any known issues with this feature?

---

@NolanHerring wrote:
Are you using the new DHCP Mandatory setting while on 26.2 version?

---

[NolanHerring]

If it is disabled then that is fine. I know I originally saw some reports with 26.1 that it was a little unstable when it was enabled.

[RubenG]

Just Tested with the DHCP Mandatory featured enabled. Still get the "Reconnecting" message.

Any other ideas?

[BrandonS]

I have an MR32 and MR33 where I am at. Before I try upgrading them 26 are you using the old RC phone app or the new one?  iPhone?  Can you share a screenshot of the error and of your SSID settings?

For the new RC app (https://itunes.apple.com/us/app/ringcentral/id715886894?mt=8) I know a trick to turn on debug features and logs.

[RubenG]

Using this Application on Version 11.0.1:
https://itunes.apple.com/us/app/ringcentral-phone/id293305984?mt=8

I have tried multiple Settings, Meraki DHCP, Bridging, No VLAN Tagging, with VLAN tagging, with splash page, without splash page, New Network with default settings. Still get same issue.
I have tested it on 3 seperate Orgs on different Networks and still the same issue. All with different forms of configuration. 

Note I have also put it on Airplane Mode and connected to wifi so it doesn't do anything funky with the cellular and same problem.

Here is the error I see:

[BrandonS]

So to recreate this I would have to be on an active call?  I will give it a try.

I suppose you have a reason for not using the new app?  Maybe worth testing that one too.

[BrandonS]

I got the reconnecting message and warble tone about 15 seconds into my first test call 😉

RC QoS shows 6.5% packet loss from server to client to match.

Let's get Meraki to fix it.  If you want to share your case number I can create another and reference it.  I am a reseller of both Meraki and RingCentral so have some vested interest in solving this too.

[RubenG]

Hello Brandon,

I send you a DM with the case number so you can refernce.

Thanks for the help. Let me know if you end up finding a solution or if Meraki releases a patch for it.

[SoCalRacer]

I am seeing this with a MR33 behind a MX67 at one office. I need to test at a different office with the same hardware. I believe the firmware is different on the MR33 at the 2 locations, but not getting the issue on the second location last I checked.

[BrandonS]

---

@SoCalRacer wrote:

I am seeing this with a MR33 behind a MX67 at one office. I need to test at a different office with the same hardware. I believe the firmware is different on the MR33 at the 2 locations, but not getting the issue on the second location last I checked.

---

Thanks.  That would be helpful to have a another person report this.  If you can replicate it and confirm that it seems to be a problem with v26 please open a case with Meraki and I can give you my case number which already references Ruben's

And I submitted a case via email about this and referenced Ruben's case over the weekend.  I have not had a reply yet except to say someone picked up my case.  I have not had time to push, but I will when I do.

[SoCalRacer]

My MR33s at both locations are 25.13. So maybe we need to look at the MX. My 67s are on 14.39.

[BrandonS]

Good point, that is possible.  I can try it here to with MX65 currently on 13.  Thanks and let us know.

[BrandonS]

I recreated this issue again and sent Meraki support a PCAP from the LAN side of my MX that captures the issue.  it was a short loss of audio from server toward client and the RC app showed an error and also played the progress tone while re-establishing connection.  It happened just after 12 minutes into a call. I also sent them the server side RingCentral QOS report screenshot and details.

[SoCalRacer]

@BrandonS Partner for RC and Meraki here also. Also noticing issues accessing the service.ringcental.com site to login to their portal when behind the MX wired. Not sure if that is related to the phone issue.

What is the difference in the apps? I have the old app on Android, debating on installing the new one for testing.

[BrandonS]

@SoCalRacer  I have never had a problem accessing service.ringcentral.com behind Meraki. Maybe a contend filter is blocking?  What error do you see?

As for the apps, the “new” one is a result of RingCentral purchasing Glip. They have been adding features to it and it seems the intention is to make it a unified app similar to Teams or Slack, etc. The original phone app is still being maintained and updated, but I feel like it will be abandoned at some point and everyone forced to the Glip based app when it is mature enough. 

Personally, I like the Glip app and use it over the phone app. 

I am am still working with Meraki support in the v26 issue.  It is really frustrating and hard to make progress. One of those issues that only seems to happen with two vendors and it is not clear who is really at fault and needs to fix it. I worked extensively with RC already and I am leaning towards Meraki needing to fix something  it needs to be clearly identified as a problem to them first though. 

[SoCalRacer]

A bit frustrating, but I found out the L3 rules on the firewalls were copied from a production mx to the new ones. In the process the rules were set to deny, when they should have been allowed. End result my config is working without issue at the office. I can check at home, since I have the same setup there. MX67/MR33.

Just to double check what kind of circuit are you on? Any tests from that side? Any loss to other servers? How much optimizing of traffic to RC have you done on your Meraki side?

[RubenG]

Interesting, @SoCalRacer what Firmware version are you running on the wireless? 

I am working with Meraki Tech, he will be pushing some changes. Unclear on what he means yet. But will retest and let you know if it fixes the issue. 

[BrandonS]

I had support make a back end change to two of my MR networks.  It was to disable 802.11k on a per MR and per SSID basis as I understand.  So far I have not been able to reproduce the lost audio issue on v26.2

This is promising though.

[SoCalRacer]

@RubenG I am running latest stable on everything.

MR33 = 25.13

MX67 = 14.39

[RubenG]

I can also confirm that disabling 802.11k solves the reconnecting issue. I tested it and di not have any problems while on 26.2 with 802.11k disabled. 

I also received the following explanation from support:

"The MR sends a standard 802.11k action frame to the client device requesting it to reply back with a report of beacons seen in the area and instead of immediately replying back stating that it's too busy to scan (per the standard) or scanning and replying promptly, it agrees to do the scan and it takes a long time (several seconds) and during this time duration the performance degrades and the call enters the 'reconnecting' loop because the client is scanning off the channel.

In the monitor mode pcap if you observe at the time stamps when we get the 'reconnecting' error you will see that the client has sent a null data frame with 'power management=1' which implies that the client device is informing the AP that it is entering sleep mode. According to the U-APSD standard when the client station informs the AP that it has entered sleep mode the AP buffers all the frames which are intended for the client station until the client station sends another null data frame to the AP with 'power management=0' which implies that the client is awake again and then the AP sends the data buffered for that client device. The duration wherein the client station is going into the sleep mode is the duration where the call enters 'reconnecting' state.

Hence when we add a configuration on the backend to disable 802.11k to mitigate the client side behavior, the 'reconnecting' behavior is not observed. This configuration is added on the backend of the AP on a per SSID basis and needs to be added by Support."

[BrandonS]

@RubenG Thanks for sharing that.  I have shared this thread and also a similar response I got from support with a team at RingCentral.  My reply indicated they felt this was an iOS issue for Apple to fix, but I told RingCentral I am not sure I agree since I use other VOIP apps like Dialpad on my iPhone and it does not have the problem.

[RubenG]

@BrandonS , I have also tried it with an Android phone and had the same issue. 

[BrandonS]

@RubenG Good to know.  So it probably has something to do with the way RC is using the 802.11k protocol.  The RingCentral team should see this comment since I directed them to this thread.  Thanks.

[RubenG]

@BrandonS 

have you tried this on another type of wireless AP and enabled 802.11k?

[BrandonS]

---

@RubenG wrote:

@BrandonS 

have you tried this on another type of wireless AP and enabled 802.11k?

---

I have not.  I don't have any gear around to try that with unfortunately.  I am still engaged with RingCentral though and there has been some discussion around how their soft phone interacts with iOS and 802.11k.  they have asked me to do some further testing that I haven't had time for yet.

I can confirm that the 802.11k workaround definitely solves the problem for me now.  I have had many long calls using RIngCentral on my iPhone and no interruptions at all.

I can probably add you to the Glip conversation with the RC developers if you are interested.  Just let me know and DM your email address to me.  They are really good and interested to get to the root cause of this issue.  I am not expecting Meraki to do anything else with it at this point since they believe it to be an issue with iOS and not their problem. 

[SoCalRacer]

I do have a MR42 and MR33 I could test this on. I am unclear on how to disable/config 802.11k, if you provide some assistance I could do some testing. My existing testing was with no changes to 802.11k. Using a Google Pixel 3 XL with both new and old apps on MR33 behind a MX67. I also have other clients environments that have different MX devices that I could test on.

[BrandonS]

@SoCalRacer You have to contact Meraki support to disable 802.11k.  They do it on a per MR and per SSID basis.  You can reference my case number so they have some context: 03790307

The test RingCentral wants me to try is to determine if this is iOS or RC app specific.  I would have to call support to have them "break it" again and then run to iOS devices at the same time while waiting for the RC app call to interrupt.  Then see if it happens on a different voip app, Dialpad is the one I am planning to test with.  You can see why I don't have time for this 😉