Integrating Cisco CME with Cisco Unity Voice Mail

As discussed in Chapter 11, "Cisco CME External Voice Mail Options," Cisco Unity is a unified messaging application running on Windows 2000. It uses the Skinny Client Control Protocol (SCCP) to integrate with Cisco CME. This section discusses troubleshooting the integration of Cisco Unity with Cisco CME.

Configuring Cisco CME for Cisco Unity

Cisco Unity connects to Cisco CME as an SCCP device. You configure ephone-dns and ephones for Cisco Unity ports to register with Cisco CME. Cisco Unity uses its Windows Telephony Application Programming Interface (TAPI) to integrate with Cisco CME. A Telephony Service Provider (TSP) is implemented to interface with Cisco CME and provide call control services to the Cisco Unity application. Hence, the Cisco Unity TSP and Cisco CME configuration should match.

Example 18-1 shows a sample Cisco CME configuration for a five-port Cisco Unity system.

Tip

This configuration is used in the next troubleshooting sections, so you might want to bookmark this page until you finish this section on Cisco Unity integration.

 

Example 18-1. CME Configuration for Cisco Unity to Integrate Using SCCP

cme#show running-config
ephone-dn 8
 number 9050
 preference 0
 huntstop
 mwi on
!
ephone-dn 9
 number 9051
 preference 0 secondary 9 huntstop
 huntstop
 mwi off
!
ephone-dn 10 dual-line
! We need dual-line for Unity to execute consult transfers at its Auto Attendant number
8050
 name Voicemail 1
 preference 1 secondary 9
 no huntstop
!
ephone-dn 11 dual-line
 number 8050
 name Voicemail 2
 preference 2 secondary 9
 no huntstop
!
ephone-dn 12 dual-line
 number 8050
 name Voicemail 3
 preference 3 secondary 9
 no huntstop
!
ephone-dn 13 dual-line
 number 8050
 preference 4 secondary 9
 huntstop
!
ephone-dn 14
 number A8
 preference 0 secondary 9
 huntstop
!
ephone 3
 vm-device-id CiscoUM1-VI1
 button 1:10
!
ephone 4
 vm-device-id CiscoUM1-VI2
 button 1:11
!
ephone 5
 vm-device-id CiscoUM1-VI3
 button 1:12
!
ephone 6
 vm-device-id CiscoUM1-VI4
 button 1:13
!
ephone 7
 vm-device-id CiscoUM1-VI5
 button 1:14

Example 18-1 shows seven ephone-dns configured on Cisco CME even though the Cisco Unity system has only five ports. Two of these ephone-dns (8 and 9) are meant for the message waiting indicator (MWI), which is discussed in the "Troubleshooting MWI" section. The remaining five ephone-dns are meant for call completion to each of the Cisco Unity ports. The voice mail pilot number in this example is 8050.

Note that four of the ephone-dns have the same number (8050), forming a hunt group, and that the last one has a different number (preferably nondialable). The reason for this is that Cisco Unity uses an outdial mechanism to turn MWI on or off. Hence, it needs one or more ports to place the MWI calls to Cisco CME. There is a possibility that a port can be seized by Cisco CME and Cisco Unity at the same time, resulting in a glare condition. Therefore, it is good practice to dedicate one or more ports (depending on the number of subscribers in your system) to MWI calls. In Example 18-1, the last ephone-dn (ephone-dn 14, with number A8) is dedicated to MWI only: A8 cannot be dialed from a phone keypad.

Figure 18-1 shows the Cisco Unity port allocation configuration for taking calls and for MWI notification. This allocation is done depending on the number of subscribers in your system and the amount of outdialing, consisting of notifications, traps, and possibly networked calls for Audio Messaging Interchange Specification (AMIS).

Figure 18-1. Cisco Unity Port Allocation

Note that the ephone-dns 10, 11, and 12 shown in Example 18-1 include a no-huntstop and preference configuration. This creates hunt group functionality for the Cisco Unity ports so that when a call is diverted to voice mail, it is connected using one of the available ports. In some instances (depending on your dialplan configuration), you might have to change the IOS dial peer hunt algorithm as shown in Example 18-2. For more information about dial peer hunt options, you can refer to Cisco IOS dial peer configuration guide at Cisco.com. Under normal circumstances, this configuration is not needed.

Example 18-2. Dial Peer Hunt Configuration

cme#show running-config

CME#configure terminal
CME(config)#dial-peer hunt 2

In addition to the ephone-dns, special ephone configurations are shown in Example 18-1. These ephones are needed for the Cisco Unity TSP to register with Cisco CME. Note that instead of the mac-address command under the ephone, this configuration uses the vm-device-id command, indicating that this ephone is meant for Cisco Unity ports rather than a Cisco IP phone.

The device identifiers used in the ephone configuration have to match the identifiers used by the Cisco Unity TSP configuration, as shown in Figure 18-2.

Figure 18-2. Cisco Unity TSP Configuration

The next important item is the configuration of the MWI DNs. Cisco Unity uses an outdial mechanism to turn MWI on or off. In this mechanism, Cisco Unity goes off-hook (just like any other phone), but it uses a special off-hook SCCP message that lets Cisco Unity use a different calling number. When it wants to do an MWI operation, Cisco Unity initiates a call with the calling number equal to the extension for which MWI must be turned on or off. Then it dials a special number called an MWI directory number (DN). In Example 18-1, that special number is 9050 for ON and 9051 for OFF. The call processing mechanism for these special DNs in Cisco CME is that it turns the MWI on or off for the corresponding IP phone, depending on the called number. You'll take a closer look at these protocol messages in the troubleshooting sections.

The call processing mechanism for these speical DNs in Cisco CME is such that after you have configured both Cisco CME and Cisco Unity properly, you should see that Cisco Unity has registered its ports to Cisco CME, as shown in Example 18-3.

Example 18-3. Cisco Unity Ports Registered to Cisco CME

cme#show ephone registered
ephone-3 Device:CiscoUM1-VI1 TCP socket:[5] activeLine:0 REGISTERED
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0
IP:200.1.1.30 1510 Unity Voice Port keepalive 425 max_line 1
button 1: dn 10 number 8050 CH1 IDLE

ephone-4 Device:CiscoUM1-VI2 TCP socket:[1] activeLine:0 REGISTERED
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0
IP:200.1.1.30 1497 Unity Voice Port keepalive 425 max_line 1
button 1: dn 11 number 8050 CH1 IDLE

ephone-5 Device:CiscoUM1-VI3 TCP socket:[2] activeLine:0 REGISTERED
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0
IP:200.1.1.30 1505 Unity Voice Port keepalive 425 max_line 1
button 1: dn 12 number 8050 CH1 IDLE

ephone-6 Device:CiscoUM1-VI4 TCP socket:[4] activeLine:0 REGISTERED
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0
IP:200.1.1.30 1509 Unity Voice Port keepalive 425 max_line 1
button 1: dn 13 number 8050 CH1 IDLE

ephone-7 Device:CiscoUM1-VI5 TCP socket:[3] activeLine:0 REGISTERED
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0
IP:200.1.1.30 1508 Unity Voice Port keepalive 425 max_line 1
button 1: dn 14 number A8 CH1 IDLE

The next section describes the process of troubleshooting the integration.

Troubleshooting Cisco Unity Integration

After you have correctly configured Cisco CME and Cisco Unity to interwork, as discussed in the preceding section, the system should work fine. However, in case you face any issues in this area, this section provides you with ways to identify and fix the problem.

Here are the most important aspects of integrating Cisco Unity with Cisco CME:

• Passing correct call information (calling number, called number, last redirecting/original called number, call type, and reason if the call is forwarded to Cisco Unity) to Cisco Unity so that it identifies the correct mailbox for leaving a message
• Passing correct dual-tone multifrequency (DTMF) information from different call legs
• Executing transfers to extensions from the Cisco Unity automated attendant (AA)
• Turning MWI on and off when appropriate

Verifying Call InformationWrong Mailbox Selection

If your users complain of reaching the wrong mailbox or no mailbox after a call forward to Cisco Unity, the reason may be because the wrong call information is passed to Cisco Unity from Cisco CME. Turn on the debug ephone state on Cisco CME to verify that the original Called Number field is correct. Sample output from this command is shown in Example 18-4. In the example, extension 9001 calls extension 9002, but 9002 does not answer. The call rolls over to the Cisco Unity system voice mail.

Example 18-4. debug ephone state Command for Forwarded Calls

cme#debug ephone state
*Oct 31 21:11:15.765: ephone-1[8]:OFFHOOK
*Oct 31 21:11:15.765: ephone-1[8]:SIEZE on activeLine 1 activeChan 1
*Oct 31 21:11:15.765: ephone-1[8]:SetCallState line 1 DN 1 chan 1 ref 198
 TsOffHook
*Oct 31 21:11:15.765: ephone-1[8]:SpeakerPhoneOffHook mute 0
*Oct 31 21:11:15.769: DN 1 chan 1 Voice_Mode
*Oct 31 21:11:15.769: dn_tone_control DN=1 chan 1 tonetype=33:DtInsideDialTone
 onoff=1 pid=158
*Oct 31 21:11:15.769: dn_tone_control DN=1 chan 1 tonetype=0:DtSilence onoff=0
 pid=158
*Oct 31 21:11:15.769: dn_tone_control DN=1 chan 1 tonetype=0:DtSilence onoff=0
 pid=158
*Oct 31 21:11:15.777: ephone-1[8]:SetCallState line 1 DN 1 chan 1 ref 198
 TsRingOut
*Oct 31 21:11:15.777: ephone-1[8]:Call Info DN 1 line 1 ref 198
 called 9002 calling 9001 origcalled 9002 calltype 2
*Oct 31 21:11:15.777: ephone-1[8]:Call Info for chan 1
*Oct 31 21:11:15.777: ephone-1[8]: name-9001 calling
*Oct 31 21:11:15.777: ephone-1[8]: No-Name
*Oct 31 21:11:15.781: ***Fixed called DN binding DN 1 chan 1 called 2
 chan 1 (was called -1 chan 1)
*Oct 31 21:11:15.781: ephone-2[7]:SetCallState line 1 DN 2 chan 1 ref
 199 TsRingIn
*Oct 31 21:11:15.781: ephone-2[7]:Call Info DN 2 line 1 ref 199
 called 9002 calling 9001 origcalled 9002 calltype 1
*Oct 31 21:11:15.781: ephone-2[7]:Call Info for chan 1
*Oct 31 21:11:15.781: ephone-2[7]: name-9001 calling
*Oct 31 21:11:15.781: ephone-2[7]: name-9002
*Oct 31 21:11:15.781: ephone-2[7]:Ringer Inside Ring On
*Oct 31 21:11:15.781: dn_tone_control DN=1 chan 1 tonetype=36:DtAlertingTone
 onoff=1 pid=158
*Oct 31 21:11:25.781: SkinnyUpdateRedirectNumber DN 1 chan 1 to 8050 reason 2
*Oct 31 21:11:25.781: ephone-2[7]:DN 2 disc reason 19 no answer state RINGING
*Oct 31 21:11:25.781: Reset called DN binding for DN 1 (was 2)
*Oct 31 21:11:25.781: ephone-2[7]:SetCallState line 1 DN 2 chan 1 ref 199 TsOnHook
*Oct 31 21:11:25.781: dn_tone_control DN=2 chan 1 tonetype=0:DtSilence onoff=0
 pid=158
*Oct 31 21:11:25.781: ephone-2[7]:SpeakerPhoneOnHook
*Oct 31 21:11:25.781: ephone-2[7]:Ringer Off
*Oct 31 21:11:25.785: ***Fixed called DN binding DN 1 chan 1 called 10 chan 1
 (was called -1 chan 1)
*Oct 31 21:11:25.785: ephone-3[5]:SetCallState line 1 DN 10 chan 1 ref 200
 TsRingIn
*Oct 31 21:11:25.789: ephone-3[5]:Call Info DN 10 line 1 ref 200 called 8050
 calling 9001 origcalled 9002 calltype 3
*Oct 31 21:11:25.789: ephone-3[5]:Call Info for chan 1
*Oct 31 21:11:25.789: ephone-3[5]: name-9001 calling
*Oct 31 21:11:25.789: ephone-3[5]: Voicemail 1
*Oct 31 21:11:25.789: ephone-3[5]:Ringer Inside Ring On

If you have access to the Cisco Unity graphical user interface (GUI), you can view the call information shown in Example 18-4 in a graphical manner using the Call Viewer application available on Cisco Unity server. Two of the fields shown in Example 18-4 might help you understand the call flow bettercalltype and reason. The Calltype field refers to how the call was set up. The values are

• 1 Inbound call
• 2 Outbound call
• 3 Forwarded call

Similarly, the Reason field signifies why the call was forwarded (such as no answer, busy, or unconditional).

If you are using the Cisco CME dialplan-pattern command, calls may come into Cisco CME using the complete E.164 number associated with the phones. Example 18-5 shows such an example. Here the call is placed by dialing 4085559002 instead of 9002, the number that would be used if the call came in from a Public Switched Telephone Network (PSTN) caller. Some of the output in the example is omitted for brevity. For Cisco Unity to understand this correctly, you must configure an alternate extension for these subscribers on Cisco Unity, as shown in Figure 18-3.

Figure 18-3. Configuring Alternate Extensions on Cisco Unity

 

Example 18-5. Call Dialed Using the E.164 Number of a Phone Forwarded to Voice Mail

cme#debug ephone state
*Oct 31 21:11:15.765: ephone-1[8]:OFFHOOK
*Oct 31 21:11:15.765: ephone-1[8]:SIEZE on activeLine 1 activeChan 1
*Oct 31 21:11:15.765: ephone-1[8]:SetCallState line 1 DN 1 chan 1 ref 198
 TsOffHook
......
*Oct 31 21:11:15.777: ephone-1[8]:SetCallState line 1 DN 1 chan 1 ref 198
 TsRingOut
*Oct 31 21:11:15.777: ephone-1[8]:Call Info DN 1 line 1 ref 198
 called 4085559002 calling 9001 origcalled 4085559002 calltype 2
*Oct 31 21:11:15.777: ephone-1[8]:Call Info for chan 1
......
*Oct 31 21:11:25.781: SkinnyUpdateRedirectNumber DN 1 chan 1 to 8050 reason 2
*Oct 31 21:11:25.781: ephone-2[7]:DN 2 disc reason 19 no answer state RINGING
*Oct 31 21:11:25.781: Reset called DN binding for DN 1 (was 2)
*Oct 31 21:11:25.781: ephone-2[7]:SetCallState line 1 DN 2 chan 1 ref 199 TsOnHook
*Oct 31 21:11:25.781: dn_tone_control DN=2 chan 1 tonetype=0:DtSilence onoff=0
 pid=158
*Oct 31 21:11:25.781: ephone-2[7]:SpeakerPhoneOnHook
*Oct 31 21:11:25.781: ephone-2[7]:Ringer Off
*Oct 31 21:11:25.785: ***Fixed called DN binding DN 1 chan 1 called 10 chan 1
 (was called -1 chan 1)
*Oct 31 21:11:25.785: ephone-3[5]:SetCallState line 1 DN 10 chan 1 ref 200 TsRingIn
*Oct 31 21:11:25.789: ephone-3[5]:Call Info DN 10 line 1 ref 200 called 8050
 calling 9001 origcalled 4085559002 calltype 3
*Oct 31 21:11:25.789: ephone-3[5]:Call Info for chan 1
*Oct 31 21:11:25.789: ephone-3[5]: name-9001 calling
*Oct 31 21:11:25.789: ephone-3[5]: Voicemail 1
*Oct 31 21:11:25.789: ephone-3[5]:Ringer Inside Ring On

 

Troubleshooting DTMFNo Response to Digit Presses from Cisco Unity

When callers communicate with a voice mail system, the interface they use is called the Telephony User Interface (TUI). The user instructs the voice mail system what to do by pressing digits on the phone. Each digit usually maps to a specific action in the voice mail system.

If you are using Cisco Unity with Cisco CME, the calls can come to Cisco Unity from another Cisco CME or PSTN gateway using the H.323 protocol or from a PSTN interface on the local Cisco CME system. If the call arrives from H.323, the h245-alphanumeric DTMF relay option must be used between Cisco CME and the calling PSTN gateway. The other two DTMF options are not supported for IP phones later than H.323. For calls coming in from other interfaces, such as ISDN Basic Rate Interface/Primary Rate Interface (BRI/PRI) and analog PSTN lines, as well as from local IP phones, there is no need for a specific DTMF relay configuration. Cisco CME and Cisco IOS automatically handle relaying the digits to the Cisco Unity system.

Cisco CME then translates the incoming H.245 DTMF messages to SCCP KeypadButtonPress messages for Cisco Unity. Similarly, if the call is coming from a local PSTN trunk on your Cisco CME system, Cisco CME translates the incoming inband DTMF digits from the PSTN trunk to SCCP messages. If you are facing any issues in this area, turn on the following combination of debugs on Cisco CME to troubleshoot this situation:

• debug ephone detail For calls originating from local IP phones
• debug cch323 h245 and debug ephone detail For calls originating from a far-end H.323 device
• debug vtsp all and debug ephone detail For calls coming in from local PSTN interfaces

The highlighted lines in Example 18-6 show DTMF events coming from an H.323/H.245 leg relayed onto an SCCP leg to Cisco Unity.

Example 18-6. DTMF Relay from an H.245 Call Leg to an SCCP Call Leg to Cisco Unity

cme#debug cch323 h245
H245 State Machine tracing is enabled
cme#debug ephone detail
*Oct 31 21:25:15.445: //326/8E5B321F806C/H323/run_h245_iwf_sm: received
 IWF_EV_PROC_TUNNEL while at state IWF_ACTIVE
*Oct 31 21:25:15.449: //326/8E5B321F806C/H323/cch323_h245_user_input_ind:
 Received User Input Indication
*Oct 31 21:25:15.449: //326/8E5B321F806C/H323/cch323_h245_user_input_alpha:
 Processing alphanumeric ind (#)
*Oct 31 21:25:15.449: dn_tone_control DN=10 chan 1 tonetype=15:DtDtmfPound
 onoff=1 pid=158
.....
*Oct 31 21:25:15.449: called DN -1 chan 1, calling DN -1 chan 1 phone 3
 incoming s2s:0
*Oct 31 21:25:15.449: ephone-3[5]:is_auto_local 0 for DN 10
*Oct 31 21:25:15.449: Skinny StationKeypadButtonMessage 15 sent on socket [5]
 DtDtmfPound
*Oct 31 21:25:15.649: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence onoff=0
 pid=158
*Oct 31 21:25:21.765: //326/8E5B321F806C/H323/run_h245_iwf_sm: received
 IWF_EV_PROC_TUNNEL while at state IWF_ACTIVE
*Oct 31 21:25:21.765: //326/8E5B321F806C/H323/cch323_h245_user_input_ind:
 Received User Input Indication
*Oct 31 21:25:21.765: //326/8E5B321F806C/H323/cch323_h245_user_input_alpha:
 Processing alphanumeric ind (3)
*Oct 31 21:25:21.765: dn_tone_control DN=10 chan 1 tonetype=3:DtDtmf3 onoff=1
 pid=158
............
*Oct 31 21:25:21.765: called DN -1 chan 1, calling DN -1 chan 1 phone 3
 incoming s2s:0
*Oct 31 21:25:21.765: ephone-3[5]:is_auto_local 0 for DN 10
*Oct 31 21:25:21.765: Skinny StationKeypadButtonMessage 3 sent on
 socket [5] DtDtmf3
*Oct 31 21:25:21.965: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence
 onoff=0 pid=158
*Oct 31 21:25:21.965: SkinnyGetCallState for DN 10 chan 1 CONNECTED
*Oct 31 21:25:21.965: called DN -1 chan 1, calling DN -1 chan 1 phone 3
 incoming s2s:0
*Oct 31 21:25:21.965: SkinnyGetCallState for DN 10 chan 1 CONNECTED
*Oct 31 21:25:21.965: called DN -1 chan 1, calling DN -1 chan 1 phone 3
 incoming s2s:0
*Oct 31 21:25:21.965: SkinnyGetCallState for DN 10 chan 1 CONNECTED
*Oct 31 21:25:21.965: called DN -1 chan 1, calling DN -1 chan 1 phone 3
 incoming s2s:0
*Oct 31 21:25:21.965: ephone-3[5]:is_auto_local 0 for DN 10
*Oct 31 21:25:21.965: ephone-3[5]:StopTone sent to ephone
*Oct 31 21:25:30.097: //326/8E5B321F806C/H323/run_h245_iwf_sm: received
 IWF_EV_PROC_TUNNEL while at state IWF_ACTIVE
*Oct 31 21:25:30.097: //326/8E5B321F806C/H323/cch323_h245_user_input_ind:
 Received User Input Indication
*Oct 31 21:25:30.097: //326/8E5B321F806C/H323/cch323_h245_user_input_alpha:
 Processing alphanumeric ind (1)
 ......
*Oct 31 21:25:30.101: SkinnyGetCallState for DN 10 chan 1 CONNECTED
*Oct 31 21:25:30.101: called DN -1 chan 1, calling DN -1 chan 1 phone 3
 incoming s2s:0
*Oct 31 21:25:30.101: ephone-3[5]:is_auto_local 0 for DN 10
*Oct 31 21:25:30.101: Skinny StationKeypadButtonMessage 1 sent
 on socket [5] DtDtmf1
*Oct 31 21:25:30.297: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence
 onoff=0 pid=158
*Oct 31 21:25:30.297: SkinnyGetCallState for DN 10 chan 1 CONNECTED

If you are not seeing the digits in the H.323/H.245 debugs, make sure that the calling gateway has the correct configuration under the dial peer pointing to the Cisco CME hosting the Cisco Unity system. For the preceding Cisco Unity integration configuration, every far-end calling gateway should have a dial peer like the one shown in Example 18-7.

Example 18-7. H.323 Dial Peer for Cisco Unity Ports Pointing to a CME Hosting Cisco Unity

dial-peer voice 1 voip
 description "H.323 Dial peer pointing to CME hosting Cisco Unity"
 destination-pattern 8050
 session target ipv4:1.1.1.1
 dtmf-relay h245-alphanumeric 
 codec G711ulaw

 

Troubleshooting Cisco Unity AA Integration

Callers may complain that when they dial an extension using the Cisco Unity AA, the call is not transferred to the correct user. This might be caused by an incorrect configuration on Cisco Unity or Cisco CME for AA integration.

Because Cisco Unity is an SCCP device like an IP phone, it uses the same methods to transfer a caller to the desired extension. Every extension that is a transfer target has to be present in the Cisco Unity database; otherwise, Cisco Unity cannot transfer the call. This avoids toll fraud by a caller who can call from the PSTN into the AA and then transfer to another PSTN number and end up charging the call to the business that owns the AA.

Cisco Unity can use a consult transfer (sometimes called a supervised transfer) or a blind transfer mechanism to transfer the call to the desired extension. A consult transfer allows the caller to recover and try again if the intended party is busy. Using this method requires a particular setting on Cisco Unity and configuring the transfer-system full-consult command on Cisco CME. Also, all the ephone-dns configured for Cisco Unity port registration must be set for dual line, as shown in Example 18-1. The Cisco Unity setting is shown in Figure 18-4. The important settings here are yes, ring subscriber's extension and supervise transfer for the user the caller is trying to reach. You select options on this page depending on the behavior you want for different subscribers.

Figure 18-4. Configuring Call Transfer Settings

If you experience any issues with Cisco Unity AA transfers, verify the configuration needed for that particular scenario. This means checking the call transfer setting for the user involved in the call. If all the configurations on Cisco Unity are correct, troubleshoot the issue on Cisco CME.

Troubleshooting this issue on Cisco CME is no different from troubleshooting any other call-transfer issue on Cisco CME. Cisco Unity is just another SCCP device like any other IP phone and uses the same protocol mechanism that a real IP phone would use. The debugs of a sample consult call transfer initiated by the Cisco Unity AA are shown in Example 18-8. This example shows a caller placing a call to the Cisco Unity AA and dialing 9003. Cisco Unity establishes a consult call while putting the original call on hold. In this particular case, extension 9003 is busy and Cisco Unity AA retrieves the original call to give the caller an option to try other extensions or leave a message for 9003. If the option selected for this user is blind transfer, the call flow will be different. In this case, Cisco Unity releases the call and asks Cisco CME to set up a call to the specified extension. If the extension is busy, the caller hears busy tone or reaches the user's mailbox, depending on the configuration. You can use the same debug commands to troubleshoot blind transfers.

Example 18-8. Cisco Unity AA Consult Transfer Call Flow

CME#debug ephone detail
*Oct 31 21:51:57.561: ephone-3[5]:SetCallState line 1 DN 10 chan 1 ref 238 TsRingIn
*Oct 31 21:51:57.565: ephone-3[5]:Call Info DN 10 line 1 ref 238 called calling
 2903 origcalled 8050 calltype 1
*Oct 31 21:51:57.565: ephone-3[5]:Call Info for chan 1
*Oct 31 21:51:57.565: ephone-3[5]:Original Called Name Voicemail 1
*Oct 31 21:51:57.565: ephone-3[5]: No-Name calling
*Oct 31 21:51:57.565: ephone-3[5]: Voicemail 1
*Oct 31 21:51:57.565: ephone-3[5]:Ringer Outside Ring On
*Oct 31 21:51:57.797: ephone-3[5]:OFFHOOK
*Oct 31 21:51:57.797: ephone-3[5]:Ringer Off
*Oct 31 21:51:57.797: ephone-3[5]:ANSWER call
*Oct 31 21:51:57.797: ephone-3[5][CiscoUM1-VI1]:Answer Incoming call from
 ephone-(-1) DN -1 chan 1
*Oct 31 21:51:57.797: ephone-3[5]:Incoming Answer: can't find ephone
 calling DN 10 chan 1
*Oct 31 21:51:57.797: defer_start for DN 10 chan 1 at CONNECTED
*Oct 31 21:51:57.797: ephone-3[5]:SetCallState line 1 DN 10 chan 1 ref 238
 TsConnected
*Oct 31 21:51:57.801: DN 10 chan 1 Voice_Mode
*Oct 31 21:51:57.801: ephone-3[5]:OpenReceive DN 10 chan 1 codec 4:G711Ulaw64k
 duration 20 ms bytes 160
*Oct 31 21:51:57.801: ephone-3[5]:OpenReceiveChannelAck:IP 200.1.1.30,
port=22866, dn_index=10, dn=10, chan=1
*Oct 31 21:51:57.801: ephone-3[5]:StartMedia 200.1.1.29 port=2000
*Oct 31 21:51:57.801: DN 10 chan 1 codec 4:G711Ulaw64k duration 20 ms bytes 160
*Oct 31 21:51:58.813: ephone-3[5]:Call Info DN 10 line 1 ref 238 called
 calling 2903 origcalled 8050 calltype 1
*Oct 31 21:51:58.813: ephone-3[5]:Call Info for chan 1
*Oct 31 21:51:58.813: ephone-3[5]:Original Called Name Voicemail 1
*Oct 31 21:51:58.813: ephone-3[5]: No-Name calling
*Oct 31 21:51:58.813: ephone-3[5]: Voicemail 1
*Oct 31 21:52:02.953: dn_tone_control DN=10 chan 1 tonetype=9:DtDtmf9
 onoff=1 pid=158
*Oct 31 21:52:03.153: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence
 onoff=0 pid=158
*Oct 31 21:52:03.253: dn_tone_control DN=10 chan 1 tonetype=10:DtDtmf0
 onoff=1 pid=158
*Oct 31 21:52:03.453: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence onoff=0
 pid=158
*Oct 31 21:52:03.553: dn_tone_control DN=10 chan 1 tonetype=10:DtDtmf0
 onoff=1 pid=158
*Oct 31 21:52:03.753: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence
 onoff=0 pid=158
*Oct 31 21:52:03.853: dn_tone_control DN=10 chan 1 tonetype=3:DtDtmf3
 onoff=1 pid=158
*Oct 31 21:52:04.053: dn_tone_control DN=10 chan 1 tonetype=0:DtSilence
 onoff=0 pid=158
*Oct 31 21:52:07.385: ephone-3[5]:TransferButtonPress
*Oct 31 21:52:07.385: ephone-3 TRANSFER using transfer-system full 
 DN 10 consult transfer 
*Oct 31 21:52:07.385: ephone-3[5]:Transfer with consult line 1 DN 10
 chan 1 using second line 1 DN 10 chan 2
*Oct 31 21:52:07.385: ephone-3[5]:Consult for line 1 DN 10 chan 1 using line 1
 DN 10 chan 2
*Oct 31 21:52:07.385: ephone-3[5]:HoldButtonPress (allow_toggle = 0)
*Oct 31 21:52:07.385: ephone-3[5]:HoldButtonPress HOLD activated for DN 10
 chan 1 
*Oct 31 21:52:07.385: ephone-3[5][CiscoUM1-VI1]:SetCallState line 1 ref 238
 state 10 TsCallTransfer ignored
*Oct 31 21:52:07.385: ephone-3[5]:CloseReceive
*Oct 31 21:52:07.385: ephone-3[5]:StopMedia
*Oct 31 21:52:08.397: PredictTarget match 9003 DN 3 not idle: SIEZE
*Oct 31 21:52:08.397: PredictTarget no idle match for 9003 after 1 attempts
*Oct 31 21:52:08.649: ephone-3[5]:ONHOOK (from phone msgID=7)
*Oct 31 21:52:08.649: ephone-3[5]:TRANSFER quit on line 1 DN 10
*Oct 31 21:52:08.649: ephone-3[5]:SetCallState line 1 DN 10 chan 1
 ref 238 TsHold
*Oct 31 21:52:10.581: dn_tone_control DN=3 chan 1 tonetype=37:DtReorderTone
 onoff=pid=158
*Oct 31 21:52:18.729: ephone-3[5]:SpeakerPhoneOffHook mute 0
*Oct 31 21:52:18.729: ephone-3[5]:OFFHOOK
*Oct 31 21:52:18.729: ephone-3[5]:RestoreHoldCall DN 10 chan 1
*Oct 31 21:52:18.729: ephone-3[5]:RestoreHoldCall using activeLine 1
 activeChan 1
*Oct 31 21:52:18.729: ephone-3[5]:SetCallState line 1 DN 10 chan 1
 ref 238 TsConnected
*Oct 31 21:52:18.729: ephone-3[5]:OpenReceive DN 10 chan 1 codec
 4:G711Ulaw64k duration 20 ms bytes 160
*Oct 31 21:52:18.729: ephone-3[5]:SetCallState line 1 DN 10 chan 1
 ref 238 TsConnected
*Oct 31 21:52:18.733: ephone-3[5]:OpenReceiveChannelAck:IP 200.1.1.30,
 port=22866, dn_index=10, dn=10, chan=1
*Oct 31 21:52:18.733: ephone-3[5]:StartMedia 200.1.1.29 port=2000
*Oct 31 21:52:18.733: DN 10 chan 1 codec 4:G711Ulaw64k duration 20 ms
 bytes 160
*Oct 31 21:52:33.769: dn_tone_control DN=10 chan 1 tonetype=3:DtDtmf3
 onoff=1 pid=158

 

Troubleshooting MWI

Cisco Unity uses a dialout mechanism for MWI. Cisco Unity places a call to a preconfigured number on Cisco CME by going off-hook using a special SCCP message. This special message lets Cisco Unity insert a different calling number than its own. Assume that there is a new voice message for extension 9002. Cisco Unity uses 9002 as the calling number in this special off-hook message and then places a call to one of the MWI DNs (9050 and 9051 in Example 18-1). The special processing of calls by these DNs turns on the MWI light on all the phones associated with extension 9002.

If extension 9002 is associated with button 1 of a phone, the MWI light turns on for that phone. If extension 9002 is associated with any button on the phone other than 1, you see a blinking envelope next to the line on the phone. Example 18-9 shows debug output for turning on MWI for extension 9002. This example uses debug ephone detail. Some of the insignificant debug output has been removed. Important things to note in this debug output are the off-hook message by a Cisco Unity port, dialing the MWI DN by Cisco Unity (KeypadButtonMessage), and the calling number. The call should be from the port assigned just to outdial to the MWI DNs. Also notice the "Set MWI" message for the ephone with extension 9002.

Example 18-9. MWI Call Flow Debugs

CME#debug ephone detail
*Oct 31 22:01:04.505: ephone-7[3]:OFFHOOK with calling party 9002
*Oct 31 22:01:04.505: SkinnyGetCallState for DN 14 chan 1 IDLE
*Oct 31 22:01:04.505: called DN -1 chan 1, calling DN -1 chan 1 phone -1 s2s:0
*Oct 31 22:01:04.505: ephone-7[3]:OFFHOOK
.........
*Oct 31 22:01:04.513: SkinnyGetCallState for DN 14 chan 1 SIEZE
*Oct 31 22:01:04.513: called DN -1 chan 1, calling DN -1 chan 1 phone 7 s2s:0
*Oct 31 22:01:04.513: ephone-7[3]:is_auto_local 0 for DN 14
*Oct 31 22:01:04.513: Skinny StartTone 33 sent on ephone socket [3]
 DtInsideDialTone
*Oct 31 22:01:04.517: ephone-7[3]:KeypadButtonMessage 9
......
*Oct 31 22:01:04.517: ephone-7[3]:StopTone sent to ephone
......
*Oct 31 22:01:04.521: ephone-7[3]:KeypadButtonMessage 0
*Oct 31 22:01:04.521: SkinnyGetCallState for DN 14 chan 1 SIEZE
.........
*Oct 31 22:01:04.521: ephone-7[3]:Store ReDial digit: 90
*Oct 31 22:01:04.521: ephone-7[3]:SkinnyTryCall to 90 instance 1
 start at 0 secondary 0
*Oct 31 22:01:04.525: ephone-7[3]:KeypadButtonMessage 5
*Oct 31 22:01:04.525: SkinnyGetCallState for DN 14 chan 1 SIEZE
......
*Oct 31 22:01:04.525: ephone-7[3]:Store ReDial digit: 905
*Oct 31 22:01:04.525: ephone-7[3]:SkinnyTryCall to 905 instance 1
 start at 0 secondary 0
*Oct 31 22:01:04.525: ephone-7[3]:KeypadButtonMessage 0
*Oct 31 22:01:04.525: SkinnyGetCallState for DN 14 chan 1 SIEZE
*Oct 31 22:01:04.525: called DN -1 chan 1, calling DN -1 chan 1 phone 7 s2s:0
......
*Oct 31 22:01:04.525: ephone-7[3]:SkinnyTryCall to 9050 instance 2
 start at 9 secondary 0
*Oct 31 22:01:04.529: SkinnyUpdateDnState by EFXS_PROCEEDING
 for DN 14 chan 1 to state ALERTING
.........
*Oct 31 22:01:04.533: SkinnyGetCallState for DN 14 chan 1 ALERTING
*Oct 31 22:01:04.533: called DN -1 chan 1, calling DN -1 chan 1 phone 7 s2s:0
*Oct 31 22:01:04.533: ephone-7[3]:SetLineLamp 1 to ON
*Oct 31 22:01:04.533: SkinnyUpdateDnState set call info for DN 14 chan 1
*Oct 31 22:01:04.533: SetCallInfo calling dn 14 chan 1 dn 14 chan 1
calling [A8] called [9050] calling name
*Oct 31 22:01:04.533: SetCallInfo DN 14 chan 1 is not skinny-to-skinny
*Oct 31 22:01:04.533: SkinnyGetCallState for DN 14 chan 1 ALERTING
*Oct 31 22:01:04.533: called DN -1 chan 1, calling DN -1 chan 1 phone 7 s2s:0
*Oct 31 22:01:04.533: ephone-7[3]:DisplayCallInfo outgoing call
*Oct 31 22:01:04.533: ephone-7[3]:SkinnyTryCall to 9050 instance 1
 start at 0 secondary 0
SkinnyTryCall to 9050 instance 1 match DN 8
*Oct 31 22:01:04.533: ephone-7[3]:Call Info DN 14 line 1 ref 248 called
 calling A8 origcalled 9050 calltype 2
*Oct 31 22:01:04.533: ephone-7[3]:Call Info for chan 1
*Oct 31 22:01:04.533: ephone-7[3]: No-Name calling
*Oct 31 22:01:04.537: ephone-7[3]: No-Name
*Oct 31 22:01:04.537: Phone 1 DN 2 MWI on 0 messages
*Oct 31 22:01:04.537: ephone-2[7]:Set MWI line 1 to ON count 0
*Oct 31 22:01:04.537: ephone-2[7]:Set MWI line 0 to ON count 0

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