Configuration and Maintenance Guide for MeetingPlace 7.1
Troubleshooting Telephone Issues
Downloads: This chapterpdf (PDF - 243.0KB) The complete bookPDF (PDF - 5.46MB) | Feedback

Troubleshooting Telephone Issues for Cisco Unified MeetingPlace

Table Of Contents

Troubleshooting Telephone Issues for Cisco Unified MeetingPlace

What to Try First When Troubleshooting Calls

Checking the System Status, Alarms, and Logs

Checking the Media Server Status

Checking the Audio 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

How to Resolve Problems That Occur During Calls

System Does Not Detect Key Presses

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

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)

For End Users: While it may be nearly impossible to avoid, users who are prone to triggering false "#" digits usually speak something like "umm" for a relatively long period of time. These sounds should be avoided or at least shortened. Additional References for Troubleshooting Telephone Issues


Troubleshooting Telephone Issues for Cisco Unified MeetingPlace


Release 7.1
Revised: April 3, 2011 8:52 pm

What to Try First When Troubleshooting Calls

How to Resolve Problems with Call Connections

How to Resolve Problems That Occur During Calls

For End Users: While it may be nearly impossible to avoid, users who are prone to triggering false "#" digits usually speak something like "umm" for a relatively long period of time. These sounds should be avoided or at least shortened. Additional References for Troubleshooting Telephone Issues

What to Try First When Troubleshooting Calls

Checking the System Status, Alarms, and Logs

Checking the Media Server Status

Checking the Audio Licenses

Checking the System Status, Alarms, and Logs

Procedure


Step 1 Log in to the Administration Center.

Step 2 Check the system status:

a. Click Services > System Status.

b. Click View Status.

c. Verify that the following 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. Click 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.

Checking the Exception Log is recommended because the Alarm Table combines multiple alarm occurrences into a single table entry.

Step 4 Check the system logs:

a. Click Services > Logs > View System Logs.

b. Set the parameters according to your needs.

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

c. Click View Logs.

d. Repeat Step 4 as needed.

For example, if the output does not include any relevant issues, then 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 Media Server Status

Procedure


Step 1 Log in to the Administration Center.

Step 2 Click Media Server Administration.

Step 3 Log in to the Media Server Administration.

Step 4 Click Resource Management > MCU.

Step 5 Verify that the following appears for each configured MCU:

Status—Online

Connection—Connected

Step 6 If the status of an MCU is unexpectedly offline, then do the following:

a. Click the MCU name.

b. Click the Online radio button.

c. Click OK.

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

Step 8 Check the network connection status for the MCU Ethernet port:

a. Log in to the Administration Center.

b. Click Media Server Administration.

c. Log in to the Media Server Administration.

d. Click Resource Management > MCU in the sidebar.

e. Click the name of an audio blade (MCU) entry.

f. Click Go TO MCU...

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

g. If prompted, log in to the MSA.

h. Click Board in the sidebar.

i. Click the Addressing tab.

j. Verify that the Ethernet Port status matches the port settings on the switch to which the MCU is connected.


Related Topics

Troubleshooting Video Issues for Cisco Unified MeetingPlace module

Checking the Audio Licenses

Procedure


Step 1 Log in to the Administration Center.

Step 2 Click Maintenance > Licenses > Licenses Summary.

Step 3 Verify that the correct voice conferencing licenses are installed and enabled on your system.

Step 4 If necessary, reinstall licenses.


Related Topics

Planning the Capacity of your Cisco Unified MeetingPlace System module in the Planning Guide for Cisco Unified MeetingPlace

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

Dial-In Calls Fail

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

Solution   See "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.

Solution   Make sure that your endpoints are supported for use with Cisco Unified MeetingPlace. .

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 Log into the CLI.

Step 2 To troubleshoot a previous call that occurred at a known time, enter one of the following 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 the following 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.

The following 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, then the call reached Cisco Unified MeetingPlace but was disconnected for some reason.

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

Make sure that the Media Server audio blades are synchronized. 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, then investigate and resolve those issues.

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

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

Your call control device may 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) in Cisco Unified MeetingPlace module

Configuring the Media Server 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 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, then 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 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 Media Server instead of to the endpoint. To see a list of service prefixes, complete these steps:


Step 1 Log in to the Administration Center.

Step 2 Click Media Server Administration.

Step 3 Log in to the Media Server Administration.

Step 4 Click 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, then 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 Log in with your Cisco Unified Communications Manager administrator username and password.

Step 3 Click Device > Trunk.

Step 4 Find the SIP trunk for Cisco Unified MeetingPlace.

Step 5 In the same row as that SIP trunk, click 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, then 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 Click Save.


Solution   Use the CLI to troubleshoot:


Step 1 Log into the CLI.

Step 2 To troubleshoot a previous call that occurred at a known time, enter one of the following 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 the following command:

eventlog -G -t

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

Use the end-user web interface to dial out to 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.

The following 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, the following 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, then investigate and resolve those issues.

Your call control device may 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, then 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 may prevent calls between Cisco Unified MeetingPlace and the call destination.

Your call control device may 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, then 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.


Related Topics

Configuring Call Control for Cisco Unified MeetingPlace module in the Administration Center Page References for Cisco Unified MeetingPlace moduleObtaining 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.

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

Solution   Make sure that the Media Server is correctly configured.

Solution   Make sure that the autonegotiation and duplex settings are correctly configured between the local switch port and the Cisco Unified MeetingPlace Application Server. .

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

Solution   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.

Solution   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.

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

Solution   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.

Solution   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.

Solution   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

How to Resolve Problems with Call Connections

Using the Command-Line Interface (CLI) in Cisco Unified MeetingPlace 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, then you may need to change the Maximum Call Duration Timer service parameter in Cisco Unified Communications Manager.

Solution   Use the CLI to troubleshoot:


Step 1 Log into the CLI.

Step 2 Enter one of the following 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.

The following 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, then 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 may indicate if and why Cisco Unified Communications Manager initiated the disconnect.

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

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

Check the Alarm Table or the Exception Log to for issues that may 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) in Cisco Unified MeetingPlace 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 to check which DID phone number was received by Cisco Unified MeetingPlace:


Step 1 Place a test call to the meeting ID.

Step 2 Log into the CLI.

Step 3 Enter the following 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 following 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 Call Control for Cisco Unified MeetingPlace module

Using the Command-Line Interface (CLI) in Cisco Unified MeetingPlace 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.

Solution   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 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 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 may not work for the pager.

Solution   Check and correct the following 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 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

System Does Not Detect Key Presses

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

Solution   


Step 1 Log into the CLI.

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

a. Enter the following 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.

The following 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, then you may 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 the Installation, Upgrade, and Migration Guide for Cisco Unified MeetingPlace at http://www.cisco.com/en/US/products/sw/ps5664/ps5669/prod_installation_guides_list.html.

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) in Cisco Unified MeetingPlace module

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)

Talk-off is the unexpected detection of a digit (often a # key) by voice systems such as Cisco Unified MeetingPlace.

This is always a statistical possibility due to 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, PSTN voice gateways). Ideally, in-band DTMF detection in these devices will correctly detect digits 100% of the time with no false detection of voice as digits. Practically, a small number of errors -- some voice will be falsely detected as a digit (aka "talk-off") -- are allowed. 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 "*" -- and are ignored, false detection of "#" or "0" can cause unexpected Cisco Unified MeetingPlace behavior.

The Cisco Unified MeetingPlace in-band DTMF detector meets the requirements of the "Bellcore Talk-off Test" specifications. The spec 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 measures at 356 false detects for all these digits with only four false "#" and four false "0" digit detects during this period. So the Cisco Unified MeetingPlace DTMF detector exceeds the Bellcore spec and changes to the DTMF detection algorithm are very unlikely.

Realistically, though, people are all different. Unfortunately, some voices and speech patterns are more prone to triggering the DTMF detector than others, so certain users may have a much higher probability of seeing this problem.

Recommendations:

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

For End Users: Use the best possible audio connection -- a land-line or a good IP connection with G.711. In some cases cordless phones may distort speech enough to make a user prone to talk-off.

For End Users: While it may be nearly impossible to avoid, users who are prone to triggering false "#" digits usually speak something like "umm" for a relatively long period of time. These sounds should be avoided or at least shortened. Additional References for Troubleshooting Telephone Issues

Topic
Documentation

Troubleshooting user access issues

Troubleshooting User Access Issues for Cisco Unified MeetingPlace module

Troubleshooting end-user issues

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

Media Server installation and configuration

 

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

Troubleshooting video issues

Troubleshooting Video Issues for Cisco Unified MeetingPlace module