ACS call recording callback issue

Question

Within ACS call recording i am receiving event on recording start callback but not receiving any event on stop recording or file status changed. If my callback url was wrong then i would not receive event on start but here i am not receiving any event after start. I checked my ACS call and i kept the call running, i am using blob storage, i checked the container folder, the audio file is saved successfully with meta file. I made the call back simple to check the status only but it is the same ... receiving on start and then nothing.

I am using ASP.Net MVC Core application in C#, ACS version 1.6.0 and Blob storage.

I am stuck here... Please help me...

Answer 1

If the recording files and metadata are already being written to the Blob container, the export is succeeding. For Bring Your Own Storage, the supported notification path for completed export is Azure Event Grid. The documentation states that when a recording is ready for retrieval, ACS publishes the Microsoft.Communication.RecordingFileStatusUpdated event, and for external storage it recommends using an Azure Event Grid webhook or other triggered action to notify services when the media is ready and exported.

What this means for this scenario:

1. RecordingStateCallbackUri is used for recording state change callbacks such as start state changes.
2. File-ready and export notifications are delivered through Azure Event Grid, including Microsoft.Communication.RecordingFileStatusUpdated.
3. With Bring Your Own Storage, a successful Blob write does not mean the file-ready notification will arrive on the same recording state callback endpoint unless Azure Event Grid is configured to send it there.

Checks to make:

1. Verify that an Azure Event Grid subscription exists for the ACS resource.
   • The event to look for is Microsoft.Communication.RecordingFileStatusUpdated.
   • Expected result: Event Grid should be configured to post to the webhook endpoint that handles file status notifications.
2. Separate start-state handling from file-status handling.
   • If the application receives the start callback, that confirms the recording state callback URL is working for start events.
   • It does not confirm that Event Grid is configured for recording file status events.
3. Check for export failure notifications.
   • For Bring Your Own Storage, export can fail because of configuration issues or service outages.
   • In that case, the failure notification includes a download URL, and recordings can still be downloaded within 24 hours.
4. Account for timing.
   • The Microsoft.Communication.RecordingFileStatusUpdated event is published when the recording is ready for retrieval, typically a few minutes after recording completes.
   • Recordings in ACS temporary storage are available for 24 hours.
5. Correlate by serverCallId if behavior looks inconsistent.
   • In rare HADR scenarios, one recording session can produce multiple files sharing the same recordingId and chunkId, and StopCallRecording can return 404 Recording not found even though files are delivered.
   • Applications should correlate recordings using serverCallId rather than assuming a one-to-one mapping between call, recording ID, chunk ID, and output file.

For an ASP.NET Core MVC app, the practical next step is to confirm that the endpoint receiving the start callback is not being assumed to also receive Event Grid notifications unless an Event Grid subscription explicitly targets it.

---

• Call Recording overview
• Call recording: Bring your own Azure storage quickstart (programming-language-csharp)
• Call Recording overview