VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

Google Cloud CCAI Platform BYOC: carrier and SIP-edge boundaries

Connect an existing carrier or enterprise SBC to CCAI Platform while keeping instance activation, call direction, authentication, regional serviceability, signaling, media and transfer ownership separate.

Reviewed 2026-10-09Current first-party Google Cloud CCAI Platform BYOC, IP allow-list, location, SIP URI, high-availability, virtual-agent escalation and telephony-partner documentation reviewed October 9, 2026; the public IP allow-list page is dated October 7, 2026 and must be re-read at each change window; no CCAI Platform instance, license, support case, carrier, SBC, FQDN, address, certificate, firewall, route, number, header, SIP transaction, transfer, media stream, emergency workflow, price, capacity, availability, compatibility or call was inspected or testedAdvancedDocumentation based · not lab tested

Classify the platform, carrier and instance boundary

Google documents CCAI Platform BYOC as a voice-only SIP integration with an existing enterprise SBC or telephony carrier. It can carry inbound and outbound calls while the organization retains its carrier and numbers. That does not make Google, the carrier, the SBC and the contact-center application one service owner.

Record the CCAI Platform instance and Google Cloud region, environment, carrier contract, number owner, SBC and system integrator, signaling and media boundaries, emergency owner and support case. BYOC voice does not establish SMS service, and the telephony-partner list does not prove that a selected carrier, country or account has been activated.

Activate each instance through the documented workflow

Google's workflow starts with current-state and end-state topology diagrams, a high-availability design, authentication choice and the CCaaS BYOC questionnaire. The questionnaire and topology are submitted in a Google Cloud support case. Each development, UAT or production instance requires its own activation record.

Google provides a unique SIP FQDN for each instance and instructs the SBC to send the INVITE to that FQDN rather than the endpoint's IP address. Preserve the issued FQDN, DNS answers, source and destination policy, support acceptance and rollback. An enabled portal toggle or saved carrier identifier is not proof that inbound activation has completed.

Keep inbound and outbound controls directional

SIP authentication is documented for inbound calls only; outbound calls require IP-to-IP handshakes, and Google recommends IP-to-IP handshakes generally. Keep the inbound source, challenge or address identity separate from the outbound destination IP or FQDN and route.

CCAI Platform supports multiple simultaneous inbound carriers but only one outbound carrier. Google telephony can be requested as an outbound fallback. This is not symmetric multi-carrier routing, and it does not establish new-call failover timing, active-call survival or restoration for a selected design.

Version signaling and media policy separately

Google publishes carrier-specific signaling and media addresses and distinguishes their roles. The reviewed allow-list page is dated October 7, 2026. Treat those values as version-sensitive input: export the current page and issued integration record at the change window rather than copying a stale list from this guide.

Signaling reachability, accepted SIP, media reachability and decoded audio are separate. The public guide identifies PCMU and PCMA for the questionnaire and publishes distinct signaling and RTP port guidance, but those facts do not prove a negotiated codec, packet path, quality or certificate acceptance for one call.

Preserve number and metadata transformations

The BYOC guide exposes TO and FROM as DNIS and ANI in session metadata, while fields such as UUI are not passed through by default. Google documents mapping required UUI data into X-header values such as SipHeader_X-UUI. Preserve the original protected message, SBC normalization, received headers, platform mapping and consuming application field.

A connected call can still carry the wrong caller, called number or context. E.164 formatting is a high-availability recommendation, not evidence that a particular inbound ANI, transfer or outbound destination survived every rewrite.

Treat INVITE and REFER transfer modes as different call ownership

CCAI Platform can redirect to a number or SIP URI. SIP REFER is available only with BYOC; the virtual-agent guide recommends REFER for a configured BYOC SIP endpoint and otherwise describes INVITE-based transfer. A REFER request can move dialog establishment and later media ownership to other systems, while an outbound INVITE keeps a different set of legs.

Record the queue or virtual-agent decision, transfer method, URI, headers, response, replacement dialog, caller identity, media owner and agent result. A 202 response or an accepted new INVITE is not the same as a human answer with the intended context.

Close serviceability, resilience and safety independently

Google's locations table lists telephony availability by country and separates Google-managed from BYOC service. Recheck the current table, regional terms and account acceptance before design or expansion. A deployable Google Cloud region is not itself proof that BYOC telephony is available for callers, numbers or regulated workflows in that jurisdiction.

The customer owns high availability and routing from carrier services to the CCAI Platform media edge. Prove authorized inbound and outbound calls, failover, restoration, header mapping, transfer, two-way audio and emergency-routing ownership as separate acceptance cases. No instance, carrier path, call or emergency workflow was tested for this guide.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP REFER and transfers: acceptance versus completion

Follow transfer requests and their outcome notifications without assuming a 202 response means the transfer succeeded.

Read guide →
Troubleshooting · Current first-party Google Cloud CCAI Platform BYOC, IP allow-list, location, SIP URI, high-availability, virtual-agent escalation and telephony-partner documentation reviewed October 9, 2026; the public IP allow-list page is dated October 7, 2026 and must be re-read at each change window; no CCAI Platform instance, license, support case, carrier, SBC, FQDN, address, certificate, firewall, route, number, header, SIP transaction, transfer, media stream, emergency workflow, price, capacity, availability, compatibility or call was inspected or tested

Google Cloud CCAI Platform BYOC call fails or has no audio

Trace one failed BYOC call through instance activation, direction, unique SIP FQDN, directional authentication, route, header mapping, signaling and media before broadening an allowlist.

Read guide →
Troubleshooting · Asterisk PJSIP documentation reviewed September 26, 2026; adapt to the installed version and PBX management layer

PJSIP contact reachable but calls fail

Understand why a successful SIP OPTIONS qualify result does not validate INVITE routing, authentication or RTP.

Read guide →