How to Read an SS7 Protocol Trace Step By Step
An SS7 protocol trace is a time-ordered record of signaling messages exchanged between network elements. Reading one effectively means connecting protocol fields with call behavior: who initiated the transaction, which route was selected, whether the destination responded, and where the exchange stopped.
The clearest method is to move from broad context to individual parameters. First identify the signaling link and protocol layer, then follow the routing label, message type, transaction identifiers, and timers. A trace becomes much easier to understand when every line is treated as part of a call flow rather than as an isolated hexadecimal record.
The example below follows a basic ISUP voice call over an SS7 network. The same reasoning can be applied to mobile signaling, number portability, roaming, SMS interworking, and SIGTRAN captures carried over SCTP and M3UA.
Establish The Trace Context
Begin by recording the capture time, signaling point names, linkset, and direction. A message from an originating service switching point toward a destination exchange has a different meaning from a response traveling backward. Check whether the analyzer displays point codes in decimal, hexadecimal, or a national point-code format.
Next identify the protocol layers. MTP1 and MTP2 describe the signaling link, while MTP3 carries routing information. ISUP sits above MTP3 for circuit-related call control. In an IP-based deployment, M3UA transports MTP3-user messages across SCTP, but the ISUP call sequence remains recognizable.
Read The Routing Label First
The MTP3 routing label normally contains the destination point code (DPC), originating point code (OPC), and signaling link selection (SLS). The DPC shows where the message is intended to go; the OPC identifies its source. The SLS value helps distribute traffic across links while preserving message sequencing for related signaling.
Verify that the OPC and DPC make sense for the observed direction. A reversed point code, unexpected signaling point, or inconsistent SLS may indicate a routing configuration problem, a trace collected on the wrong link, or a decoding issue. In a multi-operator environment, also check whether the point-code format matches the national or international network.
Follow The ISUP Call Sequence
For a circuit-switched call, locate the Initial Address Message (IAM). It typically contains the circuit identification code (CIC), called-party number, calling-party number, nature of connection indicators, and transmission medium requirements. The IAM is the request to seize a circuit and establish the call toward the next exchange.
A normal answer sequence usually contains an Address Complete Message (ACM), followed by an Answer Message (ANM) when the called party goes off hook. The release sequence begins with a Release (REL), which includes a cause value, and ends with a Release Complete (RLC). If the trace ends after IAM or ACM, the missing response often points to the location of the fault.
| Time | Direction | Message | Important Field | Interpretation |
|---|---|---|---|---|
| 10:02:14.120 | Originating switch → Transit switch | IAM | CIC 2041, called number 4412345678 | Circuit seized and call routed |
| 10:02:14.188 | Transit switch → Destination switch | IAM | DPC matches destination | Next exchange receives the call |
| 10:02:14.640 | Destination switch → Transit switch | ACM | Cause absent; address complete | Destination is alerting or collecting status |
| 10:02:19.902 | Destination switch → Transit switch | ANM | CIC 2041 | Called party answered |
| 10:02:47.311 | Originating switch → Transit switch | REL | Cause 16 | Normal call clearing requested |
| 10:02:47.350 | Transit switch → Originating switch | RLC | CIC 2041 | Circuit released |
Interpret Numbers And Cause Codes
Do not inspect the called number alone. Examine its nature of address indicator, numbering plan, and any translation-related digits. A national number, international number, subscriber number, or routing prefix can cause different digit analysis results. Compare the digits in the IAM with the digits expected at each transit point.
Release cause values provide a valuable summary of network behavior. Cause 16 generally means normal call clearing, while cause 17 indicates user busy and cause 1 commonly represents an unallocated or unknown number. Treat the cause as evidence rather than a complete diagnosis: a downstream switch may translate or replace it before the message reaches the monitoring point.
Check Timing And Missing Messages
Timing separates normal progress from protocol failure. Measure the interval between IAM and ACM, ACM and ANM, and REL and RLC. ISUP timers such as T7, associated with waiting for address-complete information, and T9, associated with answer supervision, help determine whether a switch cleared the call because a response arrived too late.
A missing message is often more informative than a present one. IAM without ACM can indicate routing failure, congestion, an unreachable destination, or a signaling link problem. ACM without ANM may represent normal ringing, but a long delay followed by REL can point to no-answer handling, supervision failure, or an application-controlled release.
Correlate The Trace Across Layers
When SS7 signaling runs through SIGTRAN, correlate the ISUP record with M3UA and SCTP events. Look for the SCTP association, stream number, M3UA traffic mode, and affected routing context. Packet loss, retransmissions, association resets, or a blocked SCTP path can explain why an otherwise valid ISUP exchange is incomplete.
Use the CIC, OPC, DPC, and timestamps to join messages captured at different network points. The same call may appear several times as it crosses tandem switches. A message that seems absent at one capture point may simply have been observed on another link, while duplicate-looking records may represent legitimate forwarding.
Use A Repeatable Trace Review Method
For efficient troubleshooting, apply the same sequence to every capture:
- Confirm the capture point, protocol layers, and message direction.
- Follow DPC, OPC, SLS, CIC, and signaling link information.
- Build the expected IAM–ACM–ANM–REL–RLC call sequence.
- Decode numbering fields, indicators, and release causes.
- Compare message timestamps with relevant ISUP and transport timers.
Keep a short event timeline beside the raw packet view. This makes it easier to distinguish a signaling failure from a bearer-channel issue, numbering translation error, or subscriber behavior. Structured SS7 learning materials can also help reinforce the relationship between MTP3 routing, ISUP procedures, and SIGTRAN transport.
Turn Findings Into A Network Diagnosis
Once the sequence is mapped, state the fault in operational terms. For example: “The originating switch sent IAM with CIC 2041, but no ACM arrived within the expected interval from the destination route.” This is more useful than reporting that “the call failed,” because it identifies the failed transaction and the direction requiring investigation.
Compare successful and failed traces using the same route, number format, CIC range, and time period. If successful calls contain identical IAM parameters but failed calls receive a particular REL cause, focus on destination analysis or resource availability. If failures stop before the destination point code appears, investigate MTP3 routing, linksets, gateway configuration, or SIGTRAN connectivity. For deeper study of protocol fields and troubleshooting workflows, review the advanced SS7 products.
A disciplined trace review turns dense signaling data into a defensible diagnosis. Start with routing, follow the message sequence, validate timers and parameters, and correlate every conclusion with the network layer that could have produced it.
