Configuration Guide for Cisco Unified MeetingPlace Release 8.5
Troubleshooting Phone Issues
Download this chapter
Troubleshooting Phone IssuesTroubleshooting Phone Issues
 Feedback

Table Of Contents

Troubleshooting Phone Issues for Cisco Unified MeetingPlace

What to Try First When Troubleshooting Calls

Checking the System Status, Alarms, and Logs

Checking the Hardware Media Server Status

Checking Licenses

How to Resolve Problems with Call Connections

Dial-In Calls Fail

Dial-Out Calls Fail

Both Dial-In and Dial-Out Calls Fail

Established Calls Get Dropped

Direct Inward Dial (DID) Call Does Not Connect to Meeting

User Does Not Receive "Find Me" Calls for a Meeting

User Does Not Receive "Find Me" Calls to a Non-Direct-Dial Pager

User Dials Into Conference and Hears Nothing After Entering Meeting ID

How to Resolve Problems That Occur During Calls

System Does Not Detect Key Presses

Outdials from Cisco WebEx Fail and Do Not Ring the Destination

One-Way Audio—User Cannot Be Heard By Other Participants

User "Talk-Off" (Triggering the Pound Key with Your Voice)

Troubleshooting General Sound Quality Issues

Using Debug Wave Recordings

Initiating DWR During a Phone Conference

Configuring the DWR Feature

Using the CLI taccli Tool

One-Way Audio Troubleshooting

Detecting CPU Utilization Overload

Additional References for Troubleshooting Phone Issues


Troubleshooting Phone Issues for Cisco Unified MeetingPlace

Release 8.5
Revised: January 11, 2013 1:19 pm

•What to Try First When Troubleshooting Calls

•How to Resolve Problems with Call Connections

•How to Resolve Problems That Occur During Calls

•Troubleshooting General Sound Quality Issues

•Additional References for Troubleshooting Phone Issues

What to Try First When Troubleshooting Calls

•Checking the System Status, Alarms, and Logs

•Checking the Hardware Media Server Status

•Checking Licenses

Checking the System Status, Alarms, and Logs

Procedure

Step 1 Sign in to the Administration Center.

Step 2 Check the system status:

a. Select Services > System Status.

b. Select View Status.

c. Verify that this text appears in the output: 

System mode: Up

Media control: Up

d. Verify that none of the modules are in DOWN state.

e. If the system status details indicate an unexpected DOWN state, check the Alarm Table or the Exception Log to see why the module or system is down, and resolve the issue.

Step 3 Check the Alarm Table:

a. Select Services > Alarms.

b. If the alarm table displays a relevant alarm entry, check the Exception Log for actual relevance to and details for the failed call.

We recommend checking the Exception Log i because the Alarm Table combines multiple alarm occurrences into a single table entry.

Step 4 Check the system logs:

a. Select Services > Logs > View System Logs.

b. Set the parameters according to your needs.

For example, you might want to first limit the displayed output to major log entries for the day when the issues occurred.

c. Select View Logs.

d. Repeat Step 4 as needed.

For example, if the output does not include any relevant issues, expand the output to include lower severity levels.

If you see relevant log entries for specific Module Numbers, you can narrow the log output to issues for a specific module.

Related Topics

•Using Alarms and Logs on Cisco Unified MeetingPlace module

•Troubleshooting Video Issues for Cisco Unified MeetingPlace module

Checking the Hardware Media Server Status

Procedure

Step 1 Sign in to the Administration Center.

Step 2 Select Media Server Administration.

Step 3 Sign in to the Media Server Administration.

Step 4 Select Resource Management > MCU.

Step 5 Verify that this status appears for each configured MCU:

•Status—Online

•Connection—Connected

Step 6 If the status of an MCU is unexpectedly offline, see Changing the Online and Offline Status of an Audio Blade in the Changing Values for the Hardware Media Server module.

Step 7 If an MCU is online but disconnected, the MCU does not have network connectivity.

a. Check the network connection status for the MCU Ethernet port by selecting the name of an Audio Blade entry.

b. Select Go TO MCU...

The Media Server Administrator (MSA) interface appears in a new browser window.

c. If prompted, sign in to the MSA interface.

d. Select Board (or Device) in the sidebar.

e. Select the Addressing tab.

See About the Addressing Tab in the Configuring the Audio and Video Blades for the Hardware Media Server module.

Related Topics

•Viewing the Status of the Hardware Media Server in the Configuring the Hardware Media Server Using the MSA Interface module

•Changing the Online and Offline Status of an Audio Blade in the Changing Values for the Hardware Media Server module

•Troubleshooting Video Issues for Cisco Unified MeetingPlace module

Checking Licenses

Procedure

Step 1 Sign in to the Administration Center.

Step 2 Select Maintenance > Licenses > Licenses Summary.

Step 3 Verify that licenses are installed and enabled on your system.

Step 4 If necessary, reinstall licenses.

Related Topics

•Planning Guide for Cisco Unified MeetingPlace at http://www.cisco.com/en/US/products/sw/
ps5664/ps5669/products_implementation_design_guides_list.html

•Installing and Managing Licenses for Cisco Unified MeetingPlace module

•Troubleshooting Video Issues for Cisco Unified MeetingPlace module

How to Resolve Problems with Call Connections

•Dial-In Calls Fail

•Dial-Out Calls Fail

•Both Dial-In and Dial-Out Calls Fail

•Established Calls Get Dropped

•Direct Inward Dial (DID) Call Does Not Connect to Meeting

•User Does Not Receive "Find Me" Calls for a Meeting

•User Does Not Receive "Find Me" Calls to a Non-Direct-Dial Pager

•User Dials Into Conference and Hears Nothing After Entering Meeting ID

Dial-In Calls Fail

Problem   Users who call Cisco Unified MeetingPlace hear dead air or a busy signal.

Recommended Action    See the "What to Try First When Troubleshooting Calls" section.

Possible Cause    Some third-party terminals are incompatible with and cannot establish connections with Cisco Unified MeetingPlace.

Recommended Action    Make sure that your endpoints are supported for use with Cisco Unified MeetingPlace. See the Compatibility Matrix for Cisco Unified MeetingPlace at http://www.cisco.com/en/US/products/sw/ps5664/ps5669/products_device_support_tables_list.ht ml.

Possible Cause    Assuming that the phone number was dialed correctly, and that call routing is set up correctly:

–Dead air generally implies that call setup is failing for some reason, or that some device (such as Cisco Unified MeetingPlace or Cisco Unified Communications Manager) is completely unresponsive.

–A busy signal means that some device knew that the call could not be answered and responded with a busy indication. This could mean that a device is down or that all resources (such as ports on Cisco Unified MeetingPlace or bandwidth on a link) are in use.

Solution   

Step 1 Sign in to the CLI as su or root on the Application Server.

Step 2 To troubleshoot a previous call that occurred at a known time, enter one of these commands, specifying a start time (-b) shortly before the failed call attempt and a stop time (-e) shortly after the failed call attempt:

•For a call on the current day: eventlog -G -b hhmm -e hhmm

For hhmm, enter the two-digit hour (in 24-hour format) and two-digit minute, according to the local server time of the Application Server.

•For a call on a previous day: eventlog -G -b [YY]MMDDhhmm -e [YY]MMDDhhmm

For MMDD, enter the two-digit month and two-digit day. Specify the two-digit year YY if you are troubleshooting issues around the start of a new calendar year.

Step 3 To troubleshoot a call in real time, complete these steps:

a. Enter this command:

eventlog -G -t

b. Place a test call to the system.

Step 4 Read the log output to see how the system responds to the incoming call.

This sample log output shows a successfully completed dial-in call: 

[mpxadmin@example-server ~]$ eventlog -G -b 1030 -e 1040 

07/15 10:36:43.14  P 0    RN MC s=013 mcpIncomingCallNotification

07/15 10:36:43.14  P 0    SE CP m=018 NEWCALLEVENT Resp 0

07/15 10:36:43.14  P 0    Leg=134217732 Dialed=9007@172.27.106.63: ANI=1881@172.27.99.180 
GCID=96E8CEEA529411DD97F60018FE735D02

07/15 10:36:43.14  P 0    RQ CP m=018 CPANSWERCALL

07/15 10:36:43.14  P 0    SQ MC s=013 mcpAnswerCallRequest

07/15 10:36:43.62  P 0    RR MC s=013 mcpAnswerCallResponse Resp 0

07/15 10:36:43.62  P 0    SR CP m=018 CPANSWERCALL Resp 0

07/15 10:36:43.65  P 0    RN MC       mcpMediaActiveNotification (audio:HC, video:off)

07/15 10:36:43.65  P 0    SE CP m=018 UPDATEMEDIAEVENT Resp 0

07/15 10:36:44.63  P 0    RQ CP m=018 CPPLAYFILELIST

07/15 10:36:44.63  P 0    SQ MC s=013 mcpPlayFileListRequest

07/15 10:36:44.63  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

07/15 10:36:49.25  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 0

07/15 10:36:49.25  P 0    SR CP m=018 CPPLAYFILELIST Resp 0

07/15 10:36:49.26  P 0    RQ CP m=018 CPPLAYFILELIST

07/15 10:36:49.26  P 0    SQ MC s=013 mcpPlayFileListRequest

07/15 10:36:49.26  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

07/15 10:36:55.50  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 22

07/15 10:36:55.50  P 0    SR CP m=018 CPPLAYFILELIST Resp 0

07/15 10:36:55.51  P 0    RN MC s=013 mcpHangupNotification

07/15 10:36:55.51  P 0    SE CP m=018 HANGUPEVENT Resp 0

07/15 10:36:55.51  P 0    RQ CP m=018 CPDISCONNECT

07/15 10:36:55.51  P 0    SQ MC s=013 mcpDisconnectCallRequest

07/15 10:36:55.51  P 0    RR MC s=013 mcpDisconnectCallResponse Resp 0

07/15 10:36:55.51  P 0    SR CP m=018 CPDISCONNECT Resp 0

Step 5 If some log messages appear but the call was not successfully completed, the call reached Cisco Unified MeetingPlace but was disconnected for some reason.

•If the log messages identify a reason for disconnecting the call, investigate and resolve those issues.

•Make sure that the Hardware Media Server audio blades are synchronized. See Synchronizing an Audio Blade or Synchronizing Audio Blades after Adding a Video Blade in the Changing Values for the Hardware Media Server module.

•In the System Information Capture log, check for Media Server log messages that indicate SIP negotiation issues. If the log identifies reasons for SIP negotiation issues, investigate and resolve those issues.

Step 6 If no log messages appear, the call never reached Cisco Unified MeetingPlace.

•Check for and reconfigure any firewalls that might be preventing the call from reaching Cisco Unified MeetingPlace.

•Your call control device might not be configured properly. In Cisco Unified Communications Manager, make sure that the route patterns and trunks are configured correctly.

Related Topics

•Configuring Call Control for Cisco Unified MeetingPlace module

•How to Resolve Problems with Call Connections

•Obtaining and Viewing the System Information Capture (Infocap) Log in the Using Alarms and Logs on Cisco Unified MeetingPlace module

•Using the Command-Line Interface (CLI) on the Cisco Unified MeetingPlace Application Server module

•How to Configure Logging Levels in the Using Alarms and Logs on Cisco Unified MeetingPlace module

Dial-Out Calls Fail

Problem   Dial-out calls do not work.

Solution   Make sure that the user has dial-out privileges. See "Enabling Dial-Out Privileges for Users" in the Configuring Dial-Out Features for Cisco Unified MeetingPlace on MeetingPlace-Scheduled and Audio-Only Deployments module.

Solution   See the "What to Try First When Troubleshooting Calls" section.

Solution   If the failed dial-out calls are trying to reach an H.323 endpoint, make sure that the directory number (DN) of the endpoint is not the same as any of the service prefixes that are configured in the Hardware Media Server. Because you cannot modify the service prefixes, you must instead modify the DN of the endpoint.

When the endpoint DN matches a service prefix, Cisco Unified MeetingPlace forwards the call to the Hardware Media Server instead of to the endpoint. To see a list of service prefixes, complete these steps:

Step 1 Sign in to the Administration Center.

Step 2 Select Media Server Administration.

Step 3 Sign in to the Media Server Administration.

Step 4 Select Resource Management > Meeting Types.

Service prefixes are listed in the Prefixes column.

Solution   If all dial-out calls are rejected with a "401 Unauthorized" response, you need to disable digest authentication for the SIP trunk in Cisco Unified Communications Manager. Complete these steps:

Step 1 Go to http://ccm-server/, where ccm-server is the fully-qualified domain name or IP address of the Cisco Unified Communications Manager server.

Step 2 Sign in to Cisco Unified Communications Manager Administration.

Step 3 Select Device > Trunk.

Step 4 Find the SIP trunk for Cisco Unified MeetingPlace.

Step 5 In the same row as that SIP trunk, select the link in the SIP Trunk Security Profile column.

The SIP Trunk Security Profile Configuration page appears.

Step 6 Uncheck Enable Digest Authentication.

Note If other trunks also use this SIP trunk security profile and require digest authentication, you should instead create a SIP trunk security profile specifically for the Cisco Unified MeetingPlace SIP trunk. See the Security Guide for your release of Cisco Unified Communications Manager at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html.

Step 7 Select Save.

Solution   Use the CLI on the Application Server to troubleshoot:

Step 1 Sign in to the CLI as su or root.

Step 2 To troubleshoot a previous call that occurred at a known time, enter one of these commands, specifying a start time (-b) shortly before the call failed and a stop time (-e) shortly after the call failed:

•For a call on the current day: eventlog -G -b hhmm -e hhmm

For hhmm, enter the two-digit hour (in 24-hour format) and two-digit minute, according to the local server time of the Application Server.

•For a call on a previous day: eventlog -G -b [YY]MMDDhhmm -e [YY]MMDDhhmm

For MMDD, enter the two-digit month and two-digit day. Specify the two-digit year YY if you are troubleshooting issues around the start of a new calendar year.

Step 3 To troubleshoot calls in real time, complete these steps:

a. Enter this command:

eventlog -G -t

b. Place a test dial-out call by doing one of the following:

–Use the Cisco Unified MeetingPlace web user portal to call your phone.

–Open a separate SSH session to the Application Server. As the root user, enter the activity command to make a test call without any specific ports.

Step 4 Read the log output as the system attempts to dial out.

This sample log output shows a successfully completed dial-out call to phone number 1004: 

mpxadmin@example-server ~]$ eventlog -G -b 08281040 | more 

08/28 10:40:39.96         RQ CP m=017 CPPLACECALL

08/28 10:40:39.96         SQ MC s=013 mcpPlaceCallRequest

08/28 10:40:39.96  P 0    RR MC s=013 mcpPlaceCallResponse Resp 0

08/28 10:40:39.98         RN MC s=013 mcpCallProgressNotification

08/28 10:40:39.99         RN MC s=013 mcpCallProgressNotification

08/28 10:40:42.59         RN MC s=013 mcpCallProgressNotification

08/28 10:40:42.62  P 0    RN MC       mcpMediaActiveNotification (audio:HC, video:off)

08/28 10:40:42.62  P 0    SE CP m=017 UPDATEMEDIAEVENT Resp 0

08/28 10:40:42.70  P 0    RC MC s=013 mcpPlaceCallCompletion Resp 0

08/28 10:40:42.70  P 0    SR CP m=017 CPPLACECALL Resp 0

08/28 10:40:42.70  P 0    Leg=520093713 Dialed=1004 ANI=outdial 
GCID=6E3D0FA9752811DDA3630018FE735D02

08/28 10:40:43.70  P 0    RQ CP m=017 CPPLAYFILELIST

08/28 10:40:43.70  P 0    SQ MC s=013 mcpPlayFileListRequest

08/28 10:40:43.70  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

08/28 10:40:45.78         RQ CP m=017 CPOPENFILE

08/28 10:40:45.78         Create: conf/028314/guest_2187.wav

08/28 10:40:45.78         SR CP m=017 CPOPENFILE Resp 0

08/28 10:40:48.31  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 0

08/28 10:40:48.31  P 0    SR CP m=017 CPPLAYFILELIST Resp 0

08/28 10:40:48.31  P 0    RQ CP m=017 CPPLAYFILELIST

08/28 10:40:48.31  P 0    SQ MC s=013 mcpPlayFileListRequest

08/28 10:40:48.31  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

08/28 10:40:53.75  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 0

08/28 10:40:53.75  P 0    SR CP m=017 CPPLAYFILELIST Resp 0

08/28 10:40:56.61  P 0    RQ CP m=017 CPPLAYFILELIST

08/28 10:40:56.61  P 0    SQ MC s=013 mcpPlayFileListRequest

08/28 10:40:56.61  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

08/28 10:41:02.05  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 0

08/28 10:41:02.05  P 0    SR CP m=017 CPPLAYFILELIST Resp 0

08/28 10:41:03.64  P 0    RN MC s=013 mcpHangupNotification

08/28 10:41:03.64  P 0    SE CP m=017 HANGUPEVENT Resp 0

08/28 10:41:03.66  P 0    RQ CP m=017 CPDISCONNECT

In contrast, this sample log output shows a dial-out call that failed, most likely because the dialed number was invalid and rejected by Cisco Unified Communications Manager. The error response 3105 indicates a general dial-out failure: 

08/28 10:39:02.41         RQ CP m=017 CPPLACECALL

08/28 10:39:02.41         SQ MC s=013 mcpPlaceCallRequest

08/28 10:39:02.46  P 0    RR MC s=013 mcpPlaceCallResponse Resp 0

08/28 10:39:02.47         RN MC s=013 mcpCallProgressNotification

08/28 10:39:02.49         RN MC s=013 mcpCallProgressNotification

08/28 10:39:32.48  P 0    RC MC s=013 mcpPlaceCallCompletion Resp 19

08/28 10:39:32.48  P 0    SR CP m=017 CPPLACECALL Resp 3105

Step 5 If the log messages indicate that Cisco Unified Communications Manager or the far-end gateway responded to the call attempts:

•If the log messages identify a reason for disconnecting the call, investigate and resolve those issues.

•Your call control device might not be configured properly. In Cisco Unified Communications Manager, make sure that the route patterns and trunks are configured correctly.

•In the System Information Capture log, check for Media Server log messages that indicate SIP negotiation issues. If the Media Server log messages identify a reason for the SIP negotiation issues, investigate and resolve those issues.

Step 6 If the log messages show no response from Cisco Unified Communications Manager or the far-end gateway:

•Check for and reconfigure any firewalls that might prevent calls between Cisco Unified MeetingPlace and the call destination.

•Your call control device might not be configured properly. In Cisco Unified Communications Manager, make sure that the route patterns and trunks are configured correctly.

Step 7 If no log messages appear, Cisco Unified MeetingPlace was unable to dial out.

•Make sure that Cisco Unified MeetingPlace is configured to find SIP proxies:

–On the SIP Configuration Page, configure the SIP domain name field to match the SIP domain used by the SIP proxy servers or your local Cisco Unified Communications Manager node. In Cisco Unified Communications Manager, the SIP domain is specified under System > Enterprise Parameters in the Organization Top Level Domain field.

–On the SIP Configuration Page, configure a SIP Proxy Server by entering at least one Hostname or IP address.

•Make sure that the Media Server is correctly configured. See the Setting Initial Values for the Hardware Media Server module.

Related Topics

•Configuring Call Control for Cisco Unified MeetingPlace module

•Field Reference: SIP Configuration Page in the Administration Center Page References for Cisco Unified MeetingPlace module

•Obtaining and Viewing the System Information Capture (Infocap) Log in the Using Alarms and Logs on Cisco Unified MeetingPlace module

•How to Resolve Problems with Call Connections

Both Dial-In and Dial-Out Calls Fail

Problem   Both dial-in and dial-out calls fail.

Recommended Action    See the "What to Try First When Troubleshooting Calls" section.

Recommended Action    Make sure that the Media Server is correctly configured. See the Setting Initial Values for the Hardware Media Server module.

Recommended Action    Make sure that the autonegotiation and duplex settings are correctly configured between the local switch port and the Cisco Unified MeetingPlace Application Server. See Reviewing Duplex Setting Requirements in the Installing the Cisco Unified MeetingPlace Application Server Software module.

To change the duplex settings on the Application Server, sign in to the CLI as the root user, and use the net command to change the duplex settings.

Recommended Action    Make sure that the Cisco Unified MeetingPlace Application Server is connected to a single switch port instead of a multiple-device Ethernet bus. Cisco Unified MeetingPlace works best when micro-segmented to use a single switch port. Sharing a bus with other devices can cause excessive collisions, which reduce bandwidth and cause unpredictable bandwidth availability.

Recommended Action    Check for and reconfigure any firewalls between the phone and Cisco Unified MeetingPlace.

Possible Cause    Network congestion. You can take a trace of network traffic as close as possible to the Application Server eth0 port.

Recommended Action    Reduce traffic in the local LAN by adding more switches and distributing the network devices between them.

Recommended Action    Reduce the number of devices (and thus the traffic) on the local LAN by adding more routers to create more (but smaller) LANs. There might also be unused ports on the local router, in which case more routers are not needed.

Recommended Action    Change network device settings to reduce unnecessary traffic. For example, add access lists to the local router to filter out irrelevant traffic.

Possible Cause    Bad frames were received.

Some phones provide network error statistics about how many bad frames have been received. See if the particular phone has these statistics. If so, see if the phone has registered receiving a large number of bad frames.

Recommended Action    Check the configuration of the device that routes calls to Cisco Unified MeetingPlace. In Cisco Unified Communications Manager, make sure that the route patterns and trunks are configured correctly.

Related Topics

•Configuring Call Control for Cisco Unified MeetingPlace module

•Field Reference: SIP Configuration Page in the Administration Center Page References for Cisco Unified MeetingPlace module

•How to Resolve Problems with Call Connections

•Using the Command-Line Interface (CLI) on the Cisco Unified MeetingPlace Application Server module

Established Calls Get Dropped

Problem   Successfully connected calls between users and Cisco Unified MeetingPlace get dropped.

Solution   See the "What to Try First When Troubleshooting Calls" section.

Solution   If meeting participants are consistently dropped after a certain period of time (for example, 12 hours) after meetings begin, you might need to change the Maximum Call Duration Timer service parameter in Cisco Unified Communications Manager.

Solution   Use the CLI on the Application Server to troubleshoot:

Step 1 Sign in to the Application Server CLI as su or root.

Step 2 Enter one of these commands, specifying a start time (-b) shortly before the call was dropped and a stop time (-e) shortly after the call was dropped:

•For a call on the current day: eventlog -G -b hhmm -e hhmm

For hhmm, enter the two-digit hour (in 24-hour format) and two-digit minute, according to the local server time of the Application Server.

•For a call on a previous day: eventlog -G -b [YY]MMDDhhmm -e [YY]MMDDhhmm

For MMDD, enter the two-digit month and two-digit day. Specify the two-digit year YY if you are troubleshooting issues around the start of a new calendar year.

This sample log output shows a normal dial-in call that was intentionally disconnected by the caller: 

[mpxadmin@example-server ~]$ eventlog -G -b 1030 -e 1040 

07/15 10:36:43.14  P 0    RN MC s=013 mcpIncomingCallNotification

07/15 10:36:43.14  P 0    SE CP m=018 NEWCALLEVENT Resp 0

07/15 10:36:43.14  P 0    Leg=134217732 Dialed=9007@172.27.106.63: ANI=1881@172.27.99.180 
GCID=96E8CEEA529411DD97F60018FE735D02

07/15 10:36:43.14  P 0    RQ CP m=018 CPANSWERCALL

07/15 10:36:43.14  P 0    SQ MC s=013 mcpAnswerCallRequest

07/15 10:36:43.62  P 0    RR MC s=013 mcpAnswerCallResponse Resp 0

07/15 10:36:43.62  P 0    SR CP m=018 CPANSWERCALL Resp 0

07/15 10:36:43.65  P 0    RN MC       mcpMediaActiveNotification (audio:HC, video:off)

07/15 10:36:43.65  P 0    SE CP m=018 UPDATEMEDIAEVENT Resp 0

07/15 10:36:44.63  P 0    RQ CP m=018 CPPLAYFILELIST

07/15 10:36:44.63  P 0    SQ MC s=013 mcpPlayFileListRequest

07/15 10:36:44.63  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

07/15 10:36:49.25  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 0

07/15 10:36:49.25  P 0    SR CP m=018 CPPLAYFILELIST Resp 0

07/15 10:36:49.26  P 0    RQ CP m=018 CPPLAYFILELIST

07/15 10:36:49.26  P 0    SQ MC s=013 mcpPlayFileListRequest

07/15 10:36:49.26  P 0    RR MC s=013 mcpPlayFileListResponse Resp 0

07/15 10:36:55.50  P 0    RC MC s=013 mcpPlayFileListCompletion Resp 22

07/15 10:36:55.50  P 0    SR CP m=018 CPPLAYFILELIST Resp 0

07/15 10:36:55.51  P 0    RN MC s=013 mcpHangupNotification

07/15 10:36:55.51  P 0    SE CP m=018 HANGUPEVENT Resp 0

07/15 10:36:55.51  P 0    RQ CP m=018 CPDISCONNECT

07/15 10:36:55.51  P 0    SQ MC s=013 mcpDisconnectCallRequest

07/15 10:36:55.51  P 0    RR MC s=013 mcpDisconnectCallResponse Resp 0

07/15 10:36:55.51  P 0    SR CP m=018 CPDISCONNECT Resp 0

Step 3 If the log includes a far-end disconnect event, the disconnect was probably initiated outside of Cisco Unified MeetingPlace.

Check for errors on the devices between the phone and Cisco Unified MeetingPlace. In a Cisco Unified Communications Manager environment, contact the Cisco Unified Communications Manager administrator to get a call session trace, which might indicate if and why Cisco Unified Communications Manager initiated the disconnect.

Step 4 If the log does not include a far-end disconnect event, the disconnect was probably initiated by Cisco Unified MeetingPlace.

•If the log messages identify a reason for disconnecting the call, investigate and resolve those issues.

•Check the Alarm Table or the Exception Log to for issues that might have caused the system to drop calls.

Related Topics

•Configuring the Maximum Call Duration in Cisco Unified Communications Manager in the Integrating Cisco Unified MeetingPlace with Cisco Unified Communications Manager module

•Using the Command-Line Interface (CLI) on the Cisco Unified MeetingPlace Application Server module

•How to Resolve Problems with Call Connections

Direct Inward Dial (DID) Call Does Not Connect to Meeting

Problem   DID calls do not connect to the designated meeting.

Solution   Verify the configuration:

Step 1 Verify that the Route calls to meeting ID that matches DID field on the Usage Configuration Page is set to Yes.

Step 2 Verify that Cisco Unified Communications Manager is configured with a valid route pattern:

•The Route Pattern field contains the meeting ID.

•The Gateway/Route List field specifies the SIP trunk to Cisco Unified MeetingPlace.

Step 3 Schedule a test meeting using these parameters:

•Meeting ID: Use one that already has a matching route pattern in Cisco Unified Communications Manager.

•Time: Now.

Step 4 Place a test call to the meeting ID.

Solution   Use the CLI on the Application Server to check which DID phone number was received by Cisco Unified MeetingPlace:

Step 1 Place a test call to the meeting ID.

Step 2 Sign in to the Application Server CLI.

Step 3 Enter this command:

eventlog | grep DID/DNIS | head

Step 4 Read the log output to see which DID phone number was received by the system.

For example, in the output, the phone (with extension number 7178) dialed the DID phone number 1717. 

08/11 13:51:54.14  P 0       In Call  : DID/DNIS 1717, ANI 7178 ============= (1)

Step 5 Verify that the DID phone number actually matches the meeting ID of the desired meeting.

Related Topics

•Configuring Direct Inward Dial on MeetingPlace-Scheduled and Audio-Only Deployments module

•Configuring Call Control for Cisco Unified MeetingPlace module

•Using the Command-Line Interface (CLI) on the Cisco Unified MeetingPlace Application Server module

•How to Resolve Problems with Call Connections

User Does Not Receive "Find Me" Calls for a Meeting

Problem   A user does not receive Find Me calls for a meeting.

Possible Cause    The meeting was scheduled from Microsoft Outlook. Users are invited from the Microsoft Outlook directory and cannot be invited by Cisco Unified MeetingPlace profile. Therefore, Cisco Unified MeetingPlace treats everyone as a guest user. This limitation prevents the system from automatically dialing out to users using the Find Me feature.

Recommended Action    Have the user dial in to the meeting.

Related Topics

•About the Find Me Feature in the Configuring Dial-Out Features for Cisco Unified MeetingPlace on MeetingPlace-Scheduled and Audio-Only Deployments module

•Enabling Cisco Unified MeetingPlace Scheduling from Microsoft Outlook module

User Does Not Receive "Find Me" Calls to a Non-Direct-Dial Pager

Problem   User does not receive Find Me calls on a non-direct-dial pager.

Possible Cause    Non-direct-dial pagers are pagers do not have individual phone numbers. Instead, a common phone number is shared by multiple pagers, each of which is identified by a unique PIN. For details, see "How the Find Me Feature Works with Pagers" in the Configuring Dial-Out Features for Cisco Unified MeetingPlace on MeetingPlace-Scheduled and Audio-Only Deployments module.

In Cisco Unified MeetingPlace, the common pager phone number shared is configured in the Phone number for non-direct-dial pagers field in the user group. The PIN, on the other hand, is configured in the Pager number field in the user profile.

Problems occur when the Group name is modified to move a user profile from one user group to another. The Phone number for non-direct-dial pagers for the new user group might not work for the pager.

Recommended Action    Check and correct these settings:

–Phone number for non-direct-dial pagers field in the user group

–PIN in the Pager number field in the user profile

Related Topics

•About the Find Me Feature in the Configuring Dial-Out Features for Cisco Unified MeetingPlace on MeetingPlace-Scheduled and Audio-Only Deployments module

User Dials Into Conference and Hears Nothing After Entering Meeting ID

Problem   User dials into Cisco Unified MeetingPlace and hears nothing after entering meeting ID.

Possible Cause    The refer trunk configuration may be wrong.

Recommended Action    Check the refer trunk configuration on the Cisco Unified Communications Manager (CUCM) cluster.

Possible Cause    The Cisco Unified MeetingPlace node hostname might match the Cluster Fully Qualified Domain Name (CFQDN) parameter that is configured in the CUCM Enterprise Parameters.

Recommended Action    Check if there the CFQDN parameter is configured in the CUCM Enterprise Parameters (System > Enterprise Parameters). Either remove the configuration in CFQDN or configure the CFQDN with a pattern that does not match the Cisco Unified MeetingPlace nodes.

Related Topics

•Configuring a SIP Route Pattern for Each Node in the Configuring Call Control for Cisco Unified MeetingPlace module

How to Resolve Problems That Occur During Calls

•System Does Not Detect Key Presses

•One-Way Audio—User Cannot Be Heard By Other Participants

•User "Talk-Off" (Triggering the Pound Key with Your Voice)

System Does Not Detect Key Presses

Problem   The system does not detect user input through the telephone user interface (TUI).

Solution   

Step 1 Sign in to the CLI as su or root on the Application Server.

Step 2 Troubleshoot a call in real time by completing these steps:

a. Enter this command:

eventlog -G -t

b. Place a test call to the system.

c. Press phone keys in response to the voice prompts.

Step 3 In the log, look for DTMFEVENT and mcpLegNotification messages, each pair of which would indicate that Cisco Unified MeetingPlace received the user input of a single digit.

This sample log output shows that at 10:42:04, a caller on port 0 pressed the "1" key on the phone: 

08/28 10:42:04.95  P 0    RN MC       mcpLegNotification (1)

08/28 10:42:04.95  P 0    SE CP m=017 DTMFEVENT Resp 0

Step 4 If you do not see DTMFEVENT and mcpLegNotification messages in the log, make sure that your call-control devices are set up to transport DTMF digits:

•In Cisco Unified Communications Manager SIP trunks to Cisco Unified MeetingPlace, make sure that the DTMF Signaling Method is set to No Preference.

•If the call passes through a voice gateway, you might need to configure that gateway to use DTMF relay to transport DTMF digits.

•On the Media Parameters Page, try setting the Enable in-band DTMF detection field to Yes.

•Make sure that the Media Server is correctly configured. See Setting Initial Values for the Hardware Media Server.

Step 5 If you do see DTMFEVENT and mcpLegNotification messages in the log, check the Alarm Table for TUI-related issues, and resolve them.

Related Topics

•Using the Command-Line Interface (CLI) on the Cisco Unified MeetingPlace Application Server module

Outdials from Cisco WebEx Fail and Do Not Ring the Destination

Problem   The outdials from Cisco WebEx fail and do not ring the destination.

Possible Cause    The outdial proxy setting in the Cisco Unified MeetingPlace node (System Configuration > Call Configuration > SIP Configuration > SIP Proxy Server) is missing.

Recommended Action    Configure the outdial proxy setting on all the Cisco Unified MeetingPlace conferencing nodes.

Possible Cause    The CUCM may be missing the translation pattern to handle the outdial requests.

Recommended Action    Check if CUCM has a translation pattern to handle the outdial requests coming in from the SIP trunk to Cisco Unified MeetingPlace. The outdial numbers will be in the form of E.164 with a leading "+."

One-Way Audio—User Cannot Be Heard By Other Participants

Problem   User gets one-way audio only. User can hear the voice meeting, but other participants cannot hear the user.

Solution   Make sure that the user is not muted:

•Have the user check for a mute button on the phone or video endpoint.

•If still in the voice meeting, have the user press #5 on the phone, in case another meeting participant muted the line.

User "Talk-Off" (Triggering the Pound Key with Your Voice)

Problem   Talk-off is the unexpected detection of a digit (often a # key) by voice systems such as Cisco Unified MeetingPlace. While most cases of talk-off cause no reaction in Cisco Unified MeetingPlace during a meeting (false detection of any number "1" to "9" or "*" are ignored), false detection of "#" or "0" can cause unexpected Cisco Unified MeetingPlace behavior.

Talk-off is a statistical possibility because of the imperfect nature of in-band (voice and DTMF sharing the same voice channel) DTMF tone-detection algorithms in any voice device (Cisco Unified MeetingPlace, and PSTN voice gateways). Ideally, in-band DTMF detection in these devices will correctly detect digits with no false detection of voice as digits. Practically, a small number of errors are allowed, and some voice will be falsely detected as a digit.

Solution   The Cisco Unified MeetingPlace in-band DTMF detector meets the requirements of the Bellcore Talk-off Test specifications. This specification allows up to 500 false detections of any digit "0" to "9", "#" and "*" after the three-hour test with real voice snippets. Cisco Unified MeetingPlace DTMF detector exceeds the Bellcore specification and changes to the DTMF detection algorithm are not needed.

Unfortunately, some voices and speech patterns are more prone to triggering the DTMF detector than others, and certain users might have a much higher probability of seeing this problem.

Recommendations:

Note KPML is only supported on Hardware Media Server systems.

•For system administrators: Use out-of-band digit transmission (RFC-2833, KPML) wherever possible. However, using RFC-2833 might only shift the talk-off problem from the Cisco Unified MeetingPlace DTMF detector to a voice gateway DTMF detector.

•For users: Tell users to use the best possible audio connection; for example, a land line or a good IP connection with G.711. In some cases, cordless phones might distort speech enough to make a user prone to talk-off.

While it might be nearly impossible to avoid, users who are prone to triggering false "#" digits usually speak "umm" for a relatively long period of time. These sounds should be avoided or at least shortened.

Troubleshooting General Sound Quality Issues

Use the following methods to analyze general sound quality issues:

•Using Debug Wave Recordings

•Using the CLI taccli Tool

•One-Way Audio Troubleshooting

•Detecting CPU Utilization Overload

Using Debug Wave Recordings

If you are having issues with poor audio quality, use Debug Wave Recording (DWR) voice captures to analyze the problem. The DWR feature lets you capture sample debug wave recordings for debug reporting.

This feature was made configurable in 8.5 MR3. Earlier versions have the feature always turned ON.

Initiating DWR During a Phone Conference

You can initiate DWR from your telephone (DTMF or RFC-2833 digits only; DWR does not work for KPML).

Procedure

Step 1 When you are in a conference and experience poor audio quality, press 1-3-7-9-5-0 on your telephone keypad to initiate a 30-second DWR.

DWR generates recording files on your conference node. A short beep indicates the start of your recording. Note the approximate start time of the capture.

Step 2 After your recording is finished, the system admin can recover the DWR files from the conference node. The DWRs are located in the /mpx-record/conf/dwr directory on the node. Each file has the format:

- dwrAAA_BBBB...B_cXXX_epYYYY_date_time.pZZ.wav

See the table below for the key to the DWR output:

Field
Description

AAA

Unique session ID for particular DWR

BBBB...B

Hostname (up to 16 characters)

XXX

Conference ID

YYYY

Endpoint ID; for mixer recordings this will be an empty string

date

Format MMDDYY

time

Format hhmmss, 24-hour clock

ZZ

Stream ID:

•98: recording point, conference slice, output from mixer

•00: recording point, main point before entering mixer

•01: recording point, after decoding RTP packet

•02: recording point, after first level of processing

•03: recording point, before encoding packet for endpoint


Sample output: dwr000_zaharije.lab.pst_c749_ep_072610_115605.p01.wav

Step 3 Compress and email your relevant recordings (all recordings for a particular time period) to your Cisco representative for analysis along with a description of the issue.

DWR has the following limitations when you initiate it from a phone:

•For small conferences of five or fewer users, all ports are recorded. For conferences larger than five users, only one port is recorded (the port that initiates the recording).

•For each port, five files are generated: four for various recording points and one for conference mix output. For a conference with five users, 25 files are generated.

•Only one recording session can be run at a time per node.

•Recordings for a particular session only occur for ports on the conference node. Ports still in the IVR session on a different node will not be recorded until they are referred to the conference node

Configuring the DWR Feature

If you are running versions 8.5 MR3, the DWR feature is turned OFF by default. To capture DTMF strings to troubleshoot poor audio quality, configure the DWR feature to the ON setting.

Procedure

Step 1 Sign in to the Application Server CLI as su or root.

Step 2 Enter vi /opt/cisco/meetingplace/meetingplace.profile to view or edit the meetingplace.profile file.

Step 3 Scroll through the file to look for the export DTMF_PARSER_ENV =<ON/OFF> statement.

–If the statement is not in the file, enter the statement and specify if you want the feature ON or OFF.

Note The ON and OFF settings are case sensitive.

–If the statement is in the file, change the ON/OFF setting to the desired setting.

Step 4 Enter mpx_sys restart to restart the server.

Step 5 After your recording is finished, the system admin can recover the DWR files from the conference node. The DWRs are located in the /mpx-record/conf/dwr directory on the node. Each file has the format:

- dwrAAA_BBBB...B_cXXX_epYYYY_date_time.pZZ.wav

See the table in Initiating DWR During a Phone Conference for the key to the DWR output.

Using the CLI taccli Tool

You can initiate recording using the node mpxadmin CLI taccli tool, option 14. A taccli recording includes the following features:

•The duration is configurable 10 to 60 seconds

•All conference ports are recorded without conference size limitations.

Note Five files are generated for each port, and for a large conference there may be a very large number of files generated. Cisco does not recommend that you use this tool to generate more than 1700 files at a time.

Compress and email your relevant recordings (all recordings for a particular time period) to your Cisco representative for analysis along with a description of the issue.

One-Way Audio Troubleshooting

To determine if one-way audio issues may be due to firewall blocking one of the two stream directions, we recommend using taccli option 2.

Step 1 Identify one of the affected channels (ports).

Step 2 Sign in to the Application Server CLI as su or root.

Step 3 Use taccli option 1 to display all channels and note the Channel ID.

Step 4 Run taccli option 2 to display the affected channel.

Step 5 For one-way audio in the receive stream (inbound) direction, check if the Total Audio Pkts Recv counts are increasing. If the count has stopped, then the firewall is likely blocking the stream from the endpoint. If the count is increasing, then there is an issue with the Cisco Unified MeetingPlace conference node.

Step 6 For one-way audio in the sending stream (outbound) direction, check if the Total Audio Pkts Sent counts are increasing. If the count has stopped, then there is some issue with the Cisco Unified MeetingPlace conference node. If the count is increasing, then the firewall might be blocking the stream to the endpoint.

One-way audio checks can also be used for initial "dead-air" troubleshooting.

Detecting CPU Utilization Overload

Audio quality problems can be caused by SMS CPU utilization overload. The symptoms in order of occurrence are

1. Jitter

2. Your system slows down

3. Gaps begin to occur

4. Eventually you experience complete silence

To determine if your system is experiencing SMS CPU utilization overload, you must read its CPU utilization.

Procedure

Step 1 Sign in to the CLI as su or root.

Step 2 To list CPU utilization 20 times every 3 seconds, enter the command sar -u 3 20. 

03:45:40 PM 	CPU 	%user 	%nice 	%system 	%iowait 	%idle

03:45:43 PM 	all 	0.13 	0.00 	0.08 	0.00 	99.79

If your %idle is less than 25% it is possible that SMS is overloaded.

Additional References for Troubleshooting Phone Issues

Topic
Documentation

Troubleshooting user access issues

Troubleshooting User Access Issues for Cisco Unified MeetingPlace module

Troubleshooting user issues

Administration Guide for Cisco Unified MeetingPlace at http://www.cisco.com/en/US/products/sw/ps5664/ps5669/prod_troubleshooting_guides_list.html

Troubleshooting the Media Server

Troubleshooting Problems with the Hardware Media Server module

Configuring basic voice and video conferencing

Quick Start Configuration: Cisco Unified MeetingPlace Basic Voice and Video Conferencing module

Call control configuration

Configuring Call Control for Cisco Unified MeetingPlace module

QoS, network management, and overall network design for Cisco Unified Communications

Cisco Unified Communications Solution Reference Network Design (SRND) at http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

Troubleshooting video issues

Troubleshooting Video Issues for Cisco Unified MeetingPlace module