Table Of Contents
Troubleshooting the Cisco Unified MeetingPlace System Configuration
About Troubleshooting the Cisco Unified MeetingPlace System
About Troubleshooting T1 CAS, T1 PRI, and E1 Cisco Unified MeetingPlace Systems
About Troubleshooting IP Ports That Do Not Answer
About Troubleshooting IP Calls That Connect but No Audio is Heard
About Troubleshooting When You Cannot Outdial on IP Ports
Checking the Cisco Unified MeetingPlace Audio Server
Checking the Cisco Unified MeetingPlace H.323/SIP Gateway
Checking Cisco Unified CallManager
Checking the IP Phone
Troubleshooting the Cisco Unified MeetingPlace System Configuration
This chapter contains the following troubleshooting topics:
•
About Troubleshooting the Cisco Unified MeetingPlace System
•About Troubleshooting T1 CAS, T1 PRI, and E1 Cisco Unified MeetingPlace Systems
•About Troubleshooting IP Ports That Do Not Answer
•About Troubleshooting IP Calls That Connect but No Audio is Heard
•About Troubleshooting When You Cannot Outdial on IP Ports
For details on troubleshooting the various Cisco Unified MeetingPlace gateways, see the administration guide for the specific gateway.
Note For more information about the CLI commands referenced in this chapter, see Appendix A, "Command-Line Interface Reference."
About Troubleshooting the Cisco Unified MeetingPlace System
If you have a problem with your Cisco Unified MeetingPlace system, try the following troubleshooting tips first:
•Make sure all cards and transition modules are seated properly.
•Check all cables and connections.
•Verify the card configuration with the blade command.
•Verify the port configuration with the port command.
•Check the error log with the errorlog command.
About Troubleshooting T1 CAS, T1 PRI, and E1 Cisco Unified MeetingPlace Systems
Troubleshooting the configuration for T1 CAS, T1 PRI, and E1 Cisco Unified MeetingPlace systems consists of the following procedures:
•To Troubleshoot T1 CAS, T1 PRI, and E1 Ports That Do Not Answer
•To Check the Port Group Protocol Table
•To Troubleshoot When You Cannot Outdial on T1 CAS, T1 PRI, or E1 Ports
To Troubleshoot T1 CAS, T1 PRI, and E1 Ports That Do Not Answer
Step 1 Access the CLI. If you do not already have terminal logging turned on, turn it on. For information on logging, see the Installation and Upgrade Guide for Cisco Unified MeetingPlace Audio Server.
Step 2 Verify that the span is up by using the spanstat command. If the trunks show no alarms, then the PBX or Telco routing may not be set up correctly or the trunks may be in a lockout state. This is an issue with the PBX or Telco and not with Cisco Unified MeetingPlace.
Use spanstat span_number -all to verify that calls are being presented to the Cisco Unified MeetingPlace system. For T1 CAS, the AB bits change state when a caller dials into the system. For T1 PRI and E1, the call state changes when a caller dials into the system.
A proper incoming call should follow this sequence:
"ds" (incoming call) => "ii" (call active) => ".." (port idle)
A proper outgoing call should follow this sequence:
"sd" (outgoing call) => "oo" (call active) => ".." (port idle)
Note If a "ds" => ".." or "sd" => ".." transition occurs quickly, this indicates that the near-end or far-end, respectively, is rejecting the call. Verify that the port is active on the Cisco Unified MeetingPlace side (near-end) and that the ISDN service is activated on the far-end. Contact Cisco TAC for information on determining the ISDN cause code for the call rejection.
Note If a port stays in any of these states for more than ten seconds, this indicates a possible protocol problem where one side is not clearing down the telephone call all of the way ("do," "di," "od," or "id"). If this is the case, contact Cisco TAC to determine if ISDN messages are being lost.
Step 3 Look for errors on the span by using the spanstat -s command.
Step 4 Verify the correct cabling, as this is frequently reversed:
•pin 1 — MP Receive (tip)
•pin 2 — MP Receive (ring)
•pin 4 — MP Send (tip)
•pin 5 — MP Send (ring)
Note Use a loopback plug to show that the physical ports are serviceable. This lets you move beyond the Cisco Unified MeetingPlace Audio Server and into the carrier for problem analysis.
Step 5 Verify the configuration with the blade command.
Step 6 Check the framing (ESF or D4) and coding (B8ZS or jammed-bit).
Step 7 Check the LEDs on the front of the Cisco Unified MeetingPlace Audio Server, as follows:
•For Cisco Unified MeetingPlace 8112, ensure that the system in service LED light is green.
•For Cisco Unified MeetingPlace 8106 and Cisco Unified MeetingPlace 8112, ensure that the lights for all active T1 Smart Blades are green.
For more information about the LEDs, see the Administration Guide for Cisco Unified MeetingPlace Audio Server.
To Check the Port Group Protocol Table
Verify that the port group, for any troubled port, references the correct protocol table for the ISDN protocol to which it is being interfaced.
Step 1 Access the CLI. If you do not already have terminal logging turned on, turn it on. For information on logging, see the Installation and Upgrade Guide for Cisco Unified MeetingPlace Audio Server.
Step 2 At the tech$ prompt, enter port. The following port command menu appears:
***** P O R T / G R O U P C O N F I G M E N U *****
Step 3 View the port group record by entering 4. The second line in the following example appears:
Enter port group record number [0..31, <cr> for all] : 0
------------ GROUP 0 ---------------
Step 4 Enter the appropriate port group number. In the preceding example, it is 0, so enter 0. The rest of the preceding example appears.
Step 5 Note the protocol table number. In this example, it is protocol table 50.
Step 6 Exit the port command by entering x.
Step 7 Enter protparm. The following example appears:
meetingplace:tech$ protparm
***** P R O T P A R M C O N F I G M E N U *****
1) View protocol parameter table(s)
2) Modify protocol parameter table
4) Delete protocol table(s)
Step 8 View the protocol parameter table by entering 1. The second line in the following example appears:
Enter protocol table number [0..99, <cr> for all] : 50
***** V I E W M E N U *****
2) View general information
3) View incoming called party number processing (DDI)
4) View incoming calling party number processing (CLI)
5) View outgoing calling party information
6) View outgoing called party type of number (TON)
7) View outgoing called party numbering plan (NPI)
8) View outgoing private number definition
9) View outgoing local number definition
a) View outgoing long distance number definition
b) View outgoing international number definition
c) View outgoing Network Specific Facilities (NSF) codes
d) View outgoing NSF Carrier Identification Code (CIC)
Enter list command [table 50]: 2
Step 9 Enter the number of the appropriate protocol table (found in Step 5). In this example, it is 50, so enter 50. The rest of the preceding example appears.
Step 10 View the general information by entering 2. A screen similar to the following appears:
Enter list command [table 50]: 2
----------------- PROTOCOL TABLE 50 ---------------
Description : Euro-ISDN generic table for Europe
CAS signaling table filename : (none)
Default clearing cause : 16 (normal clearing)
B-channel negotiation : exclusive
Enter list command [table 50]: 0
Step 11 Verify that the protocol table has the correct parameters set. If it does not, change it as necessary by going to the main protparm command menu (by entering x) and selecting the modify protocol parameter table option (by entering 2).
Note You cannot modify protocol tables 0 to 49 because they are read-only. If you need to change these tables, copy one of the read-only tables and then modify your copy of the table.
Step 12 Exit the protparm command by entering x.
To Troubleshoot When You Cannot Outdial on T1 CAS, T1 PRI, or E1 Ports
Step 1 Verify that the port and port group are configured for outdial by using the port command. Follow these steps:
a. Access the CLI. If you do not already have terminal logging turned on, turn it on. For information on logging, see the Installation and Upgrade Guide for Cisco Unified MeetingPlace Audio Server.
b. Enter port.
c. View the port records by entering 1.
d. Enter the number of the port whose records you want to see or press Enter to see the records for all the ports. In this example, you want to see the records for all the ports, so press Enter.
e. Look for the outdial parameter and ensure it is set to y for all ports.
Step 2 Verify that the trunks on the phone system are configured to allow outdialing.
Step 3 Schedule a meeting and use the #3 feature to hear if there is an error tone from the phone system.
About Troubleshooting IP Ports That Do Not Answer
For IP ports that do not answer (for example, the caller hears a busy or a fast-busy sound), follow these procedures:
•To Check the Cisco Unified MeetingPlace Audio Server
•To Check the Cisco Unified MeetingPlace H.323/SIP Gateway
•To Check Cisco Unified CallManager
For information on troubleshooting problems with the Cisco Unified MeetingPlace H.323/SIP Gateway, see the Administration Guide for Cisco Unified MeetingPlace H.323/SIP Gateway Release 5.2.1.
To Check the Cisco Unified MeetingPlace Audio Server
Step 1 Access the CLI. If you do not already have terminal logging turned on, turn it on. For information on logging, see the Installation and Upgrade Guide for Cisco Unified MeetingPlace Audio Server.
Step 2 Make sure that the Cisco Unified MeetingPlace Audio Server has IP ports configured and active by using the blade and portstat commands.
Step 3 Log in to the CLI and at the tech$ prompt, enter tvportstat -all.
Step 4 Monitor the output of this command while you make a test call. Verify that the incoming call is seen by the Audio Server.
Step 5 Enter cptrace -T 5.
Step 6 Monitor the output of this command while you make another test call. Verify that the incoming call is seen by the Audio Server.
Step 7 Enter errorlog -s info -l. Scroll through the log by typing f and check for warnings and alarms, especially those that happen in the cpiphandler.cc file. To exit this command, enter q.
Step 8 To verify that the Cisco Unified MeetingPlace Gateway SIM and Cisco Unified MeetingPlace H.323/SIP Gateway services have a status of OK, enter gwstatus.
To Check the Cisco Unified MeetingPlace H.323/SIP Gateway
Step 1 Access the CLI. If you do not already have terminal logging turned on, turn it on. For information on logging, see the Installation and Upgrade Guide for Cisco Unified MeetingPlace Audio Server.
Step 2 To verify that the Cisco Unified MeetingPlace Gateway SIM and Cisco Unified MeetingPlace H.323/SIP Gateway services have a status of OK, enter gwstatus.
Step 3 Verify that the Cisco Unified MeetingPlace H.323/SIP Gateway configuration has the appropriate call control enabled (either H.323 or SIP).
Step 4 Open the Cisco Unified MeetingPlace Gateway SIM event log and make a test call.
Step 5 While looking at the Cisco Unified MeetingPlace Gateway SIM event log, verify that the Cisco Unified MeetingPlace H.323/SIP Gateway receives the test call and that the IP server returns a response code of 0, such as the following:
MP Resp. Msg=3 CPerr=0 SeqNum=0x16
Step 6 Verify that no softphones, such as Microsoft NetMeeting, are running on the Cisco Unified MeetingPlace H.323/SIP Gateway.
Step 7 If Cisco Unified MeetingPlace Web Conferencing is running on the same machine, be sure that Web Conferencing and the Cisco Unified MeetingPlace H.323/SIP Gateway are assigned to different IP addresses.
To Check Cisco Unified CallManager
Step 1 Verify that an H.323 gateway has been created for the Cisco Unified MeetingPlace H.323/SIP Gateway and that a route pattern has been assigned to the Cisco Unified MeetingPlace H.323/SIP Gateway.
Step 2 Verify that the Cisco Unified CallManager server can ping the Cisco Unified MeetingPlace H.323/SIP Gateway and vice versa.
Step 3 In the Cisco Unified CallManager cluster, ensure that the Cisco Unified MeetingPlace H.323/SIP Gateway points at a subscriber and not at a publisher.
About Troubleshooting IP Calls That Connect but No Audio is Heard
To troubleshoot IP calls that connect but no audio is heard, see the following procedures:
•To Check the Cisco Unified MeetingPlace Audio Server
•To Check the Cisco Unified MeetingPlace H.323/SIP Gateway
•To Check the IP Phone
To Check the Cisco Unified MeetingPlace Audio Server
Step 1 Access the CLI. If you do not already have terminal logging turned on, turn it on. For information on logging, see the Installation and Upgrade Guide for Cisco Unified MeetingPlace Audio Server.
Step 2 Verify that the subnet mask address is correct by using the blade command. If the subnet mask address is not correct, Cisco Unified MeetingPlace cannot send voice packets to the phone.
Note You must restart the Cisco Unified MeetingPlace system by using the restart command before any changes can take affect.
Step 3 Enter tvportstat -all.
Step 4 While monitoring the output of this command, make a test call to verify that the Cisco Unified MeetingPlace system sees the IP call.
Step 5 Enter cptrace -T 5.
Step 6 While monitoring the output of this command, make a test call to verify that the Cisco Unified MeetingPlace system sees the IP call.
Step 7 Enter tvportstat port_number_used_in_tests_above -s. Look at "RTCP packets sent by far end" to verify that the phone is transmitting voice data to Cisco Unified MeetingPlace. If the phone is transmitting voice data to Cisco Unified MeetingPlace, there is a one-way connection.
To Check the Cisco Unified MeetingPlace H.323/SIP Gateway
Step 1 Open the Cisco Unified MeetingPlace Gateway SIM event log and verify that the following log entries have the correct IP addresses for each Multi Access Blade that is used for the IP configuration:
MP RTP info. IP=10.10.10.1 Port=5010
MP RTCP info. IP=10.10.10.2 Port=5011
Step 2 While you are still looking at the Cisco Unified MeetingPlace Gateway SIM event log, verify that the following log entries have the correct IP address for the IP phone:
Remote RTP info. IP=10.10.10.3 Port=6510
Remote RTCP info. IP=10.10.10.4 Port=6511
Step 3 Access the CLI. If you do not already have terminal logging turned on, turn it on.
Step 4 To verify that you can reach both the Multi Access Blades and the IP phone, use the ping command to ping the IP addresses of all the Multi Access Blades that are used for the IP configuration and the address of the IP phone.
To Check the IP Phone
Step 1 Press the blue "i" button quickly twice.
Step 2 Verify that the phone is receiving and sending packets (RxCnt and TxCnt).
Step 3 Verify that the expected codec has been negotiated (RxType and TxType).
About Troubleshooting When You Cannot Outdial on IP Ports
Note If you have never been able to outdial on an IP port from your Cisco Unified MeetingPlace system, contact the technician who installed your Cisco Unified MeetingPlace Audio Server so that they can correct the problem.
If you have previously been able to outdial on an IP port from your Cisco Unified MeetingPlace system but are unable to outdial now, do the steps in the following sections:
•Checking the Cisco Unified MeetingPlace Audio Server
•Checking the Cisco Unified MeetingPlace H.323/SIP Gateway
•Checking Cisco Unified CallManager
•Checking the IP Phone
Checking the Cisco Unified MeetingPlace Audio Server
•Is this a general call problem? Verify that incoming calls to the Cisco Unified MeetingPlace system are connecting. If they are not, follow the procedure in the "About Troubleshooting IP Ports That Do Not Answer" section.
•Are there any failure indications? Note the error message you get when you attempt to outdial.
–If you use the activity command, note the text message that is displayed after the failure.
–If you join a meeting and use #3 to outdial, note the audio message you hear when the outdial fails.
Note If you use the activity command and see the message "Placing call... Call was unsuccessful: General outdial error, check the exlog," then enter errorlog -s info -l to see what error information was written to the exlog. Scroll through the log by entering f and check for warnings and alarms, especially those that happen in the cpiphandler.cc and cpplacecall.cc files. To exit this command, enter q. You may see the following:
08/18 12:57:46 WARN 0x300d9 0/8, "vuiactgen.cc", 1706 (0xc23, 0x3, 0xfff0020, 0x9a)
Place Call Failed. Erc 3107, App 3, App Data 268369952, Expected App 154
In this case, contact Cisco TAC and include this error information in the problem description.
•Is this a port group configuration problem? Use the port command to verify that the port group is enabled for outgoing calls.
•Does the call even make it out of the system? The Cisco Unified MeetingPlace translation table may be wrong. In this case, the call might not have been placed or the call was placed but the network rejected it. To check for these possibilities do the following:
–Access the CLI. If you do not already have terminal logging turned on, turn it on. At the tech$ prompt, enter cptrace -T 5.
–Recreate the outdial issue by either using the #3 option (if you are already in a meeting) or by opening a new CLI and running the activity command.
–Look at the information displayed on the CLI that is running the cptrace command. If a specific port number is given (anything of the form "P nnn") then the call actually went out. You should see something similar to the following:
08/18 13:36:05.31 P 298 Outdial : UserID 3 RetCode 0
Dest 1019R Trans Dest 1019R
The preceding example shows a successful attempt to outdial to the number 1019.
–At the tech$ prompt, enter cptrace -t -v. If you see nothing, try the same call again but enter cptrace -T 5. If you see an example similar to the following, Cisco Unified MeetingPlace placed the call:
08/18 13:43:44.62 P 299 Cmd: PRE-OPEN ChanHndl: 0x000b
Near End: IP Addr 172.27.6.128 RTP Port 16110
If the output from running both the cptrace -t -v and cptrace -t -T 5 commands shows examples similar to the preceding ones, Cisco Unified MeetingPlace placed the call and the call was placed to an IP port. Any network audio messages you hear from doing a #3 outdial from a meeting may explain why the network did not accept the call.
If you see only one or neither of the two preceding examples, the problem is within Cisco Unified MeetingPlace and most likely within the outcall translation table. Contact Cisco TAC so they can modify the translation table.
•For outcalls not being placed by Cisco Unified MeetingPlace, attempt a number of outdials to internal extensions, local numbers, long distance numbers (with both 11 digits [1 + area code + number] and 10 digits [area code + number] dialing), and international numbers (011 + international number dialing). Try to determine if all outcalls fail or just some. The specific number patterns that fail will help Cisco TAC determine what is wrong with the translation table.
•For outcalls placed by Cisco Unified MeetingPlace but rejected by the network, assuming that IP outcalls were recently working, check the following:
–Have Cisco Unified CallManager routing tables been changed recently?
–Has any aspect of your network changed recently, such as new switches, routers, hubs, or changes to the existing infrastructure?
–Have the PSTN settings for the IP to PSTN gateway changed recently?
–Have you recently changed your PSTN provider or the plan under your original provider? If so, for T1 PRI and E1 connections, the NSF, numbering plan identifier, or type of number codes may need to change or for T1 CAS connections, the type of signaling may have changed. For example, the old service may have used loop start but the new service uses E&M wink start.
Checking the Cisco Unified MeetingPlace H.323/SIP Gateway
To Check the Cisco Unified MeetingPlace H.323/SIP Gateway
Step 1 Open the Cisco Unified MeetingPlace Gateway SIM event log and verify that the Cisco Unified MeetingPlace H.323/SIP Gateway receives the outdial command from the Cisco Unified MeetingPlace system.
Step 2 Still looking at the Cisco Unified MeetingPlace Gateway SIM event log, verify that the H.323/SIP Gateway received the correct phone number.
MeetingPlace IP outdial. Phone=651515 IRC=0 PSTN=46 Unit=0
Step 3 In the H.323/SIP Gateway configuration, verify that the outdial is sent using the appropriate protocol.
Step 4 In the H.323/SIP Gateway configuration, verify that the gateway, gatekeeper, and proxy server addresses and ports are correct according to the desired protocol.
Step 5 In the H.323/SIP Gateway configuration, verify that the E.164 address and H.323 ID fields are correct for H.323 outdials. Verify that the display name, user name, and session name are correct for SIP outdials.
Checking Cisco Unified CallManager
To Check Cisco Unified CallManager
Step 1 If the Cisco Unified MeetingPlace H.323/SIP Gateway resides on a gateway with multiple IP addresses, verify that Cisco Unified CallManager has an H.323 gateway configuration for each IP address.
Step 2 Verify that the gateway settings created for the H.323/SIP Gateway allow outdials.
Checking the IP Phone
Verify that the IP phone can place a direct call to the requested outdialed number.
Feedback
