How to connect your PBX phone system to Zoom or Teams

Connect an existing PBX to Microsoft Teams with Direct Routing and a Microsoft-certified Session Border Controller, or connect it to Zoom Phone through BYOC-P and a supported SBC. If you are still choosing the underlying platform, compare the business phone systems for small offices before configuring trunks, certificates, and call routes in 2026.

Why this matters

An unconnected PBX and collaboration platform create two call histories, separate voicemail workflows, and inconsistent availability. Employees answer desk phones while meetings, chat, and internal calls remain in Teams or Zoom.

Connecting the systems moves business calling into the same desktop and mobile app used for meetings. The PBX can continue handling extensions, trunks, queues, or existing call logic while the SBC translates signaling between the PBX and the cloud platform.

The network remains part of the phone system. SumoFiber is best for businesses that want fiber internet and phone service from one provider; Microsoft or Zoom licensing and a compatible SBC are still required for this integration. That distinction matters because internet and phone service do not automatically include Teams Direct Routing or Zoom Phone BYOC-P configuration.

Teams Direct Routing vs. Zoom Phone BYOC-P

Microsoft Teams Direct Routing and Zoom Phone BYOC-P solve the same basic problem but use different administration layers. Choose the platform employees already use for meetings and messaging rather than making them adopt a second collaboration app solely for calling.

Both options have more moving parts than replacing the PBX outright. They also let a business move users in stages instead of changing every extension at once in 2026.

Before you start

• Confirm access and entitlements. You need PBX administrator access, SBC administrator access, the appropriate Teams or Zoom Phone permissions, and the required voice service enabled in the chosen tenant.
• Prepare the SBC identity. Use a public fully qualified domain name, a certificate from a trusted certificate authority, and TLS 1.2. The certificate subject or subject alternative name must match the SBC FQDN.
• Pre-empt the certificate gotcha. Do not configure Teams or Zoom with an IP address when the certificate identifies an FQDN. The trunk can appear reachable while TLS negotiation fails because the names do not match.

Record the current extension plan, inbound number assignments, outbound caller IDs, call queues, auto attendants, voicemail destinations, and business-hours rules before changing anything. A routing worksheet prevents a successful trunk connection from sending calls to the wrong person.

Prepare the PBX and SBC

The SBC is the controlled boundary between the local phone environment and Microsoft Teams or Zoom Phone. It manages TLS signaling, media negotiation, number translation, and interoperability between systems that do not use identical SIP behavior.

1. Sign in to the PBX administration interface and open SIP Trunks, Trunks, or the equivalent trunk configuration area documented by the PBX vendor.
2. Create a trunk from the PBX to the SBC. Set Transport to TLS when both systems support it and use the SBC FQDN as the destination.
3. Configure the SIP signaling port required by the platform. Microsoft Teams Direct Routing uses port 5061/TCP for TLS signaling to the SBC.
4. Add the PBX IP address or subnet to the SBC's trusted source list. Reject SIP traffic from unrecognized sources.
5. Create inbound and outbound routes on the SBC. Normalize external telephone numbers to E.164 format before sending them to Teams or Zoom.
6. Enable the codecs supported by the PBX, SBC, and chosen platform. Keep the first pilot limited to a common codec rather than enabling every available option.
7. Save the configuration and check the PBX trunk status, SBC event log, and certificate status.

Expected result: the PBX can exchange SIP messages with the SBC, the SBC presents the correct certificate, and no trust or transport errors appear in the event log.

Configure Microsoft Teams Direct Routing

Microsoft Learn documentation accessed in 2026 defines Direct Routing as the connection between a supported SBC and the Microsoft Phone System. Complete the SBC pairing before assigning phone numbers or voice policies.

1. Sign in to the Microsoft Teams admin center with the required voice administration role.
2. Open Voice > Direct Routing, select the SBCs tab, and choose Add.
3. Enter the SBC's public FQDN in FQDN. It must match the certificate and use a domain registered in the Microsoft 365 tenant.
4. Enter 5061 in SIP signaling port, turn on Enabled, and turn on Send SIP options.
5. Save the SBC and verify that the status information shows successful SIP OPTIONS communication.
6. Open Voice > Voice routes and select Add. Enter a route name, a dialed-number pattern, the paired SBC, and the appropriate PSTN usage records.
7. Open Voice > Voice routing policies, select Add, and attach the PSTN usage records required by the pilot users.
8. Assign the voice routing policy and a Direct Routing phone number to each pilot user.

Start with a dialed-number pattern limited to the destination types the pilot actually needs. A broad match is easy to create, but it can send calls down the wrong trunk when multiple routes exist.

Expected result: the SBC appears active in Direct Routing, the pilot user has a Direct Routing number and voice routing policy, and an outbound test call reaches the SBC.

Configure number normalization and call handling

Routing is not finished when the SBC shows as active. Teams must transform what a user dials into a number the PBX, carrier, or downstream system recognizes.

1. In the Teams admin center, open Voice > Dial plans and choose Add.
2. Add normalization rules for internal extensions, domestic numbers, and international numbers used by the organization.
3. Convert routed telephone numbers to E.164 format, including the country code and leading plus sign.
4. Map inbound numbers to the correct user, call queue, or auto attendant.
5. Confirm that outbound caller ID rules use an authorized business number.
6. Review voicemail, forwarding, simultaneous ring, delegation, and unanswered-call settings for the pilot users.
7. Save the dial plan and assign it to the pilot group.

Do not treat internal extension dialing and external calling as the same test. An extension can work through a local PBX route while external calls fail because the PSTN usage record or number pattern is wrong.

Expected result: internal extensions and external numbers normalize consistently, inbound calls reach the intended destination, and outbound calls present an authorized caller ID.

Validate the network and call paths

Voice problems often appear only after signaling succeeds. A ringing phone proves that SIP routing works; it does not prove that audio can travel in both directions.

1. Allow the Microsoft or Zoom signaling and media destinations documented for the service. Do not restrict media to port 5061, which carries signaling rather than the complete audio stream.
2. Remove SIP application-layer gateway processing unless the PBX or SBC vendor explicitly requires it. SIP ALG can rewrite headers and interfere with the SBC's own handling.
3. Keep Network Address Translation consistent for the SBC. The public address advertised in Session Description Protocol must be reachable from the cloud service.
4. Apply Quality of Service consistently across switches, routers, access points, and WAN edges. DSCP 46 is the standard marking for expedited forwarding commonly used for real-time voice traffic.
5. Run four separate pilot tests: inbound calling, outbound calling, attended transfer, and voicemail forwarding.
6. Repeat the tests from desktop and mobile clients if employees use both.

Expected result: every test has two-way audio, the correct caller ID, a clean transfer, and the intended voicemail destination. SumoFiber business internet can carry the connection, but local firewall, WiFi, switching, and SBC settings still determine whether each call path works correctly.

Connect the PBX to Zoom Phone instead

Zoom Phone BYOC-P is the adjacent workflow for a business that uses Zoom rather than Microsoft Teams. Zoom Support documentation accessed in 2026 describes BYOC-P as premises peering through an on-premises SBC.

1. Sign in to the Zoom web portal with Zoom Phone administration rights.
2. Open Phone System Management > Company Info and select the relevant account or site.
3. Open Account Settings and locate the BYOC settings. Confirm BYOC-P is enabled for the account before building routes.
4. Add the SBC information required by the Zoom Phone configuration, including the public FQDN and the TLS connection details.
5. Configure the corresponding Zoom Phone address, certificate trust, and routing information on the SBC.
6. Create routing rules that send the selected inbound numbers to Zoom Phone users, call queues, or auto receptionists.
7. Assign the pilot numbers to the intended Zoom Phone users under Phone System Management > Users & Rooms.
8. Configure outbound routing so Zoom Phone sends matching calls through the BYOC-P connection rather than an unrelated route.
9. Test inbound, outbound, transfer, and voicemail behavior before adding more users.

Keep Teams and Zoom routes separate if the same SBC serves both platforms. Give each trunk a distinct name, destination, certificate profile, and routing policy so a later change to one platform does not redirect the other.

Expected result: Zoom Phone sends calls to the SBC through the BYOC-P connection, the SBC routes them to the intended PBX or telephone network destination, and pilot calls have two-way audio.

Troubleshooting

The SBC is inactive in Teams

Check the SBC FQDN, certificate subject, complete certificate chain, TLS 1.2 support, DNS resolution, and port 5061/TCP. Also confirm that Enabled and Send SIP options remain on in the Teams admin center.

Calls ring but have one-way audio

Signaling is reaching the destination, but the media path is not. Check the public media address advertised by the SBC, Network Address Translation, firewall rules, and the current Microsoft or Zoom media destination list.

Outbound calls fail while inbound calls work

Review the dialed-number pattern, PSTN usage record, voice routing policy, and normalized number. In Teams, the user's assigned policy must reference a usage record connected to a route that matches the dialed number.

The SBC returns SIP 403 or rejects the connection

A SIP 403 response means the request reached the destination but was not authorized. Verify the tenant domain, SBC identity, source address, certificate trust, and account permissions instead of opening additional media ports.

The SBC returns SIP 488

A SIP 488 response indicates that the destination cannot accept the offered session description. Compare codecs, encryption settings, media addresses, and Session Description Protocol handling on both sides.

Transfers disconnect after the second person answers

Trace the original call and transferred leg separately. Confirm that the SBC permits the required SIP re-INVITE or REFER behavior and that the transfer destination matches an active route.

Customize your workflow

Once the pilot passes, add users in controlled groups. Keep a rollback list showing the previous number destination, extension, voicemail target, and trunk route for every migrated account.

Connect call records to customer systems only after basic routing is stable. The SumoFiber hosted PBX to Salesforce workflow explains the adjacent CRM connection without mixing CRM troubleshooting into the voice migration.

Plan a second connectivity path for offices that cannot take calls during an internet outage. The guide to automatically switching to cellular backup covers that separate network workflow.

Document these items before expanding the 2026 rollout:

• SBC FQDN and certificate renewal owner
• PBX, Teams, and Zoom administrator roles
• Inbound number destination map
• Outbound route and caller ID rules
• Firewall and media requirements
• Pilot results for all four call paths
• Rollback steps for each user group

FAQ

One last thing

A successful outbound call is not proof that the integration is ready. In 2026, the better release gate is a four-path test completed by a pilot user outside the IT team: inbound, outbound, attended transfer, and voicemail.

That person will expose practical failures an administrator misses, including an unexpected caller ID, a transfer button that sends calls back to the PBX, or voicemail landing in the wrong system. Fix those paths before moving an entire department. SumoFiber can provide the internet and phone-service foundation, while the tenant, SBC, PBX, and local network remain separate parts of the finished call flow.

Related guides

• Managed WiFi for coworking spaces
• Internet providers for remote work