Skip to main content
New Participant
April 25, 2023
Question

TLS Issue Polycom VVX500

  • April 25, 2023
  • 4 replies
  • 704 views

Over the last few weeks, our company has been having small little "blips" on our Polycom VVX500 devices. During these blips, company-wide an error is thrown on our Polycom saying "Line Unregistered" and we are unable to make or receive calls. These blips last for about 30 seconds, and then things go back to normal on their own. My laptop is connected to the internet via ethernet, straight from the Polycom device. And during these 30 second blips, our network does not go down, and I am still able to ping out to Google's DNS with no issue.


I checked the logs on my Polycom's GUI, and see the following coinciding with whenever these blips happen:

0419025151|sip |5|00|SSL_get_error nLen -1 errno 110 nError 5 = (0)error:00000000:lib(0):func(0):reason(0)

0419025151|sip |4|00|TLS Listen Thread Exit

0419025151|cfg |5|00|Prm|Array parameter key.x.function.prim index 324 is out of range

0419025236|sip |4|00|[TLS] Server Certificate Common Name 'sip421-121.ringcentral.biz' doesn't match any of the following:

0419025236|sip |4|00|[TLS] Hostname: sip.ringcentral.com

0419025236|sip |4|00|[TLS] Outbound Proxy: 80.81.131.149

0419025236|sip |4|00|[TLS] Server Certificate SAN or CN validation failed

0419025236|sip |4|00|MakeTlsConnection: connection failed error 1

0419025247|sip |4|00|Abandon : Listen Thread has not exited. No need to abandon this socket

0419025247|sip |4|00|Abandon : Listen Thread has not exited. No need to abandon this socket

0419025247|sip |4|00|Abandon : Listen Thread has not exited. No need to abandon this socket

0419025247|sip |4|00|Abandon : Listen Thread has not exited. No need to abandon this socket

0419025247|sip |4|00|Abandon : Listen Thread has not exited. No need to abandon this socket

0419025247|sip |4|00|Abandon : connected socket. Send Message 0x279be98

0419025247|sip |5|00|SSL_get_error nLen 0 errno 0 nError 5 = (0)error:00000000:lib(0):func(0):reason(0)



These usually just repeat until eventually they go away until the next occurrence. These normally also happen overnight, from around 1:00 AM - 3:00 AM or so, but there have been some occasions (as recently as yesterday afternoon) where this happens during work hours. All calls are dropped when the blips happen, which is incredibly inconvenient for the company.


Does anyone have any suggestions? This looks to be TLS related... but I'm not sure if this is something we need to handle of RingCentral.

4 replies

New Participant
September 21, 2026

Still seeing this issue in 2026 on Poly Trio C60 devices, so wanted to bump this. Same symptom - brief "Line Unregistered" blips, self-recovers in under a minute, happens randomly (not on a fixed schedule). Logs show the same signature:

SSL_get_error ... 
TLS Listen Thread Exit
Registration failed ... Error Code: 503 Service Unavailable

We've ruled out our local network (confirmed by our network team - VLAN/QoS/firewall all correct) and reproduced the exact same issue on a second unit on a completely different network, and across multiple firmware versions (5.9.5, 8.1.4, and current 9.5.1). Has anyone gotten a fix or heard back from RingCentral on this? Also curious if the certificate mismatch (sip421-121.ringcentral.biz vs sip.ringcentral.com) mentioned above is still happening on RC's side.

Mary-Community_Moderator
Community Manager
Community Manager
September 22, 2026

​@amirza, 

Thank you so much for following up and sharing such thorough details and logs!

Since you’ve already ruled out local network issues across different environments and firmware builds, opening a support ticket is definitely the best next step. This allows us to escalate the issue directly to our Network Engineering Team so they can dig into our backend routing and isolate what’s happening with those edge proxy TLS handshakes.

Here is where you can open a case: 👉 RingCentral New Case Portal

When you submit it, make sure to include those log snippets, your firmware versions, and your public IP so our engineers can dive right into the traces without missing a beat.

For anyone else following along, please keep the comments coming if you're running into similar blips! The more examples we can collect from the community, the easier it is for our engineering team to spot patterns and get things squared away.

New Participant
September 22, 2026

Hi Mary,

Thanks for the response. I'd rather not open a new case if possible — Case #32594433 (Poor Call Quality) was already opened on September 11th, and all the logs, firmware versions, and trace details are already attached there. Opening a new case would mean starting over with a new engineer and re-submitting everything we've already provided.

What I was hoping for from the community was either a direct fix, or help getting Case #32594433 escalated to your Network Engineering Team, since that's who the current case owner says needs to look at the backend routing/TLS handshake side. Is there a way you can flag the existing case for that escalation instead of a fresh submission?

Appreciate the help.

Mary-Community_Moderator
Community Manager
Community Manager
September 22, 2026

That makes total sense! Thank you for providing the case number. 😊

Upon checking the case history, I can see that it is currently assigned to our Tier 2 Support Team, who are actively monitoring the issue and reviewing the attached logs and trace details. Tier 2 will complete their full diagnostic check to ensure all necessary packet captures, firmware specs, and network timestamps are fully validated, and as soon as that check is complete, they will escalate the case directly to our Network Engineering Team to investigate the backend edge proxy routing and TLS handshakes.

I am flagging your case internally as well to ensure this stays moving forward seamlessly.