Updating Your Phone to Sharpen's new Provisioning Server (IZ1)

What is happening

Your desk phones download their configuration from a provisioning server each time they start up. We have moved to a new provisioning system, and your phones need to be pointed at its new address. Customers will need to update either the address stored in the phones or the address your DHCP server hands out.

Your new provisioning URLs

Use exactly the URLs below. They are specific to your account — please do not share them or copy a URL from anyone else's instructions.

We are giving you two versions of each URL: a secure HTTPS version and a plain HTTP version. Use HTTPS wherever your phones support it. Some older phone models and firmware versions cannot handle HTTPS correctly; those phones can use the HTTP version. See "Try HTTPS first" below.

Preferred — HTTPS

Polycom phones:

Yealink phones:

Fallback — HTTP, for phones that cannot do HTTPS

Polycom phones:

Yealink phones:

Please note:

• The HTTPS and HTTP versions use different server names. Copy the whole URL as given. Do not take one URL and change https to http — you would end up with an address that does not exist.

• Include the trailing slash at the end. Do not add a filename or a MAC address; the phone requests its own configuration file automatically.

• Polycom and Yealink phones use different URLs. If you have both brands, each brand must get its own URL. A Polycom phone given the Yealink URL will not configure correctly.

• The long string of letters and numbers in the middle is your account identifier. Enter it exactly as shown.

• Polycom and Yealink are the phone brands supported by the new provisioning system. If you have desk phones from another manufacturer, please contact us before you begin.

Your previous address was similar to provision.fathomvoice.com/phone/polycom. That is what you are replacing.

Try HTTPS first

HTTPS encrypts the configuration your phones download. That configuration contains the credentials your phones use to register for service, so it is worth protecting: on plain HTTP, anyone able to observe traffic on the network path between your phones and us can read those credentials.

For each phone model you have:

1. Set up a test phone with the HTTPS URL for its brand and reboot it (full instructions in the next section).

2. If it comes up and calls work, use HTTPS for every phone of that model.

3. If it does not, try the HTTP URL for that brand and reboot again. If the phone then works, that model's HTTPS support is the problem — use HTTP for it for now.

4. For any model that needs HTTP, we recommend updating that phone's firmware to the latest version available from the manufacturer and trying HTTPS again. Firmware updates usually fix this, because the underlying cause is an out-of-date security library in the phone. If the model is old enough that the manufacturer no longer publishes firmware for it, we recommend planning to replace it.

If your network team needs the technical detail: our provisioning server requires TLS 1.2 or newer and modern cipher suites. It does not accept TLS 1.0 or 1.1, or older SHA-1 and 3DES ciphers. A phone that only advertises TLS 1.2 may still fail if its cipher support is dated — so please test rather than relying on a specification sheet. Our certificate is issued by Amazon and chains to a root that has been in device trust stores since 2009, so a phone rejecting it because it does not recognize the certificate authority is unlikely.

It is perfectly fine to run a mix — HTTPS on your newer phones and HTTP on the older ones. Please just let us know which models needed HTTP so we can help you plan.

Before you start: which method do you use?

Your phones get their provisioning address in one of two ways. Check which applies to you — you may be using both.

Method A — the address is set on each phone. Someone entered the provisioning server address into the phones directly. To check: log in to one phone's web interface and look at its provisioning settings. If a server address is filled in there, you are likely using this method.

Method B — your DHCP server hands out the address. Your network's DHCP server tells the phones where the provisioning server is. This is already set up and working on your network, so there is nothing new to configure — you only need to find where the current provisioning address is set and change it. Your IT team or network administrator will know where that is.

Method B is faster to change but affects every phone at once — which is why we ask you to do the following in order.

Step-by-step: what to do

1. Test one phone first

1. Identify a test phone candidate.

2. Log in to that phone's web interface as an administrator.

3. Find the provisioning / configuration server setting and enter the HTTPS URL for that phone's brand:

   • Polycom: Settings → Provisioning Server. Set the server type to HTTPS and enter the URL.

   • Yealink: Settings → Auto Provision → Server URL. Enter the URL.

   • Menu names vary by model and firmware. If you cannot find it, your phone's admin guide or our support team can help.

4. Save and reboot the phone.

5. Confirm all three of the following:

   • the phone comes up and shows its extension as registered,

   • you can place an outbound call,

   • you can receive an inbound call.

6. If the HTTPS URL does not work: change that phone to the HTTP URL for its brand (on Polycom, also change the server type to HTTP) and reboot again, then re-check the three items above.

   • If it works on HTTP, that model does not handle HTTPS properly. Use HTTP for that model, and please tell us the brand, model, and firmware version. We will recommend a firmware update or a replacement.

   • If it fails on HTTP as well, stop — set the provisioning address back to the previous value, reboot, and contact us before going any further. Include the phone's brand, model, firmware version, and what you saw on the screen.

2. If you have more than one phone brand or model, test one of each

Repeat step 1 with one Polycom and one Yealink phone, each using its own URL. If you have several different models of the same brand, test one of each model too — HTTPS support varies by model and firmware, not just by brand. Do this before rolling out.

Keep a short note of which models ended up on HTTPS and which needed HTTP. You will need it for the rollout, and for your DHCP settings if you use DHCP.

3. Roll out to the rest of your phones

Only after your test phone(s) are confirmed working.

If you use Method A (address set per phone): update the remaining phones the same way you updated the test phone — HTTPS URL for the models that passed on HTTPS, HTTP URL for the models that needed it — and reboot each one. Work through them in batches so you can stop if something looks wrong.

If you use Method B (DHCP): change the provisioning address wherever it is currently set in your DHCP server to the new URL, then reboot the phones so they pick up the new value. You are editing an existing setting, not adding a new one.

Three cautions for DHCP:

• One DHCP value cannot cover phones that need different URLs. Your phones may need different URLs for two separate reasons: brand (Polycom vs Yealink) and whether the model supports HTTPS. Each distinct combination needs its own value. Practical approach: use DHCP for the largest group and set the rest directly on the phones — or, if your DHCP server supports handing out different values per subnet or per device type, configure it that way.

• Some older phone firmware does not accept an HTTPS URL by way of DHCP even when the phone handles HTTPS fine once the URL is set in its own web interface. If a model tested successfully on HTTPS manually but fails after you move it to DHCP, set that model's URL directly on the phone instead.

• Double-check the address for typos before saving. A wrong address here affects every phone on that network.

Things worth knowing

A wrong address often fails silently. A phone that cannot reach its provisioning server usually keeps running the configuration it already has, so it may appear fine for days and then fail the next time it restarts. This is the reason we ask you to test one phone with a deliberate reboot rather than assuming a change worked.

Rolling back is simple. Put the previous provisioning address back and reboot. Nothing else needs to be undone.

If a phone has the right URL and still will not provision. A small number of phones — usually ones that have been in service a long time — may need a factory reset before they will pick up configuration from the new system. Please treat this as a last resort, and only after you have confirmed the same URL works on another phone of that model:

• A factory reset erases the phone's local settings, including its network configuration.

• Have the correct provisioning URL written down before you reset, because you will need to enter it afterwards.

• If the phone relies on your DHCP server for its provisioning address, make sure that value has already been updated, or the phone will come back up pointing at the old address.

• Do this on a phone that can be out of service for a while, not on someone's only handset.

If a reset does not fix it, stop and contact us.