cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1415
Views
1
Helpful
0
Comments
Meddane
VIP
VIP
Web Admin: Status > General

When troubleshooting a configuration issue with Cisco Meeting Server the best place to start is the Status > General page on the Web Admin. This page will tell you if the Call Bridge has any issues.

The middle section is where any current live configuration issues will be identified. For example, the figure shows that the Call Bridge cannot connect to one of the Web Bridges and it seems that there is DNS failure.

The last section is showing any recent errors so even if you have fixed the problem, the error will still appear in this table.

The table will also show errors that are not live issues. For example, in the figure the connection to the Active Directory has a problem of invalid credentials and the sync fails then the fault appears in this table.

 

Meddane_0-1676189805983.png

Event Logs

If the Status > General page shows an error but does not give you enough information to be able to solve the problem, then the next place to go is the event logs (Logs > Event Logs). The event logs are very detailed, it shows all the events that have occurred on the Call Bridge with a time stamp.

The event logs only show events for the Call Bridge, the Call Bridge is the heart of the solution and is the service that initiates all the connections to other services, such as Web Bridge, Active Directory, SIP Trunks.

 

Meddane_1-1676189805989.png

Detailed Tracing

If the event log does not show enough information about an issue then you can increase the logging level to show more detailed information. If you go to the Logs > Detailed tracing page, you can increase the logging level for specific aspect of the configuration. For example, if you are having problems connecting between the Call Bridge and the Web Bridge then you could increase the Web Bridge connection tracing and more details about the connection will be displayed.

The detailed trace can be enabled for a fixed period of time so that it is not accidentally left enabled  because this can have a performance impact on the CMS.

Another interesting event logs that can be displayed in more details is the SIP traffic tracing, this Trace is useful to troubleshoot a SIP call for users that tries to join a meeting using a video telepresence system or Jabber client.

 

Meddane_2-1676189805992.png

Detailed SIP Trace below shows the output from a SIP trace displaying the SIP INVITE message and all the SIP messages that flow between the Call Bridge, the Call Control and the endpoint including the Session Description Protocol (SDP) capabilities exchange.

 

Meddane_3-1676189806000.png

The syslogs can also be viewed in your SSH session by typing the command syslog follow, live output of the logs will be displayed in the SSH console.

Note: Syslog follow is also a way to keep an SSH session active.

 

Meddane_4-1676189806002.png

 

Meddane_5-1676189806011.png

SFTP Files

If you are still having trouble resolving the problem, then there are other files that can be useful on the CMS. These files can be retrieved using SFTP to your PC for investigation.

The Live.JSON file shows the current live configuration of the server including all the certificates, service configuration, and API configured settings. The Live.JSON file is a useful file in order to look for configuration error. For example, you can see in the Live.JSON file all the IPv4 and IPv6 ports that are used and which services are using them which can help if there is a port conflict when enabling the services.

Meddane_6-1676189806023.png

The Boot.JSON file is the same as the Live.JSON file except that it is the configuration at the point the server was booted. So you can compare the two files in order to see if any of the configuration has changed which might help to resolve your issue.

 

Meddane_7-1676189806035.png

The audit log can also be useful to help show what has changed and by who. The audit log can be useful as it will show what the system has change and not just the administrators.  So, it might highlight something that is happening that you were not aware of. Below the audit log displays the scheduler commands executed by the admin user.

 

Meddane_8-1676189806040.png

Debug File

Another file you can generate on the server is a debug file. A debug file is a detailed breakdown of everything on the server including network, firewall, database, and file information. Usually, this file is aimed at the Cisco TAC to help them have a more detailed look at the server and what is happening in trying to resolve your problems. However, it is always worth looking in the debug file before raising a case with the Cisco TAC as it may highlight something.

 

Meddane_9-1676189806059.png

Log Bundle File

If you need to raise a case with the TAC, then they will require some of these files by default. To save time, there is a file on the server called logbundle.tar.gz which is a compressed file containing all relevant log files. As the diagram shows, this file will have most of what the TAC requires in the first instance to start looking at your issue. So before raising a case download this file ready to be added to your ticket.

 

Meddane_10-1676189806085.png

Packet Capture

If none of the logging tools are helping you to diagnose your fault in connecting devices, then you may have to take a packet capture. The Cisco Meeting Server command line allows you to capture all the IP packet traversing an interface on the server.

The packet capture file (pcap) is created on the server and can be downloaded onto your device and opened with a tool like Wireshark enable you view the communications between the server and the client.

The figure above shows a pcap trace captured using the command pcap <interface>, then the capture file downloaded to the desktop and opened in Wireshark. Recall, most communication in Cisco Meeting Server will be encrypted but it is useful to see the communication going backwards and forwards to understand how far through a connection process the devices have got before they fail. The Wireshark trace below shows the TLS exchange and a SIP Dialog between two devices.

 

Meddane_11-1676189806107.png

API Space Diagnostic

Another option for understanding call quality issues is to perform a diagnostic on a space. The diagnostics on a space will show the all the connection information on the space including call stats, SDP capability sets, and ICE candidates. The space diagnostic can be useful to isolate this information for a particular space whereas the syslog, event log and traces will include all calls to isolating a particular problem for a specific space can be harder. Therefore, if the problem relates to a specific space use the API diagnostics to make the troubleshooting easier.

To create the diagnostic is a multi-step process. You have to navigate to the API page in the Web Admin then find and expand the calls object to locate your space. If you click on the space, it will give you a list of other objects related to this space including /diagnostics.

 

Meddane_12-1676189806117.png

If you click on this link and click Create, it will generate a point in time diagnostic for your space and add another link on the page ending in /contents.

Click on this /contents link and you will see the diagnostics for your space.

 

Meddane_13-1676189806123.png

 

Meddane_14-1676189806128.png

You can download the diagnostic file in txt format by navigating to Status > General.

 

Meddane_15-1676189806131.png

 

Meddane_16-1676189806139.png

 

 

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: