Twilio - OpenAI SIP Trunk calls failing with '400 Bad Request' error

API Bugs
,
1

We’ve developed a voice application powered by gpt-realtime. We connect callers with the model via SIP Trunking with a twilio number. The setup has been working well so far, but from mid-December, some calls started to fail. Recently, the number of failed calls has been increasing, to the point that we’re getting more failed calls than successful ones now.

We don’t have any SIP header records for the failed calls because the OpenAI webhook is not even sending the realtime.call.incoming event. We can only see this in Twilio:

  • Status: failed
  • Last SIP Response: 400 Bad Request

For testing purposes, we disconnected the SIP trunk on Twilio and forwarded incoming calls to a local webhook URL instead, to see if they reached it. All did, which seems to indicate that there’s some issue with the SIP connection between Twilio and OpenAI.

As mentioned, this issue is intermittent and completely unpredictable. We have no way to reproduce it more than calling many times until it starts failing. We can have 3 failing calls in a row; then one works; then the next two fail again; etc. All without changing anything on Twilio, OpenAI or our app.

Is anyone else experiencing this?

@Sean-Der , would you be able to help? I’m tagging you as per your request in this post, reporting a similar issue: Receiving SIP 400 Bad Request when sending an INVITE from Twilio to OpenAI

Thank you :folded_hands:

4 Likes
2

Sorry about this. I am working on this right now.

The Webhook service isn’t sending HTTP Requests fast enough (because of the amount of traffic it is processing). This then means you aren’t getting notified to accept the call fast enough.

I am tracking this and I hope to have a fix soon. Today I am moving SIP servers to IP Ranges (so customers can allow list them) after that this is next!

5 Likes
Troubleshooting SIP and Asterisk communication issues
3

Hi everyone,

We’ve been running an AI voice assistant in production using the Realtime API over SIP, with Twilio Elastic SIP Trunking pointing to:

sip:proj_6ThBeJvaJTKbbGyke5l6Dzah@sip.api.openai.com;transport=tls

Everything was working fine in production until Saturday, at which point we started seeing two issues:

  1. Sporadic dropped calls right at dial start

    • Symptom: the caller dials our Twilio DID, hears nothing, and the call fails in the first fraction of a second.

    • In Twilio Call Insights for those calls:

      • Duration: 0 seconds

      • Post-dial delay: ~0.3 seconds

      • Direction: Trunking Originating (sip-pstn)

      • Last SIP response: 400 Bad Request

      • “To” is the OpenAI SIP URI above, region Frankfurt (de1).

    • Example Call SID from Twilio:

      • CA1d752a45cd2157075b9ed2098d61a5bc

    • For these failed calls:

      • Our server never receives any realtime.call.incoming webhook.

      • There are no hits to our webhook endpoint at all at those timestamps.

    • This strongly suggests the INVITE is being rejected directly by sip.api.openai.com with 400, before the Realtime session and webhooks are created.

  2. High latency / lag when calls do connect

    • Other times, the call is accepted and realtime.call.incoming is delivered, we accept the call and open the Realtime WebSocket as usual.

    • However, we are now seeing significantly higher latency in the assistant’s responses compared to before Saturday.

    • We checked the Realtime rate limits and there is no limit being hit; the traffic is very low right now (we’re just starting with our first customers).

Environment / context

  • Provider: Twilio Elastic SIP Trunking

  • Twilio → OpenAI SIP region: Frankfurt (de1)

  • OpenAI project: proj_6ThBeJvaJTKbbGyke5l6Dzah

  • Our backend:

    • Receives realtime.call.incoming webhooks

    • Resolves tenant by phone number

    • Calls /v1/realtime/calls/{call_id}/accept

    • Opens wss://api.openai.com/v1/realtime?call_id=...

  • For successful calls we see logs like:

    • Incoming webhook payload ... type: "realtime.call.incoming"

    • SIP call accepted by OpenAI: <call_id>

    • Opening Realtime WS for SIP call: wss://api.openai.com/v1/realtime?call_id=...

    • Followed by the usual conversation.item.* and response.output_audio_transcript.* events.

For the 0-sec failed calls, none of this happens. Twilio shows 400 Bad Request from sip.api.openai.com, and our server logs are completely silent for those attempts.

Impact

This started happening right as we began onboarding our first clients onto this system. It’s not a good look when half the calls just die instantly or answer with huge lag, and it’s currently blocking us from safely routing their business numbers through the OpenAI SIP connector.

What we’ve already done

  • Restarted our Realtime server and verified that when calls are accepted by OpenAI, our flow works as expected (webhook received, accept call OK, WS open, assistant talks, tools run).

  • Verified that the Twilio trunk target URI is correct and unchanged.

  • Confirmed that for 0-sec failed calls:

    • Twilio shows a final SIP 400 from sip.api.openai.com.

    • No realtime.call.incoming webhook or any HTTP traffic hits our backend.

  • Checked Realtime rate limits – no limits or errors, and volume is very low.

  • We temporarily routed production numbers away from SIP to human reception so our customers aren’t impacted, and we’re testing on separate dev numbers.

Could anyone please:

  1. Check the SIP side for project proj_6ThBeJvaJTKbbGyke5l6Dzah and the example Twilio Call SID(s) above, to see why sip.api.openai.com is returning 400 Bad Request on some INVITEs?

  2. Confirm whether there are any known issues or recent changes affecting Twilio → OpenAI SIP interoperability in the Frankfurt region.

  3. Provide guidance on any required SDP / codec / header constraints we might be missing, or any configuration changes on the OpenAI side that would explain why this suddenly started happening on Saturday.

This is currently blocking us from confidently using Realtime over SIP in production, right at the moment where we began onboarding real clients, so any help or internal investigation on your side would be hugely appreciated.

Thanks in advance.

4

Hi there, I was just wondering what is the state of the Agents Python SDK. I am trying to use the classes in the agents SDK but I cannot get the agent to use function tools.

I’m integrating Twilio SIP with OpenAI Realtime using openai-agents==0.6.5 (FastAPI server). I accept the SIP call via:

await _openai_client.post(
f"/realtime/calls/{call_id}/accept",
body={“type”: “realtime”, “model”: “gpt-realtime”},
cast_to=dict,
)

Then I attach a RealtimeRunner:

initial_model_settings = {
“voice”: “alloy”,
“modalities”: [“audio”],
“turn_detection”: {“type”: “semantic_vad”, “interrupt_response”: True},
}

_agent = RealtimeAgent(
name=“Customer Support”,
instructions=base_instructions,
tools=tools,
)

runner = RealtimeRunner(
starting_agent=_agent,
model=OpenAIRealtimeSIPModel(),
)

async with await runner.run(
model_config={
“call_id”: call_id,
“initial_model_settings”: initial_model_settings,
}
) as session:
…

I’m trying to configure the audio format for Twilio (PCMU/8k). The Realtime docs show session.update with audio.input.format and output_modalities.

So I tried:

session_update = {
“type”: “realtime”,
“model”: “gpt-realtime”,
“output_modalities”: [“audio”],
“audio”: {
“input”: {“format”: {“type”: “audio/pcmu”, “rate”: 8000}},
“output”: {“format”: {“type”: “audio/pcmu”}, “voice”: “alloy”},
},
}

await session.model.send_event(
RealtimeModelSendRawMessage(
message={“type”: “session.update”, “session”: session_update}
)
)

But I get:

ERROR:openai.agents:Failed to convert raw message: RealtimeModelSendRawMessage(…)
ERROR: RealtimeError(message=“Invalid type for ‘session.audio.input.format’: expected an object, but got null
instead.”, param=‘session.audio.input.format’)

If I remove the explicit session.update, I still get the session.audio.input.format null error. If I set legacy fields like input_audio_format / output_audio_format in initial_model_settings, the call connects but I get no audio on the Twilio leg.

Questions:

  • What is the correct way to set session.audio.input.format / output_modalities when using openai-agents
    RealtimeRunner?
  • Is RealtimeModelSendRawMessage supposed to support session.update, or do I need a different API/event shape?
  • Do I need to upgrade openai-agents or use input_audio_format/output_audio_format in some other place for SIP?

Environment:

  • openai-agents 0.6.5
  • openai 2.14.0
  • FastAPI 0.128.0
  • Twilio SIP (PCMU 8k)

Thanks for any guidance on getting the audio format set correctly in Realtime SIP. I’m happy to send the full script for the code too for context!

1 Like
5

Just clarifying - I think the function tool calls are not occuring because the Realtime session is erroring out (session.audio.input.format null).

1 Like
6

We’re seeing the same pattern you described, and this strongly points to an issue on the SIP ingress side rather than Twilio or application logic.

Since Twilio reports a SIP 400 Bad Request and OpenAI never emits realtime.call.incoming, the INVITE is being rejected before it reaches the realtime pipeline. The intermittent nature (no config changes, mixed success/failure) suggests either a SIP validation regression, load-related rejection, or edge-level inconsistency on OpenAI’s SIP endpoint.

We’ve verified:

  • Twilio receives all calls correctly

  • Forwarding to a local webhook works 100% of the time

  • Failures only occur when routing through the OpenAI SIP trunk

The increase in failures since mid-December also suggests a backend or infrastructure change rather than a client-side issue.

@Sean-Der — can you confirm whether there were:

  • SIP validation or SDP requirement changes rolled out recently?

  • Known intermittent SIP 400 issues under load or specific regions?

  • Recommended constraints for Twilio SIP interoperability (headers, transport, codecs)?

At the moment, the lack of visibility into rejected INVITEs makes this very difficult to diagnose from the client side.

4 Likes
7

I’ve also been experiencing this same issue

8

Anyone else got function tool calling working with the Realtime API / RealtimeAgent?

9

I have function tool calling working with no issues with Realtime API, but the 400 and webhook not delivered is the real issue here. For us personally, the issue with webhooks not delivering and/or 400 starts around 12pm PST

10

We just had 404 occur again. Here are IDs:

rtc_u1_7e953e0c69da48a1977d8d5a44cfc900

rtc_u2_f99d427f2b884c7ea438607836fa3b74

with this error:
Accept response: 404, preview={
“error”: {
“message”: “No session found for the provided call_id”,
“type”: “invalid_request_error”,
“code”: “call_id_not_found”,
“param”: “”
}
}

11

Hi guys.
Hi @Sean-Der, any advance on this issue? We are experiencing the same problem.
We have two different project and all fails at the same time.
Thank you in advance.

1 Like
12

Same here. Every call is failing.

13

We’re seeing the same intermittent behavior with Twilio SIP → OpenAI: ~10–20% of calls fail with no realtime.call.incoming webhook and Twilio times out, even though the SIP URI is correctly formatted and includes X-Voice-Call-Id. When it connects, quality is great.

Example failed call SIDs (Twilio):

CA4dd4e3527463650e9896f6f0d6ef8803

CA30365c2b1c0ba18f152db4b6aedb6799

We can also provide OpenAI call IDs when the webhook arrives, but in the failure cases OpenAI never accepts the call (SIP 400 returned). If you need specific timestamps, we can share those too.

14

  • It’s not a timeout — Twilio is getting an immediate SIP 400 (often with ErrorCode 13224)

  • That means OpenAI is rejecting the INVITE before the webhook, so no realtime.call.incoming arrives for those failures.

1 Like
15

Do you mind if I merge here?

1 Like
16

go for it! That thread is a better description of my issue. Thanks!

1 Like
17

we changed our flow to establish realtime session first, only then we accept/make a call, but nevertheless, multiple retries is also not ideal, as this still affects incoming calls, if retries occur.

1 Like
18

Are you using the Python SDK too? Do you mind sharing a bit of the code for the initial setup + function tool call?

19

Lots of different issues here, will try my best to address them all!

Most peoples issues were coming from our Webhooks that should be fixed Realtime API unreliable over SIP - #13 by Sean-Der

@Ted_Papan

  • The 0 second calls were because the webhook service had OOMed (so we failed right away)
  • High Latency/Lag was because of internal delay

Both of these should be fixed. Would you mind evaluating it again and tell me if you see either behaviors?

I also would really love to here if OpenAI + SIP is missing any features that would make it more useful. If people want to post here or email me seaduboi @ openai I am trying my best to make this a service people love using.

Sorry for the frustrations up to this point, but will keep making it better.

1 Like
20

Go for it ! That Thread is a better Description of my issues.Thanks