The previously reported SIP SDP error is happening again. We are dead in the water trying to place new SIP calls into gpt-realtime.
SIP/2.0 400 Bad Request
Contact: sips:[my email]:5061
{
“error”: {
“message”: “Invalid SDP offer.”,
“type”: “invalid_request_error”,
“code”: “invalid_offer”,
“param”: “”
}
}
Same here. We started seeing what appears to be a related SIP / Realtime issue around March 24, 2026 at approximately 08:30 JST (March 23, 2026 23:30 UTC).
Our setup is Twilio SIP → OpenAI Realtime API → webhook to Google Cloud Run.
In our case, we are not seeing the normal OpenAI webhook traffic reach our Cloud Run service for failed calls, so the failure seems to happen before our usual handling flow even starts. Because the webhook never arrives, we also see no /accept flow and no sideband WebSocket connection attempt in our logs.
This had been working before, and we did not deploy any relevant code or configuration changes around the time the issue started. We are also already using the GA Realtime setup with gpt-realtime, so this does not appear to line up with a scheduled beta migration issue.
This makes us suspect there may be a broader regression affecting new inbound SIP calls / SIP call handling on the OpenAI side, not just a single malformed SDP case.
@Sean-Der Could you please take a look? This seems broader than a single SDP formatting issue and may be affecting new inbound SIP calls starting around 2026-03-24 08:30 JST.
We are seeing what looks like the same issue in Japan on March 24, 2026 (JST).
Setup:
<Dial><Sip> to OpenAI SIP endpointWe reduced the TwiML to a minimal repro and still get the same failure:
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Say language="ja-JP" voice="Polly.Mizuki">Connecting you now. Please hold.</Say>
<Dial callerId="+81xxxxxxxxxx">
<Sip statusCallback="https://example.com/twilio/call-status?probe=openai-sip">sip:proj_xxxxx@sip.api.openai.com;transport=tls</Sip>
</Dial>
</Response>
We also tested:
with and without callerId
without any extra SIP query params
without X-To
with multiple different OpenAI project IDs
Result is unchanged:
the OpenAI webhook is never fired
the Twilio SIP child leg fails immediately
Twilio reports SipResponseCode: 400
Twilio maps it to ErrorCode: 13224
Twilio message is invalid phone number format
Important point:
this happens even with the bare SIP URI only:
sip:proj_xxxxx@sip.api.openai.com;transport=tls
So at least in our case, this does not seem to be caused by custom SIP params on our side.
Because the webhook is never reached, it looks like the INVITE is being rejected at SIP ingress before realtime.call.incoming.
I also noticed at least one other report from Japan, so this may not be an isolated case. It would be helpful to know whether this could be:
an invalid SDP / SDP negotiation issue
a Japan-specific carrier / number-format / caller identity issue
or a broader SIP ingress regression
We are also experiencing the same issue. There have been no changes to the IP-PBX configuration or the webhook endpoint, but calls are not being connected.
@OpenAIAPIhelper @OpenAI_Support @Sean-Der Please check it, seems all around the world SIP isn’t working at all.
Hi,
We are also got this.
{
“error”: {
“message”: “Invalid SDP offer.”,
“type”: “invalid_request_error”,
“code”: “invalid_offer”,
“param”: “”
}
}
All calls are rejected.
/ Magnus
Same as in Italy,
@Sean-Der @OpenAI_Support please give us a feedback
Adding to this thread — I did some independent testing and can confirm the same behavior with additional detail.
Test setup: Raw Python TLS socket sending SIP INVITE directly to sip.api.openai.com:5061, no SIP stack, so the SDP content is fully controlled.
| SDP type | Response sequence |
|---|---|
| No SDP body | 100 Trying → 400 (no body) |
| RTP/SAVP with SRTP/crypto | 100 Trying → 400 (no body) |
| RTP/AVP PCMU/PCMA | 100 Trying → 180 Ringing → 400 invalid_offer |
| RTP/AVP Opus | 100 Trying → 180 Ringing → 400 invalid_offer |
DTLS-SRTP (UDP/TLS/RTP/SAVPF) |
100 Trying → 180 Ringing → 400 invalid_offer |
180 Ringing before being rejected — indicating the SIP ingress accepts the offer structure and attempts to route it, but something fails before the webhook fires."param": "" field in the error JSON is empty — if a specific SDP field were invalid, we’d expect a non-empty param. This points away from an SDP formatting problem.The rejection is happening at OpenAI’s SIP ingress layer, after initial routing but before webhook dispatch. This doesn’t appear to be a caller-side configuration issue. Looks like a regression on OpenAI’s end.
Hi, Same here in belgium. SDP incorrect as result.
Probably something broken in the stack sip on openai’s side.
Same here:
{
“error”: {
“message”: “Invalid SDP offer.”,
“type”: “invalid_request_error”,
“code”: “invalid_offer”,
“param”: “”
}
}
We too in Italy encounter the same problem: when transferring the SIP flow to Openai, the response is 400.
I’m in italy too
Forgot to mention: we are in italy too
Same in belgium, here
x ACK x x “error”: {
x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x “message”: “Invalid SDP offer.”,
x x x “type”: “invalid_request_error”,
x x x “code”: “invalid_offer”,
x x x “param”: “”
x x x }
x x x}
we have the same problem too
@OpenAIAPIhelper @OpenAI_Support @Sean-Der would appreciate your help. Realtime SIP is down for us too and impacting our customers in EU and UK.
Hello, same here from Italy.
Nothing changed on the config server side but each call we receive:
{
“error”: {
“message”: “Invalid SDP offer.”,
“type”: “invalid_request_error”,
“code”: “invalid_offer”,
“param”: “”
}
}
At 11 hours now, is there any other way to engage support?
(or any SIP alternatives from other vendors?)
Even Gandalf can’t solve this! (nice to meet you)
LOL. Nice to meet you too