Voice Live Error : Failed to create message

Question

Hi Team

We are currently working on the Azure AI Foundry Voice Live Agent, which connects telephonically via ACS over a WebSocket. However, during conversations, the agent frequently disconnects and throws the following error.

{

   "type": "failed",

  "error": {

     "message": "Failed to create message",

     "type": "invalid_request_error",

     "code": "message_creation_failed",

     "param": null

   }

 }

Along this issue we are getting more than 5 second of delay. Really appreciate if anyone one can help over this. Thank You

---

Moved from: Community Center | Discuss the Q&A site | Get started on Q&A

Answer 1

Hi Vivek Anand

This is a known and reproducible issue pattern with Azure AI Foundry Voice Live Agents over ACS WebSocket,

why this happens, what causes the disconnects and 5+ second delay, and what you should change immediately to stabilize the agent.

error actually means:

{
  "type": "failed",
  "error": {
    "message": "Failed to create message",
    "type": "invalid_request_error",
    "code": "message_creation_failed"
  }
}

Key point: This happens after the call is connected — during message creation, not call setup.

Voice Live only accepts plain-text chat messages (and raw audio frames). If your agent tries to send:

• Structured JSON
• Tool output objects
• Non-string values (PortableValue, arrays, dicts)
• Extremely large text blobs
• Rapid back-to-back response.create events

the runtime cannot serialize the message, and it closes the WebSocket, causing the disconnect.

This same behavior is seen in other Foundry agent failures when non-text payloads are returned at the final boundary

Every message sent must be:

{
  "type": "response.create",
  "response": {
    "modalities": ["text", "audio"],
    "instructions": "This is a plain text string"
  }
}

Common mistake Sending tool output, parsed values, or objects directly.

you see >5 seconds latency before disconnect:

This delay is not network latency — it’s server-side buffering.

What happens internally:

1. ACS streams audio → Voice Live
2. Voice Live buffers audio awaiting:
   • turn detection
     • valid message creation
     1. An invalid message event arrives
     2. Runtime retries creation
     3. Retry timeout expires (~5–6 seconds)
     4. WebSocket is forcibly closed

This aligns with the delay behavior reported in the same Q&A thread and in Voice Live ACS bridge scenarios.

Fix 1: Ensure only plain text reaches Voice Live

Before sending any message to response.create:

• Convert content explicitly:
  • str(value)
    • JSON.stringify(value)
    • Remove tool metadata
• Truncate large responses (recommended <8–10 KB)

If you are using Foundry workflows or agents: Add a “Set Variable” or stringify step before Voice Live output

Fix 2: Send exactly one response per user turn

Voice Live does not handle multiple overlapping responses well.

Ensure:

• One response.create per detected user turn
• No parallel sends
• No “thinking” or intermediate responses

Many disconnects happen due to rapid, concurrent message creation.

Microsoft explicitly recommends that the first event after WebSocket connect is:

{

  "type": "session.update"

}

I recommend you do next (practical steps)

1. Log every outbound Voice Live message
2. Verify it is:
   • string
     • non-empty
       • <10 KB
       1. Add a final stringify step before sending
       2. Ensure single response per turn
       3. Confirm region alignment
       4. Test with a text-only response (no audio) once to validate stability

If you want, you can paste:

• your response.create payload
• or your agent’s final output structure

You’re hitting a real product edge, not a mistake on your side — but it is resolvable with the above fixes

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

Thankyou!

Answer 2

The error message you are encountering, "Failed to create message" with the type "invalid_request_error" and code "message_creation_failed", typically indicates that there is an issue with the request being sent to the Voice Live API. This could be due to several reasons, such as malformed requests, network issues, or problems with the WebSocket connection itself.

Here are some steps you can take to troubleshoot this issue:

1. Check WebSocket Connection: Ensure that the WebSocket connection is stable and not being interrupted. You can monitor the connection events in your logs to see if there are any disconnections or errors.
2. Review Request Format: Verify that the messages being sent to the API are correctly formatted according to the API specifications. Any discrepancies in the request structure could lead to this error.
3. Inspect Logs: Look into the technical logs (like voicelive.log) for any additional error messages or stack traces that might provide more context on why the message creation failed. This log can help identify if there are issues with the connection or the audio stream.
4. Delay Issues: The delay of more than 5 seconds could be related to network latency or processing time on the server side. Ensure that your network connection is stable and that there are no bottlenecks.
5. Consult Documentation: Review the Voice Live API documentation for any updates or changes that might affect how messages are created and sent.

If the problem persists after these checks, consider reaching out to Azure support for more specific assistance related to your implementation.

---

References:

• Quickstart: Create a voice live real-time voice agent with Microsoft Foundry Agent Service (programming-language-python)
• VoiceLiveConnectionError class