Call Routing with ISUP Redirecting and Original Called Numbers
ISUP call routing is often described as a sequence of digit analysis, translation, and trunk selection. That description is accurate, but it misses an important detail: the number originally dialed by the subscriber may differ from the destination currently being served. Redirecting Number and Original Called Number parameters preserve that history inside the signaling exchange.
This distinction matters in forwarded calls, corporate numbering plans, voicemail access, freephone services, and intelligent network applications. A switch that treats every received number as the same type of identity can route calls correctly in simple cases while creating billing, screening, or service errors in more complex scenarios.
Within SS7, these parameters are carried through ISUP messages and interpreted by exchanges, service logic, gateways, and application servers. In SIGTRAN networks, the transport may use SCTP and M3UA rather than traditional signaling links, but the routing meaning of the ISUP fields remains fundamentally the same.
The Purpose of Each Number
The Called Party Number normally identifies the destination that the current switch must reach. When call forwarding or another redirection service is active, this can be different from the number the caller originally entered. The switch uses the current called number for immediate digit analysis and route selection.
The Original Called Number preserves the first destination associated with the call. It helps downstream equipment recognize the subscriber, service code, hunt group, or geographic number that initiated the service logic. This is particularly useful when several numbers are redirected to a shared endpoint.
The Redirecting Number identifies the number associated with the redirection event, subject to the applicable national and carrier interpretation. In a chain of forwarding events, it can help indicate which party or service caused the latest diversion. The Redirection Information parameter typically supplies related details such as the reason and counter.
How ISUP Carries Routing Context
The Initial Address Message, or IAM, is the principal message used to establish an ISUP call. It may include Called Party Number, Original Called Number, Redirecting Number, and Redirection Information when those fields are required by the service or network configuration. Each parameter has encoding rules that include address nature, numbering plan, and presentation or screening indicators where applicable.
A receiving exchange should validate the fields before using them. It must distinguish international, national, subscriber, network-specific, and other address types rather than applying one digit manipulation rule to every value. Incorrect handling of odd/even indicators, numbering plan information, or nature-of-address values can produce failed translations and misrouted calls.
ISUP does not require every network to expose every parameter across every interconnect. Transit carriers may pass the information transparently, normalize it, or remove it according to standards, regulatory policy, privacy settings, and commercial agreements. Routing design therefore needs a clear policy for missing, inconsistent, or contradictory values.
Routing Decisions in Forwarded Calls
Consider a subscriber who dials 212-555-0100, but that number forwards to 646-555-0199. The IAM toward the final destination may contain 646-555-0199 as the Called Party Number, while 212-555-0100 remains in Original Called Number. A Redirecting Number may identify the service subscriber or the number that triggered the forwarding operation.
The terminating switch can use the current destination to select the physical route while using the original value to apply supplementary services. These services may include voicemail selection, class-of-service checks, closed user group policies, lawful intercept handling, or enterprise call treatment.
Routing engines should avoid blindly replacing the Called Party Number with the Original Called Number. The original value is generally context, not an instruction to reverse the forwarding decision. It supports policy evaluation while the current called number drives the next network hop.
Operational Comparison
| Signaling value | Main meaning | Typical routing use | Common risk |
|---|---|---|---|
| Called Party Number | Current destination | Digit analysis and trunk selection | Routing to the wrong number after translation |
| Original Called Number | First destination associated with the call | Service logic, voicemail, billing context | Losing the original service identity |
| Redirecting Number | Number or party linked to redirection | Forwarding policy and screening | Misinterpreting the redirecting party |
| Redirection Information | Reason and history of diversion | Loop control and supplementary services | Ignoring forwarding limits or reason codes |
These fields work together rather than competing with one another. A routing application can select a destination from the Called Party Number, inspect the Original Called Number for service context, and use the Redirecting Number plus redirection reason to decide whether another diversion is permitted.
Numbering Plans and Translation Logic
Number translation should be deterministic and traceable. The routing engine can first normalize digits according to the received numbering plan, then apply translation rules to the current destination. Original and redirecting values should be retained in separate fields so that normalization does not destroy their individual meanings.
Forwarding loops are a major concern. A call may move through several exchanges, service platforms, or mobile networks before reaching an endpoint. Redirection counters and reason indicators can support loop prevention, while local policy can impose a maximum number of diversions or reject a route that repeatedly returns to the same destination.
Privacy and presentation settings also require attention. A network may be permitted to use a value internally while being prohibited from displaying it to the called user. Routing, charging, and display functions should therefore consume the correct parameter independently instead of assuming that the number used for one purpose is suitable for all purposes.
Interworking Across SS7 and IP Networks
When an SS7 signaling point connects to an IP-based core through SIGTRAN, the ISUP parameters are usually transported through adaptation layers rather than rewritten into a different call model. MTP3 user adaptation preserves the relationship between signaling messages, while SCTP supplies reliable transport between signaling endpoints.
The interworking gateway still has to map local numbering policies correctly. SIP gateways, mobile switching centers, softswitches, and application servers may represent original, redirecting, and current destinations using different internal attributes. A careful mapping prevents a SIP diversion header or proprietary field from being confused with the ISUP Original Called Number.
Interoperability testing should include direct calls, single forwarding, chained forwarding, busy and no-answer diversion, international numbering, restricted presentation, and calls crossing multiple carriers. Trace captures should compare IAM contents at each signaling boundary and confirm whether each parameter is preserved, translated, or intentionally omitted.
Practical Design Recommendations
A robust implementation benefits from explicit rules rather than assumptions about parameter availability. Teams building an SS7 routing platform or troubleshooting an interconnect can use the following practices:
- Treat Called Party Number as the immediate routing target and preserve the other values as separate call context.
- Validate numbering plan, nature-of-address, screening, and presentation indicators before digit translation.
- Use Redirection Information to enforce forwarding limits and detect possible loops.
- Record parameter changes at each ISUP or SIGTRAN boundary for billing and fault analysis.
- Test privacy, international formats, missing parameters, and multi-stage forwarding before production deployment.
For engineers developing their signaling knowledge, training support can provide a useful path to focused guidance on ISUP, MTP3, SIGTRAN, and related telecom protocols.
Correct handling of Redirecting Number and Original Called Number gives a routing system more than accurate destination selection. It preserves the call’s service history, supports consistent policy decisions, and makes inter-carrier troubleshooting far more precise. Apply these principles to IAM analysis, translation tables, and interoperability tests to create signaling behavior that remains reliable as calls move across legacy SS7 and modern IP networks.
