Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Understanding IEC 17342-05: The Generic Functional Protocol for Supplementary Services in Private Integrated Services Networks
A technical deep dive into the ISO/IEC 17342 standard for inter-exchange signalling and supplementary service control in PISN environments
Scope of IEC 17342-05
IEC 17342-05, technically equivalent to CAN/CSA-ISO/IEC 17342-05 and the international base standard ISO/IEC 17342:2004, specifies the Generic Functional Protocol (GFP) for the support of supplementary services (SS) in a Private Integrated Services Network (PISN). The standard focuses on the inter-exchange signalling between Private Integrated services Network eXchanges (PINXs) using the digital signalling system protocol defined in the broader GFP framework (ISO/IEC 11582).
The scope encompasses the signalling procedures, message formats, and protocol state machines necessary to invoke, activate, deactivate, and interrogate supplementary services across a PISN. IEC 17342-05 is part of the ISO/IEC 173xx series that standardises PISN supplementary services; this document specifically provides the generic protocol building blocks that are reused by individual service stage 3 standards (e.g., ISO/IEC 17343 for Call Forwarding).
Typical application environments include enterprise telephony networks, campus-wide voice and multimedia systems, and any private network requiring consistent feature interaction between nodes from different vendors. The standard ensures interoperability at the signalling level for a wide range of supplementary services, including call transfer, call forwarding, conference calling, and call hold.
Technical Requirements and Protocol Architecture
Protocol Stack and Reference Model
IEC 17342-05 aligns the Generic Functional Protocol with the OSI reference model. The protocol operates at the network layer (Layer 3) of the inter-exchange signalling interface (the Q interface). The key protocol elements include:
- GFP Messages: Facility (FACILITY), Register (REGISTER), and Facility-Reject messages, each with a defined set of information elements.
- Operations and Errors: The protocol uses a remote operations service element (ROSE) based on ASN.1 encoding for operation invocation and result/error reporting.
- Association Control: A single association per signalling connection is used for supplementary service control.
Supplementary Services Covered
The standard defines the generic protocol mechanism that is then applied to individual supplementary services. Table 1 lists the main supplementary services supported under the GFP framework, indicating their typical status in a conformant implementation.
| Supplementary Service | Standard Reference | Mandatory (M) / Optional (O) |
|---|---|---|
| Call Transfer | ISO/IEC 17343 | M |
| Call Forwarding Unconditional | ISO/IEC 17344 | M |
| Call Forwarding on Busy | ISO/IEC 17345 | M |
| Call Forwarding on No Reply | ISO/IEC 17346 | M |
| Call Hold | ISO/IEC 17347 | O |
| Conference | ISO/IEC 17348 | O |
| Completion of Calls to Busy Subscriber | ISO/IEC 17349 | O |
Each service uses the GFP operations (e.g., Activate, Deactivate, Interrogate, Invoke) with service-specific parameters. The standard mandates that all implementations support the mandatory services at the inter-exchange signalling level to guarantee a basic set of features across multi-vendor PISNs.
Signalling Procedures
The procedures defined in IEC 17342-05 cover:
- Service Invocation: Initiating a supplementary service during a call, using the FACILITY message.
- Operation Invocation and Return: Use of the ROSE-linked procedures to request and acknowledge service operations.
- Error Handling: Definition of error types (e.g., InvalidParam, ResourceUnavailable) and corresponding rejection messages.
- Transparency: The protocol ensures that supplementary service information is transparently passed between network nodes without requiring intermediate PINX processing for services not locally relevant.
Implementation Highlights
Implementation Tip: When developing a PINX stack that conforms to IEC 17342-05, start by implementing the mandatory services (Call Transfer, Call Forwarding variants) using the GFP Facility message. Use ASN.1 tools to auto-generate encoding/decoding routines for the operation components, as hand-coding is error-prone and incompatible with the strict conformance requirements.
Key implementation considerations include:
- ASN.1 Encoding Compliance: All operations and parameters are encoded using ASN.1 (Basic Encoding Rules – BER). The standard provides ASN.1 module definitions that must be exactly followed to ensure interoperability.
- State Machine Alignment: The protocol state machines defined in Annex A of ISO/IEC 17342 for mandatory services must be implemented without deviation. Optional services may extend the state machines but must not conflict with the mandatory behaviors.
- Timer Management: The standard defines several timers (e.g., T1 for waiting for operation response). Implementations must use the specified timer values and recovery procedures.
- Inter-working with Legacy PBXs: Gateways connecting PISN to traditional circuit-switched networks must map GFP messages to Q.931 or DSS1 supplementary service procedures, requiring careful translation of operation identifiers and parameters.
Best Practice: Use a layered signalling design that separates the generic GFP module from service-specific logic. This modular approach simplifies conformance testing and allows independent updates if a particular supplementary service is revised.
Compliance and Conformance Testing
Conformance to IEC 17342-05 is essential for multi-vendor PISN interoperability. The standard references the conformance testing methodology defined in ISO/IEC 9646 (OSI Conformance Testing Methodology and Framework). Key compliance requirements include:
- Protocol Implementation Conformance Statement (PICS): Suppliers must provide a PICS proforma declaring which mandatory and optional services are supported.
- Static Conformance Review: Verification that all mandatory capabilities (messages, parameters, operations) are implemented.
- Dynamic Conformance Testing: Execution of test suites covering normal and abnormal protocol sequences for each claimed service.
- Interoperability Testing: Practical testing between at least two independent PISN implementations to validate end-to-end service behaviour.
Warning: Failure to conform to the mandatory service definitions can result in call processing failures or service interruption across the PISN. Non‑conformant implementations may also introduce security vulnerabilities if supplementary service control messages are improperly validated.
Organisations seeking certification should work with accredited laboratories that have experience with the PISN family of standards (ISO/IEC 17340 series). The CSA version (CAN/CSA-ISO/IEC 17342-05) contains additional national deviations; these must be reviewed if deploying in the Canadian market.
Compliance Note: As of 2026, the PISN standards are being updated to align with modern IP‑based signalling (e.g., SIP interworking). However, IEC 17342-05 remains the reference for hybrid TDM‑VoIP networks and must be strictly applied in legacy systems until migration is fully complete.
Frequently Asked Questions
Q: What is the primary difference between IEC 17342-05 and the earlier standard ISO/IEC 17342:2004?
A: IEC 17342-05 corresponds to the CAN/CSA adoption of ISO/IEC 17342:2004 with minor editorial clarifications and a harmonised Canadian title. The technical content is identical to the 2004 base edition. There is no separate revision; the “-05” suffix indicates the Canadian adoption year.
A: IEC 17342-05 corresponds to the CAN/CSA adoption of ISO/IEC 17342:2004 with minor editorial clarifications and a harmonised Canadian title. The technical content is identical to the 2004 base edition. There is no separate revision; the “-05” suffix indicates the Canadian adoption year.
Q: Can IEC 17342-05 be used for IP‑based PISN implementations?
A: The standard was originally designed for circuit‑switched digital networks (e.g., using E‑1 or T‑1 links). However, its generic functional protocol is transport‑agnostic and can be tunnelled over IP using facilities such as Q‑SIG over IP. For pure VoIP systems, SIP‑based supplementary services may be more appropriate, but IEC 17342-05 remains relevant for hybrid or migration scenarios.
A: The standard was originally designed for circuit‑switched digital networks (e.g., using E‑1 or T‑1 links). However, its generic functional protocol is transport‑agnostic and can be tunnelled over IP using facilities such as Q‑SIG over IP. For pure VoIP systems, SIP‑based supplementary services may be more appropriate, but IEC 17342-05 remains relevant for hybrid or migration scenarios.
Q: Which supplementary services are mandatory for conformance?
A: The mandatory services are Call Transfer, Call Forwarding Unconditional, Call Forwarding on Busy, and Call Forwarding on No Reply. All other services such as Call Hold, Conference, and Completion of Calls to Busy Subscriber are optional but must be documented in the PICS if omitted.
A: The mandatory services are Call Transfer, Call Forwarding Unconditional, Call Forwarding on Busy, and Call Forwarding on No Reply. All other services such as Call Hold, Conference, and Completion of Calls to Busy Subscriber are optional but must be documented in the PICS if omitted.
Q: How does the standard handle feature interactions between multiple supplementary services?
A: IEC 17342-05 delegates feature interaction management to the service stage 3 definitions (individual service standards) and the PINX internal logic. The GFP provides a mechanism for service control, but interaction resolution (e.g., between Call Transfer and Conference) must follow the service‑specific precedence rules defined in the related standards (e.g., ISO/IEC 17341 for general interaction).
A: IEC 17342-05 delegates feature interaction management to the service stage 3 definitions (individual service standards) and the PINX internal logic. The GFP provides a mechanism for service control, but interaction resolution (e.g., between Call Transfer and Conference) must follow the service‑specific precedence rules defined in the related standards (e.g., ISO/IEC 17341 for general interaction).
© 2026 Technical Standards Review. All rights reserved. Icons and styling are provided for informational purposes; verify always with the latest edition of the standard.