VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

Zoom Phone BYOC-P trunk is down or calls fail

Trace one failed call through carrier delivery, customer SBC, Zoom transport and certificate state, routing objects, E.164 normalization, destination mapping and media before changing firewall or codec policy.

Reviewed 2026-10-09Current first-party Zoom Phone BYOC-P architecture, deployment, infrastructure, call-processing, configuration, dial-plan, emergency-calling and BYOC-messaging documentation reviewed October 9, 2026; no Zoom account, license, carrier order, number, port, SBC, firmware, certificate, private key, firewall, route group, SIP group, trunk, call, media stream, emergency workflow, message, serviceability, availability, price, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failed transaction and the intended path

Choose one authorized inbound or outbound attempt and record timestamp and timezone, Zoom account cluster and region, carrier, calling and called number in protected form, SBC node and software, Route Group, SIP Group, expected destination, Call-ID, first response or timeout and observed media result. Compare one closely matched successful control if available.

Do not recreate portal objects or open broad firewall ranges before locating the missing boundary. A carrier route, certificate, TLS session, accepted INVITE, Zoom destination, answer and two-way media are distinct checkpoints.

Confirm the exact topology and current portal objects

Read the loaded SBC, Route Group and SIP Group state from the Zoom portal and compare it with the current deployment design. Confirm that the Route Group region and account cluster match the configured Zoom peers. For inbound service, verify that the expected E.164 number is present and maps through the intended SIP Group to an assigned user or service.

Keep BYOC-P and BYOP-P roles distinct. BYOC-P owns third-party PSTN interoperability and E.164 numbers; BYOP-P can extend a private PBX dial plan. Enabling or troubleshooting the wrong role can route an otherwise valid number through the wrong ownership model.

Prove network reachability and TLS identity separately

For Internet peering, confirm bidirectional signaling and the account-specific firewall values from the current portal. Preserve DNS and route results, source and destination addresses and ports, first TCP or TLS failure, negotiated protocol and cipher, certificate chain, validity and key usage. Do not paste private keys or reusable credentials into tickets.

Zoom requires a supported public CA, complete chain, Server Authentication and the SBC FQDN in CN or SAN. Its current documentation also says expected-hostname peer-name validation is not performed on the customer SBC certificate. A completed handshake therefore does not prove the correct route, authorized source, SIP identity or call result.

Follow E.164 identity through carrier, SBC and Zoom

For inbound BYOC-P, inspect the carrier-delivered called number, SBC transformation and Request-URI user sent to Zoom. It must be E.164. Compare P-Asserted-Identity and From with the intended calling identity and preserve any rejection without rewriting fields blindly. Then confirm number inventory, SIP Group mapping and destination assignment.

For outbound service, follow the Zoom-selected BYOC number, normalized destination, Route Group, SBC route and carrier response. A number shown in the portal can still be unactivated or misrouted at the carrier, while a carrier-delivered number can still lack a Zoom assignment.

Inspect Early Offer, codec and protected media after signaling

If signaling reaches Zoom but the call is rejected or silent, retain both SBC legs' SDP. INVITEs sent to Zoom require Early Offer. Compare the offered and selected codec, packetization, telephone-event payload, SRTP profile, media addresses and ports. Then prove packets in both directions and decoded audio independently.

Do not assume that a supported codec list, TLS session or 200 response proves media. The SBC can translate between Zoom and carrier legs, and a working direction does not establish the reverse path. Keep fax outside the voice conclusion unless its own current profile and completed pages are observed.

Correct one demonstrated owner and retest the service

Correct only the evidenced owner: carrier activation or route, SBC peer or normalization, account-specific firewall rule, certificate or chain, Zoom routing object, number assignment, Early Offer, codec, DTMF or media policy. Preserve the prior configuration and a rollback trigger. Do not weaken certificate validation, disable SRTP or widen sources merely to clear one failure.

Run a fresh inbound and outbound case where authorized, confirm identity, answer, two-way audio, DTMF and normal hangup, then exercise only approved resilience and emergency validation. Reconcile monitoring and remove temporary captures. No Zoom account, SBC, trunk, call, media stream, emergency workflow or message was inspected or tested 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.

Continue your research

Provider research · Current first-party Zoom Phone BYOC-P architecture, deployment, infrastructure, call-processing, configuration, dial-plan, emergency-calling and BYOC-messaging documentation reviewed October 9, 2026; no Zoom account, license, carrier order, number, port, SBC, firmware, certificate, private key, firewall, route group, SIP group, trunk, call, media stream, emergency workflow, message, serviceability, availability, price, compatibility or support response was inspected or tested

Zoom Phone BYOC-P: carrier, SBC and routing boundaries

Connect a retained carrier to Zoom Phone through a customer-managed SBC while keeping Zoom routing objects, E.164 numbers, protected peering and emergency responsibilities distinct.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide

SIP trunk IP authentication

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

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 →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 evidence workflow; first-party documentation reviewed September 30, 2026; no endpoint, PBX, certificate or registration test

SIP TLS registration fails

Separate DNS, TCP, TLS, SIP transport selection and digest authentication before changing credentials.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

One-way VoIP audio

Trace the missing direction from advertised media address to receiving endpoint.

Read guide →
Troubleshooting · RFC 3261 with current Asterisk PJSIP documentation; Asterisk 22 LTS and FreePBX 17 deployment context; no live test

Phone is registered but cannot make calls: trace the INVITE path

Keep registration, account selection, endpoint identification, dialplan match, channel creation, answer and media separate.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →