ISUP cause code 23 in Australian mobile routing
ISUP cause code 23, formally called “exchange routing error”, indicates that a signalling exchange could not select or complete a valid route for the called party. In a mobile network, the failure may occur between an MSC, GMSC, transit switch, or international gateway rather than at the handset itself.
The code belongs to the Q.850 cause framework used with ISDN User Part signalling. It is different from a busy subscriber, an unallocated number, or a temporary congestion condition. The network has generally recognised the destination address but has encountered a routing problem while processing it.
Australian operators handle these events across complex interconnects linking Telstra, Optus, TPG Telecom and smaller service providers. Number portability, national roaming arrangements, VoLTE interworking and international termination can all affect how a dialled mobile number is translated and routed.
A fault affecting calls between Sydney and Melbourne may have a different operational signature from one involving a Perth mobile subscriber or an overseas caller using the +61 numbering format. Accurate correlation of ISUP messages, SIP responses and mobile-core events is therefore essential.
What cause 23 means in ISUP
Cause 23 usually means that an exchange has failed to determine an acceptable outgoing route. The originating switch may have sent an IAM containing a valid called-party number, but the next exchange cannot match the destination to an available trunk group, route set, carrier code or signalling relationship.
The phrase “exchange routing error” does not identify one universal fault. It is a result supplied by the network element that detects the problem. A transit switch might generate it after unsuccessful route analysis, while an MSC or gateway may use it when a translated destination cannot be reached through its configured interconnect.
How mobile routing produces the error
A mobile call often passes through several logical stages: access-side call control, the serving MSC, gateway MSC, number analysis, portability lookup and an inter-operator trunk. An error in any stage can prevent the call from reaching the terminating MSC. Incorrect mobile-number ranges, stale portability data and missing route prefixes are common areas to examine.
The problem can also arise when legacy circuit-switched signalling meets an IP-based transport network. SIGTRAN may carry MTP3 and ISUP over SCTP, while SIP or IMS handles another part of the call. A mismatch between point codes, routing contexts, global titles or interworking rules can leave the call with no usable next hop.
Diagnostic clues in traces
An engineer should begin with the IAM and the release sequence. Check the called-party number, nature of address indicator, numbering plan, transmission medium requirement, circuit identification code and originating point code. Compare the message with a successful call using the same carrier, destination range and time period.
| Investigation area | Useful evidence | Typical interpretation |
|---|---|---|
| Number analysis | Called digits and translated digits | Prefix, portability or format mismatch |
| Route selection | Route set, trunk group and status | No valid outgoing destination |
| Signalling transport | MTP3, SCTP and ASP events | Point-code or SIGTRAN reachability issue |
| Interworking | ISUP, SIP and IMS mapping | Incorrect cause-code conversion |
| Operations data | Call detail records and alarms | Localised carrier or time-based failure |
A single cause 23 does not prove that the remote operator is at fault. If the release arrives from a transit exchange, inspect the preceding and following signalling legs. MTP3 network management events can provide additional context; for example, a MTP3 transfer restriction may explain why traffic was diverted or rejected before ISUP routing completed.
Australian network considerations
Australia’s national numbering plan uses geographic and non-geographic ranges alongside mobile numbers beginning with 04. Mobile number portability means that the current carrier cannot reliably be inferred from the original number range. A routing database that has not received a recent update can therefore send calls towards an obsolete carrier path.
Inter-carrier traffic is particularly important around major commercial centres such as Melbourne and Sydney, where several network and enterprise interconnects may be involved. Calls to regional Queensland, Western Australia or remote Northern Territory areas may traverse different transit arrangements, making route-specific testing more informative than a single metropolitan test.
Distinguishing cause 23 from similar failures
Cause 1, “unallocated number”, normally indicates that the destination number is not assigned or cannot be found in the numbering plan. Cause 17, “user busy”, points to the subscriber state. Cause 34, “no circuit/channel available”, is more closely associated with resource exhaustion. Cause 38, “network out of order”, suggests a broader network availability problem.
In practice, gateways may translate these causes imperfectly. A SIP 404, 480 or 503 response can be mapped to different ISUP values depending on vendor configuration and interworking policy. Engineers should therefore record the original cause, the translated cause and the network element that performed the conversion.
A practical fault-isolation method
Start by grouping failures by destination number, originating carrier, route, time window and signalling node. If only one mobile range fails, investigate portability and digit analysis. If many destinations fail after a routing change, inspect route-set activation, point-code availability and trunk-group administration.
Next, compare successful and failed calls at each boundary: originating MSC to GMSC, GMSC to transit carrier, and transit carrier to the terminating operator. Verify MTP3 routing labels, signalling link availability, SCCP global-title translation where applicable, and the relationship between ISUP circuit identifiers and physical or virtual trunks.
The most useful next step is to capture one failed and one successful call for the same Australian mobile destination range, then compare their IAM, routing translation, release cause and SIGTRAN path hop by hop.
