Avaya Message Sequence Trace (MST) Demystified

4 characteristics to use the Message Sequence Trace Utility.

In this post Avaya MST Demystified you learn 4 different characteristics to utilize the Message Sequence Trace Utility or MST. To help you debug and understand the reasoning to why some events might happened to way they do, and present that data to your peers to fix or adjust any issues.

As an engineer I get to use the Message Sequence Trace utility to take a quick snippet of any elements participating on the call flow that I might be task to work on. In other occasions I use it to extract call events to compare them with other system traces from a SBCE or ASM, AES, ISDN, H.323 Registrations among others. 

Here are the 4 characteristics of the MST Utility:

• 1.- Understand what it is
• 2.- Benefits and drawbacks of the MST
• 3.- MST commands
• 4.- Extracting MST files.

1.– Understand what it is

The Message Sequence Trace Utility began in the early 1990’s due to the complexity of determining how and why internal processing was affecting undesirable end-user functions. The tool acts a debug logger tracing tool capturing different evens from extension button presses, lighting lamps, etc. Each process invokes a request and respond to each event. Because of the level of debugging this tool offers it can easily crash the system if not configured correctly.

What kind of events you may ask?

Well for staters you can collect information on telephony internal protocols such as CCMS (Control Channel Message Set), call vectoring, denial events, and others. It also examines external protocols like SIP, H.323, H.225, ISDN-PRI/BRI, CDR, etc.

Besides protocols you can capture information on physical and logical ports. From Port Networks (Trunk/Station/TDM-BUS/Circuit-Packs), Media Gateways, and IP-Endpoints to Processor Errors and Denial Events.

Message Sequence Trace – MST

2.- Benefits of the Message Sequence Trace Utility

The real benefit is knowing what type of data to extract to tell you more about what is going on under the hood. Providing you more details of each event related to the elements that you are troubleshooting. Keep in mind this tool is for data collection only.

For example on ISDN-PRI, extracting the Q931 Signaling messages show the call flow and conversation sequence between the Service Provider and CM.

On another example you can extract SIP Messages to show the SIP Headers and Message Body of each SIP transaction. The same is true if you are working with 3rd Party Call Center applications using DMCC station off the CM Server.

With each of the ‘types of MST Messages’ (CCMS, x.25, ISDN, etc) there will likely be additional ‘types of information’ related tot he particular MST message Type. For instance a particular CCMS message might contain a VDT_UPD, MNT_MSG, or LIN_ULM, etc. message To or From a particular endpoint calling from some particular action to be taken.

On another example you can extract SIP Messages to show the SIP Headers and Message Body of each SIP transaction. The same is true if you are working with 3rd Party Call Center applications using DMCC station off the CM Server.

Here are some of the benefits of MST

• Help understand and troubleshoot the state of each call by extracting Trunk/Station/MG/PN slot information.
• Comes with the MTA utility to make it human readable.
• Associates an Event/Process/Call ID or classifier to help you track the call flow.

Drawbacks

• There is buffer limit depending the CM version.
• It can crash the system if not configured correctly.
• Traces are hard to read and understand.
• Difficult to extract specific events without the correct tools.
• DADMIN Level login is needed to extract the Internal CM Data of each station, trunk, VDN, etc.

3.– MST Commands

• First. – Before you start debugging any type of protocols or system events, it is a good practice to see if the MST has been previously enabled. The “status mst” shows you the time that it was enabled. “clear mst” is the command that you want to run to reset the trace.
• Second –  Bring all triggers back to their factory settings by running the “change mst default” command.
• Third – Decide which triggers need to be enabled and run the “change mst”. The more triggers you enabled the easier it is to capture the desired data.
• Fourth – “ enable mst” is the command that you need to run to start capturing.
• Fifth – “status mst” checks the status.
• Sixth – “disable mst” stops capturing.
• Seventh – “clear mst” to clear the CM MST buffer.

4.– Extracting MST files.

There are three ways to extract the MST debug logs. On legacy systems you can “list mst” while capturing the output into a local file. You can then take the file to extract the messages.

Using the Web-Console or SMI is the second option, and the third option is through CLI using the logc application.

What type of issues have you encountered where the MST may help finding more details of the problem?

If you are interested on learning more :

Avaya MST Documents