This document provides an overview of migrating to a Cisco Unified Communications system from a legacy phone system. It discusses deployment models including single-site, centralized call processing, and distributed call processing. It also covers migration options like phased migration and parallel cutover. Key application examples covered include Cisco Unified Mobile Communicator and WebDialer. Planning considerations for implementing Unified Communications Manager such as network infrastructure, dial plan, and user requirements are also outlined.

1. Migration to Unified Communications from Legacy Phone Systems Cisco Centric High Level Discussion Topics Jack Brown -- June 16th, 2009

3. Overall Costs Down Today’s Silo’ed Communications Integrated Communications Fundamentally UC is About Services and Applications Convergence Focused Here From an Enterprise Perspective Jack Brown -- June 16th, 2009 Voice Mail Enterprise Telephony Audio Conference Web Conference Video Conference E-Mail & Instant Messaging Separate Management E-Mail + UM Instant Messaging Enterprise Telephony Conferencing Platform Unified Experience Common Management

5. Representation Of Cisco’s Unified Communications Application Control Planes Jack Brown -- June 16th, 2009

6. Cisco Unified Communications Deployment Models Jack Brown -- June 16th, 2009

7. Jack Brown -- June 16th, 2009 Cisco IP Telephony Implementation Overview

8. Jack Brown -- June 16th, 2009 Cisco Defined Typical Unified Communications Deployment A Cisco defined typical Unified Communications deployment employing the Cisco IP network infrastructure, with Cisco Unified Communications Manager (Unified CM) as the call processing agent. Survivable Remote Site Telephony (SRST)

9. The single-site model for Cisco Unified Communications consists of a call processing agent cluster located at a single site, or campus, with no telephony services provided over an IP WAN. An enterprise would typically deploy the single-site model over a LAN or metropolitan area network (MAN), which carries the voice traffic within the site. In this model, calls beyond the LAN or MAN use the public switched telephone network (PSTN). Single-Site Deployment Jack Brown -- June 16th, 2009

10. Jack Brown -- June 16th, 2009 Deployment Models - Centralized Call Processing The model for a multisite deployment with centralized call processing consists of a single call processing agent cluster that provides services for many remote sites and uses the IP WAN to transport Cisco Unified Communications traffic between the sites. The IP WAN also carries call control signaling between the central site and the remote sites

11. Jack Brown -- June 16th, 2009 Deployment Models - Distributed Call Processing The model for a multisite deployment with distributed call processing consists of multiple independent sites, each with its own call processing agent cluster connected to an IP WAN that carries voice traffic between the distributed sites

12. Jack Brown -- June 16th, 2009 Deployment Model for Tier 1 Sites

13. Jack Brown -- June 16th, 2009 Deployment Model for Tier 2 sites

14. Jack Brown -- June 16th, 2009 Deployment Model for Tier 3 sites

15. Jack Brown -- June 16th, 2009 Deployment Model for Tier 4 sites

16. Jack Brown -- June 16th, 2009 Migration Options

18. Jack Brown -- June 16th, 2009 This approach typically entails a small initial IP Telephony deployment that is connected to the main corporate PBX. The choice of which signaling protocol to use is determined by the required features and functionality as well as by the cost of implementation. Cisco Unified Communications Manager (Unified CM) can support either regular PSTN-type PRI or QSIG PRI as well as H.323 and SIP. Of these options, T1/E1 QSIG provides the highest level of feature transparency between the two systems. Phased Migration

19. Jack Brown -- June 16th, 2009 Call Flow for an Existing Nortel PBX Telephony Phased Migration

21. Jack Brown -- June 16th, 2009 Call Flow for users Migrated to Cisco IP Telephony

22. Jack Brown -- June 16th, 2009 Phased Migration A campus, consisting of some 23,000 subscribers housed in approximately 60 buildings, was migrated to IP Telephony in this manner and took just over one year from start to finish. They converted one building per weekend. All subscribers in the selected building were identified, and their extensions were deleted from the PBX on a Friday evening. At the same time, additions were made to the PBX routing tables so that anyone dialing those extension numbers would then be routed over the correct PRI trunk for delivery to Unified CM. During the weekend, new extensions were created in Unified CM for the subscribers, and new IP phones were delivered to their appropriate locations, ready for use by Monday morning. This process was simply repeated for each building until all subscribers had been migrated.

26. Jack Brown -- June 16th, 2009 Parallel Cutover Once the IP Telephony system is fully deployed, you can select a time slot for bringing the new system into full service by transferring the inbound PSTN trunks from the PBX to the IP Telephony gateways. You can also leave the PBX in place until such a time as you are confident with the operation of the IP Telephony system, at which point the PBX can be decommissioned.

27. Jack Brown -- June 16th, 2009 Parallel Cutover

28. Jack Brown -- June 16th, 2009 Parallel Cutover Pros for a Parallel Cutover • If something unexpected occurs, the parallel cutover provides a back-out plan that allows you to revert to the PBX system by simply transferring the inbound PSTN trunks from the IP Telephony gateways back to the PBX. • The parallel cutover allows for verification of the IP Telephony database configuration before the system carries live PSTN traffic. This scenario can be run for any length of time prior to the cutover of the inbound PSTN trunks from the PBX to the IP Telephony gateways, thereby ensuring correct configuration of all subscriber information, phones, gateways, the dial plan, and so forth.

29. Jack Brown -- June 16th, 2009 Parallel Cutover Pros for a Parallel Cutover • Training can be carried out at a more relaxed pace by allowing subscribers to explore and use the IP Telephony system at their own leisure before the cutover of the inbound PSTN trunks. • The system administrator does not have to make special provisions for "communities of interest." With a phased approach, you have to consider maintaining the integrity of call pick-up groups, hunt groups, shared lines, and so forth. These associations can be easily accounted for when moving the complete site in a parallel cutover.

33. Jack Brown -- June 16th, 2009 Final IP Telephone Services

34. Jack Brown -- June 16th, 2009 Planning the Unified Communications Manager Implementation

35. Prepare: Is the right team in place? Are technical and business requirements clearly understood? Have end-user features and functionality been documented and addressed? Plan: Does the network have the bandwidth, QoS & call control infrastructure to handle growth and new rich media applications? Does a customer’s operations staff have the expertise required to administer and sustain the solution? Design: Is the current or proposed network design resilient enough to handle a customer’s planned growth? Does the dial plan scale to future needs? Is the network secure? Implement: Are the disciplines in place for change & risk management during implementation? Have users been trained? Have planning and design processes ensured that growth and new applications will not downgrade network performance? “Data teams should not execute any change management without consulting the Voice Team.” Operate and Optimize: Does the customer continue to get the best performance from their network? Are devices at the optimal software level? What happens when software or security updates must occur? Are there procedures to keep the network at peak performance? Jack Brown -- June 16th, 2009 Planning the Unified Communications Manager Implementation

42. Jack Brown -- June 16th, 2009 Example Applications

44. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator Dial via Office: Call Flow

45. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator Dial via Office: Call Flow

46. Jack Brown -- June 16th, 2009 WebDialer WebDialer is a click-to-call application for Unified CM that enables users to place calls easily from their PCs using any supported phone device. There is no requirement for administrators to manage CTI links or build JTAPI or TAPI applications because Cisco WebDialer provides a simplified web application and HTTP or Simple Objects Access Protocol (SOAP) interface for those who want to provide their own user interface and authentication mechanisms.

47. Jack Brown -- June 16th, 2009 2. The WebDialer application on the user's PC communicates with the Cisco WebDialer Web Service (see step 2) via one of the following interfaces: – HTML over HTTPS This interface is used by web-based applications based on the HTTPS protocol. This is the only interface that provides access to the WebDialer and Redirector servlets. – Simple Object Access Protocol (SOAP) over HTTPS This interface is used by desktop applications based on the SOAP interface. 1. WebDialer user phones register and make and receive calls via the Cisco CallManager service (see step 1) 3. The WebDialer Web service reads user and phone information from the Unified CM Database (see step 3). 4. The WebDialer Web service in turn interacts with the CTI Manager service for exchanging line and phone control information (see step 4 ). 5. The CTIManager service passes WebDialer phone control information to the Cisco CallManager service (see step 5 ). WebDialer

48. Jack Brown -- June 16th, 2009 WebDialer URL HTML Example

49. Jack Brown -- June 16th, 2009 Appendix

50. Jack Brown -- June 16th, 2009 Example Gateway Protocols and Cisco Unified Communications Gateways

51. Jack Brown -- June 16th, 2009 Typical Unified CM Cluster Within a Unified CM cluster, there are servers that provide unique services. Each of these services can coexist with others on the same physical server. For example, in a small system it is possible to have a single server be a database publisher, backup subscriber, music on hold (MoH) server, TFTP server, CTI Manager, and Conference Bridge. As the scale and performance requirements of the cluster increase, many of these services should be moved to a single, dedicated physical server. A cluster may contain as many as 20 servers, of which a maximum of eight may run the Cisco CallManager Service that provides call processing. The other servers may be configured as a dedicated database publisher, dedicated Trivial File Transfer Protocol (TFTP) server, or music on hold (MoH) servers. Media streaming applications (conference bridge or media termination point) may also be enabled on a separate server that registers with the cluster.

52. Jack Brown -- June 16th, 2009 Typical Unified CM Cluster

53. Jack Brown -- June 16th, 2009 SIP TRUNKING

54. Jack Brown -- June 16th, 2009 Call Coverage Between Multiple Sites in a Centralized Call Processing Deployment

55. Jack Brown -- June 16th, 2009 Detailed SCCP Multicast MoH Call Flow

56. Jack Brown -- June 16th, 2009 Detailed SIP Multicast MoH Call Flow

57. Jack Brown -- June 16th, 2009 Call Admission Control The call admission control function is an essential component of any IP telephony system, especially those that involve multiple sites connected through an IP WAN To preserve a satisfactory end-user experience, the call admission control function should always be performed during the call setup phase so that, if there are no network resources available, a message can be presented to the end-user or the call can be rerouted across a different network (such as the PSTN).

58. Jack Brown -- June 16th, 2009 The Need for QSIG in Multisite Enterprises While some enterprises consist of only one location, others consist of many sites, some of which may potentially be spread over large distances. PBX networks for multisite enterprises are usually connected using T1 or E1 PRI trunks (depending on location) running a proprietary protocol such as Avaya DCS, Nortel MCDN, Siemens CorNet, NEC CCIS, Fujitsu FIPN, or Alcatel ABC, among others. These proprietary networking protocols enable the PBXs to deliver a high level of feature transparency between subscribers. QSIG was developed to enable the interconnection of PBXs from different vendors, thereby allowing similar levels of feature transparency. Cisco first added QSIG to Unified CM Release 3.3 to enable Unified CM to be part of a large enterprise network Unless you already have QSIG enabled on your PBX or have a specific need for its additional features and functionality, the cost of upgrading the PBX might be hard to justify if it will be retired within a short period of time. For example, why spend $30,000 on enabling the PBX for QSIG if you plan to retire the PBX in two or three months

59. Jack Brown -- June 16th, 2009 QSIG is an internationally standardized signaling protocol for use in corporate or enterprise voice or integrated services networks, typically between Private Automatic Branch eXchanges (PABX). QSIG is designed to be independent of its own transport and independent of the means of transporting speech or other media in calls established by QSIG. Although a typical deployment of QSIG is on primary rate leased lines (QSIG occupying one of the 24 or 30 64 kbit/s channels, the rest acting as 64 kbit/s bearers for media), many other deployments are possible. In particular, QSIG can be deployed in Internet Protocol (IP networks, tunneled directly over a transport protocol or over some other signaling protocol such as H.323 or SIP. QSIG is a variant of ISDN D-channel signaling. The protocol was originally specified by ECMA, then was adopted by European Telecommunications Standards Institute (ETSI) and the ISO. The table below identifies the ECMA standards and the OSI layer of the QSIG protocol stack to which they relate. QSIG Protocol Stack

60. Jack Brown -- June 16th, 2009 The Networking and Signaling Task Groups of ECMA TC32 are responsible for the definitions of standards for QSIG Basic Services as well as a wide range of Supplementary Services. All of theses have been published as European Standards by the European Telecommunications Standards Institute, Basic Service is sufficient to set up a simple call rapidly between two users in a private network but it is the implementation of Supplementary Services that makes modern digital networks really attractive. The ability to control and operate PABX features such as Call Diversion across a network and between different manufacturer's' PABXs is what distinguishes these networks from the analogue systems that we have traditionally used. More than 25 Supplementary Services have already been standardized and these include Call Diversion, Calling Line Identification, Call Intrusion and services to support mobility within a private network. At a world level, both ITU­T and ISO/IEC have made extensive use of ECMA's output on PISN signaling. QSIG has been adopted by ISO/IEC JTC1/SC6/WG6 and published in International Standards as the PSS1 signaling system. QSIG information flows have been adopted as the basis for supplementary services in packet based multimedia communications systems (the H.323 suite of Recommendations from ITU-T). QSIG Protocol Stack

61. Jack Brown -- June 16th, 2009 The QSIG protocol allows for additional feature transparency between PBXs from different vendors, over and above the features that can be obtained from PSTN-type PRI, and it is therefore more appropriate for large enterprises that are already operating complex networks QSIG as implemented in Cisco Unified CM Release 4.1 supports the following features: • Basic call • Direct Inward Dialing (DID) • Calling number • Called number • Connected name • Transfer (by join) • Message Waiting Indication (MWI) • Divert (by forward-switching) • Calling name restriction • Calling number restriction • Divert (by re-route) • Divert (responding to “check restriction” request) • Alerting name (on-ringing) • Path Replacement • Callback — Call Completion Busy Subscriber (CCBS) and Call Completion No Reply (CCNR) QSIG Protocol Stack

63. Jack Brown -- June 16th, 2009 Deployment Methodology Determine Your Requirements The first step in deploying a system is to determine the requirements for your situation. This step involves: • Analyzing your business operations to determine features and functions that you need

64. Jack Brown -- June 16th, 2009 Deployment Methodology Determine the Solution Requirements After you determine your requirements, you are ready to define the solution that meet your requirements. In this step, you determine the component and component options that meet your business and operational needs. The solution consists a Communications platforms and systems that make up the architecture. It also includes the features, functions, and applications that provide the services that you require. The solution also may include third-party products. Assess Your Network and Infrastructure Readiness Network and infrastructure readiness assessment involves the review and audit of all network infrastructure areas that will be affected by the deployment. The assessment should be performed at each site where you will deploy. Items to assess include: • Network design (routing and switching network) • Software • Hardware • Power/environment • Network links • Network services

65. Jack Brown -- June 16th, 2009 Deployment Methodology Assess Your Operational Readiness Operational readiness assessment involves determining your ability to administer and manage the new communications system. Based on this assessment, you will determine whether additional products and services are required, either temporarily or long-term, when you deploy the system. Operational areas to consider include: • System configuration • System monitoring • System upgrading

66. Jack Brown -- June 16th, 2009 Deployment Methodology Develop Site Requirements When you develop your site requirements, you identify the hardware, software, and physical and environmental needs that relate to the implementation and operation of the Cisco Unified Communications system at each location where you will deploy the solution. To assist with this process, review the high-level design documents to understand the component requirements for the solution at each location. Consider these issues: • Solution hardware components • Solution software levels • Telephone company circuits • WAN connectivity • Solution equipment electrical requirements • Solution environmental/physical space requirements • Solution equipment rack and cabinet locations and layouts

67. Jack Brown -- June 16th, 2009 Deployment Methodology Develop a Detailed Design After you develop your site requirements, you are ready to develop a detailed design for the Cisco Unified Communications system based on the requirements that you identified. The detailed design will address a wide variety of issues regarding each Cisco Unified Communications component that you will implement. These issues include: • Network infrastructure • Interoperability requirements • Call processing system requirements • Application software requirements • Customer interaction requirements • Corporate directory architecture and requirements • Messaging system architecture and requirements • Conferencing requirements • Current utilization of voice messaging system, integration plans and migration strategy • Enterprise directory and messaging security requirements

68. Jack Brown -- June 16th, 2009 Deployment Methodology Develop Your Implementation Plan Developing an implementation plan involves defining the processes required to carry out the implementation the Cisco Unified Communications system. In this step, make sure to consider: • Accurate scheduling of any site-specific actions needed prior to implementation • Equipment delivery and staging • Resource requirements for network and site-specific implementation, including third-party support requirements • Project phases and deadlines • Acceptance criteria for each project phase • Training Stage and Configure Your Solution Staging and configuring your system can help make final installation more efficient. For this step, you can perform some or all of these tasks: • Assemble the components that will be installed at each site • Perform basic testing of the hardware and software • Pre-configure of the devices as appropriate

69. Jack Brown -- June 16th, 2009 Install the Solution Installing the system involves installing and configuring your network infrastructure and installing and setting up the system components. After you verify the readiness of this equipment, you perform the following general steps to install the solution: • Catalog and inventory the system components • Install equipment in data racks • Complete cabling and other physical connectivity • Place phone units in workspaces • Verify that all units power up correctly • Capture Installation-specific information, including: – Rack layouts – Phone placement – Server placements and configurations – Key connectivity specifics in routers and switches – Port-specific details Deployment Methodology

70. Jack Brown -- June 16th, 2009 9-1-1

71. Jack Brown -- June 16th, 2009 9-1-1

72. Jack Brown -- June 16th, 2009 9-1-1

73. Jack Brown -- June 16th, 2009 9-1-1

74. Jack Brown -- June 16th, 2009 9-1-1

75. Jack Brown -- June 16th, 2009 9-1-1

76. Jack Brown -- June 16th, 2009 9-1-1

77. Jack Brown -- June 16th, 2009 9-1-1

78. Jack Brown -- June 16th, 2009 9-1-1

79. Jack Brown -- June 16th, 2009 9-1-1

80. Jack Brown -- June 16th, 2009 9-1-1

81. Jack Brown -- June 16th, 2009 9-1-1

82. Jack Brown -- June 16th, 2009 9-1-1

83. Jack Brown -- June 16th, 2009 9-1-1

84. Jack Brown -- June 16th, 2009 9-1-1

85. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator

86. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator

87. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator

88. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator

89. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator

90. Jack Brown -- June 16th, 2009 The Cisco Unified Application Environment is a development and runtime platform designed for creating, deploying, and executing converged voice and data applications. It is integrated with Cisco Unified Communications Manager and Cisco Unified Presence. Unified Application Environment 1.An HTTP request invokes the application on the Cisco Unified Application Server. 2.The Cisco Unified Application Server sends JTAPI requests to the CTI Manager on the Cisco Unified Communications Manager. 3.Phone A makes a SIP and/ or SCCP call to Phone B. 4.Phone B answers the call. This establishes an RTP stream between the two phones.

91. Jack Brown -- June 16th, 2009

92. Jack Brown -- June 16th, 2009

93. Jack Brown -- June 16th, 2009

94. Jack Brown -- June 16th, 2009

95. Jack Brown -- June 16th, 2009

96. Jack Brown -- June 16th, 2009

97. Jack Brown -- June 16th, 2009

98. Jack Brown -- June 16th, 2009