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 
1 Like
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!
2 Likes
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:
-
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:
-
This strongly suggests the INVITE is being rejected directly by sip.api.openai.com with 400, before the Realtime session and webhooks are created.
-
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:
-
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:
-
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?
-
Confirm whether there are any known issues or recent changes affecting Twilio → OpenAI SIP interoperability in the Frankfurt region.
-
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.