IP Phone Auto-Provisioning
A significant part of the setup of any IP phone system is provisioning the phones themselves. “Provisioning” is essentially the creation and management of the configuration files that define phone settings. Every phone’s setup will be just a little different, reflecting each as a unique extension, referencing a specific user’s voicemail, contact list, etc. Provisioning is a very detail-oriented task and typically the domain of a consultant or installer.
Every manufacturer uses a slightly different provisioning scheme. Some use a TFTP server to dole out text-based configuration files, while others use FTP or HTTP to serve XML-based configuration files. Phone firmware is also typically distributed via the provisioning server, making it a simple matter to upgrade the firmware on a number of phones at once.
Auto-provisioning one aspect of the Jazinga system software that really stands out. The box is a very capable provisioning server. It uses its vantage point on the network as DHCP server to automatically create and distribute provisioning details to the phones.
In my case, I plugged a couple of Polycom SoundPoint IP430 desk phones into the system and gave each one a reset keystroke (1, 3, 5 & 7) to restore it to factory fresh status. On reboot, each phone took an IP address from the DHCP server then automatically loaded new Boot ROM and firmware images from the Jazinga server.
Finally, the Jazinga system handed out the operational configuration for each phone. When the process was completed, the phones had extensions and were ready to be assigned to users. It was truly slick and utterly painless.
The system supports auto-provisioning of phones from a number of leading manufacturers including;
- Linksys SPA-94x, SPA-92x
- Polycom SoundPoint IP Series
- Snom 3×0 Series
- Snom m3 SIP/DECT Cordless
- Sipura/Linksys SPA-2xxx series ATA’s
If you have an IP phone that is not directly supported, you simply assign it to be the “soft phone” type while setting up the device. This defeats any kind of provisioning for that phone.
While Jazinga isn’t the only Asterisk-based system to support auto-provisioning, I was very impressed that the process worked as smoothly as it did. This eliminates a major headache for the non-technical user.
It would have been nice if the system had included power-over-ethernet (POE) capability in its switch to support IP phones. In combination with a good UPS, this would ensure that Jazinga could ride out minor power outages. Of course, a larger switch will be required in many installations, so PoE could be added externally if required.
From its vantage point as the network router, Jazinga is able to support VoIP not only as the Asterisk host, but also by ensuring quality of service (QoS) for VoIP traffic passed to remote ITSPs. In fact, QoS for VoIP traffic is automatic and cannot be defeated.
Prioritization of other network traffic can be established using the Internet> QoS menu on the web interface (Figure 7). The minimum setup requires only that you define the measured maximum upload and download data rates provided by your ISP.
Jazinga’s one analog line interface (FXO) provides local Telco line access for local calling or as a failover line should IP connectivity be lost. Access to a local analog line can be critically important as a means of accessing 911 and 411 services.
The two built-in analog station interfaces (FXS) provide support for two analog extensions. These are often used to support FAX capability and cordless phones.
With only the one analog trunk interface Jazinga is clearly intended to leverage IP trunks from VoIP services providers. Since it’s Asterisk at its core, Jazinga supports IP trunks using either SIP or IAX2 protocols. Both types are easily set up, although since Jazinga is its own firewall, there may be little incentive to choose IAX2 over SIP.
Jazinga has made no special effort to provide fax capabilities. That said, a fax machine connected to one of the FXS ports would work perfectly fine as long as it used the analog trunk for all its calling.
Fax over a VoIP trunk can be hit or miss. Some people report good results when using G.711 encoded calls, while others have nothing but problems. In truth, newer standards for sending Fax-over-IP (T.38) have evolved. But hardware support for this is still somewhat limited.
If fax is a concern to anyone considering Jazinga, the simplest and most reliable thing to do is provide a dedicated analog line for the fax machine, or use a fax-to-email gateway service. That could eliminate the need for a fax machine entirely.
By happy coincidence, a new Wi-Fi SIP handset arrived just days before I set up the Jazinga system. This gave me a testbed with which to revisit voice-over-wifi (VoWifi or VoWLAN), something that I’d pretty much given up in favor of DECT cordless phones.
The pair worked reasonably well in cursory testing, although with considerably shorter range than my DECT cordless phones. The WMM feature of the Jazinga Wi-Fi interface seemed to work. Calls from the Wi-Fi phone did not suffer breakup even as I downloaded a large suite of files via FTP over the Wi-Fi.
At no point in my use of Jazinga did the term “codec” ever come up. So I asked the manufacturer and confirmed that the system operates exclusively in G.711. This is good from the standpoint of call quality and maximizing the number of concurrent calls supported by the hardware. With no possible transcoding between codecs, the CPU load is light.
However, the higher bandwidth requirements of G.711 may limit the number of calls that you can pass over a limited bandwidth connection. This is typically a function of the maximum allowable upload speed, emphasis on the “Asymmetrical” in ADSL. At 80 Kbps per call, some lower speed (256 K) DSL connections will support only a couple of simultaneous calls.
When asked about broader codec support, the manufacturer responded that it could be possible in the future if they see enough demand from their users. They expressed some concern about the possible cost and complexity of licensing patent-protected low bit-rate codecs like G.729a.
As was described in my earlier Astlinux article, transcoding to and from compressed codecs is processor intensive. The 500 MHz Geode in the Jazinga device could likely handle only five or six simultaneous transcodes. So the bandwidth savings might not yield much real-world benefit.
Technical minutiae aside, it’s easy to see how Jazinga could easily support a small office with perhaps a dozen phones and four to six trunks. The only issue would be ensuring adequate bandwidth to sustain the IP trunking. Six active trunks would need roughly 512 Kbps in each direction, well within the capabilities of mid-range DSL or cable modem service.
I encountered a couple of minor issues during set up and contacted Jazinga for help. They were immediately able to access the box remotely and provide assistance. And while they were accessing the system, performed a software update as well. The problem I faced turned out to be at the provider end of a VoIP account. Jazinga’s support staff were clear and helpful, making the whole experience painless.
In many ways Jazinga is the ideal customer premises equipment (CPE) for a VoIP service provider or reseller targeting small businesses. It’s entirely self-contained and can be used stand-alone, yet could also be the platform for various services. For example, an online reseller or ITSP might sell a 24/7 technical extended support knowing that they have secure yet convenient remote access to standardized on-site equipment.