Cisco Unified MeetingPlace, Release 7.0 -- How to Resolve Problems with Call Connections

From DocWiki

Jump to: navigation, search

Main page: Cisco Unified MeetingPlace, Release 7.0

Up one level: Troubleshooting




Contents

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.


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 Video Endpoint Compatibility.


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: Follow this procedure.


  1. Log into the CLI.
  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.
  3. To troubleshoot a call in real time, complete these steps:
    1. Enter the following 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.
    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


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


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



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.


Solution: See What to Try First When Troubleshooting Calls.


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:


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


  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. Log in with your Cisco Unified Communications Manager administrator username and password.
  3. Click Device > Trunk.
  4. Find the SIP trunk for Cisco Unified MeetingPlace.
  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.
  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.
  7. Click Save.


Solution: Use the CLI to troubleshoot:

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


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.


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.


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.


Related Topics





Both Dial-In and Dial-Out Calls Fail

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


Solution: See What to Try First When Troubleshooting Calls.


Solution: Make sure that the Media Server is correctly configured. See Configuring the Media Server Using the MSA Interface.


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 Preparing to Install the Cisco Unified MeetingPlace Web Conferencing 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




Established Calls Get Dropped

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


Solution: See 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, then you may need to change the Maximum Call Duration Timer service parameter in Cisco Unified Communications Manager.


Solution: Use the CLI to troubleshoot:

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


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.


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



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 to check which DID phone number was received by Cisco Unified MeetingPlace:

  1. Place a test call to the meeting ID.
  2. Log into the CLI.
  3. Enter the following 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 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)


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

Rating: 0.0/5 (0 votes cast)

Personal tools