Understanding SS7 Timers From T1 to T33
SS7 timers control how long a signaling point waits for a response before it retries, releases a call, reports failure, or changes state. They are essential to ISUP call control, MTP3 recovery, SCCP transactions, and related telecom procedures.
A timer is more than a timeout value. Its meaning depends on the message sequence, protocol layer, network role, and national implementation. T1 in one vendor’s ISUP stack may not have exactly the same operational scope as T1 in another stack.
The values below provide a practical reference for engineers working with traditional PSTN signaling and SIGTRAN deployments. They should be treated as commonly encountered baseline values rather than universal settings.
Why SS7 timers matter
When an IAM is sent, the originating exchange expects progress such as ACM, CPG, or ANM. If that response does not arrive within the relevant interval, the exchange must avoid holding the circuit indefinitely. Timers create that boundary and trigger a defined recovery action.
Timers also protect signaling links from stale transactions. A failed call, lost RLC, or interrupted continuity check can otherwise leave circuit state inconsistent at opposite ends of the network.
In IP-based signaling, SCTP retransmission timers and SS7 protocol timers operate at different layers. A healthy SCTP association does not guarantee that an ISUP transaction is progressing, so both sets of timers must be monitored.
How T1 through T33 are organized
The T-series is commonly associated with ISUP procedures, but its exact allocation varies between ITU-T recommendations, regional profiles, and vendor documentation. Early timers generally relate to call setup and release, while later timers may support continuity checks, circuit blocking, reset procedures, or implementation-specific supervision.
The same numeric value can also have different consequences. Expiry may cause a REL message, an RSC procedure, a retry, an alarm, or a transition to an idle state. Engineers should therefore read the timer together with its start event, stop event, and expiry action.
For mobile roaming, these signaling exchanges can interact with MAP operations across GSM and LTE networks. The MAP and SS7 roaming guide gives useful context for understanding how application-layer transactions depend on lower-level signaling behavior.
Common default values
The following worksheet reflects values frequently seen in training material and commercial SS7 implementations. “15 seconds” is often used as a general transaction safeguard, while call setup timers may be longer to allow remote exchanges and interworking gateways to respond.
| Timer | Common baseline | Typical role or note |
|---|---|---|
| T1 | 15 seconds | Initial call supervision |
| T2 | 15 seconds | Response during call setup |
| T3 | 30 seconds | Extended answer or progress wait |
| T4 | 15 seconds | Call-release supervision |
| T5 | 15 seconds | Waiting for release completion |
| T6 | 15 seconds | Reset or circuit-state supervision |
| T7 | 20 seconds | IAM to ACM or progress response |
| T8 | 20 seconds | ACM or CPG to ANM |
| T9 | 60 seconds | Extended call-control wait |
| T10 | 10 seconds | Continuity or related procedure |
| T11 | 5 seconds | Short retry or response interval |
| T12–T33 | 15 seconds each in many stacks | Often profile- or vendor-dependent |
These are engineering defaults, not guaranteed Q.764 values for every network. Some systems express timers in milliseconds, use a range rather than one value, or disable procedures that make certain timers irrelevant. A configuration file may also rename a timer according to the message pair it supervises.
Reading a timer definition correctly
A useful timer record has at least five fields: the identifier, start condition, stop condition, expiry action, and retry behavior. For example, a setup timer may start when IAM leaves the originating exchange, stop when ACM or an equivalent progress message arrives, and release the call if the interval expires.
Do not infer behavior from the numeric label alone. Confirm whether T7 begins at IAM transmission or after a lower-layer acknowledgment, and whether receipt of CPG stops it or merely restarts another timer.
Timer values should also be compared with routing delays, international transit paths, and media gateway processing. A setting that works in a domestic network may generate false failures across multiple signaling transfer points.
Default values versus deployed values
Operators often modify defaults after measuring real signaling performance. Heavy congestion, satellite links, interworking with older exchanges, and long MAP transactions can justify longer intervals. Shortening timers can improve resource release, but it can also create unnecessary call failures when signaling is merely delayed.
Network designers should distinguish protocol timers from operational watchdogs. An MTP3 link-alignment timer, an SCTP retransmission timer, and an ISUP answer timer solve different problems. Changing one without reviewing the others may hide the actual source of a fault.
Documentation is especially important when T12 through T33 are presented as a contiguous series. Many products reserve portions of this range for national options or internal procedures, so a “default” copied from another platform may be misleading.
Troubleshooting timer expiry
Start with traces at both signaling endpoints. Identify the message that started the timer, verify whether the expected response was sent, and check whether it was lost, delayed, rejected, or routed to the wrong circuit.
Useful checks include:
- Compare IAM, ACM, CPG, ANM, REL, and RLC timestamps.
- Confirm CIC alignment and circuit-group status at both exchanges.
- Review MTP3 route changes, link congestion, and SCCP errors.
- Separate SCTP retransmissions from ISUP timer expiry.
- Record timer changes with the applicable ITU-T, national, or vendor profile.
A recurring T7 or T8 expiry often points to delayed call progress or interworking problems. Repeated T5 or T6 expiry may indicate a release, reset, or circuit-state mismatch rather than a simple network delay.
Build a reliable timer baseline
SS7 timers should be validated in a controlled test environment before production changes are made. Capture normal and failed calls, test link failover, and observe how each timer interacts with circuit blocking and recovery.
For structured learning on ISUP, MTP3, SIGTRAN, routing, and signaling security, use the SS7 training resources as a companion to vendor manuals and current protocol recommendations. Then document the approved values, triggers, and expiry actions for every deployed signaling point.
