Reflecting back over the past year on the significant implementation issues that we addressed over time by patience, luck or persistence, it's safe to say that regardless of what you elect as a telephony solution, there's nothing standard about what awaits you in the field. One expert, two experts or more just don't have all the answers.
Case in point: In late summer, we started implementation of a beta PBX. Progress on the project was seemingly fast--using the onboard discovery tool to implement telephones was just too cool. Then a snag jammed any further progress--there seemed to be an issue with the product:
A significant task in any PBX deployment is the button programming of desktop telephones. Buttons are real estate and whatever anyone thinks or tells you, they are indeed important, and without them, you don't have the equivalent of F-Keys or shortcuts as you do on your computer keyboard. Sure, you can argue you don't need them since you have a UC client running on your desktop--but don't assume that UC clients don't have buttons, because they do. But in this deployment, it turned out that no buttons--physical or virtual--could be programmed.
We traced our efforts backward for the folks at the factory, detailing what software changes we made leading up to the discovery that we could not program the buttons. We attempted programming from different desktops, using different browsers and versions--same result. We backed up the system database and ported it to the factory's system, and they could find no issue. We ran continuous pings between VLANs just to see if there was something disrupting traffic--and there wasn't. The IT administrator insisted that the firewall was allowing all traffic between VLANs.
What we didn't do first was simply remove the PBX from the network and attempt programming. That was our key mistake and assumption--that the network wasn't the issue. After boxing the system up and returning it to the factory guys, we set the new system in place, restored software and again attempted button programming (connected to the network).
Failure!
Keep in mind, when we worked on this site it was after hours so as not to disrupt the customer. We already put in weeks of work through the day on other jobs, then spent more hours after business hours to work on this beta site. You can imagine what happens after long hours and during long days.
In any case, the second mistake we made was not simply doing a packet trace. So before you start thinking that we must be involved in some after-hours fun or misguided activities, let me assure you that we simply frequented an all-night diner for grub and coffee, to commiserate over our problems.
Again we had discussion with the IT administrator about the firewall, and having had some past experience with this brand, I asked him to check his logs. Firewalls do edge patrolling to keep the bad guys out, but they also do inside work to prevent users from visiting infected sites, downloading malware and partaking in online activities that the employer or organization forbid.
Cracking a smile, the IT administrator proclaimed that our system was involved in "Sex and Nudity" and thus the source of our difficulty--it turned out that the real issue was, he forgot that "content" and "keyword" filtering was activated on both networks. The firewall detected the words: Extensions-Flexible Buttons. So seemingly the PBX was flagged for s-e-x web activities. After removing both content and keyword filtering from the PBX (VLAN2) we could then program telephone buttons using any desktop or browser (VLAN1).
The marketing folks always say that "Sex sells." If they're right, then this PBX should really rack up the sales.
