Azure Communication Services (ACS) intermittently fails to play the expected event during calls. In these cases, the call times out, remains silent, and call recording does not start.

Question

Azure Communication Services (ACS) intermittently fails to play the expected event during calls. In these cases, the call times out, remains silent, and call recording does not start.

Anonymous

Issue Details:

The expected event is not triggered consistently by ACS.

When the issue occurs, the call is silent and eventually reaches a timeout.

Call recording is not initiated for the affected calls.

The issue is intermittent and does not occur on every call.

For example, out of 10 test calls, this issue occurs approximately 3–4 times, while the remaining calls function as expected.

Impact:

This behavior impacts call flow reliability, call recordings, and overall user experience.

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-02-06T11:26:51.4233333+00:00

Thank you for contacting us about the Azure Communication Services (ACS) intermittently fails to play the expected event during calls. In these cases, the call times out, remains silent, and call recording does not start. issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-02-06T17:36:01.6366667+00:00
Hi @Anonymous ,

Thank you for reaching out regarding the issue with Azure Communication Services (ACS), where the expected event sometimes does not play during calls. When this occurs, the call times out, there is no audio, and call recording does not begin.

Why this happens:

Call recording starts only after a call is successfully connected. If the call fails or times out before connecting, no recording, file, or notification is created.

Audio playback starts only after the call is connected and media is established. If this does not occur, no audio plays, the call stays silent, and it eventually times out as expected.

Call lifecycle events are delivered via webhooks, not guaranteed Event Grid notifications. If events are delayed or missed, related media playback or recording logic may not run, causing intermittent failures.

Media establishment can intermittently fail due to network or transient service issues. When this happens, the call may connect without audio or recording and eventually time out.

Recommendations:

Ensure the callback (webhook) endpoint is highly available, secure (HTTPS), and low‑latency.

Use Call Automation event handling to manage delayed or out‑of‑order events.

Monitor network and media quality using ACS diagnostic tools.

Check Azure Service Health for any regional ACS issues during intermittent failures.

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/voice-video-calling/get-started-call-recording?pivots=programming-language-javascript
https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/troubleshooting-codes?pivots=calling
https://learn.microsoft.com/en-us/azure/communication-services/how-tos/call-automation/handle-events-with-event-processor
https://learn.microsoft.com/en-us/azure/communication-services/concepts/troubleshooting-info?tabs=csharp%2Cjavascript%2Cdotnet
https://learn.microsoft.com/en-us/azure/communication-services/concepts/voice-video-calling/call-recording

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Anonymous

2026-02-09T11:19:58.1766667+00:00

Hi @Golla Venkata Pavani

We are observing an intermittent issue with Azure Communication Services Call Automation where one of the expected Play prompts is not audibly heard during the call. When this happens, the call remains silent and eventually times out, and in some cases call recording does not start. The behavior is inconsistent (around 3–4 out of 10 calls).

We enabled diagnostics and analyzed logs in Microsoft Azure Log Analytics (ACSCallAutomationIncomingOperations). For the affected calls, every Play operation shows ResultType = Succeeded with valid playback duration, and we do not see any PlayFailed, timeout, or failure events. From the service logs, ACS appears to have successfully executed playback, yet the caller hears silence.

Could you please confirm if this could be related to media establishment delays, latency, or intermittent audio delivery issues on the ACS/PSTN path, even when Play returns Success, and advise if any additional service-side telemetry can be checked to validate this?
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-02-10T00:41:09.0633333+00:00
Hi @Mohammed Suhail ,

Thanks for the update.

Yes, You are right. what you are seeing can be related to media establishment delays, latency, or intermittent audio delivery issues on the ACS ↔ PSTN media path, even when the Play operation returns Success. And there is no additional service‑side telemetry today that can conclusively validate audible audio delivery to the caller.

Yes. Microsoft documentation consistently distinguishes between:

Control‑plane success (API/action execution)

Media‑plane delivery (actual audio flowing to the remote participant)

From the Call Automation overview and media action model:

Call Automation uses an asynchronous action–event model

A Play action returning Succeeded confirms that:

The request was accepted

The media action was executed by the service

It does not guarantee that audio was audibly rendered to the PSTN endpoint

Is there any additional service‑side telemetry to check?

Based on the troubleshooting guidance and service limits documentation for Azure Communication Services, ACS diagnostics and Log Analytics can validate API execution and service-side processing, but they do not provide telemetry that confirms audio packet delivery or rendering on the PSTN endpoint. As a result, intermittent media issues caused by network conditions or the PSTN are documented as possible, even when API operations complete successfully.
Recommended Next Steps

Correlate with media metrics - Query ACSNetworkDiagnostics and ACSCallDiagnostics for the affected call IDs / correlation IDs. Look especially for elevated jitter, packet loss, or media negotiation warnings during silent calls.

Application mitigations - Wait for PlayCompleted, then use Recognize with appropriate silence timeouts. Add retry logic if silence is detected (via no input or timeout).

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/concepts/call-automation/play-action
https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/audio-issues/overview
https://learn.microsoft.com/en-us/azure/communication-services/concepts/known-issues?pivots=platform-web
https://learn.microsoft.com/en-us/azure/communication-services/concepts/troubleshooting-info?tabs=csharp%2Cjavascript%2Cdotnet

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

Anonymous

Hi @Golla Venkata Pavani ,

After further debugging, we observed that the issue occurs when an event is sent back from ACS to our application. Please find the reference details below.

We have also queried the data, and all the related events are showing as successful (please refer to the attached image). However, our concern is that the error observed in the application is not reflected in the call diagnostics. Ideally, the application-level error should also appear in the call diagnostics.

Could you please help us understand why this error is not being captured in the call diagnostics? Additionally, it would be helpful if you could share the relevant tables or logs we should review to further debug this issue and assist us in identifying the root cause.

And additionally how should be mitigate this error of cognitive service failed.

ACSCallAutomationIncomingOperations
| where CallConnectionId == "my call id"
| where OperationName == "Recognize" or Type contains "Recognize"
| project
    TimeGenerated,
    OperationName,
    Type,
    ResultType,
    ResultSignature
| order by TimeGenerated asc

{'id': '...', 'source': 'calling/callConnections/...', 'type': 'Microsoft.Communication.RecognizeFailed', 'data': {'failedPlaySourceIndex': 0, 'version': '2025-06-15', 'operationContext': 'default', 'resultInformation': {'code': 408, 'subCode': 8565, 'message': 'Action failed due to a request to Cognitive Services timing out. Please try again later or check for any issues with the service.'}, 'callConnectionId': '...', 'serverCallId': '...', 'correlationId': '...', 'publicEventType': 'Microsoft.Communication.RecognizeFailed'}, 'time': '2026-02-10T11:35:02.3120858+00:00', 'specversion': '1.0', 'datacontenttype': 'application/json', 'subject': 'calling/callConnections/...'}

Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-02-10T20:41:59.86+00:00
Hi @Mohammed Suhail ,

Thank you for sharing the detailed investigation results, including the Log Analytics queries and the RecognizeFailed event payload. That information is very helpful and does clarify what you are observing. I see the timeout (code 408, subcode 8565) is pointing to a Cognitive Services request timing out during the Recognize action, which explains the intermittent silence and failures you're hitting.

Why isn't this error showing up in the call diagnostics?
The ACSCallAutomationIncomingOperations logs capture the initial API request handling, so they show "Succeeded" when the Recognize operation is accepted and started by ACS. However, the actual failure happens later in the process, during the async integration with Cognitive Services. These control-plane events (like RecognizeFailed) are delivered separately via webhooks or Event Grid to your app, rather than in the media-focused diagnostics logs (e.g., ACSCallDiagnostics), which track things like stream quality and endpoints but not these action outcomes.

Relevant tables/logs for further debugging:
Stick with Azure Monitor Log Analytics and use your CallConnectionId, CorrelationId, or ServerCallId to query these tables for patterns:

ACSCallAutomationIncomingOperations: Expand your query to check surrounding operations and durations for context.

ACSCallDiagnostics (or ACSCallDiagnosticsUpdates for fresher data): Look for media metrics like jitter, packet loss, or RTT that might contribute to timeouts.

ACSCallSummary (or ACSCallSummaryUpdates): Gives a high-level view of call duration and any summary diagnostics to spot trends across affected calls.

If you haven't already, enable diagnostic settings in the Azure portal to route these to Log Analytics for easier querying.

Mitigating the Cognitive Services timeout:
This is often tied to transient issues like network latency or service load, but here's how to handle it:

Add retry logic in your app, catch RecognizeFailed events and retry the action with a short backoff (e.g., 2-5 seconds, up to 3 attempts).

Ensure your ACS and Cognitive Services resources are in the same region to cut down on latency, and confirm the "Cognitive Services User" role is assigned to your ACS identity.

Tweak Recognize options: Bump up InitialSilenceTimeout (max 300s for DTMF, 20s for speech) or EndSilenceTimeout to give more buffer without failing prematurely.

Monitor Cognitive Services health in the Azure portal for any quotas or outages, if you're on a free tier, consider upgrading.

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/troubleshooting-codes?pivots=calling
https://learn.microsoft.com/en-us/azure/communication-services/concepts/analytics/logs/call-automation-logs
https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/acscallautomationincomingoperations
https://learn.microsoft.com/en-us/azure/communication-services/how-tos/call-automation/recognize-action?pivots=programming-language-javascript

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Anonymous

2026-02-12T04:08:14.4733333+00:00

Hi @Golla Venkata Pavani why our message is deleted.
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-02-13T10:43:26.8466667+00:00

Hi @Mohammed Suhail ,

We aren't sure how the comment was deleted. Could you please share your query one more time and please share the requested details via private chat to investigate the issue further.
Shree Hima Bindu Maganti 7,590 Reputation points Microsoft External Staff Moderator

2026-03-02T03:02:29.4266667+00:00

Hi @Mohammed Suhail ,
Apology for your inconveniences
In Azure Communication Services Call Automation, most call-related actions (like playing audio or starting recording) complete asynchronously, and the service relies on your webhook callback endpoint to acknowledge receipt (HTTP 200) and deliver the corresponding events such as PlayCompleted, CallConnected or recording events; if your webhook doesn’t respond quickly with a success status (or is unreachable), those events may not be delivered, causing the call to remain silent and time out without starting recording. This webhook delivery model is documented by Microsoft in the Call Automation overview, which explains that mid-call actions have corresponding webhook callback events that your application must handle to build reliable call workflows.
https://learn.microsoft.com/en-us/azure/communication-services/concepts/call-automation/call-automation
Let me know if you have any further assisstences needed.

1 answer

Your answer

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-02-06T11:26:51.4233333+00:00

Thank you for contacting us about the Azure Communication Services (ACS) intermittently fails to play the expected event during calls. In these cases, the call times out, remains silent, and call recording does not start. issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Anonymous

2026-02-09T11:19:58.1766667+00:00

Hi @Golla Venkata Pavani

We are observing an intermittent issue with Azure Communication Services Call Automation where one of the expected Play prompts is not audibly heard during the call. When this happens, the call remains silent and eventually times out, and in some cases call recording does not start. The behavior is inconsistent (around 3–4 out of 10 calls).

We enabled diagnostics and analyzed logs in Microsoft Azure Log Analytics (ACSCallAutomationIncomingOperations). For the affected calls, every Play operation shows ResultType = Succeeded with valid playback duration, and we do not see any PlayFailed, timeout, or failure events. From the service logs, ACS appears to have successfully executed playback, yet the caller hears silence.

Could you please confirm if this could be related to media establishment delays, latency, or intermittent audio delivery issues on the ACS/PSTN path, even when Play returns Success, and advise if any additional service-side telemetry can be checked to validate this?
Anonymous

2026-02-10T12:07:35.31+00:00

Hi @Golla Venkata Pavani ,

After further debugging, we observed that the issue occurs when an event is sent back from ACS to our application. Please find the reference details below.

We have also queried the data, and all the related events are showing as successful (please refer to the attached image). However, our concern is that the error observed in the application is not reflected in the call diagnostics. Ideally, the application-level error should also appear in the call diagnostics.

Could you please help us understand why this error is not being captured in the call diagnostics? Additionally, it would be helpful if you could share the relevant tables or logs we should review to further debug this issue and assist us in identifying the root cause.

And additionally how should be mitigate this error of cognitive service failed.

ACSCallAutomationIncomingOperations | where CallConnectionId == "my call id" | where OperationName == "Recognize" or Type contains "Recognize" | project TimeGenerated, OperationName, Type, ResultType, ResultSignature | order by TimeGenerated asc

{'id': '...', 'source': 'calling/callConnections/...', 'type': 'Microsoft.Communication.RecognizeFailed', 'data': {'failedPlaySourceIndex': 0, 'version': '2025-06-15', 'operationContext': 'default', 'resultInformation': {'code': 408, 'subCode': 8565, 'message': 'Action failed due to a request to Cognitive Services timing out. Please try again later or check for any issues with the service.'}, 'callConnectionId': '...', 'serverCallId': '...', 'correlationId': '...', 'publicEventType': 'Microsoft.Communication.RecognizeFailed'}, 'time': '2026-02-10T11:35:02.3120858+00:00', 'specversion': '1.0', 'datacontenttype': 'application/json', 'subject': 'calling/callConnections/...'}
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Anonymous

2026-02-12T04:08:14.4733333+00:00

Hi @Golla Venkata Pavani why our message is deleted.
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-02-13T10:43:26.8466667+00:00

Hi @Mohammed Suhail ,

We aren't sure how the comment was deleted. Could you please share your query one more time and please share the requested details via private chat to investigate the issue further.
Shree Hima Bindu Maganti 7,590 Reputation points Microsoft External Staff Moderator

2026-03-02T03:02:29.4266667+00:00

Hi @Mohammed Suhail ,
Apology for your inconveniences
In Azure Communication Services Call Automation, most call-related actions (like playing audio or starting recording) complete asynchronously, and the service relies on your webhook callback endpoint to acknowledge receipt (HTTP 200) and deliver the corresponding events such as PlayCompleted, CallConnected or recording events; if your webhook doesn’t respond quickly with a success status (or is unreachable), those events may not be delivered, causing the call to remain silent and time out without starting recording. This webhook delivery model is documented by Microsoft in the Call Automation overview, which explains that mid-call actions have corresponding webhook callback events that your application must handle to build reliable call workflows.
https://learn.microsoft.com/en-us/azure/communication-services/concepts/call-automation/call-automation
Let me know if you have any further assisstences needed.

Answer 1

The intermittent issue you are experiencing with Azure Communication Services (ACS) not consistently triggering expected events during calls, leading to silence and call timeouts, may be related to various factors. Since the problem does not occur in every call, it suggests that there could be underlying network conditions or specific scenarios that contribute to this behavior.

To troubleshoot this issue, consider the following steps:

Monitor Network Quality: Use the User Facing Diagnostics API or MediaStats feature to assess network conditions during calls. This can help identify if network issues are contributing to the problem.
Check for Known Issues: Review any known issues related to the ACS SDKs that may affect call reliability and event triggering. For instance, there are known issues with audio/video calls on certain browsers or devices that could impact functionality.
Event Handling: Ensure that your application correctly handles events and timeouts. Implementing a robust error handling mechanism can help manage unexpected behaviors during calls.
Collect Diagnostic Information: When the issue occurs, gather relevant diagnostic information, such as correlation IDs from callbacks, to assist in troubleshooting and reporting the issue to Microsoft support if necessary.

By following these steps, you may be able to mitigate the impact of the issue on call flow reliability and user experience.

References: