We’re seeing long setup time before the model is available when using the SIP connector. TLS/DNS are warm and our webhook/accept is fast, but the INVITE→realtime.call.incoming webhook is taking 3–5s (occasionally ~7s). Once the webhook arrives, the rest is sub second.
Setup
-
FreeSWITCH gateway (host-only, no registration) to sip.api.openai…;transport=tls
-
OPTIONS keepalive every 20s; TLS cert accepted
-
Dial string: sofia/gateway/openai/proj_@sip.api.openai.com
-
Codecs: PCMU/PCMA 8 kHz + telephone-event/8000
-
We pre-originate a parked leg as soon as the IVR decides to invoke AI
-
Webhook handler does only: verify, POST /v1/realtime/calls/{call_id}/accept, return 200 immediately
-
/accept completes in ~400‑600 ms
-
Project/tenant IDs per call; no SIP auth
Example timeline (CallsId 57275144, CallId rtc_u2_0236a02e796c453c97767e202a93f179)
-
19:31:37.176 — Warm originate to OpenAI started (INVITE handed to FS)
-
19:31:40.602 — realtime.call.incoming webhook received (created_at was null) → ~3.43 s after INVITE
-
19:31:40.607 — /accept POST sent
-
19:31:41.181 — /accept succeeded (573 ms)
-
19:31:41.209 — SIP 200 OK / originate completed (matches accept finish)
-
19:31:41.210–19.336 — uuid_transfer/bind/ws connect (instant) Similar runs: INVITE→webhook is 3–4.5 s; /accept is ~0.4‑0.6 s.
What we’re asking
-
Is this INVITE→webhook delay expected? If not, what should we check?
-
Are there regional endpoints, headers, or config that reduce this?
-
Should realtime.call.incoming include a populated created_at? (we often see null)
-
Any known server-side queueing or rate limiting that would cause 3‑7 s before the webhook?
-
Suggested troubleshooting from OpenAI side to get to sub second call_incoming delivery (we’ve minimized our handler and kept infra warm).