Cisco Unity can support thousands of subscribers, so when it is used with Cisco CME, it often makes sense to share a single Cisco Unity system among many Cisco CMEs in a network of Cisco CME nodes. The advantages of doing this instead of using a Cisco Unity Express (UE) system at each site are that voice mail administration can be done at a single central location, and a voice mail networking configuration is not needed to exchange messages between users located at different sites. However, you still need a Cisco CME collocated with Cisco Unity because Cisco Unity registers with only a single local Cisco CME system. This configuration was discussed in Chapter 11.
A centralized Cisco Unity system also means that all calls that access voice mail have to travel over the WAN. This requires a quality of service (QoS)-enabled WAN backbone as well as more bandwidth, especially if Cisco Unity is configured to use the G.711 codec. You can reduce bandwidth consumption in several ways:
One more thing to consider in centralized voice mail architecture is that all the IP phone extensions in the network must be unique. In other words, no two Cisco CMEs can share the same phone extension. Also, if you use central Cisco Unity as the AA for all the Cisco CME sites, you need to enable H.450 services in the network for call transfers to extensions appearing on different Cisco CMEs, and configure transfer patterns on the central Cisco CME. Figure 18-5 shows a sample topology of such a network.
Figure 18-5. Centralized Cisco Unity with Distributed Cisco CME Sites
The preceding section covered how MWI integration works between Cisco CME and Cisco Unity. However, it assumed that all the phones subscribed to Cisco Unity are on the same Cisco CME where the Cisco Unity ports are registered. In the case of the centralized voice mail architecture discussed in this section, not all the phones are on the same Cisco CME. They are registered to different Cisco CMEs in the network. To propagate MWIs to the appropriate phone(s) in the network, the MWI indication has to be relayed from the central Cisco CME where Cisco Unity is registered to the remote Cisco CME where the appropriate phone is registered.
To achieve this, the Cisco CME hosting the Cisco Unity server acts as an MWI server, and the remote Cisco CMEs that share the central Cisco Unity server act as MWI clients. The client Cisco CMEs receive notifications from the central Cisco CME server when one of their extensions gets a new voice mail. This is done using a mechanism called SIP SUBSCRIBE/NOTIFY. The client Cisco CMEs register their ephone-dns for MWI notification using the SIP SUBSCRIBE method. The central CME relays the MWI notifications from the Cisco Unity system using the SIP NOTIFY method.
One thing to keep in mind in this scenario is that call control between Cisco CMEs may still use either the SIP or H.323 protocol. The SIP SUBSCRIBE/NOTIFY mechanism for MWI is independent of the call control mechanism used between the networked Cisco CMEs. So a call from extension 5002 on Cisco CME3 to extension 6002 Cisco CME2 can use the H.323 protocol, and when 6002 does not answer, the call to the central Cisco Unity system can also use the H.323 protocol. When the caller leaves a message for 6002 on the Cisco Unity system, it informs the central Cisco CME of the new message using the SCCP protocol. Then the central CME sends a SIP NOTIFY to the corresponding client CME, passing the extension number for which the message was left.
You must configure each ephone-dn that represents a subscriber on the central Cisco Unity system with the mwi sip command on the Cisco CME system where it is registered. You use the command-line interface (CLI) command mwi sip-server to configure on each client Cisco CME the central Cisco CME as the MWI server, as shown in Example 18-10. The Cisco CME server must have the mwi relay command configured under telephony-service.
Example 18-10. Configuration for MWI Client Cisco CME
cme#show telephony-service CONFIG (Version=3.1) ===================== Version 3.1 Cisco CallManager Express ip source-address 17.17.17.1 port 2000 max-ephones 48 max-dn 15 max-conferences 4 max-redirect 5 voicemail 8050 mwi sip-server 200.1.1.29 transport tcp mwi expires 86400 transfer-system full-blind local directory service: enabled. ephone-dn 1 number 2902 preference 0 secondary 9 huntstop call-forward noan 8050 timeout 10 mwi sip ephone-dn 2 number 2903 preference 0 secondary 9 huntstop mwi sip ephone-dn 4 number 2904 preference 0 secondary 9 huntstop mwi sip
Each ephone-dn that has mwi sip configured is subscribed to the central MWI server Cisco CME for MWI notifications. This is done using the SIP SUBSCRIBE method. You can see the subscriptions on the MWI server Cisco CME, as shown in Example 18-11.
Example 18-11. List of Subscribed Clients for MWI Notifications
cme#show mwi relay clients Client IPADDR EXPIRES(sec) MWI ============ =============== ============ ==== 2902 49.23.48.2 61319 OFF 2903 49.23.48.2 86359 OFF 2904 49.23.48.2 86365 OFF
When the MWI server Cisco CME gets an MWI notification from the Cisco Unity server, it relays the notification by sending a SIP NOTIFY to the client Cisco CME, informing it that a particular extension has a new message. The client Cisco CME then turns on the MWI for the appropriate phone using the normal SCCP message.
Example 18-12 shows that ephone 7, which is the Cisco Unity port for MWI notifications, goes off-hook with calling number (subscriber extension number) 2902 and dials 9051, which is the MWI off DN. In the highlighted line, the called number is missing but the original Called Number field is set to 9051. It is confusing, but that is the way the fields appear in the debug output.
The MWI server in Cisco CME looks to see if 2902 is a local ephone-dn in its configuration. If it is not, the server looks for SIP subscriptions for MWI notifications. If it finds a subscription for extension 2902, it sends a SIP NOTIFY to the IP address received in the subscription, as shown in Example 18-12. The receiving (client) Cisco CME sends a "200 OK" SIP message acknowledging receipt of the MWI notification. This results in the client Cisco CME's turning on the MWI lamp for the phone using the usual SCCP.
Example 18-12. SCCP and SIP Debugs for MWI Relay
CME#debug ephone state CME#debug ccsip messages *Oct 31 22:29:22.433: ephone-7[3]:OFFHOOK with calling party 2902 *Oct 31 22:29:22.433: ephone-7[3]:OFFHOOK *Oct 31 22:29:22.433: ephone-7[3]:SIEZE on activeLine 0 activeChan 1 *Oct 31 22:29:22.433: ephone-7[3]:SetCallState line 1 DN 14 chan 1 ref 257 TsOffHook *Oct 31 22:29:22.437: DN 14 chan 1 Voice_Mode *Oct 31 22:29:22.437: dn_tone_control DN=14 chan 1 tonetype=33:DtInsideDialTone onoff=1 pid=158 *Oct 31 22:29:22.437: dn_tone_control DN=14 chan 1 tonetype=0:DtSilence onoff=0 pid=158 *Oct 31 22:29:22.441: dn_tone_control DN=14 chan 1 tonetype=0:DtSilence onoff=0 pid=158 *Oct 31 22:29:22.445: ephone-7[3]:SetCallState line 1 DN 14 chan 1 ref 257 TsRingOut *Oct 31 22:29:22.449: ephone-7[3]:Call Info DN 14 line 1 ref 257 called calling A8 origcalled 9051 calltype 2 *Oct 31 22:29:22.449: ephone-7[3]:Call Info for chan 1 *Oct 31 22:29:22.449: ephone-7[3]: No-Name calling *Oct 31 22:29:22.449: ephone-7[3]: No-Name *Oct 31 22:29:22.449: ephone-7[3]:SetCallState line 1 DN 14 chan 1 ref 257 TsProceed *Oct 31 22:29:22.449: UpdateCallState DN 9 chan 1 operating in mode 2 *Oct 31 22:29:22.449: UpdateCallState DN 9 chan 1 operating in mode 2 *Oct 31 22:29:22.453: dn_tone_control DN=14 chan 1 tonetype=36:DtAlertingTone onoff=1 pid=158 *Oct 31 22:29:22.497: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: NOTIFY sip:2902@49.23.48.2:5060 SIP/2.0 Via: SIP/2.0/TCP 200.1.1.29;branch=z9hG4bKFC3 From: "2902" To: ;tag=99F03BFD-2307 Date: Thu, 31 Oct 2002 22:29:22 UTC Call-ID: B77C4F4E-68B011D8-80B9958B-10B1AC79 User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 6 Timestamp: 1036103362 CSeq: 6 NOTIFY Event: message-summary Contact: Content-Length: 22 Content-Type: application/simple-message-summary Messages-Waiting: no *Oct 31 22:29:22.569: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 200.1.1.29;branch=z9hG4bKFC3 From: To: "2902" ;tag=99F03BFD-2307 Date: Fri, 27 Feb 2004 23:29:14 UTC Call-ID: B77C4F4E-68B011D8-80B9958B-10B1AC79 CSeq: 6 NOTIFY Timestamp: 1077924554 Event: message-summary Content-Length: 0
Troubleshooting Call Transfers and Call Forwards |
Part I: Cisco IP Communications Express Overview
Introducing Cisco IPC Express
Building a Cisco IPC Express Network
Cisco IPC Express Architecture Overview
Part II: Feature Operation and Applications
Cisco IP Phone Options
Cisco CME Call Processing Features
Cisco CME PSTN Connectivity Options
Connecting Multiple Cisco CMEs with VoIP
Integrating Cisco CME with Cisco CallManager
Cisco IPC Express Automated Attendant Options
Cisco IPC Express Integrated Voice Mail
Cisco CME External Voice Mail Options
Additional External Applications with Cisco CME
Part III: Administration and Management
Cisco IPC Express General Administration and Initial System Setup
Configuring and Managing Cisco IPC Express Systems
Cisco IPC Express System Configuration Example
Part IV: Maintenance and Troubleshooting
Troubleshooting Basic Cisco IPC Express Features
Troubleshooting Advanced Cisco CME Features
Troubleshooting Cisco CME Network Integration
Troubleshooting Cisco UE System Features
Troubleshooting Cisco UE Automated Attendant
Troubleshooting Cisco UE Integrated Voice Mail Features
Part V: Appendixes
Appendix A. Cisco IPC Express Features, Releases, and Ordering Information
Appendix B. Sample Cisco UE AA Scripts
Appendix C. Cisco Unity Express Database Schema
Index