A Cisco Unity System with a Network of Cisco CMEsCentralized Voice Mail Architecture

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:

• Configure Cisco Unity to use the G.729 codec. In this case, Cisco Unity can accept both G.729 and G.711 calls.
• Use a hardware transcoder in front of Cisco Unity to convert G.729 audio streams to G.711. Cisco CME 3.2 and greater supports a transcoding function.

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