Azure Speech SDK WebSocket Connection Fails on One Quest Headset but Works on Another (Same Build, Same Azure Resource)

Question

Azure Speech SDK WebSocket Connection Fails on One Quest Headset but Works on Another (Same Build, Same Azure Resource)

David Bain (GCE) 0

Environment

Unity application using Azure Speech-to-Text
Azure Speech Region: centralus
Azure Speech SDK: 1.44.0
Platform: Meta Quest (Android 14)
Endpoint: wss://centralus.stt.speech.microsoft.com/stt/speech/universal/v2

Problem

We've had a Unity application using Azure Speech-to-Text successfully for several years. Recently, speech recognition stopped working on one headset.

What's confusing is that the same APK, same Azure Speech resource, same Speech key, and same SDK version work perfectly on another headset.

Current Initialization Code

_config = SpeechConfig.FromSubscription(

ServiceCredentials.SpeechToText.serviceKey,

ServiceCredentials.SpeechToText.region);

_recognizer = new SpeechRecognizer(_config);

await _recognizer.StartContinuousRecognitionAsync();

What We've Verified

✅ Azure Speech works in Unity Editor

✅ Same Azure Speech resource

✅ Same subscription key

✅ Same Azure region (centralus)

✅ Same APK

✅ Same Speech SDK version (1.44.0)

✅ Same Quest OS build string reported in logs

✅ Microphone audio is being captured

✅ Network connectivity exists (Photon works)

✅ HTTPS access to Speech endpoint works on both devices

A test request to:
https://centralus.stt.speech.microsoft.com

returns HTTP 404 on both headsets, which suggests:

DNS resolution works
TLS works
The endpoint is reachable

Device Difference

The only notable difference we've identified so far:

Working headset: developer-managed device
Failing headset: enrolled through Meta Work / enterprise management

Working Headset Log

The working headset successfully opens the websocket

OnWebSocketOpened

Opening websocket completed

Connected, forwarding 9 queued messages

AdapterConnected to

wss://centralus.stt.speech.microsoft.com/stt/speech/universal/v2

Failing Headset Log

The failing headset reaches the websocket open step but then fails:

WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED

Connection failed (no connection to the remote host)

wss://centralus.stt.speech.microsoft.com/stt/speech/universal/v2

Additional log output:

TransportError: connection failed

Internal error: 1

Failed with error:

WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED

The SDK then retries and recreates the recognizer, but continues to fail.

Additional Observations

The failing headset captures microphone audio successfully:

Received audio chunk

size:3200

and begins streaming audio.

The failure appears to occur before a successful Azure Speech websocket session is established.

We are not seeing:

AuthenticationFailure

401

403

Forbidden

which makes me think this is not an Azure authentication issue.

Questions

Has anyone seen WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED from Azure Speech on Android/Quest devices?
Does Azure Speech use any websocket/TLS requirements that differ from a normal HTTPS request?
Are there known issues with Azure Speech SDK 1.44.0 on Android 14 or Quest devices?
Has anyone migrated from the legacy Unity Speech SDK package to the NuGet-based approach and seen similar websocket behavior?
Is there any diagnostic logging available beyond the Speech SDK logs that would help identify exactly why the websocket open operation fails?

Any guidance would be appreciated. At this point the Azure resource itself appears healthy because the same build works correctly on another headset, but I'm trying to determine whether this is:

an Azure Speech SDK issue,
a websocket/TLS issue,
or something specific to the managed Quest environment.

SRILAKSHMI C 19,730 Reputation points Microsoft External Staff Moderator

2026-09-11T17:07:58.09+00:00
Hello @David Bain (GCE)

Thank you for providing the detailed information, logs, and the comparison between the two Quest headsets.

We understand that the application has been working successfully for several years and that the same APK, Azure Speech resource, subscription key, region, and Speech SDK version (1.44.0) work correctly on another Quest headset. We also understand that the affected headset is enrolled through Meta Work / enterprise management, whereas the working headset is developer-managed.

Based on the information currently available, the failure appears to occur during the WebSocket connection establishment rather than during microphone capture or a normal Azure authentication flow.

The key error reported by the affected device is:

WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED

followed by:

Connection failed (no connection to the remote host)

This is important because the application is successfully capturing microphone audio, and you are not seeing errors such as 401, 403, or AuthenticationFailure. Therefore, based on the current evidence, there is no indication of a straightforward subscription-key or Azure Speech resource authentication problem.

Recommended troubleshooting

The first item we recommend checking is the Speech SDK version.

You are currently using Microsoft Cognitive Services Speech SDK 1.44.0 on Android/Quest. Microsoft's Speech SDK troubleshooting guidance identifies connection-related issues on Android/Linux with older SDK versions, including issues associated with certificate revocation list (CRL) handling.

For this reason, please upgrade the Speech SDK to version 1.48.2 or later and retest the application on the affected Quest headset.

Troubleshoot Speech SDK issues

If upgrading the SDK is not immediately possible, the same troubleshooting guidance describes CRL-related configuration options, including:

OPENSSL_DISABLE_CRL_CHECK

OPENSSL_CONTINUE_ON_CRL_DOWNLOAD_FAILURE

These should only be applied according to the documented Speech SDK configuration guidance and should be evaluated in your test environment before being considered for production use.

Check the difference between the two Quest devices

Because the same application configuration works on one headset and fails on another, the difference between the two devices is particularly relevant.

The affected headset is enrolled through Meta Work / enterprise management, so we recommend checking whether the device-management configuration introduces any differences in:

Proxy configuration

TLS/certificate handling

Certificate validation

Firewall or network security policies

WebSocket traffic restrictions

Enterprise network inspection or filtering

Device-level security policies

The successful HTTPS test against:

https://centralus.stt.speech.microsoft.com

confirms that the endpoint is reachable over HTTPS, but this test alone does not establish that the WebSocket connection used by Speech SDK is able to complete successfully. The Speech SDK uses a WebSocket connection for continuous recognition, so it is useful to specifically compare WebSocket connectivity between the working and failing devices.

Retry behavior

The logs also indicate that the SDK is retrying and recreating the recognizer after the WebSocket failure.

Please ensure that the application does not introduce an aggressive retry loop when the connection fails. If application-level retry logic is being used in addition to the SDK behavior, we recommend using an appropriate delay/backoff between attempts rather than immediately creating another recognizer and reconnecting.

This will help avoid repeatedly attempting a connection while the underlying connectivity issue is still present.

Regarding the individual questions

1. Is WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED a known Azure Speech issue?

The error indicates that the underlying WebSocket connection could not be opened successfully. The information currently provided is not sufficient to conclude that this is an Azure service-side issue. The documented Android/Linux connection troubleshooting guidance makes the SDK version an important first check.

2. Does Azure Speech WebSocket connectivity have different requirements from normal HTTPS?

The successful HTTPS test is useful, but it does not completely validate the WebSocket connection path. Since the failure occurs specifically while opening the Speech WebSocket, WebSocket/TLS handling on the affected device should also be investigated.

3. Could Speech SDK 1.44.0 be relevant?

Yes, this should be investigated first. Since the affected application is using 1.44.0 on Android, upgrading to 1.48.2 or later is the recommended next step based on the documented troubleshooting guidance for older Android/Linux SDK versions.

4. Could the Unity package/NuGet migration be related?

There is not enough information from the current error to establish that the packaging approach is responsible. Since the exact same APK works on another headset, the device/environment difference should be investigated first.

5. Is additional diagnostic information available?

If the issue continues after upgrading the SDK, the updated Speech SDK logs would be useful. In addition, comparing the working and failing devices at the network/WebSocket/TLS level would help determine whether the failure is occurring before the request reaches the Azure Speech service.

As the same build and Azure configuration are working successfully on another headset, we recommend the following order of investigation:

Upgrade Speech SDK 1.44.0 → 1.48.2 or later.

Retest the same APK/configuration on the affected Quest headset.

If the issue persists, compare the managed and unmanaged headset network, certificate, TLS, proxy, and WebSocket policies.

Review the CRL-related configuration described in the Microsoft troubleshooting documentation.

If the failure continues, provide the updated SDK logs and any additional WebSocket/TLS diagnostic information so that the issue can be investigated further.

At this stage, we cannot confirm that the Azure Speech resource itself is unhealthy, particularly because the same resource and credentials successfully work from another headset.

I Hope this helps. Do let me know if you have any further queries.

Thank you!

1 answer

Your answer

Answer 1

WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED is documented as a connection failure pattern for the Speech SDK. For the specific CRL-related case, the documented indicators are:

running on Linux or Android
using SDK version prior to 1.48.2
failures that can appear after a period of working connections or when connecting across regions
SDK logs that show TLS verification failures such as certificate verify failed
Error 44 / X509_V_ERR_DIFFERENT_CRL_SCOPE

That makes the first concrete action to upgrade from 1.44.0 to 1.48.2 or later and then retest on the failing Quest device. The documented risk of staying on an older SDK is continued connection failures until the SDK is upgraded, CRL checking is disabled, or the CRL cache is cleared.

For diagnostics, enable Speech SDK logging and inspect the TLS-related lines. The documented log signatures to look for are:

SPX_TRACE_ERROR: AZ_LOG_ERROR: tlsio_openssl.c:1655 Error 44 was unexpected
SPX_TRACE_ERROR: AZ_LOG_ERROR: tlsio_openssl.c:691 error:0A000086:SSL routines::certificate verify failed
SPX_TRACE_ERROR: web_socket.cpp:930 WS open operation failed with result=1(WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED)

If those lines appear on the managed headset and not on the unmanaged headset, that strongly points to a TLS/CRL validation difference on the device rather than a Speech key or region problem.

On authentication: the documented authentication failures for Speech SDK typically surface as 401, 403, AuthenticationFailure, invalid SpeechConfig, or access denied 0x5. Since those are not appearing in the failing logs, the failure pattern described is more consistent with a lower-level connection problem than with invalid key/region configuration.

On HTTPS versus WebSocket behavior: the context confirms the Speech SDK uses WebSocket connections, and the failing error is specifically during WebSocket open. A successful HTTPS reachability test does not rule out a WebSocket/TLS problem.

Given the device difference, the most supported troubleshooting path is:

Upgrade the Speech SDK on Android/Quest from 1.44.0 to 1.48.2 or later.
Enable SDK logging on both headsets and compare TLS-related errors during socket open.
Check whether the failing device shows the documented TLS indicators: certificate verify failed, Error 44, or X509_V_ERR_DIFFERENT_CRL_SCOPE.
If the app is using a Speech container anywhere in testing, make sure it is initialized with host authentication. Using key+region sends traffic to the public Speech service instead of the container.
If the issue persists after upgrade, use the public support channels for Speech SDK issues: Stack Overflow with the azure-speech tag or the Speech SDK GitHub issue tracker.

For the Unity package migration question, the available context does not document a Unity-specific migration issue causing this behavior.

References: