Point the SBC at sip:[email protected];transport=tls on TCP port 5061, register a webhook first, and open bidirectional UDP for SRTP to the four published /28 blocks — 64 addresses in total. No SIP password and no IP access control list is documented for you to configure, and the path is inbound only as at 16 September 2026.
This is the topology with nothing in the middle: your own SBC or PBX speaking SIP straight to a model provider’s telephony edge. The worked example is the OpenAI Realtime API SIP endpoint. The failure set differs from the trunk-provider path for a structural reason: when Twilio Elastic SIP Trunking, Telnyx or Plivo sits in the middle, that vendor absorbs certificate policy, address stability, transport negotiation and carrier authentication for you. Take it out and those become yours.
Three adjacent questions are answered elsewhere and not repeated here: the platform-and-carrier interop matrix for Retell, Vapi, LiveKit and Twilio is in how to connect an AI agent to your SIP trunk; whether a trunk is worth owning is in do I need a SIP trunk for an AI voice agent; and the error that lands one HTTPS request after the INVITE succeeded is in why the SIP accept returns 404 call_id_not_found.
How do I point my SBC straight at the model’s SIP endpoint instead of going through Twilio?
Eight steps, in this order. Steps 3 and 5 are the ones quickstarts omit, and the ones that fail silently.
- Day one, before any console: confirm direct SIP is enabled for the project. OpenAI’s telephony and SIP guide names
sip.api.openai.com, andsip-eu.api.openai.comfor European data residency, and tells you to confirm that GPT-Live SIP support is enabled for your project before using that flow. That is a gate, not a setting you find later. - Get the project ID, which carries a
proj_prefix and becomes the user part of the Request-URI. On this path the project ID is the routing identity; there is no trunk object to create. - Create the webhook before you send a single INVITE. The guide says to start by creating a webhook for incoming calls, then point the trunk at the endpoint using the project ID the webhook was configured for.
- Configure the SBC route as
sip:[email protected];transport=tls. The network section specifies outbound TCP/TLS on port 5061. Not UDP, not 5060. - Validate the TLS trust path on the SBC itself, not from a laptop with a browser certificate store. Gate 1 below, and the most common reason a direct-SIP INVITE gets no answer.
- Open media separately. SRTP is a different flow, transport and firewall rule from signalling; the guide publishes four CIDRs and requires bidirectional UDP.
- Stand up the accept handler: verify the webhook signature, deduplicate on
webhook-id, return 2xx at the edge, POST the accept from a worker. - Place one inbound call and read the trace from the SBC, because there is no carrier console to read it from. Our note on testing an AI voice agent before go-live covers the rest of that window.
The finish state. An inbound PSTN call reaches the SBC, the INVITE draws a response rather than a timeout, the webhook fires carrying data.call_id, the accept returns 200 OK, and two-way audio runs for at least 30 seconds with SRTP flowing to and from one of the four published media blocks. Four of those five is not a cutover.
One planning constraint belongs at the top: the direct SIP flow accepts inbound calls. The GPT-Live section of the same guide states that creating an outbound SIP call through the Live sessions endpoint is not supported, and directs you to a partner integration for provider-owned outbound calling. If your use case is outbound dialling, you cannot remove the intermediary yet.
The Direct-SIP Cutover Gate: five checks to run before you move traffic
Each row is a check you can run today and the exact failure you get if you skip it. Every one fails in a way that looks like something else.
| Gate | The check to run before cutover | What you get if you skip it |
|---|---|---|
| 1. Certificate identity | Read the certificate the SIP port presents, then confirm the SBC accepts a wildcard SAN for a SIP peer. openssl s_client -connect sip.api.openai.com:5061, run 16 September 2026, returned CN = api.openai.com with SANs api.openai.com and *.api.openai.com, issuer Google Trust Services WE1, valid 5 September to 4 December 2026. |
No SIP response at all. RFC 5922 section 7.2 says implementations MUST NOT match any form of wildcard, so a strict SIP stack refuses the identity while the web PKI accepts it — that same run returned Verify return code: 0 (ok). An operator reported this against 3CX on 3 August 2026 and worked around it with an external SIP proxy. |
| 2. Transport and port | TLS on 5061 with ;transport=tls present in the Request-URI, not only selected in a console. |
A timeout rather than an error. The SBC trace published on 25 June 2026 shows an AudioCodes Mediant sending a TLS INVITE to port 5061 and receiving nothing back. |
| 3. Reachability method | Use a TLS handshake plus a SIP request as your health check. Do not use a TCP port probe. | A monitor that is green while SIP is dead. From our own host on 16 September 2026, TCP connects to the address serving sip.api.openai.com completed on 5060, 5061, 5063, 5070 and 443 alike, while the same probe to two control hosts on 5060 timed out with no response at all. |
| 4. Name resolution | Query SRV rather than assuming it. On 16 September 2026, _sips._tcp, _sip._tcp and _sip._udp for sip.api.openai.com all returned NXDOMAIN, so RFC 3263 section 4.2 sends a compliant client to A or AAAA records at the default port. |
Nothing here — but the same resolver code meets real SRV zones on the carrier side. LiveKit issue 810, opened 25 August 2026 and open at 16 September 2026, reports an A record short-circuiting the lookup, the SRV port discarded and _sips._tcp never queried. |
| 5. Media path | Open bidirectional UDP for SRTP to all four published blocks, as a rule separate from the signalling rule. | The call connects and both parties hear silence until a media timeout ends it. |
Gate 1 is worth reading twice: it is the only failure here where two correct tools disagree. OpenSSL says the certificate is valid; a SIP stack implementing RFC 5922 says it is not. Both are right — the web PKI permits wildcard matching and the SIP profile forbids it — and nothing in the handshake tells the operator which rule rejected the call.
What the CPaaS was doing that nobody is doing now
Removing the intermediary removes five services, and only one is a per-minute charge.
| What the CPaaS layer was doing | Who owns it on the direct path | The published position |
|---|---|---|
| Authenticating the trunk | Nobody you can configure; authorise in the webhook handler | Twilio requires a minimum of either an ACL or credential authentication on the termination side of an Elastic SIP Trunk. |
| Outbound dialling | Still a provider | The direct SIP flow accepts inbound calls; creating an outbound SIP call through the Live sessions endpoint is not supported. |
| Numbers and porting | Still a carrier | The number, the port-in and the regulatory registration stay where they were. |
| Caller-ID attestation | Still the originating carrier | Attestation attaches to the originating service provider, not to whatever answers. See STIR/SHAKEN for AI voice agents. |
| A stable address to allowlist | Nobody | OpenAI documents the SIP hosts as GeoIP-routed endpoints, and says to allow outbound TCP/TLS to the addresses returned by DNS on port 5061. |
The Untrusted-Header Rule. Treat the project ID as a routing label rather than a credential, and authorise every call inside the webhook handler against something you hold — a number you own, a mapping you maintain, a time window you set — never against From, To or any other SIP header. That is the provider’s own guidance sharpened into a decision: the GPT-Live section of the SIP guide says to treat data.sip_headers as untrusted caller metadata, not as authorisation.
Scope that carefully, because it is a claim about absence. We read the OpenAI telephony and SIP guide in full on 16 September 2026 looking for a SIP-side authentication mechanism you could configure — digest credentials, an IP access control list, a registration — and found none; the API key authenticates the call-control requests, which happen after the INVITE. That is not proof no such control exists, so ask before you depend on it. It does mean none is documented for you to switch on.
How big is the allowlist, and what does the firewall rule actually say?
Media is the pinnable half: OpenAI publishes four CIDRs for SRTP, and a /28 is 16 addresses.
| Block | First address | Last address | Addresses |
|---|---|---|---|
| 13.79.45.80/28 | 13.79.45.80 | 13.79.45.95 | 16 |
| 23.98.140.64/28 | 23.98.140.64 | 23.98.140.79 | 16 |
| 40.67.149.176/28 | 40.67.149.176 | 40.67.149.191 | 16 |
| 40.83.204.240/28 | 40.83.204.240 | 40.83.204.255 | 16 |
| Total | 64 |
16 + 16 + 16 + 16 = 64 individual IPv4 addresses on the media path, and all four blocks return NetName: MSFT in an ARIN whois lookup run on 16 September 2026.
Signalling is the half you cannot pin: zero addresses. On 16 September 2026, sip.api.openai.com resolved through a CNAME chain into cdn.cloudflare.net and then to 172.65.182.150, which ARIN returns as CLOUDFLARENET, Cloudflare, Inc.; sip-eu.api.openai.com resolved to 172.65.194.43 on the same network. The SBC trace published on 25 June 2026 shows the same hostname reached at 13.79.45.80 — a Microsoft address, and the first address of one of the four blocks now published for media. Over roughly twelve weeks the signalling address moved between two networks, and an operator reported on 9 July 2026 that the address resolving for the hostname had changed under him mid-week. An IP allowlist cannot survive that.
So the change request is one hostname-based egress rule on TCP 5061, plus 64 destination addresses on UDP for SRTP. Substitute your own vendor blocks; the shape is the point. For contrast, the same arithmetic on the trunk-provider path in our SIP trunk interop matrix expanded one vendor’s five blocks to 27,140 addresses. Direct SIP asks for far fewer addresses and one thing many appliances cannot do: resolve a name when the rule is evaluated.
When to go direct, and when to keep something in the middle
The honest crossover, as conditions rather than a recommendation.
| Go direct when | Keep a CPaaS in the path when |
|---|---|
| Every call you care about is inbound | You need outbound dialling at all, which the direct flow does not support |
| Your SBC lets you set peer certificate policy, or you can put a proxy in front of it | Your PBX enforces the RFC 5922 wildcard prohibition and cannot be changed |
| Your firewall can write an egress rule by hostname | Your firewall takes IP addresses only, because there is no stable signalling address to give it |
| Someone on the team reads a SIP trace and a TLS handshake in the same afternoon | Nobody does, and the characteristic failure returns no SIP response to read |
| You want one fewer vendor on the media path for data-residency reasons | You need number provisioning, porting or attestation, which stay with a carrier |
What it costs to run is mostly not money. The recurring cost is an on-call capability spanning SIP signalling, TLS certificate policy and a REST call-control API in the same incident, because on this topology all three present identically: the caller hears ringing and then nothing. There is no carrier desk to open a ticket with and no trunk console showing a red light — you get an SBC trace and whatever your own logs captured. Budget the engineering, not the minutes.
Sources, and who owns each figure
| Figure or claim | Owner credited | Source, read 16 September 2026 |
|---|---|---|
| Endpoint form, EU endpoint, webhook-first flow, GeoIP-routed signalling on TCP/TLS 5061, the four SRTP CIDRs, SIP headers as untrusted metadata, outbound SIP unsupported on the Live sessions endpoint | OpenAI | developers.openai.com/api/docs/guides/voice-sip |
| Wildcard prohibition for SIP domain identities; SRV and A record resolution order | IETF | RFC 5922 section 7.2 and RFC 3263 section 4.2 |
| Wildcard certificate refused by 3CX and the proxy workaround; a TLS INVITE to 5061 drawing no response, with destination 13.79.45.80; the resolved address changing in the week of 7 July 2026 | Three individual reporters on community.openai.com. Topic 1388888, 3 August 2026, open with no reply at 16 September 2026; topic 1384785, 25 June 2026, answered by OpenAI Support 10 September 2026 and now closed; topic 1386113, 9 July 2026, no reply at 16 September 2026 | Linked at left |
A record short-circuiting SRV, discarded SRV port, _sips._tcp never queried |
Reporter, livekit/sip issue 810, opened 25 August 2026, open at 16 September 2026 | github.com/livekit/sip/issues/810 |
| Minimum of an ACL or credential authentication on an Elastic SIP Trunk | Twilio | twilio.com/docs/sip-trunking |
| Certificate subject and SANs, TLS 1.3 handshake, DNS and NXDOMAIN results, port-probe behaviour, whois netnames, the 64-address total | Zian AI | Our own measurements, 16 September 2026 |
Where to go from here
If you have an SBC you control, a firewall that resolves names and someone who reads TLS handshakes, the gate table is enough to finish the job yourself. Run all five checks before you move traffic, because four of them produce silence rather than an error. More answers of this kind sit in the Zian AI questions and answers hub.
If you would rather the telephony seam belonged to someone else, that is where Zian AI sits: autonomous sales agents running live phone, SMS, email and WhatsApp outreach in 30 or more languages, with private model deployment on customer infrastructure for teams that need the call path inside their own boundary. Zian AI is in partnership-application beta, so there is no free trial and no self-serve signup. Apply For Partnership.
Frequently asked questions
Can I run an AI voice agent on direct SIP with no Twilio in the path?
For inbound calls, yes. Point an SBC or PBX at the model provider SIP endpoint over TLS on port 5061, register a webhook that receives the incoming-call event, and accept the call over HTTPS. You still need a carrier for the number itself, because a model provider does not sell numbers.
Why does my SBC reject the TLS certificate on the model SIP endpoint?
Because the certificate is a wildcard and the SIP profile forbids matching one. RFC 5922 section 7.2 states that implementations MUST NOT match any form of wildcard when comparing SIP domain identities. On 16 September 2026 the certificate served on port 5061 at sip.api.openai.com carried the SANs api.openai.com and a wildcard for that domain, so a strict SIP stack refuses it while a browser accepts it.
Can I allowlist the model SIP endpoint by IP address?
Not for signalling. The OpenAI telephony and SIP guide describes the SIP hosts as GeoIP-routed endpoints and instructs you to allow outbound TCP and TLS traffic to the addresses returned by DNS on port 5061. Media is different: four CIDR blocks are published for SRTP, which expand to 64 individual addresses.
Does direct SIP support outbound calls?
Not as at 16 September 2026. The direct SIP flow accepts inbound calls, and the guide states that creating an outbound SIP call through the Live sessions endpoint is not supported, directing you to a partner integration for provider-owned outbound calling. If outbound dialling is the requirement, a provider stays in the path for now.
Is a TCP port check a valid health check for a SIP endpoint?
No, and it can mislead badly. From our own host on 16 September 2026, TCP connections to the address serving sip.api.openai.com completed on ports 5060, 5061, 5063, 5070 and 443, while the same probe against two control hosts on port 5060 timed out with no response at all. Use a TLS handshake and a SIP request instead.