Realtime API SIP accept endpoint takes ~5.3s to return 404 call_id_not_found

API Bugs
1

Summary

We integrated the OpenAI Realtime API for inbound SIP calls (realtime.call.incoming webhook → POST /v1/realtime/calls/{call_id}/accept). We measured that our own webhook handling (signature verification, DB writes, session setup) completes in 20-30ms, but the POST /v1/realtime/calls/{call_id}/accept request itself consistently takes about 5.3 seconds to return, and the response is a 404 with body:

{“error”: {“message”: “No session found for the provided call_id”, “type”: “invalid_request_error”, “code”: “call_id_not_found”}}

What we ruled out on our side

Our own processing time (instrumented with timestamps): about 20-30ms before the accept call.
DNS/network latency to the OpenAI API host: about 25ms raw TCP connect from the container.
HTTP/HTTPS proxy misconfiguration: none present, verified via env inspection.
Client-side timeout: httpx AsyncClient timeout is 20s, well above the 5.3s delay, so it is not a client timeout being hit early.

Questions

First: Is a ~5.3s response time expected/normal for the /v1/realtime/calls/{call_id}/accept endpoint, especially when it returns call_id_not_found? This delay causes the caller to hear several ring tones and then the call aborts before we can accept it in time.

Second: Are there known race conditions between when the realtime.call.incoming webhook fires and when the call_id becomes valid/acceptable server-side, that could explain the 404 despite accepting almost immediately after receiving the webhook?

Any guidance on reducing this latency, or clarification on the expected timing contract between receiving the webhook and successfully accepting the call, would be very helpful. Happy to share more logs/timestamps if useful.

2

Hi @alexanderhaas77, welcome to the community, and thank you for providing the detailed timing information.

Based on the current Realtime SIP documentation, the call_id supplied in the realtime.call.incoming webhook should already identify a pending SIP session available for acceptance. There is no documented requirement to wait before calling /v1/realtime/calls/{call_id}/accept, so a repeatable request taking approximately 5.3 seconds and then returning 404 call_id_not_found does not appear expected.

Could you please verify the following:

  • The value being used is exactly event.data.call_id, rather than the SIP Call-ID header.
  • The API key or OpenAI-Project header belongs to the same project used in the SIP destination and webhook configuration.
  • Only one application instance or worker attempts to accept each call.
  • No separate live.call.incoming handler is accepting the same pending SIP session.
  • Duplicate webhook deliveries are deduplicated using the webhook-id header.

It would also be useful to compare the event’s created_at and webhook-timestamp values with your actual webhook receipt time. Your 20–30 ms measurement confirms that your local processing is fast, but it does not yet show whether the webhook itself arrived late.

For two or three failed calls, please capture the exact UTC timestamps, call_id, webhook ID, event ID, SIP provider call ID, redacted /accept payload, x-request-id, and openai-processing-ms response header. These details should be submitted privately via email to support@openai.com so the requests can be traced internally; please do not post API keys, phone numbers, or unredacted SIP headers publicly. Once submitted, feel free to share the support case ID here for tracking.

-Mark G.