SIGTRAN Explained: SCTP, M2PA, M2UA, and M3UA - What Each Adaptation Layer Actually Does

Most engineers who came up through VoIP know "SIGTRAN" as the bit of the network where SS7 meets IP. Pressed for specifics (what runs over what, why some interconnect is "M3UA" and some is "M2PA", what an Application Server actually is) the picture gets blurry fast. That fuzziness usually doesn't matter until an SCTP association won't come up, an ASP sits stuck in ASP-INACTIVE, or a circuit refuses to seize because nobody has registered a routing key. Then you need to know which layer owns which decision.

This post walks through the SIGTRAN stack as it actually appears in carrier networks: SCTP at the bottom, with M2PA, M2UA, and M3UA as the adaptation layers above it. The semantics apply whether you are looking at a Cisco ITP, a Ribbon or Mavenir SG, or an Asterisk box running libosmo-sigtran.

SCTP: the transport every adaptation layer depends on

The Stream Control Transmission Protocol (RFC 4960) is the IP transport underneath all of SIGTRAN. SCTP exists because TCP gets two things wrong for telephony signalling: it is a byte stream rather than a message stream, and it head-of-line-blocks on a single ordered queue. Neither is acceptable for ISUP IAMs that must arrive whole, where one stalled message must not freeze every other call on the link.

Four properties of SCTP matter when you are debugging SIGTRAN:

• Multi-streaming. Up to 65,535 independent streams per association, each ordered (or unordered) on its own. M3UA spreads MTP3 user traffic across streams keyed off SLS to preserve per-call ordering while avoiding HOL blocking across calls.
• Multi-homing. Both endpoints list multiple IP addresses in INIT / INIT-ACK. The association has a primary path and secondaries probed by HEARTBEAT chunks; when Path.Max.Retrans is exceeded, traffic fails over without the upper layer noticing.
• Four-way handshake with a cookie. INIT → INIT-ACK → COOKIE-ECHO → COOKIE-ACK. The cookie defeats SYN-flood attacks by keeping the responder stateless until COOKIE-ECHO is verified. Associations stuck after INIT-ACK usually mean cookie-path MTU trouble.
• PPID per chunk. The Payload Protocol Identifier tags every DATA chunk with the upper-layer protocol (M3UA = 3, M2PA = 5, M2UA = 2, SUA = 4). This is what lets Wireshark dissect correctly and lets a single endpoint multiplex more than one adaptation layer.

Two SCTP failure signatures are worth knowing on sight. An ABORT with cause "Out of Resource" or "Unrecognised Chunk Type" means the far end rejected the association - usually a config mismatch (port, INIT parameters, or one side M3UA and the other M2PA). A clean SHUTDOWN / SHUTDOWN-ACK / SHUTDOWN-COMPLETE means the upper layer asked for the tear-down; the policy decision came from above.

M2PA: making the IP link look like an MTP-2 link

M2PA (MTP2 Peer-to-Peer Adaptation, RFC 4165, IANA port 3565) is the simplest SIGTRAN layer conceptually. It replaces the MTP-Level-2 link between two SS7 Signalling Points with an SCTP association. From either box's SS7 stack, nothing has changed: MTP3 still sees a peer MTP3 across what looks like an MTP2 link, with the same Link State Control state machine (Out-of-Service → Initial-Alignment → Aligned-Not-Ready → Aligned-Ready → In-Service) on top.

This is the right tool for interconnecting two SS7 Signalling Points (typically STPs) over IP without disturbing anything above the link layer. The point codes and linkset are real; only the bits are riding SCTP rather than a T1/E1 timeslot. M2PA is what you reach for to retire DS-0 SS7 links between your own switches while keeping the rest of the SS7 architecture intact.

In trace, watch for link-status messages (Alignment, Proving Normal, Proving Emergency, Ready, Processor Outage, Busy) in M2PA User Data. A linkset that proves repeatedly and falls back to "Processor Outage" almost always means MTP3 isn't draining its receive queue fast enough - typically an IPSP sized for a fraction of the offered SLS load.

M2UA: terminating MTP2 at the Signalling Gateway

M2UA (MTP2 User Adaptation, RFC 3331, IANA port 2904) splits the SS7 stack across two boxes. The Signalling Gateway (SG) terminates MTP-1 and MTP-2 and ferries MTP3 messages over SCTP to a Media Gateway Controller (MGC) running the actual MTP3, ISUP, and TCAP. The IUA family (RFC 4233) is the analogous layer for ISDN PRI access.

M2UA matters historically (early IP softswitches were built on it) but greenfield carrier deployments rarely use it now. M2UA forces the MGC to behave as MTP3, inheriting SS7 link-management complexity most softswitch vendors would rather not own. M3UA pushes that complexity down to the SG where it belongs. On a legacy M2UA network, remember that MTP3 timers (T1-T22) run at the MGC while the link state they react to is reported by the SG - correlate both before deciding what failed.

M3UA: the carrier-network workhorse

M3UA (MTP3 User Adaptation, RFC 4666, IANA port 2905) is what you will see on essentially every modern SS7-over-IP interconnect. The SG terminates MTP1/2/3 entirely; M3UA carries MTP3-user payloads (ISUP, SCCP, and onward TCAP) between the SG and one or more Application Server Processes (ASPs). The ASPs are grouped logically into an Application Server (AS), addressed by Routing Context, with optional Network Appearance to disambiguate multiple SS7 networks behind a single SG.

The state machine you have to know is the ASP state machine:

• ASP-DOWN - SCTP association exists, no ASPSM exchange yet.
• ASP-INACTIVE - ASPSM ASP-UP / ASP-UP-ACK done; the ASP can register routing keys but is not carrying user traffic.
• ASP-ACTIVE - ASPTM ASP-ACTIVE / ASP-ACTIVE-ACK done; the ASP is in the load-share / override / broadcast group for its AS and will receive user traffic.

Three M3UA management messages dominate any non-trivial trace. DUNA and DAVA (Destination Unavailable / Available) tell the ASP that a remote point code reachable through the SG has come or gone - this is how MTP3's TFP/TFA/TFR network management is surfaced into the IP domain. DUPU (Destination User Part Unavailable) is how an ASP learns the far end has no ISUP listener and stops offering circuits in vain. SCON carries MTP3 congestion onset and abatement.

The most common production failure pattern is an ASP that comes ASP-UP cleanly, then stays ASP-INACTIVE forever. The cause is almost always one of: the SG has Routing Key Management disabled and the ASP is trying to dynamically register a key the SG won't accept; the Routing Context numbers don't match between the two sides; or the AS mode (Override / Loadshare / Broadcast) is mismatched so the SG won't promote the ASP into the traffic group.

What to look for in a SIGTRAN trace

A checklist that catches most SIGTRAN interconnect issues:

• SCTP INIT exchange. Did INIT-ACK come back, and did COOKIE-ECHO survive the path? Multi-homed cookies are a common MTU casualty.
• Heartbeat behaviour. HEARTBEAT / HEARTBEAT-ACK flowing on both paths of a multi-homed association? A silent secondary is a failover that won't happen.
• PPID on DATA chunks. Wrong PPID and the dissector falls back to raw bytes. If you can't see M3UA in Wireshark, check this first.
• ASPSM completeness. ASP-UP followed by ASP-ACTIVE on every ASP. Missing ASP-ACTIVE-ACK is the classic "stuck in inactive" symptom.
• Routing Context and Network Appearance. Both sides agreeing on the integers. Off-by-one mismatches are surprisingly common when two teams configure the two ends.
• DUNA / DAVA churn. A storm of DUNA/DAVA without a corresponding SS7 problem usually means the SG's MTP3 is flapping a real link - chase it back to the TDM/IP-link side.

Useful tshark filters: sctp.chunk_type == 0 (DATA), sctp.chunk_type == 4 (HEARTBEAT), m3ua.message_class == 0 (Management), m3ua.message_class == 3 (ASPSM), m3ua.message_class == 4 (ASPTM), m3ua.routing_context. Combine with decode-as if your SG uses non-IANA ports.

Where this fits in the larger picture

SIGTRAN is an area where a working mental model (which layer terminates what, where state lives, what the failure modes look like) is worth more than memorising RFC numbers. Once you can read an SCTP association and an M3UA ASP state machine together, the rest of carrier SS7-over-IP stops feeling like magic.

SIGTRAN is a foundation of our SIPT-301 - SS7 and SIGTRAN for SIP Engineers course on the CCVE track. If you want to go deeper - SCTP association walk-throughs, M3UA Routing Key Management labs, end-to-end ISUP-over-M3UA trace analysis - that is where to look next.