What provisioning is
A desk phone is a small computer that has to be told a great deal before it can make a call: which server to register with, which extension number and password to use, the time zone, the codecs it may use, and what each of its line and function keys does. Typing all of that into a phone's keypad is slow and error-prone, and it means the SIP password is handled by whoever sets up the phone. Provisioning is the alternative: the phone fetches a configuration file from the phone system over the network and configures itself.
The mechanism is simple in outline. Every phone has a unique MAC address printed on a sticker underneath it. When the phone starts, it is told where its provisioning server is, either from the DHCP server using option 66 (so every phone on the network finds the server automatically) or from a setting typed once into the phone's own web page. The phone then asks the server for a file named after its MAC address. The server, knowing which extension that MAC belongs to, writes a file in the format that make of phone understands, containing the account, the keys and the settings, and the phone applies it and registers. From then on the phone's line keys show who is on the phone and nobody has touched a password.
The economics are the whole point. A business deploying ten phones might set them up by hand once; a business deploying two hundred, or an installer fitting out an office a week, cannot. Provisioning turns the deployment of a hundred phones into the deployment of one, repeated: the work is in getting the first phone right, and the rest follow the same path. It also centralises change. When a codec preference, a time zone or a set of busy-lamp keys changes, the phones re-fetch their files and apply the change, rather than someone walking from desk to desk. And it keeps the SIP password out of human hands: the password is generated by the phone system, written into the file, and never typed by an installer who might write it on a sticky note.
A phone coming to life
You unbox a Yealink, read its MAC address off the sticker, and add it on the phone system against extension 100. You set DHCP option 66 to the server's provisioning address once, for the whole network. You plug the phone in. It boots, asks DHCP where to provision, fetches MAC.cfg over HTTPS, finds its account and its busy-lamp keys inside, registers as extension 100, and its screen lights up with the line and the colleagues it is set to watch. The second and the hundredth phone need no extra work: each finds the server, each fetches its own file.
Where provisioning goes wrong
HTTP versus HTTPS. Phones should fetch their files over HTTPS, but some older phones cannot use HTTPS at all, and many do not trust a certificate the phone system generated itself. Falling back to plain HTTP sends the SIP password across the network in the clear, which is fine on a trusted office LAN and a risk anywhere else.
Wrong option 66 or firmware. If DHCP option 66 points at the wrong place, or a phone is running an incompatible firmware (enterprise firmware where multiplatform is needed, for example), the phone never finds or never applies its file.
Format drift between models. Each maker has its own file format, and formats differ between model ranges and firmware versions, so a file that works on one Yealink range may not on another.
Untested models. A format written from a maker's documentation is not the same as a format proven on the maker's actual hardware; the two usually agree, but not always.
How BitVoice does it
On Phones you press Add phone, enter the MAC address and the extension, and choose the make. BitVoice tells the phone where it is, either through DHCP option 66 or through the address shown on screen typed into the phone's auto-provisioning page. The phone fetches its file over HTTPS, signs in, and its keys show who is on the phone. The file carries the extension and its password, the time zone, the codecs, the busy-lamp keys and the server's address, and provisioning is protected by a username and password the phones are given once.
For phones that cannot use HTTPS or do not trust BitVoice's self-made certificate, the screen also shows a plain http:// address on the same port, used only for these files; every other page stays on HTTPS. Over plain HTTP the SIP password crosses the network unencrypted, so you keep it to a trusted network or install a certificate from an authority and switch on HTTPS only for phones.
The makes with models that have been tried on real hardware are Yealink (T3x, T4x, T5x), Poly (VVX, Edge E), Grandstream (GRP, GXP and the HT802/814 analogue adapters, with an account per port) and Snom (D7xx), each getting its account, busy-lamp keys, time and codecs in its own format. The following makes are provisioned too, from each maker's documented format but not yet tried on their devices, and the Phones screen marks them untested: Fanvil (X and V series), Cisco (6800, 7800, 8800 multiplatform and SPA adapters), Mitel/Aastra (6800, 6900 SIP), Sangoma, Algo and CyberData.
Around provisioning sit the features desk phones are bought for. Busy lamps (BLF) let a key on one phone show whether a colleague is on a call and dial them with a press; these keys are written into the provisioning file. Hot desking (*33) lets a person sign in to any phone and have it become their extension, so shared desks and shift work need no dedicated phones. Paging sends an announcement to a group of phones or to overhead speakers, with the phones auto-answering onto their speakers. Phones that do not speak SIP at all, older Cisco phones running Skinny and gateways driven by MGCP, are handled separately and covered in the legacy-protocols article.
These features lean on provisioning because they depend on the phone being configured, not merely registered. A busy lamp only works if the phone was told which extension each key should watch, and that instruction travels in the provisioning file alongside subscriptions the phone then raises to the server. Hot desking changes which account a phone presents without re-provisioning it, so a shared phone fetches a neutral file and takes on a person's identity at sign-in. Paging needs the phone to accept an auto-answer instruction, which again is a provisioned setting. Getting the provisioning file right is therefore not only about the first registration; it is what makes the day-to-day behaviour of the phone match what the organisation expects.
Why BitVoice fits
Provisioning, BLF, hot desking and paging are all configured in the web interface, and the provisioning server is part of the one Go binary, so there is no separate TFTP or HTTP provisioning service to run. Against FreePBX, which provisions phones through its endpoint manager and commercial modules for some makes, BitVoice provisions the four big makers from the core product at no cost and under Apache-2.0, and it is candid about which makes are proven on real handsets and which are written from documentation. The honesty is deliberate: the screen itself marks the untested makes.
What has been tested, and what has not
Provisioning is software-tested: the files are written to each maker's documented format and checked by BitVoice's own tests, but have not been applied to real handsets. This holds for every make, including Yealink, Poly, Grandstream and Snom, whose model ranges are listed above from the makers' documentation. Real Yealink, Poly or Grandstream handsets have not yet been tried on a live network; Asterisk has stood in as a desk phone across the internet to prove the SIP side. The browser phone, which needs no provisioning, is field-tested, and the Android app is field-tested on a real device. In short, the SIP registration and calling that a provisioned phone would perform are proven; the exact provisioning files on the exact handsets are the piece that still needs real hardware.