Troubleshooting Cisco CME and Cisco UE Integration

Cisco CME is the system's call control engine. All calls coming into voice mail to leave or retrieve messages involve an interaction (via SIP) between Cisco CME and Cisco UE. Cisco CME integration with Cisco UE voice mail includes the following activities:

• Forwarding of a call to Cisco UE on busy or ring-no-answer
• Dual-tone multifrequency (DTMF) relay to interact with the voice mail system
• A call transfer from the automated attendant (AA) that forwards into voice mail
• Turning the MWI on or off

Call forwarding into voice mail requires passing the right original called number to the voice mail system so that the correct user's mailbox is selected to play the greeting and leave a message. DTMF relay encompasses the conversion of IP phone keypad digit presses sent via Skinny Client Control Protocol (SCCP) messages from the phone to Cisco CME call control, and from there to Cisco UE via SIP NOTIFY messages. Call transfer from the AA is implemented as a blind transfer using the SIP BYE/Also message sequence.

The most common problems encountered with calls into voice mail are caused by incorrect or incomplete configuration:

• The wrong mailbox selection or no mailbox selection on call forward to voice mail (which might also result in the wrong greeting being played to the caller)
• Digit presses from the phone do not get the required response (in other words, DTMF messages do not reach the application)
• Call transfers from the AA do not work
• Fast-busy tone is heard for calls going to voice mail
• MWI does not operate properly

Correcting each of these problems is discussed in the following sections.

Wrong Mailbox Selection or Unexpected Greeting

Calls to a Cisco CME IP phone can arrive from two different sources:

• A call received from an internal extension, where the dialed number is the phone's extension
• A call received from the PSTN or from another site (routed via H.323 or SIP), where the called number may be the phone's E.164 number

Therefore, depending on what number was dialed, the original called number (also called the last redirecting number in the case of multiple forwards) sent from Cisco CME to Cisco UE is either the internal extension of the called IP phone or the complete E.164 number dialed to reach the IP phone. Cisco UE voice mail must be able to recognize both types of numbers.

Furthermore, when a subscriber calls Cisco UE voice mail directly (for example, to check voice mail), the calling number is used to identify the appropriate mailbox. This calling number may also be an internal extension or a fully qualified E.164 phone number (if the dialplan-pattern command is configured on Cisco CME). Therefore, it is important that the calling number be delivered correctly to Cisco UE for these calls. Various PSTN and Cisco CME configurations may transform (via digit manipulation) the calling number, which may cause the voice mail system to play the wrong prompt. The following sections demonstrate how to identify and rectify these problems.

Call from an Internal Extension to Voice Mail

Example 21-14 shows the output of the debug ccsip messages command on Cisco CME when a call to extension 5010 arrives from internal extension 7010. A SIP INVITE message is sent from Cisco CME to Cisco UE. 7010 is the calling number, used to recognize whether the caller is a subscriber on the system. Subsequently, when the called person listens to the message left in voice mail, this Calling Number field determines which prompts are played. If the calling number of the original call (extension 7010) matches a valid subscriber with a mailbox on Cisco UE, the voice mail system plays "Extension 7010 sent message 1...." If the caller has a spoken name recorded in the system, the system plays "Spoken name sent message 1...." On the other hand, if the calling number does not match any user in the system, the voice mail plays "An unknown caller sent message 1..." or "7010 sent message 1..." if the voicemail callerid configuration on Cisco UE is enabled.

Example 21-14. SIP Debugs for a Call Forwarded to Cisco UE

ccme#debug ccsip messages
INVITE sip:6800@192.168.0.2:5060 SIP/2.0 
Via: SIP/2.0/UDP 192.168.0.1:5060
From: "7010" ;tag=691AE6E4-223C 
To:  
Call-ID: E5D39E6A-8FC011D7-9025DAEC-459632B0@192.168.0.1
CSeq: 101 INVITE
Max-Forwards: 6
Remote-Party-ID: ;party=calling;screen=no;privacy=off
Timestamp: 1054070868
Contact: 
Diversion: ;reason=no-answer;counter=1 

The voice mail pilot number (extension 6800 in Example 21-14). is shown in the To: field of the SIP INVITE message. The most important part of this trace is the Diversion field. It contains the number (extension 5010) that the caller originally called (extension 7010, which shows up in the From: field) before the call was forwarded to voice mail. The value in the Diversion header (5010) is the mailbox number for which the message will be left. Also, the SIP message has a Reason field, which indicates whether the called party did not answer the call or was busy on the phone. Some voice mail systems play different greetings depending on these reason codes, but Cisco UE voice mail currently plays the same prompt for both situations.

There is a case in which a call is forwarded more than once before it reaches voice mail. For example, if extension 5010 forwards its calls to 5012 on busy or ring-no-answer and then 5012 forwards all calls to voice mail, the Diversion header contains 5012 instead of 5010. This can create confusion, because the caller thinks he called 5010 and wants to leave a message for 5010, but instead he gets the voice mail greeting for the person at extension 5012. Cisco CME uses the last redirecting number rather than the original called number for mailbox selection.

Call Using an E.164 Number to Voice Mail

Example 21-15 shows a slightly different variation of a call-forward-to-voice-mail situation. The call comes from the PSTN and goes to an IP phone in E.164 number format (444.555.5010). The original Called Number field in the Diversion header is populated with this E.164 number. If the E.164 field is not configured for this subscriber within the Cisco UE voice mail application, this call does not reach a mailbox, and the caller does not hear the right greeting.

Note

In the following debugs, some output has been removed to show only the most important parts of the trace.

 

Example 21-15. Call Forward When the Called Number Is in E.164 Format

ccme#debug ephone state
ccme#debug ccsip messages
*Mar 4 00:19:34.566: ephone-2[2]:SetCallState line 1 DN 1 chan 1 ref 7 TsRingIn
*Mar 4 00:19:34.566: ephone-2[2]:Call Info DN 1 line 1 ref 7 called 4445555010
 calling 5702 origcalled 4085255010 calltype 1
*Mar 4 00:19:34.566: ephone-2[2]: No-Name calling
*Mar 4 00:19:34.566: ephone-2[2]: 5010
*Mar 4 00:19:34.566: ephone-2[2]:Ringer Outside Ring On
*Mar 4 00:19:44.566: ephone-2[2]:SetCallState line 1 DN 1 chan 1 ref 7 TsOnHook
*Mar 4 00:19:44.566: dn_tone_control DN=1 chan 1 tonetype=0:DtSilence onoff=0
 pid=137
*Mar 4 00:19:44.566: ephone-2[2]:SpeakerPhoneOnHook
*Mar 4 00:19:44.566: ephone-2[2]:Ringer Off
*Mar 4 00:19:44.570: Sent:
INVITE sip:5800@1.3.6.129:5060 SIP/2.0 
Via: SIP/2.0/UDP 1.3.6.29:5060
From: "5702" ;tag=F85274C-2696
To: 
Date: Thu, 04 Mar 1993 00:19:44 GMT
Remote-Party-ID: ;party=calling;screen=no;privacy=off
Timestamp: 731204384
Contact: 
Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=2000"
Diversion: ;reason=no-answer;counter=1 
Expires: 180

If a call fails to get a greeting from the right mailbox, make sure that the recipient subscriber has the E.164 number field configured, as shown in Example 21-16. This also can be done through the GUI's user profile page.

Example 21-16. Checking for an E.164 Number for a Subscriber

cue#show user detail username johndoe
Full Name: John Doe
First Name: John
Last Name: Doe
Nickname: John Doe
Phone: 5010
Phone(E.164): 4445555010 
Language: en_US

If this field is not yet configured, populate it as follows:

cue(config)#username johndoe phonenumberE164 4445555010

Sometimes, when a subscriber directly calls Cisco UE to check voice mail, the person hears the "Enter your ID" prompt instead of the "Enter your password" prompt. The reason could be that the calling number is not delivered properly to the Cisco UE application or the application doesn't recognize the number because of configuration mismatches.

Digit Manipulation

Often Cisco UE voice mail doesn't recognize a calling number because of digit manipulation done by the PSTN voice gateway router or the Cisco CME call control software.

One of the digit manipulation features is the Cisco CME dialplan-pattern command. If configured, Cisco CME call control promotes the extension of an IP phone to the fully qualified E.164 number by inserting the appropriate digits. For instance, extension 5010 is promoted to 444.555.5010.

In this case, the From field in the SIP INVITE from Cisco CME call control to Cisco UE is populated with the E.164 number. For this to work properly, you have to configure the E.164 field for the Cisco UE subscribers, as shown in Example 21-16. To check whether Cisco CME has dial plan patterns configured, use the show telephony-service command, as shown in Example 21-17.

Example 21-17. Verifying the Cisco CME Dial Plan Pattern Configuration

ccme#show telephony-service
CONFIG (Version=3.0)
=====================
Version 3.0ip source-address 10.10.10.1 port 2000
max-ephones 12
max-dn 48
max-conferences 8
huntstop
dialplan-pattern 1 4445555... extension-length 4 
time-format 12
date-format mm-dd-yy

The debug traces shown in Example 21-18 demonstrate the calling number being populated with the E.164 number when the call is sent to the Cisco UE voice mail application.

Example 21-18. Calling Number Delivered in E.164 Format

ccme#debug ccsip messages
SIP Call messages tracing is enabled
c2600-ITS-NM#
Jun 9 08:55:04.214: Sent:
INVITE sip:5800@1.3.6.130:5060 SIP/2.0
Via: SIP/2.0/UDP 1.3.6.30:5060;branch=z9hG4bK373
From: ;tag=1F5DE9-996 
To: 
Date: Sun, 09 Jun 2002 08:55:04 GMT
Call-ID: 6C827377-7ABD11D6-800FA41E-A3784778@1.3.6.30
Supported: timer,100rel
Min-SE: 1800
Cisco-Guid: 1767160890-2059211222-2148312094-2742568824
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
 INFO, UPDATE, REGISTER
CSeq: 101 INVITE
Max-Forwards: 6

Another digit manipulation feature that may convert the calling number is the Cisco IOS translation rule feature. Translation rules might be configured for the calling ephone-dn or for the dial peers governing the incoming PSTN or VoIP calls. Or a global translation rule might be translating calling numbers for every incoming VoIP call using the Cisco IOS voip-incoming CLI. This translation rule might convert the calling number to a different digit string that Cisco UE does not recognize. In this case, correct the Cisco IOS configuration such that the translated calling number matches either the extension or the E.164 field value in the Cisco UE user configuration for the subscriber.

Troubleshooting DTMFNo Response for Digit Presses from Cisco UE

During calls to either voice mail or the AA, the system might not respond to the caller's digit presses. This may be caused by an incorrect configuration on the SIP dial peer directing calls to Cisco UE. It also might be caused by a failed SIP SUBSCRIBE/NOTIFY transaction.

Example 21-19 shows a working DTMF configuration for the SIP dial peer on the Cisco CME router to direct calls to Cisco UE applications. Note the DTMF relay specified as sip-notify. Currently, this is the only DTMF relay option supported by Cisco UE applications. Also note that voice activity detection (VAD) is turned off. The CRS component does not detect DTMF correctly if VAD is enabled for calls.

Example 21-19. SIP Dial Peer on Cisco CME for Cisco UE

ccme#show running-config
dial-peer voice 6800 voip
 destination-pattern 5...
 session protocol sipv2 
 session target ipv4:1.3.6.127
 dtmf-relay sip-notify 
 codec g711ulaw
 no vad 

In the SIP-NOTIFY DTMF relay mechanism, the Cisco UE application subscribes internally to Cisco CME call control for telephony events (in this case, the event is the pressing of a digit) as soon as the call is established. Cisco CME accepts this subscription and sends a NOTIFY to Cisco UE whenever a digit is pressed on the phone.

If the DTMF digits for a call to Cisco UE do not take effect, the configuration of the SIP dial peer is the first place to inspect. There may be other causes of DTMF recognition problems, but the incorrect configuration of the dial peer is by far the most common mistake.

The trace shown in Example 21-20 demonstrates how a digit press on an IP phone is translated to a SIP-NOTIFY DTMF relay event to the application. For every KeypadButtonMessage from the phone, you can see a SIP-NOTIFY message going toward Cisco UE. If these messages do not match, this indicates a failure in the Cisco CME code to translate digit presses to the application, effectively breaking DTMF relay.

Example 21-20. Debug Traces Showing DTMF Relay

ccme#debug ephone detail
EPHONE detail debugging is enabled
ccme#debug ccsip messages
SIP Call messages tracing is enabled
ccme#
*Mar 4 00:34:55.649: ephone-2[2]:Call Info DN 1 line 1 ref 11 called 5700 calling
 5010 origcalled 5700 calltype 2
*Mar 4 00:34:55.649: ephone-2[2]: 5010 calling
*Mar 4 00:34:55.649: ephone-2[2]: No-Name
*Mar 4 00:35:01.949: ephone-2[2]:KeypadButtonMessage 1 
*Mar 4 00:35:01.949: SkinnyGetCallState for DN 1 chan 1 CONNECTED
*Mar 4 00:35:01.949: called DN -1 chan 1, calling DN -1 chan 1 phone 2 s2s:0
*Mar 4 00:35:01.949: Sent:
NOTIFY sip:5700@1.3.6.129:5060 SIP/2.0 
Via: SIP/2.0/UDP 1.3.6.29:5060
From: ;tag=F930B80-674
To: "Cisco SIP Channel3" ;tag=c2e25d00-284
CSeq: 102 NOTIFY
Event: telephone-event;rate=1000
Contact: 
Content-Length: 10
Content-Type: audio/telephone-event

0x01800064 
*Mar 4 00:35:01.949: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.3.6.29:5060
From: ;tag=F930B80-674
CSeq: 102 NOTIFY

*Mar 4 00:35:05.225: ephone-2[2]:KeypadButtonMessage 5 
*Mar 4 00:35:05.225: SkinnyGetCallState for DN 1 chan 1 CONNECTED

NOTIFY sip:5700@1.3.6.129:5060 SIP/2.0 
Via: SIP/2.0/UDP 1.3.6.29:5060
From: ;tag=F930B80-674
To: "Cisco SIP Channel3" ;tag=c2e25d00-284
CSeq: 103 NOTIFY
Contact: 
Content-Type: audio/telephone-event

0x05800064

The highlighted hexadecimal number represents the digits pressed for the SIP protocol NOTIFY message. Table 21-1 shows the mapping of hex values to digit buttons on a phone. The important thing is the first byte in the hex value. The remaining bytes can vary depending on the configuration on the calling gateway.

Table 21-1. Digit-to-SIP Protocol Value Mapping

Digit	SIP Protocol Value
0	0x00800064
1	0x02800064
2	0x02800064
3	0x03800064
4	0x04800064
5	0x05800064
6	0x06800064
7	0x07800064
8	0x08800064
9	0x09800064
*	0x0A800064
#	0x0B800064

The trace segment shown in Example 21-20 ensures that Cisco CME is correctly translating and sending the digits to the Cisco UE application. This does not necessarily mean that digits are reaching the correct component within Cisco UE to which the call is established. Other components of the Cisco UE software must work properly for the digits to take effect. For example, the CRS SIP stack must handle the incoming SIP-NOTIFY event properly, and send the digit to the CRS application software. If this application software is using the voice browser component, the digits have to reach the voice browser properly. As you saw in Chapter 20, "Troubleshooting Cisco UE Automated Attendant," many CRS step customizations change the behavior of DTMF handling in applications. Be sure to verify those customizations if the application script was not supplied as part of the Cisco UE software.

Troubleshooting Automated Attendant Transfers

It may happen that a caller interacting with the Cisco UE AA presses the extension of the user he wants to speak to, but then the call to the extension is unsuccessful, and the caller hears overflow tone instead of a ringing phone. When a caller chooses an extension in the AA, the Cisco UE AA application does a blind transfer operation. This operation might fail for various reasons.

The simplest reason is that the extension chosen does not exist on the Cisco CME router. Other reasons could be a mistake in either the Cisco IOS, Cisco UE software, or Class of Restriction (COR) configuration. For more information on COR and troubleshooting, refer to Chapter 17, "Troubleshooting Advanced Cisco CME Features."

For example, suppose a call goes from the PSTN to the AA, and the caller presses the extension of a phone in the break room. A COR may be configured for the ephone-dn associated with the break room phone such that it may receive calls only from internal phones and not from the PSTN. Check for this kind of configuration before looking more deeply into troubleshooting AA call transfer failures.

Cisco UE uses the SIP BYE/Also message to instruct Cisco CME call control software to execute a call transfer to a requested extension. The SIP BYE/Also mechanism triggers a blind transfer. This means that there are no intermediate steps between initiating the transfer, making sure the destination phone rings, and completing the transfer. A blind transfer is a one-step mechanism in which control of the call is relinquished at the same time that the call is redirected to the new extension, so the Cisco UE application has no further control over the call after the transfer has been executed. So if the caller dials a nonexistent extension or an extension where the phone isn't registered, the caller hears fast-busy (also called overflow) tone.

In the trace shown earlier in Example 21-20, assume that the call was to the Cisco UE AA (instead of voice mail) and that the caller selected dial-by-extension and then pressed the extension of the destination user to talk to.

The trace shown in Example 21-21 shows how Cisco UE executes the transfer using the BYE/Also mechanism. The BYE message is the SIP message to disconnect the original call. The BYE message additionally includes a header called Also, which further tells the Cisco CME call control software to set up a new call to the number specified in the message. This sequence effectively transfers the call.

Example 21-21. SIP Blind Transfer Using BYE/Also by Cisco UE

ccme#debug ccsip messages
*Mar 4 00:35:13.769: Received:
BYE sip:4085255010@1.3.6.29:5060 SIP/2.0 
Via: SIP/2.0/UDP 1.3.6.129:5060
From: ;tag=c2e25d00-284
To: "5010" ;tag=F930B44-165C
Call-ID: E7B1CE85-174E11CC-802B8935-B1821821@1.3.6.29
CSeq: 53 BYE
User-Agent: Jasmin UA / ver 1.1
Max-Forwards: 50
Content-Length: 0
Also:  

The Cisco UE AA before release 2.1 allowed transfers to any digit string. It did not mandate that the destination telephone number must be available or configured in the Cisco UE system's LDAP database.

Using the mechanism just described, a local PSTN caller can potentially call the Cisco CME AA and dial a long-distance or even an international destination telephone number, and the call will be transferred to that number. This effectively executes a hairpinned call (in from the PSTN and back out to the PSTN on the same router) and charges the call to the business hosting Cisco UE. This process can result in toll fraud. If you are using Cisco UE release 2.0 or earlier, you can avoid this by configuring the COR feature on the dial peers pointing to long-distance PSTN numbers so that only select phones may call these numbers. In such cases, it is especially important to consider COR configurations while troubleshooting AA call transfer failures.

The COR configuration introduces some complexity into Cisco CME operation. The other option is to use Cisco UE release 2.1 or higher, which has a configurable parameter in the AA for allowing (or disallowing) external transfers. The GUI screen where you can configure this parameter is shown in Figure 21-5.

Figure 21-5. Allowing or Blocking AA Transfers to External Numbers

If you are writing your own customized AA scripts, you can use the Extension To User step provided in the release 2.1 Cisco UE Script Editor to block transfers to external numbers.

Calls to Cisco UE Get Fast-Busy

Sometimes when a call is placed to Cisco UE (to either the AA or voice mail applications), you may hear fast-busy tone unexpectedly. That may be because the call setup from the originating system (such as a Cisco CME or PSTN voice gateway at another site) may not be using the right codec.

Cisco UE supports only the G.711 µ-law codec with 20-ms packetization. It is important that all the dial peers pointing to Cisco UE on Cisco CME, or from any other PSTN voice gateway, are configured with this codec type. If calls with other types of codecs must be supported, a transcoder must be used to change the call to G.711 before it enters the Cisco UE application. Transcoding with Cisco CME is supported as of release 3.2.

You can check that the codec in the Cisco CME configuration is correct as shown in Example 21-22.

Example 21-22. Dial Peer Configuration for a Codec

ccme#show running-config
dial-peer voice 6800 voip
 destination-pattern 5...
 session protocol sipv2
 session target ipv4:1.3.6.127
 dtmf-relay sip-notify
 codec g711ulaw
 no vad

If Cisco UE is getting calls from other PSTN gateways in the network apart from the Cisco CME host router, another way to verify the codec type used for the calls to Cisco UE is to enable SIP debugging on Cisco UE. In the trace ccn stacksip dbug output shown in Example 21-23, you see that the codec used is pcmu (which is G.711 µ-law).

Example 21-23. SIP Traces on Cisco UE to Identify a Codec

cue#trace ccn stacksip dbug
cue#show trace buffer tail
Press  to exit...
2407 07/26 19:34:50.582 ACCN SIPL 0 -------
INVITE sip:5800@1.4.14.134:5060 SIP/2.0
Via: SIP/2.0/UDP 1.4.14.34:5060;branch=z9hG4bK165B
From: ;tag=372DC22C-19CA
To: 
Date: Mon, 26 Jul 2004 12:27:48 GMT
Call-ID: A3342E0-DE3611D8-80A2AFCE-EEF507D3@1.4.14.34
Supported: 100rel,timer
Min-SE: 1800
Cisco-Guid: 155931842-3728085464-2157948878-4009035731
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
 INFO, UPDATE, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Remote-Party-ID: ;party=calling;screen=no;privacy=off
Timestamp: 1090844868
Contact: 
Call-Info: ;method="NOTIFY;Event=telephone-event;
 Duration=2000"
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 182

v=0
o=CiscoSystemsSIP-GW-UserAgent 2366 3655 IN IP4 1.4.14.34
s=SIP Call
c=IN IP4 1.4.14.34
t=0 0
m=audio 16506 RTP/AVP 0 
c=IN IP4 1.4.14.34 
a=rtpmap:0 PCMU/8000 
a=ptime:20 
Content-Length: 0

In countries where G.711 a-law is used, the conversion from G.711 a-law to G.711 µ-law is done automatically by the Cisco IOS voice infrastructure software and is not a cause for concern for calls to Cisco UE. No additional configuration is needed.

Troubleshooting the TUI and VXML Browser