Migration to Unified Communications from Legacy Phone Systems Presentation Transcript

1. Migration to Unified Communications from Legacy Phone Systems Cisco Centric High Level Discussion Topics Jack Brown -- June 16th, 2009 2. Jack Brown -- June 16th, 2009 UC Fundamental Unified Communications Deployment Models Migration Options Planning the Unified Communications Manager Implementation Example Applications Unified Mobile Communicator Dial-via-Office WebDialer SOAP-XML-HTTP/S Appendix Example Gateway Protocols and Cisco Unified Communications Gateways Typical Unified CM Cluster SIP Trunking Call Coverage Between Multiple Sites in a Centralized Call Processing Deployment Detailed SCCP Multicast MoH Call Flow Detailed SIP Multicast MoH Call Flow Call Admission Control QSIG Protocol Stack in Multisite Enterprises Dual Phones for Phased Migrations Deployment Methodology 911 Mobile Communicator Application Development QoS Network Security FCAPS

3. Overall Costs Down Todays Siloed 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

4. People-Centric Communications Jack Brown -- June 16th, 2009 Standards-based platform Rich APIs and Web Services Developer Tools Infrastructure simplification Consolidation Intuitive and contextual Rich-presence; multimodal Any device, any place 5. Representation Of Ciscos 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 17. Jack Brown -- June 16th, 2009 Phased Migration Parallel/Flash Cut Dual Phone for Phased/Parallel 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 20. Jack Brown -- June 16th, 2009 Phased Migration With either PSTN-type PRI or QSIG, the process of phased migration is similar: move subscribers from the PBX to Unified CM in groups, one group at a time, until the migration is complete All users migrated from Nortel PBX to the Cisco Unified

Communications Manager will keep the same Directory Number All incoming calls coming through PBX in the first phase and will go directly to Cisco Unified Communications Manager in the second phase All outgoing calls go directly to the PSTN

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.

23. Jack Brown -- June 16th, 2009 Ability to perform smaller migrations of a larger Campus while maintaining majority of the users dial behavior and features. Administration overhead can be more personalized. User groups or communities can be moved instead of the whole Campus assisting in Gap Analysis and Data Collection. User base prioritization can occur. Key groups can be moved first or last depending on requirements and priorities. Migration Partitions can be used to support Dual Phone deployments. Tight project timelines and deliverables can be met without risk of a large flash-cut. Options are available to minimize PSTN provisioning, leveraging use of PBX interconnections. Legacy dependencies can be maintained during the rollouts until EOL replacement products are replaced. Day 2 support decreased from a Parallel Deployment. Pros for Phased Deployment

24. Jack Brown -- June 16th, 2009 Cons for Phased Deployment Large numbers of QSIG or direct PBX to PBX connections will complicate phone rollout phase by potentially necessitating extra equipment/services for a temporary solution. Dial-Plan segmentation or micro-management required to insure proper routing of DID and On-Net PBX traffic. Feature differences could occur in the Campus as a portion of users would be migrated and a portion of users would be on the legacy system Administration would occur on multiple phone systems during the life cycle of the rollout. Troubleshooting might involve multiple vendors and the required integration between the systems. Potential for increasing the number of site visits for branch/retail environments. Corporate Directory via phone can be segmented or require redundant configuration.

25. Jack Brown -- June 16th, 2009 This approach begins with implementation of a complete IP Telephony infrastructure that is redundant, highly available, QoS-enabled, and equipped with Ethernet ports that are powered inline. Once the infrastructure is complete, the IP Telephony application can then be deployed. All IP phones and gateways can be fully configured and deployed so that subscribers have two phones on their desk simultaneously, an IP phone as well as a PBX phone. This approach provides the opportunity to test the system as well as allowing subscribers time to familiarize themselves with their new IP phones. Outbound-only trunks can also be connected to the IP Telephony system, giving subscribers the opportunity to use their new IP phones to place external calls as well as internal calls. Parallel Cutover

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 pickup groups, hunt groups, shared lines, and so forth. These associations can be easily accounted for when moving the complete site in a parallel cutover.

30. Jack Brown -- June 16th, 2009 Parallel Cutover Cons for Parallel Deployment Potential costs for redundant PSTN facilities during deployment. Data infrastructure must be complete, rather than a phased rollout in conjunction with UC deployments. Entire site rollout must be funded from the beginning. Voicemail, call centers, turrets, or other 3rd party legacy applications which will need to be migrated for use with the new platform. Inbound calling cut over all at once must be tested thoroughly Analog infrastructure similarly must be given special attention during cutover Tremendous amount of focus on system, performance, features, scalability during deployment phase to ensure no operational problems after final cutover Higher risk factor as you are cutting all of your PBX users at once. DID migration, phone migration, routing migration all occurring in a single window.

31. Jack Brown -- June 16th, 2009 PSTN Migration Circuit Swing Strategy During cutover, legacy circuits are physically swung to new gateways Carrier reprovisioning may be required No PSTN calls available until cut When demarcs moved our circuit extension required, this can be very stressful DID Swing Strategy New PSTN circuits turned up prior to cutover of site Prior to cutover, outbound only calling available via new circuits If new DID ranges are in use- inbound calling may be enabled Dial-plan interworking with other sites for outbound calling must be in place as well as all sites will not be cut at once

32. Jack Brown -- June 16th, 2009 PSTN Migration DID over Tandem PBX T1/E1 Local T1/E1 connections are made between Legacy PBX and Cisco Unified Communications Manager Dial Plan is segmented to allow DID to be sent to phones configured on Cisco Unified Communications Manager via T1 (PRI/QSIG) Not available in a Parallel depolyment Allows support for Internal On-Net dial between PBX and Cisco Unified Communications Manager as well

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 customers 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 customers 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

36. Jack Brown -- June 16th, 2009 Planning the Unified Communications Manager Implementation Assess and document the current network infrastructure to ensure proper quality of service(QOS), availability, and security Document the existing and desired dial plan, classes of service, analog requirements, recording needs and the call detail record (CDR) method to ensure transparency of operation Talk with existing users to determine the current applications in use, phone usage patterns and most used features Understand various add-on hardware such as headsets, wallboards etc..

37. Jack Brown -- June 16th, 2009 Assessing Current Data Infrastructure QOS Verify that the network devices can provide a priority queue for voice packets in case network congestion occurs. High Availability UPS Ensure optimum operational environment Build redundancy into the Network design ex: redundant core. Good idea to have a separate server farm connected in a redundant fashion to the core. This lets you keep the servers off the core and distribution switches. This allows them to be upgraded and maintained without service interruption. Security Physical securit y (limit access to key individuals) Virus/worm mitigation. Run Cisco Security Agent at a minimum Layer 2 security using tools such as DHCP snooping, Dynamic Arp Inspection, and IP SourceGuard can help mitigate these attacks. Routing Protocol Security ( use neighbor authentication to keep hackers out) Firewall policy ( be sure policy allows necessary protocols through if there is a FW between the data and voice subnets

38. Jack Brown -- June 16th, 2009 Document Data Infrastructure Physical network diagram Logical network diagram Copies saved in PNG, JPG, or GIF so that technical personnel will have easy access 39. Jack Brown -- June 16th, 2009 Document Desired Dial Plan Internal extensions Manager/Admin Pairings (Shared Lines) Rollover extensions Emergency numbers Trunk access codes Tie-Line access codes Message Waiting Indicator (MWI) ON/OFF numbers Application numbers( call center, voice-mail) System Speed dials Route/hunt patterns Translation patterns

40. Jack Brown -- June 16th, 2009 Verify Customer Requirements IP Telephony requirements Attendant console Authorization codes Availability Call admission control Call routing and dial plan requirements Call Detail Records Unified Communications Manager system and users Unified Communications Manager clustering requirements Directory access and integration E-911 (Cisco Emergency Responder) requirements Feature Access Codes Integrations Phones and endpoints Media resources Music on hold Unified Survivable Remote Site Telephony (SRST) requirements Voice gateways Unified Communications security requirements Conferencing and rich media conferencing requirements User license information Voice messaging requirements Message store and infrastructure requirements Messaging integrations: Lotus Domino, Microsoft Exchange Legacy PBX integration requirements Licensing requirements

41. Jack Brown -- June 16th, 2009 Assess Current Voice Environment Conduct a feature Inventory and Create User Classes Gather existing spreadsheets or databases of users and the phone features associated with their jobs. In the absence of existing info research tools that are available to extract info. Third party extraction tools such as those from Unimax can aid in the transition as well Interviews The approach of gathering the inventory has two extremesrepresentative sample and exhaustive sample. The representative sample indicates a reasonable percentage of each user class in the organization. The exhaustive requires an interview with each user. The recommended approach is a combination of the two. Construct a list of all users to be interviewed Use Application such as Microsoft Excel which can provide greater flexibility than handwritten documents. After the inventory is complete create a set of user classes that represent a common set of user features and capabilities identified during the interviews.

42. Jack Brown -- June 16th, 2009 Example Applications 43. Jack Brown -- June 16th, 2009 Cisco Unified Mobile Communicator Dial-via-Office When enabled, will dial all calls from mobile via Cisco Unified Communications Manager Emergency calls go direct Admin or user defined Dial-via-Office Setting Always on Always off Choose on a per call basis User may see extra prompts when: Verify how to route calls on a call-by-call basis Select an alternate end-point

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 enduser 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 ITUT 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

62. Jack Brown -- June 16th, 2009 Dual Phones for Phased Migrations Dual Phones can deployed to assist with User learning For Phased Migrations, typically phones are configured as per the final configuration but the DN is placed in a Partition that is not routeable to receive calls. Pros Phone can be used for Outdial. Typically PSTN is over PBX or new T1s in Cisco Unified Communications Manager gateways. Caller receives inbound on Legacy phone to avoid multi-tasking multiple sets. Phone is truly for learning. If phone is unavailable then no disruption of service. Day 2 will go smoother as users will be accustomed to the new phones . Cons Inbound testing cannot be experienced unless you allow inbound routing to the line, thus requiring multiple set multi-tasking. Configuration slightly more advanced, with additional Dial Plan partitions created. Cut weekend requires a bulk update to move all phones to the permanent partition. Troubleshooting will be more advanced due to different endpoints able to make outbound calls.

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 sitespecific 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 Preconfigure 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