Analyzing SS7 call traces with TShark: a field-by-field walkthrough
Many engineers in Australia still work on PSTN interconnects running alongside the NBN, particularly across regional New South Wales and Queensland where copper meets fibre. Reading raw call traces separates a confident protocol analyst from someone who relies on vendor dashboards alone. SS7 signalling carries the intelligence that makes every voice call work, and TShark puts that intelligence under your control.
TShark, the command-line companion to Wireshark, gives granular visibility into every octet of an MTP and ISUP message. Whether you work from a switching centre in Sydney or troubleshoot inter-carrier signalling from a remote node near Alice Springs, the same dissection rules apply. The trick is knowing which fields to expand first and which values indicate normal operation rather than a fault.
| ISUP Message | Acronym | Purpose in call flow |
|---|---|---|
| Initial Address Message | IAM | Seizes the outgoing circuit and carries the called number |
| Address Complete Message | ACM | Confirms the called party is being alerted |
| Answer Message | ANM | Indicates the called party has picked up |
| Release | REL | Tears down the call from either end |
| Release Complete | RLC | Acknowledges the release and frees the circuit |
Setting up your TShark capture environment
TShark runs well on the Linux distributions common in Australian carrier labs and parses both raw MTP2 frames on TDM links and M2PA traffic over UDP. A typical capture begins with selecting the right interface, often a SPAN port on a switch that mirrors the signalling link. For SIGTRAN sessions between a media gateway and a signalling transfer point, a capture filter such as -f "udp port 2905" narrows the stream to M2PA traffic before dissection begins.
The Telecommunications (Interception and Access) Act 1979 sets strict rules about recording call content, and while signalling metadata is treated differently, your legal and security teams should still sign off on live capture. For training, sanitised PCAPs from public repositories or generated by your own test bed keep you on the right side of compliance.
Reading the MTP layers
The Message Transfer Part layers form the backbone of every SS7 packet and appear at the top of your TShark tree. MTP2 handles link-level framing, including flags, length indicators, and a checksum that catches bit errors on the physical link. MTP3 sits above it and routes messages between signalling points using a destination point code, an origination point code, and a signalling link selection field that picks which link in a linkset carries the traffic.
When you expand an MTP3 packet, the routing label is the natural place to start. The destination point code tells you where the message is headed, useful when tracing a call between Telstra's network and a competitive carrier. The origination point code reveals the sender, and an unexpected signalling link selection pattern hints at a load-balancing glitch after maintenance in a Brisbane exchange.
Decoding ISUP parameters
ISDN User Part messages carry the call control logic, and their fields reveal everything you need to understand a call. The circuit identification code follows, tying the message to a specific timeslot or bearer channel. The IAM then carries the called party number, the calling party category, the transmission medium requirement, and a nature of address indicator that tells you whether to expect a national, international, or local format number.
Australian numbers often appear with a nature of address indicator of 3 (national significant) and a prefix that includes the area code, such as 02 for Sydney, 03 for Melbourne, or 07 for Brisbane. The transmission medium requirement reveals whether the call expects 64 kbps speech, 3.1 kHz audio, or a data mode, which helps when diagnosing modem handoff failures on older interconnects between regional switches.
Tracing a call from seizure to release
A complete call leaves a distinctive fingerprint across multiple ISUP messages. An IAM establishes the forward path, the ACM reports back that the far end is ringing, and the ANM marks the moment the called subscriber answers. Continuity check messages appear beforehand on older circuits, particularly on long-haul routes between capital cities that predate full IP migration.
When the call ends, the REL message carries a cause value that explains the termination reason. Cause 16 indicates a normal clearing, while cause 41 means a temporary failure. Australian networks often see cause 27 (destination out of order) during NBN migration windows and cause 34 (no circuit available) during peak evening traffic on the eastern seaboard. The matching RLC closes the loop.
Spotting anomalies in the fields
Field-level inspection exposes problems that high-level summaries hide. An unexpected destination point code might indicate a misconfigured gateway pointing at the wrong signalling transfer point. A jumpy signalling link selection field suggests a load-balancing glitch, which engineers often see right after a hardware swap in a Brisbane or Perth exchange.
Cause values also tell a story when you aggregate them. A cluster of cause 38 (network out of order) entries during a specific window may correlate with a fibre cut, common when bushfires or floods disrupt backhaul in regional areas. Cause 111 (protocol error, unspecified) is a red flag that warrants a closer look at MTP2 alignment and error-rate counters on the affected link.
Building a repeatable workflow
Consistent analysis beats ad-hoc inspection every time. Begin with a coarse filter such as isup to isolate call control traffic, then narrow to a specific circuit identification code or destination point code when investigating one subscriber or route. Export the filtered packets and use tshark -T fields to extract the called number, the cause value, and the signalling link selection for later processing.
Document every trace with the capture time in UTC alongside the local Australian time zone, since switch logs require accurate timing. When you encounter an unfamiliar cause value or a dissection warning, you can reach the team that maintains this resource for a second opinion.
A practical takeaway worth remembering: capture at least one full ISUP exchange before drawing conclusions, because a single message in isolation rarely tells the whole story. Pairing TShark filters with documented time windows turns trace analysis into a defensible diagnostic record.
