Telemanagement editor and industry analyst Stefan Dubowski attempts hands-on IP-PBX education, and learns it’s not easy for newbies. Telecom expert Roberta Fox provides the training, and learns that teaching isn’t straightforward. What follows are the “student’s” and the “teacher’s” accounts of this informative exchange.
The Student’s Account – Stefan Dubowski
Well, I asked for it: a hands-on education in IP-PBX/ key system deployment. And Roberta Fox, head of Fox Group Consulting in Mount Albert ON, was kind enough to take me on as an apprentice while her company installed its own IP-PBX. During this time I would learn that no matter how “easy” vendors say it is to set up a phone system, it’s hardly foolproof for the novice.
My participation in the Fox Group project was basic: help pull and dress LAN cables; plug them into the switch; and configure IP phones. In performing these duties I gained a new level of respect for Telemanagement’s readers, many of whom have been there and done that.
So, what did I learn?
Software Sell
“This isn’t the same as I’m used to,” Roberta said, huddled close to the computer screen. She was troubleshooting a problem on one of the phones – a telework set to be shipped to one of the Fox Group’s offsite associates. We couldn’t reach it by dialling its extension number from the other sets. At the workstation, Roberta hunted through the IP-PBX’s GUI, searching the menu and folders for the proper input screen. But the folder names didn’t intuitively correspond to the functions they held.
After some time, we realized our error: we assumed that the VoIP system would connect all remote “hard” phones in extension-to-extension calls with the original equipment. But because the phone system acts more as a key system than a full-fledged PBX, it doesn’t provide direct links to remote IP telework sets, unless you add VPN hardware on both ends of the connection.
Meanwhile, I came to a conclusion: network gear vendors need to make their GUIs easier to use. This is important. The likes of Avaya Inc., Cisco Systems Inc. and Nortel Networks say voice-network gear isn’t about hardware anymore. It’s about software. Marketing messages suggest the vendors want to put their products in a category that includes, say, Microsoft Corp.’s applications. Many vendors plan to decouple their IP-PBX software from the hardware and sell the app alone.
But this puts network vendors on a collision course with Microsoft, which is adding voice to its programs. Microsoft will compete with IP-PBX firms in software, where Microsoft has the upper hand. IT professionals understand Microsoft’s idiosyncrasies. That’s not the case with IP-PBXs. Unless IP-PBX vendors make their apps easier to use, IT managers will chose Microsoft every time.
What Interoperability?
Take an IP phone from one vendor. Attach it to a carrier’s hosted IP phone service. Filter the service through another vendor’s IP-PBX. What do you get? Annoyed.
The Fox Group tried it. The consultants like to test every scenario. When the original configuration didn’t work, they decided to bypass the IP-PBX and connect the hosted service directly into the switch. That did the trick, but the first plan didn’t click. Why not?
Despite claims that their equipment interoperates, network vendors have not discovered the magic middleware to bring their individual products together. Numerous groups are working on the SIP protocol – maybe too many to hope for a single standard to emerge. That said, Ed Mier, founder of network test house Miercom, noted in a July 2005 Business Communications Review article (“SIP: Getting There From Here”) that the various organizations steeped in SIP development are all working on specific parts of the protocol, so hope yet springs for interoperability.
Configure This
On to phone programming. Bill Elliott, one of Fox Group’s directors, handed me a sheet of paper listing 18 steps detailing the numbers to punch into the phone to make it work. “This is supposed to be user-configurable,” he said.
It took me five minutes to do the first phone. When it didn’t work, I had to go through the steps again and make sure I’d punched in the right figures. (I hadn’t.) I sped up as phones two, three and four came under my purview, but whatever happened to plug-‘n’-play? One of the selling features of IP-PBXs was supposed to be phone configuration simple enough for anyone. But an IP phone is a data-network element. And like most data-network elements, the phone must be taught what to do. Configuration missteps are inevitable if companies expect end users to do it themselves.
Conclusion
I embarked on this IP-PBX journey so I could claim that I have hands-on experience. But after a few weeks at this, I don’t feel particularly educated. I just feel I have a lot more to learn.
The Teacher’s Account – Roberta Fox
When Telemanagement’s editor Stefan Dubowski asked about participating in our upcoming VoIP installation project (associated with our move to Mount Albert ON), we discussed it as a team. We considered: “Stefan writes about this stuff, so how and what do we need to teach him? How much time is it going to take us? Where do we start? How deep do we need to go to help him understand?”
Our Approach
We decided to start by giving him an overview of the various technologies that we would be installing, and how they all fit together. This involved sharing the overall voice, data and video architecture for our two-building campus and how the buildings would be interconnected. The session took about three hours, delivered by me and Stephen Lawson, VP operations and technology. I covered the voice and data architecture. Stephen covered the Internet and computing topics. There was plenty of back and forth discussion with our “student,” who seemed eager to make sure that he understood how things “all fit together.”
The New Installation
The first phase involved removing the previous IP phone system and Ethernet switch and re-connecting the Cat 6 Ethernet cables to the new switch. Prior to disconnecting the previous system, Stefan helped us update our documentation so we could match the specs on the new system.
We labeled all cables at both ends prior to unplugging them so we would be able to easily reconnect them. We also shared the basics on cable installations and explained the theories of “dressing” cables and proper cable management including cable lengths, bend radius, cable tying techniques and other fundamentals that many vendors and suppliers don’t understand. (Both Stephen and I were field engineers in our earlier careers and had completed many voice, data network and computer system installations in the ‘80s and early-‘90s).
We then swapped out the previous IP phones with the new ones and configured them for each user. (The replacement VoIP system was installed by one of our vendors with assistance by our fellow consultant Linda Hunter of Sudbury who did the call centre software portion of the installation). We re-routed all carrier services including moving equipment and cabling so that everything would be in line with common engineering guidelines, including labelling each piece of equipment as to its use, and applying reference numbers to help with future troubleshooting. Lastly, we updated our documentation on the master blueprints as we went along so we would have complete and accurate documents once we were finished.
Lessons Learned
The first lesson was that it was critical to have documentation and diagrams in addition to discussing the various technologies to help teach someone, especially when your student is not a techie.
The second lesson: IP telephony requires detailed voice, data and IT knowledge. Doing the installation and teaching Stefan made us realize how much detailed experience we had in many areas, and in fact had forgotten from our hands-on days.
The third lesson involved configurations. Both the system and the phone set configuration steps were too complicated and written i
