Child pages
  • Display SIP Message flow using Sipviewer

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Diagnosing complex SIP problems often requires looking at the SIP message flow between the components of sipXecssipXcom, as well as to and from phones and external gateways. This page tells the adventurous how to use the tools that come with sipXecs are available for sipXcom to display SIP message flows. Sipviewer is a very powerful tool used to diagnose problems.


Before you can display the messages, you'll need to install the viewerrun sipx-trace to generate XML files of a SIP call you're interested in and you'll need to install sipviewer on a computer that has a GUI. You can do that either on the sipXecs sipXcom system itself (which requires a few prerequisites not installed by the ISO image, but most of us don't want to run a GUI on the communications server), or standalone on your regular system (Windows, Mac, or Linux). Once you've gotten one of these done, you're ready to collect trace data for viewing.

You'll also want sipxtools installed for sipx-trace (yum install sipxtools).


There is a standalone on your sipXcom server and sipviewer installed on some computer with a GUI and Java (works on Linux, Mac and Windows).


Code Block
yum install sipxtools


SIPViewer Installation

The installer for the sipviewer tool in the temp area on the sipxecs project server:is available here: Download the sipviewer installer

The above installer is a java .jar file - execute it on the command line of your system to run the installer, egas follows:


java -jar sipviewer-install.jar

The installer should work on any system (Linux, Windows, Mac) that has java installed.

On your sipXcom system

On RPM-based distributions sipviewer is installed with the sipxtools RPM. Sipviewer is written in Java and requires an X server to be running to display results graphically.

Getting SIP Messages to display

The SIP messages are logged by sipXecs components sipXcom services when their logging is at the INFO or DEBUG logging level; this is a more verbose level than the default NOTICE level. The log level can be changed in the Web UI by going to "System/General/Logging". You must restart the components for the change in logging level to take effecteach service needed in  the System menu (Proxy, Registrar, etc.). Logging level changes do not require service restarts (they used to in older versions of code).

To get useful trace information, at least the proxy and registrar must be set at INFO or DEBUG (INFO is sufficient for traces, and makes for much smaller log files). You should also have detailed logging for any other component you suspect to be involved in the problem.


search that list for the call that starts at the right time (log times are in UTC), and then use the call-id from that call as the <token> argument to sipx-trace - you'll get just the one call you're after.Then

Alternatively, if you download CDR's from Diagnostic -> Call Detail Records -> Historic (download is on the right, just above the call table). The CSV's include the call id of each call.

Next, use 'sipx-trace' to create an xml file that contains trace data for messages on your system:


  • Install your ssh public key in your account on the sipXecs sipXcom system. You should then be able to execute a command remotely on that system without entering a password:


  • Configure that account so that it can read the sipXecs log files (making the account a member of the 'sipxchange' group should do this).

Now you can execute sipx-trace remotely by adding the --system (-s) argument: