ISUP Call Diversion Using Forward Call Indicators
Call diversion in a telephone network moves an incoming call from the originally dialed destination to another number. In SS7 environments, this process depends on coordinated signaling between the originating exchange, transit nodes, and the terminating switch. ISUP provides the call-control messages, while selected parameters explain how the call has been routed and whether protocol conversion has occurred.
Forward Call Indicators (FCI) are carried in the Initial Address Message (IAM). They do not, by themselves, state every detail of a diversion event. Instead, they describe the call’s signaling context and help downstream exchanges decide whether end-to-end ISDN information, interworking treatment, or national-network handling is appropriate.
A reliable analysis therefore combines FCI with Redirection Information, Redirecting Number, Original Called Number, and related optional parameters. Engineers studying SS7 solutions can use this relationship to distinguish a genuinely diverted call from an ordinary transit connection.
The Role Of The Initial Address Message
The IAM begins the ISUP call setup procedure. It identifies the called party and includes indicators that guide subsequent exchanges. Among these fields, the Forward Call Indicators provide important information about the network path and available signaling capabilities.
An exchange receiving an IAM examines the FCI before selecting its next action. The information can influence whether the node expects ISUP to remain available across the connection, whether an interworking point has already been encountered, and how certain supplementary service data should be interpreted.
FCI is therefore a decision-support field rather than a complete diversion record. The switch must correlate it with the call-routing database, subscriber service profile, and other IAM parameters before applying call forwarding or redirection logic.
Diversion Data And FCI Interaction
Call forwarding may be unconditional, busy, no-answer, or activated when the subscriber is unreachable. These conditions are generally represented through redirection-related parameters instead of being encoded solely in FCI. Redirection Information can identify the reason and count of diversions, while the Redirecting Number identifies a party associated with the redirection.
The Original Called Number is useful when multiple forwarding steps have taken place. It preserves the first destination, allowing billing systems, lawful-intercept functions, fraud controls, and customer-service tools to understand the call’s history.
FCI supplies the surrounding protocol context. For example, an interworking indication can warn the terminating side that the call has passed through a network using a different signaling capability. That distinction matters when a diverted call crosses between ISDN-based SS7 signaling, older telephony systems, or an IP signaling environment.
Interpreting Important Indicator Bits
The exact bit layout and permitted combinations depend on the applicable ITU-T or national ISUP specification. Implementations should never assume that a bit has the same operational meaning across every carrier profile. A signaling trace must be read alongside the regional variant and switch documentation.
| Signaling element | Main purpose | Relevance to diversion |
|---|---|---|
| Forward Call Indicators | Describe call and signaling conditions | Helps a switch assess interworking and end-to-end capability |
| Redirection Information | Records diversion reason and forwarding count | Explains why the call was redirected |
| Redirecting Number | Identifies the redirecting party | Supports service logic, billing, and screening |
| Original Called Number | Preserves the first destination | Maintains call history through multiple diversions |
| IAM Called Party Number | Identifies the current destination | Tells the network where to route the next leg |
A common mistake is to interpret the FCI “interworking encountered” state as proof that diversion occurred. It only indicates that a signaling or bearer interworking condition has been encountered. Diversion must be confirmed through redirection parameters and the sequence of IAM messages.
Similarly, an indication that ISDN User Part is used all the way does not mean that every supplementary service will be preserved automatically. Intermediate nodes can alter, remove, or fail to support optional parameters even when the basic ISUP path remains available.
Call Flow Through A Forwarding Exchange
In a typical no-answer diversion, the originating exchange sends an IAM toward the original subscriber. The terminating service logic waits for the configured timer to expire, then creates or triggers a new call leg toward the forwarding destination. The second IAM should carry the appropriate called-party data and, where supported, redirection information.
The forwarding exchange may retain the original called number while inserting the redirecting number and updating the redirection counter. FCI on the new leg reflects the signaling conditions known at that point, which may differ from those on the first leg if the call has crossed a gateway or protocol boundary.
Address Complete Message and Answer Message handling then proceeds for the selected destination. Release messages must also be correlated with the correct call leg, since a failed attempt to reach the original number does not necessarily mean that the forwarded leg has failed.
Interworking In SS7 And SIGTRAN Networks
In traditional SS7, ISUP messages travel over MTP2 and MTP3 links, with signaling points using point codes and routing labels. In SIGTRAN, protocols such as M2PA, M2UA, or SUA can transport signaling over IP, but the ISUP parameters still require consistent interpretation at the application layer.
An IP signaling gateway may terminate one protocol stack and originate another. When that happens, FCI can reveal that the call has encountered interworking, while the gateway may also need to map or preserve redirection fields. Incorrect translation can cause a destination switch to lose the forwarding reason or reject an otherwise valid call.
For practical protocol study, the SS7 training resource provides useful context on ISUP, MTP3, timers, routing, and signaling architecture. These subjects help engineers trace diversion across both TDM and IP-based transport.
Trace Checks For Engineers
A packet or signaling trace should follow the call by CIC, point codes, and message sequence. Compare the first IAM with every later IAM created by forwarding logic. Record changes to FCI, called-party digits, redirecting number, original called number, and redirection indicators.
Useful validation steps include:
- Confirm the national or international nature of each call leg.
- Check whether interworking is indicated before or after diversion.
- Compare redirection counters with the number of forwarding attempts.
- Verify that the original destination remains available for billing and service records.
- Review IAM, ACM, ANM, and REL timing against configured no-answer or retry timers.
A test should cover successful forwarding, busy forwarding, no-answer forwarding, unreachable forwarding, and a call that crosses an ISUP-to-ISDN or ISUP-to-SIP gateway. Each scenario can expose different parameter-loss or timer problems.
Apply The Signaling Logic
Accurate diversion analysis requires more than checking a single FCI value. Map the complete call path, identify each signaling boundary, and verify how every node handles redirection information. This approach prevents false conclusions about interworking, forwarding causes, and end-to-end ISUP support.
Use controlled test calls and signaling traces to confirm the behavior of your switches, gateways, and SIGTRAN links, then incorporate the verified interpretation into routing, monitoring, and troubleshooting procedures.
