Cloud Voice PBX Onboarding Troubleshooting Guide

Setting up a new phone system occasionally hits a snag. This guide walks through the problems customers most often run into while onboarding Cloud Voice, explains what tends to cause each one, and gives you the steps to get back on track. “PBX” (Private Branch Exchange) is the phone system that routes calls for your organization.

Each section follows the same shape: what you see, why it happens, and how to fix it. Work through the section that matches your symptom.

Activation email not received

What you see: After you purchase Cloud Voice, an activation email is sent with everything you need to stand up your PBX. That message never arrives in your inbox.

Why it happens: Your mail provider most likely filtered the message into a spam or junk folder before you saw it.

How to fix it: Open your spam or junk folder and look for the activation message that contains your setup details. If you find it there, mark it as trusted so future notifications land in your inbox.

Note

The activation email is sent automatically from a no-reply system address, which is a common trigger for spam filters. Once you locate it, add the sender to your safe-senders (allow) list so later Cloud Voice messages, such as setup links and system alerts, reach your inbox instead of being filtered again.

Activation URL not working

What you see: You click the activation link, but the activation page fails to load or spins indefinitely.

Why it happens: The browser you opened the link in isn’t fully compatible with the activation page. A URL (Uniform Resource Locator) is simply the web address you were given.

How to fix it: Open the activation URL in Google Chrome.

Tip

Google Chrome is the supported browser for activation. Using it avoids the rendering and compatibility problems that can appear in other browsers, so reach for Chrome first before troubleshooting anything else.

Auto provisioning over RPS fails

Auto provisioning pushes the correct configuration to an IP phone (a desk phone that connects over your network) automatically, so you don’t have to program each phone by hand. RPS (Redirection and Provisioning Service) is the cloud redirection step that makes remote provisioning possible: when a supported phone starts up, it checks in with RPS, which points the phone to your Cloud Voice provisioning link so the phone can pull its settings.

What you see: A remote auto provisioning attempt for one or more IP phones over RPS does not complete.

There are a few common reasons this fails. Work through each one below.

The phone is already provisioned by another PBX

An IP phone can only be tied to one provisioning list at a time. Remove the phone from the provisioning list on the other PBX first, then run auto provisioning over RPS again from Cloud Voice.

The provisioning server URL doesn’t match

The provisioning server URL saved on the phone must be identical to the provisioning link Cloud Voice generated for that phone in the web portal. Compare the two values and correct the phone so they match exactly.

Caution

The two URLs must match character for character. Easy-to-miss differences such as http versus https, a trailing slash, a different port number, or a typo will cause provisioning to fail even though the values look similar at a glance. Copy and paste rather than retyping when you can.

No certificate is uploaded, or the certificate has expired

If the PBX has no certificate, or its certificate has lapsed, the phone can reject the connection. A certificate is the digital identity a server presents to prove it is genuine. Upgrade the phone to its latest firmware, or turn off certificate verification on the phone.

Caution

Disabling certificate verification stops the phone from checking that it is talking to the genuine server, which lowers security. Where possible, prefer the safer fixes first: upgrade the phone’s firmware, or make sure a valid, current certificate is in place on Cloud Voice. Turn verification off only as a temporary workaround.

Tip

The setting below shows how to disable certificate verification on a Yealink T53W. The option and label vary by phone model.

If provisioning still fails after all of the above, contact IZT Cloud Voice support for help.

Tip

You can also register the IP phone with Cloud Voice manually instead of relying on auto provisioning. See the IP Phone Configuration Guide for the manual registration steps.

Trunk registration fails

A SIP (Session Initiation Protocol) trunk is the virtual line that connects Cloud Voice to your service provider and carries calls over the internet. SIP is the signaling protocol that sets up and ends voice calls.

What you see: You create a SIP register or SIP peer trunk to connect Cloud Voice to your service provider, and the trunk fails to register.

Emergency calls

While a trunk is not registered, it cannot carry calls in either direction, including outbound emergency (911) calls. Treat a registration failure as urgent, and do not rely on the affected trunk for emergency calling until it is registered again.

The cause depends on the trunk type. With a register trunk, your PBX logs in to the provider to stay reachable. With a peer trunk, the two sides trust each other by IP address and no login takes place.

SIP register trunk

This usually points to a proxy server setting. A proxy server is the provider server that relays your SIP traffic. Some providers spread traffic across multiple proxy servers for load balancing (sharing traffic) or failover (switching to a backup), and publish NAPTR-SRV records for their domain. NAPTR (Naming Authority Pointer) records, combined with SRV records, let a domain advertise several servers and transport options through DNS (Domain Name System, the internet’s address book). When that’s the case, switch the trunk’s transport to DNS-NAPTR so the PBX looks up and resolves the correct server:

1. In the PBX web portal, go to Extension and Trunk > Trunk.

2. Click the edit icon () next to the SIP register trunk you want to change.

3. Open the Transport drop-down list and choose DNS-NAPTR. (Transport is how SIP messages travel between the PBX and the provider.)

   

4. Click Save, then Apply.

Note

Changes to a trunk do not take effect until you click Apply. Saving alone stores the change but does not activate it, so a forgotten Apply is a common reason a fix appears not to work.

SIP peer trunk

This also tends to be a proxy server issue. Some providers require a dedicated, fixed public IP address to accept a trunk, but your PBX instance may share a proxy server with other instances. Contact IZT Cloud Voice support to have a dedicated proxy server provisioned for you.

Inbound calls aren’t routed

What you see: Inbound calls arriving on your SIP trunk should follow the inbound route to its destination, but they don’t route the way you expect.

Why it happens: The DID on the SIP trunk or inbound route isn’t configured to cover every number your provider might send. A DID (Direct Inward Dialing, also called DDI or Direct Dial-In in some regions) is the specific phone number the caller dialed to reach you. When you route inbound calls by DID, only calls whose number matches a defined DID pattern reach the destination. Providers differ in what they send: some pass the originally dialed number, others prepend a country code. If your patterns don’t account for every format, some calls slip through.

How to fix it: Add all of the DID patterns your provider might present, on the SIP trunk, the inbound route, or both.

Tip

List every format the number can arrive in, not just the one you expect: national format, the full number with country code, and versions with or without a leading +. Covering each variant is what keeps calls from being dropped when the provider changes how it presents the number.

Add DID patterns on the SIP trunk

1. In the PBX web portal, go to Extension and Trunk > Trunk.

2. Click the edit icon () next to the trunk you want to change.

3. On the DIDs/DDIs tab, click Add and enter every DID your provider may send.

   

4. Click Save, then Apply.

Add DID patterns on the inbound route

1. In the PBX web portal, go to Call Control > Inbound Route.

2. Click the edit icon next to the inbound route you want to change.

3. Scroll to the DID Pattern section, click Add, and enter every DID your provider may send.

   

4. Click Save, then Apply.