Implementing IP Telephony on a Campus: The good, the bad, and the ugly MiCTA 2005 Spring Conference Brenda Helminen, Director, Telcom Engineering

In the beginning… (Spring 2000) Centrex service (~ 2000 lines); contract ending June 2003 A la carte pricing model; LD revenue covered trunk costs, etc. Phone set inventory fully amortized Converged network/telephone staff Little inter-building copper cable plant Robust data network & physical infrastructure

In summary MTU already doing video over IP. IP technology fit our strategic goals. MTU was in a good position to leap frog classic PBX technology if IP telephony was mature enough to implement. The primary goals of this project are to stabilize the cost of telephone service for campus and to enhance the business support functionality of our telephone service. memo to campus October 2002

Intuition strong that …. Managing one physical/datalink infrastructure would significantly reduce cost of all end user/edge management tasks (work order processing, device configuration, troubleshooting, monitoring) while increasing the reliability, functionality, and integration of all the services provided.

Anticipated Technical Challenges Voice quality on packet-based network Power to IP phones Power fail plan E911 compliance Vendor support

Timeline Initial Plan: Dont do anything dumb, but try to finish before Centrex contract end date of June 2003 For a variety of technical reasons, we did not start converting departments until early Availability of PoE-standard equipment was a major factor. (aka Plan B) Pricing model redone – (7/2002): LD covers LD call costs, bundled common options

Timeline (cont)

Bottom line? Technology has been mature enough to deploy for last year or so. IP-enabled voice applications now available which may entice customers off legacy PBX systems. Many of the legacy PBX vendors have migration strategies to IP systems to ease transition.

Planning Considerations Power for phones (preferably from closet) Backup power (UPSs, generator?) Type and availability of jacks Feature-rich network switches Hardware failover plan Robust DHCP, Directory (LDAP) services

What did we learn? Separating voice traffic critical (restricted VLAN). Network switches uplinks must not be excessively over-subscribed (4:1 to 8:1) RSTP (Rapid spanning tree) necessary for transparent network failover There will still be network issues that affect telephone service

More lessons Technology is still young and evolving. So, think of this less as a project and more as a lifestyle change. 3 nines uptime for phone sufficient. Keep your amortization periods short – 3-5 years for all components. Network switches that support PoE save space, cables, and hence cost. They work great, too.

Operational lessons All work orders are minor variations of the same basic process. One technician on our campus can do all network and telephone work orders. Troubleshooting has become more standardized. Less test equipment needed. Services to remote sites cost effective with no reduced functionality.

Management & Monitoring Still have engineers dedicated to PBX programming. Have been able to combine network monitoring & configuration software/tools with telemanagement system rules to reduce manual device configurations (and errors). Network ports get software-configured from telemanagement system.

Web / Database reports

Cricket perf graphs

Financial Planning Built an extensive financial model of the system. Borrowed money to fund upfront equipment expenses. Model facilitates continuous re- investment/upgrades to the various components of the system. Costs have reduced since initial calculations.

Rate Model

And the ugly? Lots of spreadsheets showing whos saving money and whos not. Slow deployment leaves lots of room for the naysayers to exploit. Guard against mission creep – as finances have tightened goal moved from containing costs to saving money. Trying to keep enough resources on the project to complete it eventually.

Spreadsheets…

More spreadsheets

And more spreadsheets

More information…