VoIP.info Troubleshooting

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.

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

Freeze one attempt and the intended ownership

Record an authorized attempt's timestamp and timezone, direction, CCAI Platform instance and region, environment, carrier and SBC, protected calling and called numbers, Call-ID, target FQDN, first response or timeout, selected contact-center resource, transfer result and media result. Compare one closely matched successful control if available.

Do not change DNS, enable a broader address range or replace the trunk before locating the missing boundary. Instance activation, reachable peer, accepted INVITE, routed session, answer, transferred dialog and two-way audio are different states.

Prove instance activation and FQDN selection

Confirm that the exact development, UAT or production instance was included in its own questionnaire and support-case activation. Compare the SBC destination with the unique SIP FQDN issued for that instance. Google instructs integrators to send the INVITE to the FQDN, not the endpoint's IP address.

Capture DNS resolution from the sending system and retain the issued integration record. A valid IP reached directly can bypass the supported identity and change model; a portal BYOC toggle for outbound traffic does not establish inbound activation.

Branch by direction and authentication model

For inbound failure, prove the carrier or SBC source, inbound authentication or IP policy, destination FQDN and Google response. For outbound failure, prove the chosen carrier configuration, target URI or trunk identifier, destination IP or FQDN and the required IP-to-IP handshake. Do not copy an inbound credential assumption to the outbound leg.

Multiple inbound carriers are supported, but only one outbound carrier is documented. If a Google-telephony fallback was requested, preserve the accepted support configuration and selected route rather than inferring it from another carrier's success.

Compare current signaling and media policy

Retrieve the current Google BYOC allow-list and the instance-specific integration values during the incident. Compare signaling and media addresses independently with the SBC and firewall. Preserve the exact reviewed revision; the public page was last updated October 7, 2026 when this diagnostic was written.

OPTIONS reachability proves only the tested transaction and path. After an INVITE succeeds, inspect the offer and answer, selected PCMU or PCMA payload, advertised and observed media addresses, RTP packets and decoded audio in both directions. A signaling fix does not prove the media rule or listener result.

Follow number, header and destination transformations

Trace the protected original ANI, DNIS and required context through carrier normalization, SBC rules, SIP headers, CCAI session metadata and queue or virtual-agent selection. TO and FROM can appear as DNIS and ANI, while UUI requires deliberate mapping to an X-header if it must enter session metadata.

Correct audio to the wrong queue is a routing defect, not a media success. Do not expose caller data or proprietary context in a public ticket; retain redacted correlations and the field-by-field transformation.

Trace REFER or INVITE transfer as a new stage

If the initial contact-center leg works but escalation fails, identify whether the platform used SIP REFER or an outbound INVITE. REFER is BYOC-specific in the documented workflow and requires the integration to be implemented. Capture the request, response, replacement dialog, selected URI, passed X-headers, caller identity and final human-agent answer.

A successful initial call does not prove transfer routing, and a successful transfer request does not prove that the replacement dialog alerted or carried audio. Keep the original and replacement Call-IDs and media owners distinct.

Retest bounded calls, failover and restoration

Retest one authorized inbound call, one outbound call when in scope, one transfer path and one new-call failover case. Correlate signaling, selected destination, answer, two-way audio, metadata and hangup. Restore the primary path and prove that new calls return without duplicate routing or stale policy.

Do not place an unscheduled live emergency test. Preserve the carrier, Google, SBC, contact-center and emergency-routing owners, remove temporary captures and narrow any diagnostic access. No Google Cloud instance, carrier, SBC, transaction, media path, transfer or call was validated for this diagnostic.

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.