ISUP Backward And Forward Call Indicators Explained
Signaling System No. 7 uses Initial Address Message (IAM), Address Complete Message (ACM), Answer Message (ANM), and release messages to coordinate circuit-switched calls. Within this exchange, call indicators carry compact information about the call’s origin, capabilities, progress, and treatment across the network.
Forward Call Indicators (FCI) travel toward the called party, usually inside the IAM. Backward Call Indicators (BCI) travel toward the originating exchange, commonly in the ACM or related backward signaling. Their names reflect signaling direction, not whether a call is succeeding or failing.
Understanding the distinction is essential when troubleshooting ISUP call setup, interworking between ISDN and non-ISDN networks, or interpreting protocol traces. A single indicator can influence routing, alerting, charging, and the availability of end-to-end signaling features.
Direction Defines The Primary Meaning
FCI describes conditions known at, or selected by, the originating side before the call reaches the destination. It tells downstream exchanges what kind of call is being offered and which signaling capabilities may be available. The IAM can therefore establish expectations before the destination responds.
BCI reports information learned in the reverse direction after a destination exchange has examined the IAM or attempted to reach the subscriber. It can communicate called-party status, charging conditions, and the result of capability negotiation. The ACM is often the first message in which the originating exchange receives these details.
The distinction is operational: FCI helps a network decide how to handle an outgoing call, while BCI helps it interpret how the far end is handling that call.
What Forward Call Indicators Carry
The FCI field commonly includes the nature of the connection, the desired end-to-end signaling method, interworking information, and ISDN User Part availability. It can indicate whether the call is national or international and whether signaling information can pass transparently from end to end.
The end-to-end method indicator is especially important. It describes whether signaling can be performed through the complete route, through a pass-along mechanism, or only on a link-by-link basis. The interworking indicator warns that the call has crossed a network boundary or encountered a system that does not provide the expected ISDN signaling functions.
At the originating exchange, these bits help determine compatibility and route selection. They do not themselves confirm that the destination accepted the call; they describe the offered call and the capabilities associated with it.
What Backward Call Indicators Carry
BCI provides the return-side interpretation of call progress. Its fields can identify the called party’s status, such as whether the address is complete, the subscriber is reachable, or the destination condition requires special treatment. It may also carry a charge indicator showing whether charging is possible, not applicable, or subject to a particular arrangement.
Backward indicators also report end-to-end signaling capabilities and interworking. When a terminating network cannot support the requested method, the BCI values help the originating side understand that limitation. This can affect the delivery of progress tones, supplementary services, or transparent user-to-user information.
The exact field layout depends on the applicable ITU-T, ETSI, ANSI, or national ISUP variant. Implementations should therefore interpret the complete parameter definition rather than assuming that every network uses identical bit assignments.
Side-By-Side Protocol Comparison
| Characteristic | Forward Call Indicators | Backward Call Indicators |
|---|---|---|
| Normal message direction | Originating exchange toward the destination | Destination or terminating exchange toward the origin |
| Common ISUP message | IAM | ACM, and sometimes related backward messages |
| Main purpose | Describe the offered call and originating capabilities | Report destination status and backward capabilities |
| Typical information | National or international nature, end-to-end method, interworking, ISUP availability | Charge condition, called-party status, end-to-end method, interworking |
| Network decision | Route and process the outgoing call | Interpret progress and adjust call treatment |
| Diagnostic value | Shows what the origin requested or advertised | Shows what the far end accepted, supported, or reported |
Why Interworking Changes The Indicators
A pure ISUP path can preserve signaling information more effectively than a route involving older analog, non-ISDN, or incompatible signaling systems. When a call crosses such a boundary, interworking indicators may be set in the forward direction and reflected in backward information.
This matters because an exchange should not assume that a requested end-to-end feature survived every network segment. For example, a transit switch may receive an IAM that requests end-to-end signaling but return an ACM indicating that only link-by-link procedures are possible.
Engineers analyzing signaling link sets should correlate these indicator values with link availability, route topology, and signaling transfer points. A correct bit value cannot compensate for a congested or incorrectly dimensioned SS7 path.
Reading Indicators In A Trace
Start with the IAM and record the FCI before examining the ACM. Confirm the direction, message type, protocol variant, and parameter length. Then decode each field according to the network’s specification, since spare bits and national options can differ.
Next, compare the BCI in the ACM with the original request. A mismatch may reveal capability loss, an interworking point, an incorrect translation, or a faulty gateway implementation. The BCI should be read with the called party’s number, cause indicators, and subsequent ANM or REL messages.
In modern environments, SS7 signaling may be transported through SIGTRAN and integrated with IP-based core networks. The transport technology changes the carrier, but it does not remove the need to understand ISUP semantics; protocol analysis still depends on message direction and parameter context. The wider transition toward IMS is described in SS7 and LTE evolution.
Practical Checks For Engineers
Use a consistent decoding process when reviewing live traces or lab captures:
- Identify whether the parameter came from an IAM, ACM, ANM, or another ISUP message.
- Verify the exact regional or vendor-specific ISUP specification.
- Separate capability indicators from status and cause information.
- Compare forward values with backward values across the same call reference.
- Correlate indicator changes with interworking gateways, route changes, and release causes.
This approach prevents a common error: treating an FCI value as proof of successful service delivery or treating a BCI value as a simple mirror of the IAM. The two fields describe related but different points in the call lifecycle.
A reliable interpretation combines indicator decoding with call timing, circuit selection, MTP3 routing, and timer behavior. For example, an ACM may arrive with valid backward indicators while a delayed ANM or unexpected release still exposes a downstream problem.
Use these distinctions when building SS7 training exercises, validating ISUP gateways, or investigating failed call setup. Decode the forward offer first, interpret the backward response second, and document the protocol variant used for every analysis.
