Planning the deployment of BYOC-P/BYOP-P is crucial for a successful implementation. Learn more from the following resources:
The dial plan functionality aims to provide users and administrators with a seamless experience when interacting with the Zoom platform. This section presents an overview of administrative tools available for both BYOC-P and BYOP-P, as well as details about Zoom's dial plan implementation.
Note: This is for Zoom Phone customers only.
Bring Your Own Carrier- Premises (BYOC-P) was developed to enable organizations to utilize their existing PSTN carriers, facilitating a smooth migration to the Zoom Phone platform.
A Direct Inward Dial (DID) number from a third-party carrier is configured within Zoom and assigned to a Zoom Phone user who has a Zoom Phone Pro License. The outbound routing is determined by the package assigned to each user. Depending on the assigned package, users can place PSTN calls through either native Zoom Phone or BYOC-P. Zoom Phone identifies the appropriate carrier for each number based on whether it's a native Zoom Phone number or BYOC Number.
When a user has both native Zoom Phone and BYOC-P packages, calls are routed according to the calling number. For instance, if the calling number is associated with a Zoom Phone carrier, the call will be routed through Zoom Phone carriers. Conversely, if the calling number is a BYOC number, the call will be directed to the BYOC-P SIP trunk.
Zoom implements the E.164 numbering plan to maintain a global dial plan architecture. All BYOC-P SIP trunks integrated with Zoom must send and receive E.164 dialing strings for all calls.
Bring Your Own PBX - Premises (BYOP-P) architecture enables hybrid environments while also providing a PSTN solution for customers in regions where Zoom Native is unavailable. BYOP-P implementation requires BYOC-P enablement on SIP trunks as a prerequisite. Unlike BYOC-P, BYOP-P does not require Zoom number provisioning. For dial plan considerations, BYOP-P can utilize existing BYOC-P SIP trunk SBCs, and organizations should configure their SBC dial plans accordingly. This approach simplifies management by eliminating the need for separate SBCs serving different purposes.
E.164 signaling, while supported, is not mandatory for BYOP-P.
Note: When using Bring Your Own PBX-Premises, the From and Contact headers (within the SIP invites going out to the customer's SBC) will have the Zoom Phone user’s extensions. The P-Asserted-Identity (PAI) will have the user’s phone number.
When designing dial plans for BYOP-P, careful consideration must be given to the interaction between existing PBX and Zoom Phone dial plans.
BYOP-P dial plan functionalities encompass external contacts and account/site-level Routing Rules with called number translation capabilities.
When the called number is not an internal Zoom Phone extension, the system first searches through external contacts, which are maintained at the account level. If no matching external contact is found, the system proceeds to analyze Routing Rules. During this process, site-specific Routing Rules take precedence, followed by account-wide Routing Rules. The final routing decision is determined by the calling number:
Importantly, routing analysis stops once a matching route is identified, as multiple routing constructs are not combined. However, this principle does not apply to Routing Rules with the path Other Sites. The figure below illustrates the routing logic.
External contacts are account-wide and can be configured with or without a routing path. The following figure summarizes the routing decision when the dialed number matches an external contact and the routing path has not been selected.
When the routing path is not specified, Zoom recommends formatting the external contact in E.164 format. In cases where the external contact is an internal extension and no routing path is selected, call failure is likely to occur because the called number will automatically receive a country code prefix, potentially resulting in an unknown number.
For instance, if an external contact is added with extension 1000 in the North American Numbering Plan (NANP) region where +1 is the country code, the system will convert it to +11000.
When a routing path exists within a BYOC-P enabled Route Group (without BYOP-P), the system follows the same logic outlined in the External contacts with no routing path section. However, the egress route is determined by the routing path specified in the external contact rather than the SIP Group associated with the BYOC number.
The following figure illustrates the routing decision process when the dialed number corresponds to an external contact, the routing path has been selected, and the Route Group is configured for both BYOC-P and BYOP-P.
For cases where the routing path is set to PSTN, the external contact must be formatted in E164 standard, as Zoom does not support internal extensions as external contacts when using PSTN as the routing path.
Routing Rules are the most flexible method of routing calls since a called number translation can be performed prior to route selection. The following figure summarizes the routing decision when the dialed number matches a Routing Rule.
Note: Number matching patterns for routing rules must not conflict with DTMF codes or emergency numbers. Using emergency numbers as number-matching patterns will not send location information to the PSAP.
Routing Rules configured with the path Other Sites are distinct from other Routing Rules, as they enable call steering to internal or on-net destinations rather than PSTN or off-net destinations. Admins can match a dialed number to a pattern within a Routing Rule, perform a translation, and direct the call to any internal destination defined in the account. These internal destinations may include site codes and extensions or PSTN numbers associated with Zoom Phone endpoints, such as users, Auto Reception, Call Queue, and other constructs.
Note: When using an internal extension, the site code must be prepended to the extension.
For example, consider a company wanting to enable users to dial "0" to reach an operator. In this scenario, the operator is an auto receptionist configured with the number 5551212 (where 555 represents the site code and 1212 is the short extension).
An account-wide Routing Rule should be established with the pattern "0". The translation in this Routing Rule is set to "5551212", and the routing path is configured as "Other Sites". See below for a screenshot of the configuration.
When a user dials "0" and there are no other matching patterns, the Routing Rule is triggered, translating the dialed number to 5551212 and directing the call to an auto receptionist configured with this number. If no matching Zoom Phone construct exists for the translated number (5551212), the translation is reversed and routing continues as if this rule were not present. Subsequently, Zoom Phone attempts to globalize the called number and routes the call either to the SIP Group associated with the BYOC-P number, or to Zoom Native PSTN, depending on the call's originating number type. Since the dialed number in this scenario is "0", Zoom Phone will prepend +1 (assuming a North American caller), which ultimately results in call failure.