Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 13575-96 (2004): Private Integrated Services Network – Call Transfer Supplementary Service
Specification, Functional Model, and Information Flows for Reliable Call Transfer in PISN
Scope and General Introduction
IEC 13575-96 (2004) is a key standard within the Private Integrated Services Network (PISN) family, jointly developed under the ISO/IEC framework. It specifies the call transfer supplementary service, which enables a user to transfer an established call to a third party. The standard defines the complete functional model, information flows, and signalling protocol requirements necessary for interoperability across PISN exchanges. The 2004 edition supersedes the original 1996 version, incorporating clarifications on state transitions, protocol elements, and support for multiple signalling scenarios.
Primarily targeting enterprise telecommunication systems, the standard ensures that call transfer works uniformly regardless of the equipment vendor. It applies to networks using the QSIG signalling system and complements the basic call control procedures defined in ISO/IEC 11572.
Tip: Implementors should also consult ISO/IEC 11582 for the generic functional protocol used to transport supplementary service information.
Technical Requirements and Functional Model
IEC 13575-96 (2004) identifies two fundamental call transfer types:
- Explicit Transfer – The transferring user initiates a consultation call to the target before completing the transfer.
- Implicit Transfer – The transfer is requested without prior consultation, often used for blind transfers.
The standard defines three functional roles:
- Transferring User – The party that requests the call transfer.
- Transferred User – The original called (or calling) party who will be transferred.
- Transfer Target – The third party to whom the call is transferred.
The functional model employs state diagrams (SDL) to describe the behaviour of each role. The key service primitives used in the call transfer procedure are summarised in the table below.
| Primitive | Direction | Purpose |
|---|---|---|
| Call Transfer Request | User → Network | Initiate transfer with target address and optional parameters |
| Call Transfer Indication | Network → Transferred User | Notify the party that a transfer is in progress |
| Call Transfer Response | Transferred User → Network | Accept or reject the incoming transfer |
| Call Transfer Confirm | Network → Transferring User | Indicate successful completion of the transfer |
| Call Transfer Failure Report | Network → Transferring User | Provide reason code if transfer fails |
The standard also specifies timers (e.g., TCT, TCTO) to handle abnormal situations and prevent deadlock states.
Warning: Failure to implement all mandatory timers correctly can lead to unpredictable call clearing and interoperability issues.
Implementation Highlights and Protocols
IEC 13575-96 (2004) relies on the QSIG signalling protocol for conveying call transfer information between PISN nodes. It extends the basic QSIG call control with supplementary service elements defined in the standard. The information are encapsulated using the Generic Functional Transport (GFT) mechanism, ensuring compatibility with the standard PISN architecture.
Key implementation aspects include:
- Correct handling of the consultation call and busy conditions.
- Support for both network- and user-initiated transfers.
- State consistency across multiple signalling endpoints, especially during failure scenarios.
- Interworking with ISDN and other networks through gateway functions.
Developers are advised to pay close attention to the encoding of the Call Transfer Identification Number (CTIN) and the Call Transfer Number (CTN) in the signalling messages.
Success: Many enterprise telephony platforms have successfully implemented this standard, achieving seamless call transfer across multi-vendor PISN environments.
Compliance, Testing, and Certification Notes
Conformity with IEC 13575-96 (2004) is assessed through protocol conformance testing, typically following the guidelines in the companion test suite standard ISO/IEC 13576. Certifying bodies require demonstration of:
- All mandatory procedures (explicit and implicit transfer) operating correctly.
- Proper handling of optional features if claimed (e.g., transfer of a consultation call, park and retrieve).
- Negative tests covering erroneous messages and timeout conditions.
Test scenarios are defined for each functional entity role, and a formal protocol implementation conformance statement (PICS) must be provided.
Important: Networks not compliant with the 2004 edition may reject call transfer requests or display undefined behaviour. Upgrading to the latest edition is strongly recommended for cross-vendor interoperability.
The standard is stable and widely adopted. However, national regulatory requirements may impose additional restrictions on call transfer for emergency or lawful interception services; these are beyond the scope of IEC 13575-96 (2004) but must be respected in operational deployments.
Frequently Asked Questions
Q: What is the difference between IEC 13575-96 (2004) and the earlier 1996 edition?
A: The 2004 edition adds clarifications for the handling of the consultation call, revised state diagrams for failure recovery, and updates to the information element coding to align with other PISN supplementary services.
A: The 2004 edition adds clarifications for the handling of the consultation call, revised state diagrams for failure recovery, and updates to the information element coding to align with other PISN supplementary services.
Q: Does the standard require QSIG support at both ends of the connection?
A: Yes, the call transfer supplementary service assumes an underlying QSIG signalling capability between all involved nodes. If QSIG is not supported, the transfer may fall back to basic call procedures, but full functionality is only guaranteed with end-to-end QSIG.
A: Yes, the call transfer supplementary service assumes an underlying QSIG signalling capability between all involved nodes. If QSIG is not supported, the transfer may fall back to basic call procedures, but full functionality is only guaranteed with end-to-end QSIG.
Q: Can this standard be applied to SIP-based VoIP systems?
A: While the functional model is protocol‑neutral, the encoding and signalling procedures are specific to QSIG. For SIP networks, analogous services are defined in RFC 5589 (Session Initiation Protocol Call Control – Transfer). Direct mapping of IEC 13575-96 primitives to SIP is possible but requires adaptation.
A: While the functional model is protocol‑neutral, the encoding and signalling procedures are specific to QSIG. For SIP networks, analogous services are defined in RFC 5589 (Session Initiation Protocol Call Control – Transfer). Direct mapping of IEC 13575-96 primitives to SIP is possible but requires adaptation.
Q: Is IEC 13575-96 (2004) still actively maintained?
A: The technical content is considered stable, and as of 2026 it has not been withdrawn. However, ecosystem trends may shift toward all‑IP solutions; users should monitor the official ISO/IEC status for any reaffirmation or supersession.
A: The technical content is considered stable, and as of 2026 it has not been withdrawn. However, ecosystem trends may shift toward all‑IP solutions; users should monitor the official ISO/IEC status for any reaffirmation or supersession.
This article is based on IEC 13575-96 (2004) and reflects the standard as of 2026.