Cisco Unified MeetingPlace Release 8.0 -- Troubleshooting Phone Issues for Cisco Unified MeetingPlace

From DocWiki

Jump to: navigation, search

Main page: Cisco Unified MeetingPlace, Release 8.0

Up one level: Troubleshooting




Contents

What to Try First When Troubleshooting Calls


Checking the System Status, Alarms, and Logs

Procedure
  1. Sign in to the Administration Center.
  2. Check the system status:
    1. Select Services > System Status.
    2. Select View Status.
    3. Verify that this text appears in the output:
      System mode: Up
      Media control: Up
    4. Verify that none of the modules are in DOWN state.
    5. 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.
  3. Check the Alarm Table:
    1. Select Services > Alarms.
    2. 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 because the Alarm Table combines multiple alarm occurrences into a single table entry.
  4. Check the system logs:
    1. Select Services > Logs > View System Logs.
    2. 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.
    3. Select View Logs.
    4. 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

Checking the Hardware Media Server Status

Procedure
  1. Sign in to the Administration Center.
  2. Select Media Server Administration.
  3. Sign in to the Media Server Administration.
  4. Select Resource Management > MCU.
  5. Verify that this status appears for each configured MCU:
    • Status-Online
    • Connection-Connected
  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.
  7. If an MCU is online but disconnected, the MCU does not have network connectivity.
    1. Check the network connection status for the MCU Ethernet port by selecting the name of an Audio Blade entry.
    2. Select Go TO MCU...
      The Media Server Administrator (MSA) interface appears in a new browser window.
    3. If prompted, sign in to the MSA interface.
    4. Select Board (or Device) in the sidebar.
    5. 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

Checking the Audio Licenses

Procedure
  1. Sign in to the Administration Center.
  2. Select Maintenance > Licenses > Licenses Summary.
  3. Verify that the correct voice conferencing licenses are installed and enabled on your system.
  4. If necessary, reinstall licenses.


Related Topics

How to Resolve Problems with Call Connections


Dial-In Calls Fail

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

Solution: See the What to Try First When Troubleshooting Calls.

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. See the Compatibility Matrix for Cisco Unified MeetingPlace at http://docwiki.cisco.com/wiki/Cisco_Unified_MeetingPlace_Release_8.0_--_Compatibility_Matrix_for_Cisco_Unified_MeetingPlace_Release_8.0.

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:


  1. Sign in to the CLI on the Application Server.
  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.
  3. To troubleshoot a call in real time, complete these steps:
    1. Enter this command:
      eventlog -G -t
    2. Place a test call to the system.
  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
  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.
  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

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.

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:


  1. Sign in to the Administration Center.
  2. Select Media Server Administration.
  3. Sign in to the Media Server Administration.
  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:


  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.
  2. Sign in to Cisco Unified Communications Manager Administration.
  3. Select Device > Trunk.
  4. Find the SIP trunk for Cisco Unified MeetingPlace.
  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.
  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.
  7. Select Save.

Solution: Use the CLI on the Application Server to troubleshoot:


  1. Sign in to the CLI.
  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.
  3. To troubleshoot calls in real time, complete these steps:
    1. Enter this command:
      eventlog -G -t
    2. 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.
  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
  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.
  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.
  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

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.

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

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

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

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.

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:


  1. Sign in to the Application Server CLI.
  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
  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.
  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

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

Problem: DID calls do not connect to the designated meeting.

Solution: Verify the configuration:


  1. Verify that the Route calls to meeting ID that matches DID field on the Usage Configuration Page is set to Yes.
  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.
  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.
  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:


  1. Place a test call to the meeting ID.
  2. Sign in to the Application Server CLI.
  3. Enter this command:
    eventlog | grep DID/DNIS | head
  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)
  5. Verify that the DID phone number actually matches the meeting ID of the desired meeting.


Related Topics

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


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

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

How to Resolve Problems That Occur During Calls


System Does Not Detect Key Presses

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

Solution:


  1. Sign in to the CLI on the Application Server.
  2. Troubleshoot a call in real time by completing these steps:
    1. Enter this command:
      eventlog -G -t
    2. Place a test call to the system.
    3. Press phone keys in response to the voice prompts.
  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
  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.
  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

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:

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

Additional References for Troubleshooting Phone Issues

Topic Documentation

Troubleshooting user access issues

Troubleshooting User Access Issues for Cisco Unified MeetingPlace module

Troubleshooting user issues

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

Troubleshooting the Media Server

Troubleshooting Problems with the Hardware Media Server module

Configuring basic voice and video conferencing

Quick Start Configuration for 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

Rating: 0.0/5 (0 votes cast)

Personal tools