What the work looks like
Four situations of the kind we are called into, told from start to finish: what was wrong, what we did, and how it ended.
Illustrative scenarios. They show the kind of work we do and are not accounts of specific clients.
A regional hospital
One call in twenty failed, and every vendor blamed another
The situation
Nurses calling patients' families heard a fast busy signal about one time in twenty. A second attempt usually worked. The carrier found nothing wrong on its side, the gateway logs showed calls leaving normally, and the ticket had been open for six weeks.
What we did
- We captured failing and working calls at the gateway and lined each one up with the carrier's own record of the same call.
- Side by side, the failures had one thing in common: they all left through the second of two carrier-facing gateways. It carried only overflow calls and, since an upgrade the year before, had offered a list of codecs the carrier rejected.
- We corrected the configuration, placed test calls through each gateway in turn, and left the hospital's engineers with the comparison and the method.
How it ended
The failures stopped. The hospital's team had the evidence to close the ticket with the carrier, and a repeatable way to compare a bad call with a good one the next time.
About voice and collaborationThe tool we used: CollabPlane Workbench
A state agency
The cloud calling migration nobody could size
The situation
The phone system had grown for fifteen years under four administrators. The project had a budget and a deadline, and the only inventory was a spreadsheet of users. Nobody could say how many fax lines, door phones, hunt groups or shared lines existed, or who depended on them.
What we did
- We inventoried the system itself: every device, line, group, forwarding rule and analog port, and sorted each into what would move as it was, what needed a decision, and what could be retired.
- The inventory surfaced the items that fail on cutover day: analog lines for elevators and alarms, a paging system, and two departments sharing one main number.
- We migrated in groups, starting with a small one that contained one of everything, and verified calling in every direction before each next group.
How it ended
The agency cut over in stages, each with a documented way back, and ported its numbers last. The items that usually surface as user complaints were found by the project team and settled before any user moved.
About voice and collaborationThe tool we used: CollabPlane Vector
A multi-site business
The new firewall that broke the phones every afternoon
The situation
The firewall project had gone well by every security measure. Two weeks later the help desk was taking daily complaints about call quality from the branches. The security team saw no blocked traffic. The voice team saw nothing wrong with the phone system.
What we did
- We followed a single call across the path: phone, branch switch, WAN, firewall, data center.
- Two things had changed with the new firewall. The priority markings that protect voice on a busy link were being reset as traffic crossed it, which caused the afternoon audio problems. Separately, its SIP inspection was rewriting part of the call setup, which explained the dropped calls.
- We adjusted the inspection settings for the voice traffic, restored the markings end to end, and documented the rules so the next firewall change would keep them.
How it ended
Call quality returned at the branches without weakening the security policy. The security and voice teams now share one document that describes how voice crosses the firewall.
About network and security
