ISUP Forward Transfer Signalling For Supplementary Services
The ISDN User Part (ISUP) Forward Transfer message, commonly identified as FOT, is a signalling mechanism used when a call needs an action at a distant exchange. It sits within the SS7 call-control framework and can support operator intervention, service triggering, and supplementary-service interworking, depending on the carrier’s implementation.
FOT is easy to confuse with the subscriber feature usually called call transfer. They are not the same thing. Call transfer is a service outcome, while FOT is an ISUP message that can communicate a request or condition between exchanges. Its practical meaning therefore depends on the national ISUP profile, switch software, and interconnect agreement in use.
Meaning And Scope Of FOT
In standard ISUP, FOT has message code 0x08 and travels in the forward direction. It may be generated after call establishment or during call progress when the originating side needs the distant exchange to perform a defined action. Traditional applications include operator assistance and connection of the speech path to an operator position.
For supplementary services, the message is best viewed as a network trigger rather than a complete service definition. A carrier may map FOT to a service procedure, translate it into another signalling method, or ignore it when the receiving switch does not support the relevant capability. The exact behaviour should be checked against the applicable ITU-T and national specifications.
This distinction matters in Australia, where a call may cross Telstra, Optus, another wholesale carrier, and an IP-based interconnect before reaching the destination. A switch in Sydney may support a feature that is handled differently by a regional exchange in Queensland or Western Australia.
How FOT Fits Call Signalling
FOT does not usually begin the call. The IAM carries the initial address and service information, while ACM and ANM report alerting and answer conditions. If a supplementary-service or operator-related event occurs, FOT can provide an additional forward signal without restarting the basic call set-up procedure.
A receiving exchange must interpret FOT within the context of the existing call. It may examine the circuit identity, CIC, call state, service indicators, and any associated timers before acting. If the message arrives in an unexpected state, the exchange may reject it, release the call, log an alarm, or continue without applying the requested feature.
Interworking with SIP requires particular care. An Australian carrier migrating legacy PSTN services towards fibre and NBN-based access may carry the service across an ISUP-to-SIP gateway. That gateway needs an explicit mapping rule; otherwise, an FOT event can disappear even though the basic voice call succeeds.
Related ISUP Messages Compared
FOT should be analysed alongside the other messages visible in a signalling trace. A Forward Transfer message is not a substitute for a release procedure, a call-progress indication, or the address information in the initial call attempt.
| ISUP message | Main direction | Typical role | Relationship to supplementary services |
|---|---|---|---|
| IAM | Forward | Starts call establishment | Carries initial service and addressing information |
| ACM | Backward | Reports that the destination is being reached | May indicate progress before a feature is applied |
| CPG | Backward | Reports call progress or alerting changes | Can accompany supplementary-service state changes |
| FOT | Forward | Requests or signals a distant action | May trigger operator or service-related handling |
| ANM | Backward | Confirms answer | Establishes the answered-call state |
| REL | Either direction | Requests call release | Ends the call when service handling fails or completes |
| RLC | Either direction | Confirms release | Clears the signalling and circuit state |
The table shows why a trace containing FOT alone is not enough to diagnose a feature problem. Analysts should correlate the message with IAM service indicators, optional parameters, timestamps, circuit state, and subsequent ACM, ANM, REL, or RLC messages.
Testing In Australian Networks
Testing should use a controlled service scenario rather than a generic test call. For example, a laboratory route can connect a legacy ISUP switch to a SIP gateway and then to a test number. Repeating the same scenario through a Telstra or Optus wholesale path may reveal differences in supported message types and translation rules.
Australian numbering and emergency-service constraints also need attention. Do not use 000 for feature testing, and do not place uncontrolled test traffic across a live customer route. ACMA requirements, carrier change windows, and local maintenance practices should be included in the test plan.
Trace review
- Confirm the FOT message type, direction, CIC, and timestamp.
- Compare the message with the IAM, call state, and received optional parameters.
- Check whether the gateway preserves, translates, or discards FOT.
Service verification
- Test operator intervention and the intended supplementary feature separately.
- Repeat calls across metropolitan and regional routes where possible.
- Record the switch response, timer behaviour, alarms, and final release cause.
Security should be part of the same exercise. Unexpected FOT messages, forged signalling, and weak trust boundaries can be used to disrupt calls or provoke unauthorised service behaviour. A practical review of SS7 security threats helps place message validation, signalling firewalls, and route controls in context.
Deployment And Troubleshooting Priorities
A production design should document which supplementary services depend on FOT, which nodes originate it, and what the destination exchange is expected to do. It should also define fallback behaviour when FOT is unsupported. Silent feature loss is particularly difficult to detect because ordinary voice calls may continue normally.
For SIGTRAN deployments, the message is still an ISUP payload even when transported over MTP3 user adaptation, such as M2PA or M3UA. Engineers must therefore inspect both layers: SCTP association health and routing context at the transport side, then ISUP message sequencing and circuit identity at the application side.
The practical next step is to capture one controlled end-to-end trace, identify every FOT occurrence, and compare the observed switch response with the carrier’s ISUP service profile.
