Posted: 01/2005

8 Tips for Transitioning to IP Telephony
By Christopher J. Kearney

There is much to consider when planning for an IP telephony deployment — from business requirements, to product evaluation and vendor selection, etc. However, there are many process issues that will require some effort and attention regardless of the product or vendor selected. This article contains a brief list of issues that are typically overlooked, often to the detriment of overall deployment success. Many may seem obvious, but they are forgotten nonetheless as technical details consume a project team. While not comprehensive, what follows is a short list that can help keep a project on track while decreasing the likelihood of unpleasant “surprises” along the way.

1. Develop an understanding of the proposed architecture as early as possible. There are many different solution architectures currently promoted among vendors, including variations of pure IP and TDM/IP hybrid, in both centralized and distributed models. The specific solution architecture will drive infrastructure requirements, equipment requirements and other project dependencies. Developing an understanding of the proposed architecture is a necessary early step in any successful IP telephony project. It is entirely possible to lose sight of the architecture and its implications when point products become the focus and granular discussions of the relative merits of one box or another consume the project team. It is imperative that someone on the project team stay focused on the overall solution architecture, and the implications of that architecture on the overall project.

2. Remove ambiguity and define expectations early in the project lifecycle. Many IP telephony projects include the end user, manufacturer and at least one systems integrator. Taking the time to develop a specific delineation of project responsibilities and detailed descriptions of expected project deliverables can reduce the stress and conflict that can arise from misunderstandings among the project team regarding project goals and responsibilities. This is another effort that may appear to be a make-work exercise, but the value of this effort cannot be overestimated. IP telephony projects have many moving parts and parallel tasks by their very nature. Removing ambiguity and defining expectations early in the project lifecycle benefits all participants and promotes a successful completion to the project.

3. Take a holistic approach to traffic engineering. Sizing the converged network requires a complete understanding of the traffic load. This includes existing data traffic, and the load represented by voice traffic migrated to the data network. The architecture of the proposed solution may have significant impact on voice traffic patterns. Quality of service will become a critical concern, most obviously in WANs, but also in LANs to some extent. If historical voice traffic data is available, it may be possible to use traditional voice traffic engineering tools such as Erlang modeling to predict voice traffic loads. However, when an organization is migrating from a voice architecture of distributed, isolated PBX systems, to a centralized IP telephony model, the change in architecture will significantly reduce the usefulness of the historical data. This may require review of the historical data coupled with an effort to apply the applicable data points into a model that reflects the proposed architecture. This exercise can produce results that may be significantly less accurate than desired, and it may be necessary to monitor the traffic post-cutover to ensure that delivered solution supports the actual traffic load.

4. Inventory features required by actual users. Once focused in on the technical properties of a proposed solution, it is easy to forget that to the user community, the phone is one of their most important tools, and the current phone system may provide features that they find indispensable. Features and their relative importances often vary with job function. Therefore, the IT staff may not have an innate understanding of the relative importance of specific features to the user community. User feature requirements are overlooked at great peril to the overall project, in fact it is entirely possible to have an IP telephony project that is technically flawless, yet still considered a failure because the user expectations were not met, and the ability for users to perform their job functions were compromised.

5. Identify all devices peripheral to the existing phone system. Legacy devices, such as recorded announcement devices (RAN), interactive voice response units (IVR), automatic call distribution units (ACD), automated attendants, readerboards and other peripheral devices may be found integrated to an incumbent PBX. Such devices may be easily overlooked unless a detailed inventory of the current state of the voice facilities is performed early in the project lifecycle. It is imperative to identify all existing devices, catalog their functions, and plan to replicate those functions in the proposed solution.

6. Identify all voice circuits connecting to the existing phone system. A detailed inventory of current voice facilities should identify all telco circuits currently in use; circuits should be cataloged by type (T1- CAS, T1-PRI, Ground Start, Loop Start, etc.), circuit ID, provisioning detail and carrier. All direct-inward dial (DID) number ranges must be identified and cataloged. All toll-free numbers must be identified, along with their methods of termination including DNIS values if provided. This information should be collected and verified early in the project lifecycle, as it is vital to the success of any IP telephony migration.

7. Test required interoperability. Take nothing for granted. It is a common desire to retain legacy equipment during an IP telephony deployment; either as part of a staged migration, or to retain a feature or function provided by a specific device. The effort of testing interoperability may appear onerous at first glance, but considering that a common set of supported standards does not guarantee complete interoperability of specific features, it is an extremely important exercise. Identify the key functions of the device to be integrated, create a test plan that validates these functions and perform the testing. This is the only guarantee that the desired level of interoperability will be supported.

8. Identify required skillsets for ongoing maintenance/management. A successful cutover is a good start. A company that has merged its voice and data networks must be organizationally equipped to manage that converged network going forward. Many organizations still maintain separate voice and data teams, under separate management, competing for budget and headcount. Transforming this into a single team with the skills and resources necessary to support a converged voice and data network requires planning and dedication. It is highly desirable to begin the organizational changes upfront by building a crossdisciplinary team to drive the IP telephony project. This team can become the genesis of the converged IT structure needed going forward to manage and support the converged network successfully.