How SS7 timeouts increase post-dial delay
Post-dial delay (PDD) is the time between a caller sending the final dialled digit and hearing ringing, an announcement, or a failure tone. In an SS7 network, this interval reflects several signalling exchanges rather than a single switch decision. A small delay in one transaction can become noticeable when several network elements wait for responses.
Network timeouts are particularly important because they make a system pause before choosing an alternative route or releasing the call. The caller may hear silence while the originating exchange waits for an ISUP response, an address-complete message, a routing query, or a return from an IP-based signalling link.
The effect is familiar in large Australian networks, where calls may cross carrier boundaries, mobile and fixed platforms, and long geographic distances between Sydney, Melbourne, Brisbane, Perth, and regional exchanges. A link that is healthy most of the time can still create poor call setup performance when congestion or packet loss triggers repeated timer expiry.
Understanding the relationship between timers and PDD helps engineers distinguish a slow destination from a slow signalling path. It also supports better capacity planning, fault diagnosis, and service-level discussions between carriers and wholesale operators.
How post-dial delay develops
A typical call begins when the originating exchange sends an ISUP Initial Address Message (IAM). The destination side should respond with messages such as Address Complete Message (ACM) or Answer Message (ANM), depending on call progress. If the expected response does not arrive promptly, the originating equipment continues waiting or starts another procedure.
The delay becomes more visible when a call requires number translation, portability checking, least-cost routing, or an additional service platform. Each step can introduce processing time. A caller does not see these transactions; they experience the combined result as silence after dialling.
Where SS7 timers matter
Timers in MTP3, ISUP, SCCP, and higher-level applications protect the network from stalled transactions. They define how long a node waits for acknowledgement, route availability, or a response from a remote signalling point. When a timer expires, the network may retransmit, select another link, reject the call, or clear the transaction.
A timer that is too short can cause unnecessary failures during brief congestion. A timer that is too long increases PDD because the caller waits for a decision that the network may already know is unlikely to succeed. Correct values depend on topology, signalling transport, and the expected response time of connected platforms.
SIGTRAN and IP transport effects
SIGTRAN carries SS7 protocols over IP, commonly using SCTP for reliable transport. This architecture offers path redundancy and flexible interconnection, but it also introduces IP behaviours that traditional TDM links did not expose in the same way. Packet loss, route changes, jitter, firewall inspection, and overloaded signalling gateways can delay an otherwise valid exchange.
SCTP retransmission and congestion control may add waiting time before an upper-layer SS7 timer expires. If the IP transport timer and the ISUP timer are poorly coordinated, the application can declare a route unavailable while the transport is still attempting recovery. Conversely, repeated application retries can amplify congestion and make PDD worse.
Measuring the delay correctly
PDD should be measured from a clearly defined event, such as receipt of the final digit, to a clearly defined outcome, such as ACM, audible ringing, an announcement, or release. Call detail records alone may not provide enough precision, so packet captures, signalling traces, and switch event logs are often needed.
Useful measurements include the proportion of calls exceeding a target threshold, the 95th and 99th percentile setup times, timer expiries by message type, and delay by route or carrier. Comparing successful and failed calls is essential because a network may show an acceptable average while a small group of timeout-affected calls experiences several seconds of silence.
Australian network conditions
Australian operators manage a mix of dense metropolitan traffic and long-haul connections to regional and remote areas. A call between Melbourne and Sydney may use a very different signalling path from one involving a regional mobile service or an enterprise gateway in Western Australia. These differences make route-specific monitoring more useful than a single national average.
Mobile network modernisation also means legacy SS7 interworking with IP Multimedia Subsystem platforms, voice-over-LTE services, and carrier signalling gateways. Wholesale transit arrangements can add another administrative and technical boundary. In practical terms, a timeout may originate in a partner network even when the originating switch appears healthy.
Emergency and priority services require particular care. Australian operators must preserve dependable call establishment for services such as 000, while also managing ordinary commercial traffic across interconnected networks. Timer changes should therefore be tested against routing, accessibility, and release behaviour rather than judged only by a reduction in average PDD.
Diagnosing timeout-driven delay
A disciplined investigation starts by identifying the first missing or late message. Engineers can then separate radio access, switching, signalling transfer, database, and destination causes. The SS7 solutions resource can provide useful context when mapping these signalling functions to network components.
Practical checks should focus on evidence rather than assumptions.
- Correlate IAM, ACM, ANM, REL, and RLC timestamps.
- Review MTP3 link utilisation and route-set changes.
- Check SCTP retransmissions, packet loss, and failover events.
- Compare PDD by destination, trunk group, and time of day.
The following operational habits also reduce misdiagnosis.
- Keep timer changes under controlled change management.
- Test primary and alternate signalling routes separately.
- Record whether silence ends in ringing, tone, or release.
- Use synthetic calls alongside live traffic statistics.
Comparing timeout behaviour
| Condition | Likely signalling behaviour | Effect on PDD | Useful response |
|---|---|---|---|
| Healthy route, prompt ACM | Normal ISUP exchange | Low | Maintain baseline |
| Brief packet loss | SCTP recovery or message retransmission | Moderate increase | Inspect transport quality |
| Unreachable signalling point | Timer expiry and route selection | High | Verify routing and redundancy |
| Slow database or service node | Delayed application response | Variable to high | Measure node processing time |
| Excessively long timer | Extended wait before failure | Very high | Review timer alignment |
Timer tuning should preserve protocol compliance and interoperability. Reducing every timeout may make dashboards look better while increasing false releases, duplicate requests, or failed calls during temporary congestion. Increasing every timeout can hide faults and create an unacceptable caller experience.
The best result comes from aligning transport recovery, MTP3 route management, ISUP procedures, and service-platform response times. Once traces show where the delay begins, the next concrete step is to capture a controlled set of calls and calculate the 95th-percentile interval from final digit to ACM or failure.
