Just tested using the Troubleshooter URL and received same behavior (both off and on VPN, from different machines as well)
Call Quality attempts to check, then goes to "Checking -> Never Ran", but I can see it dialing *86 in background. Then after waiting 10-15 seconds, it then shows "Excellent" for Call Quality. I tried this multiple times in a row and each time had same behavior.
You can see the 'Never Ran' below, but if we wait 10-20 seconds, that changes to Excellent as shown in screenshot 2.
Now Call Quality is "Excellent" after waiting 10-20 seconds while *86 and diagnostics completes
Original Message:
Sent: 10-09-2025 13:28
From: Chad Markle
Subject: Telephony-0010 and Telephony-0011 Events recently started
We use ZScaler as well and have RTP traffic bypassing it.
I've tried running Diagnostics several times on and off VPN, but I could only get that error message you are getting immediately after disconnecting from the VPN. If you run the Standalone WebRTC Diagnostics app, do you get that error as well?

------------------------------
Chad Markle
Senior Director of IT Unified Communications
Original Message:
Sent: 10-09-2025 12:36
From: Shane Jenkins
Subject: Telephony-0010 and Telephony-0011 Events recently started
Hi Chad,
Just tested this on our VPN and off the VPN.
Both scenarios seemed to behave the same. We do get an error as shown in screenshot below, but if we wait it out for 15-20 seconds, we eventually get Test Results and they are positive. We first thought this was something to do w our VPN (Zscaler), but this behavior also occurs off network from our home network. We've had several individuals test this from their home network w same results. We do have supposedly ALL RTP traffic bypassing Zscaler when on network, but again this seems to occur even when not on the VPN.
This also generates the Telephony-0011 event when this occurs.
Are you able to replicate this at all?
------------------------------
Shane Jenkins
Original Message:
Sent: 10-09-2025 12:18
From: Chad Markle
Subject: Telephony-0010 and Telephony-0011 Events recently started
Shane,
Do you receive any errors when running WebRTC phone diagnostics, or does it run successfully and you get a TELEPHONY-0011 event?
Thanks,
Chad
------------------------------
Chad Markle
Senior Director of IT Unified Communications
Original Message:
Sent: 09-30-2025 10:01
From: Shane Jenkins
Subject: Telephony-0010 and Telephony-0011 Events recently started
Hi Kevin / all,
Really appreciate the information and good to know we aren't totally alone in this. We felt pretty strongly that the Edge update led to these new events / errors being reported. We're now getting them hundreds per day and previously we were getting zero of these specific errors. Kind of crazy that we can also recreate at least one of the "errors" on demand by simply running WebRTC phone diagnostics.
Kevin, did you get any indication that Genesys would address this or correct this issue?
Seems like that Edge version introduced or significantly changed how the Edge processes these events. To your point, we also have a trigger and thus are getting email notifications each time these events are generated and we also noticed the disconnect type being ERROR now vs. ENDPOINT for some of them. Just curious if you got a sense this is something Genesys can/will address?
I'll reach back out to support via our open ticket and ask for additional information and if there are next steps as well. I'll update here if I learn anything more/new.
Thanks again all!
------------------------------
Shane Jenkins
Original Message:
Sent: 09-30-2025 01:42
From: Kevin Young
Subject: Telephony-0010 and Telephony-0011 Events recently started
Hi Shane,
We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).
This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same observations as you had above for the operational log. Genesys confirmed these changes.
Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.
hope that helps,
------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com
Original Message:
Sent: 09-29-2025 10:37
From: Shane Jenkins
Subject: Telephony-0010 and Telephony-0011 Events recently started
Good morning all,
Curious if anyone else has ran into this issue.
We are a FedRAMP customer and starting last week (09/25/25 to be exact) our Edges (vendor managed) were updated to version 1.0.0.26833 after midnight on 09/25. Starting at around 6:20AM EST, we began receiving Telephony-0010 and Telephony-0011 events for the very first time (we've been on the platform for around 18 months and cannot recall receiving these two specific events until 09/25). We also have a trigger setup to email us when operational events occur. We cannot find an email for previous 6 months of these events occurring.
We can recreate the 0011 event by running webRTC diagnostics and this occurs whether we're on our corporate network or using a personal machine from our home network. Several of our folks have recreated this. We highly suspect the Edge update to 1.0.0.26833 or something w last weeks platform release has changed something which is now leading to us seeing / receiving these two specific events. Has anyone here ran into the same issue or something similar?
You can also spot check these from the Operational Console. Seems odd to us that multiple users can recreate off or on network and these first began happening last week. Seems logical to think something changed somewhere.
We have an open ticket w support, thought we'd check here as well.
Telephony-0011 is a DTLS Peer Disconnect event
Telephony-0010 is a WebRTC ICE Idle Detected
Thanks as always!
#PlatformAdministration
#SIP/VoIP
#SystemAdministration
#Telephony
------------------------------
Shane Jenkins
------------------------------