Freeze one failed transaction and the intended path
Record an authorized attempt's timestamp and timezone, direction, organization and region, telephony connection option, site and location, external trunk name and type, cloud Voice platform or premises Edge and interface, carrier or PBX peer, protected calling and called numbers, Call-ID, first response or timeout and media result. Compare one closely matched successful control if available.
Do not recreate the trunk, broaden access lists, replace an Edge or migrate platforms before locating the missing boundary. In-service configuration, reachable peer, accepted INVITE, routed destination, answer and media are different states.
Separate the Cloud and Premises evidence paths
For BYOC Cloud, prove the legacy or Dynamic Cloud Voice platform, regional cloud peers and inbound organization identity. For BYOC Premises, prove the exact Edge, cloud connectivity, software and hardware identity, network interface, External SIP trunk, Edge-group access and Premises media-model site. Do not apply a cloud peer list or certificate-root migration to a premises Edge fault.
If a premises appliance is Genesys-supplied hardware, record the December 1, 2026 end-of-support boundary and the approved migration plan separately from the immediate incident. Customer Hardware Solution is a separate provisioning path, not evidence that the installed Genesys appliance is already covered or converted.
Prove the Voice platform and current regional values
For BYOC Cloud, read the trunk's actual platform and the current UI reference values. Compare its ingress and egress addresses, DNS or FQDN suffix, certificate roots and configured destinations with the matching Genesys platform documentation. Existing Cloud trunks are not automatically migrated by the future-default announcement.
For BYOC Premises, instead confirm the Edge's cloud connection and external-trunk status, the bound interface, prioritized peer list and any configured registration or availability mechanism. Do not replace either path with the other's addresses, roots or health assumptions.
Follow the outbound transport and response
For an outbound failure, confirm the selected site classification, normalized number, outbound route, trunk and destination. The protocol setting controls calls sent from Genesys, so compare UDP, TCP or TLS with the peer and retain the first network, TLS or SIP result. A successful inbound transaction does not prove this outbound configuration.
Preserve OPTIONS evidence, destination order and each response. A 503 and sequential-failover requirement does not reveal the selected carrier's retryable codes, timer, target capacity or restoration behavior without the current handoff.
Follow inbound organization identity and site selection
For an inbound failure, inspect the Request-URI and the chosen FQDN, TGRP, DNIS or custom-header method. Confirm that the regionally unique termination identifier reaches the correct Genesys organization before evaluating the public called number or destination.
Then prove the Number Plan Site, transform, normalized digits and final route. A valid carrier number can still fail organization association, and a correctly identified organization can still transform or route the number through the wrong site.
Inspect TLS and media as later boundaries
For TLS, record the platform-specific endpoint, TCP and TLS roles, chain, public root, validity, name and negotiated cipher without exposing private keys. Dynamic Cloud Voice uses different roots and explicitly does not support client authentication or mutual TLS. Keep that fact separate from source-address and inbound-identifier controls.
After signaling succeeds, compare offer and answer, selected codec, telephone-event payload, SRTP profile and media addresses. Prove packets and decoded audio in both directions. Provider support for G.711, DTMF or fax pass-through is not an observed result.
Accept routing, failover and service outcome independently
Retest one bounded inbound and outbound case, the authorized OPTIONS or health signal, new-call failover and restoration. Correlate organization identification, site selection, destination alerting, answer, two-way audio, digits and hangup. Preserve the carrier and Genesys owners for every failed boundary.
Emergency calls require the carrier's location and dispatch record plus Genesys Number Plan and Outbound Route configuration; do not place an unscheduled live emergency test. Remove temporary diagnostics and access changes. No Genesys Cloud organization, trunk, carrier path, call, media or emergency workflow was validated for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- About Genesys Cloud BYOC Cloud ↗
- Carrier requirements for BYOC Cloud ↗
- Create a BYOC Cloud trunk ↗
- Configure SIP routing for a BYOC Cloud trunk ↗
- Choose a BYOC Cloud trunk transport ↗
- TLS trunk transport specification for BYOC Cloud ↗
- Dynamic Cloud Voice platform overview and migration guide ↗
- Dynamic Cloud Voice future-default announcement ↗
- SIP provider questionnaire for BYOC trunks ↗
- Genesys Cloud sites overview ↗
- Select an inbound Number Plan Site ↗
- Set up emergency services with BYOC ↗
- Genesys Cloud fair use policy ↗
- BYOC Cloud configuration checklist ↗
- BYOC Premises trunk connection overview ↗
- Create a trunk under BYOC Premises ↗
- Get details on a BYOC Premises Edge ↗
- Trunk status indicators ↗
- Deprecation: BYOC Premises – Genesys Hardware Solution ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.