ISO/IEC 21411:2001

Information technology - Telecommunications and information exchange between systems - Corporate telecommunication networks - Signalling interworking between QSIG and H.323 - Call diversion supplementary services

This International Standard specifies signalling interworking between "QSIG" and "H.323" in support of call diversion supplementary services within a Corporate telecommunication Network (CN). "QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges (PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ISO/IEC 11579-1. A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other Standards, in particular ISO/IEC 11572 (call control in support of basic services), ISO/IEC 11582 (generic functional protocol for the support of supplementary services) and a number of standards specifying individual supplementary services. ISO/IEC 13873 specifies the QSIG protocol in support of call diversion services. "H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation referring to various ITU-T recommendations, in particular Recommendations H.225.0 and H.245 (basic communication capabilities) and Recommendation H.450.1 (generic functional protocol for the support of supplementary services). Recommendation H.450.3 specifies the H.323 protocol in support of call diversion services. NOTE - H.450.3 applies only to the 1998 version of H.323 (also known as H.323 version 2) and to later versions. In both ISO/IEC 13873 (QSIG) and ITU-Recommendation H.450.3 (H.323), the call diversion supplementary services are Call Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply (SS-CFNR) and Call Deflection (SS-CD). These supplementary services apply during call establishment and provide diversion of an incoming call to another destination. Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP network, or a call originating at a user of an IP network to terminate at a user of a PISN. This International Standard provides the following additional capabilities: _ a call originating from a PISN and destined for a user of an H.323 network to be diverted by the H.323 network to an alternative destination; _ a call originating from an H.323 network and destined for a user of a PISN to be diverted by the PISN to an alternative destination; _ a call destined for a user of a PISN to be diverted to an alternative destination where that alternative destination is in an H.323 network; _ a call destined for a user of an H.323 network to be diverted to an alternative destination where that alternative destination is in a PISN. This International Standard is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and an IP network employing H.323.

Technologies de l'information — Télécommunications et échange d'information entre systèmes — Réseaux de télécommunications corporatifs — Signalisation de travail entre QSIG et H.323 — Services supplémentaires de diversion d'appel

General Information

• Status: Published
• Publication Date: 29-Aug-2001
• ICS: 33.040.35 - Telephone networks
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 20-Sep-2006
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 28017:2011 - Rubber hoses and hose assemblies, wire or textile reinforced, for dredging applications - Specification
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 21411:2001 specifies signalling interworking between QSIG and H.323 to support call diversion (call forwarding) supplementary services within a Corporate Telecommunication Network (CN). The standard describes how circuit‑switched Private Integrated Services Networks (PISNs) using QSIG (PINX at the Q reference point) interoperate with packet‑based IP networks using H.323 signalling so that calls can be diverted across network boundaries. It applies to any interworking unit or gateway that connects a PISN and an H.323 IP network.

Key topics and technical requirements

• Support for the four call diversion supplementary services defined in QSIG / H.450.3:
  • SS‑CFU (Call Forwarding Unconditional)
  • SS‑CFB (Call Forwarding Busy)
  • SS‑CFNR (Call Forwarding No Reply)
  • SS‑CD (Call Deflection)
• Service architecture for invocation, operation, activation, deactivation and interrogation of diversion services across QSIG and H.323 domains.
• Definition of call legs and roles (Entity A/B/C, rerouting entity) and interworking scenarios where the rerouting entity may reside in the PISN or the IP network (scenarios A1–G2).
• Protocol interworking requirements: message/APDU mapping, signalling behaviour during call establishment and rerouting, and handling of call clearing when diversion occurs.
• Conformance requirement: gateways must satisfy the Implementation Conformance Statement (ICS) proforma provided in Annex A.
• Informative examples: Annex B contains example message sequence diagrams for the interworking scenarios.

Practical applications and who uses this standard

• Telecom equipment vendors and gateway manufacturers implementing QSIG ↔ H.323 interworking for corporate PBX and VoIP integration.
• Enterprise network architects and system integrators migrating legacy PISN/PBX services to IP while preserving supplementary services such as call forwarding.
• Service providers and operators deploying private corporate networks that include mixed circuit‑switched and packet‑based components.
• Developers of unified communications and multimedia endpoint/gatekeeper solutions that must interwork with PBX features.

Benefits include preserving consistent call diversion behaviour across heterogeneous networks, enabling calls to be forwarded between PBX users and IP endpoints, and supporting enterprise migration to IP while maintaining existing supplementary services.

Related standards

Relevant normative references include:

• ISO/IEC 13873 (QSIG call diversion)
• ISO/IEC 11572, 11579‑1, 11582 (PISN / QSIG fundamentals)
• ISO/IEC 21409 (QSIG ↔ H.323 generic supplementary services)
• ITU‑T H.323, H.225.0, H.245, H.450.1 and H.450.3 (H.323 call diversion)

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 21411
First edition
2001-08-15
Information technology —
Telecommunications and information
exchange between systems — Corporate
telecommunication networks — Signalling
interworking between QSIG and H.323 —
Call diversion supplementary services
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Réseaux de télécommunications
corporatifs — Signalisation de travail entre QSIG et H.323 — Services
supplémentaires de diversion d'appel
Reference number
©
ISO/IEC 2001
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading
this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in
this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the
unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2001
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
© ISO/IEC 2001 – All rights reserved
ii
Contents
Foreword v
Introduction vi
1 Scope 1
2 Conformance 1
3 Normative references 1
4 Definitions 2
4.1 External definitions 2
4.2 Other definitions 2
4.2.1 Association D 2
4.2.2 Association E 2
4.2.3 Association F 2
4.2.4 Association G 2
4.2.5 Entity A 2
4.2.6 Entity B 2
4.2.7 Entity B’ 2
4.2.8 Entity C 2
4.2.9 Entity D 2
4.2.10 Entity E 3
4.2.11 Entity F 3
4.2.12 Entity G 3
4.2.13 Entity H 3
4.2.14 Gateway 3
4.2.15 Leg A 3
4.2.16 Leg B 3
4.2.17 Leg B’ 3
4.2.18 Leg C 3
4.2.19 Rerouting entity 3
4.2.20 Scenario A1 3
4.2.21 Scenario A2 3
4.2.22 Scenario B1 3
4.2.23 Scenario B2 3
4.2.24 Scenario C1 3
4.2.25 Scenario C2 3
4.2.26 Scenario D1 3
4.2.27 Scenario D2 3
4.2.28 Scenario E1 3
4.2.29 Scenario E2 3
4.2.30 Scenario F1 3
4.2.31 Scenario F2 3
4.2.32 Scenario G1 3
4.2.33 Scenario G2 3
5 Acronyms 4
6 Service architecture 4
6.1 Service architecture for invocation and operation 4
6.1.1 ISO/IEC 13873 service architecture 4
© ISO/IEC 2001 – All rights reserved
iii
6.1.2 H.450.3 service architecture 5
6.1.3 Scenarios for interworking 5
6.1.4 Determination of the location of the rerouting entity when interworking 6
6.2 Service architecture for activation, deactivation and interrogation 6
6.2.1 ISO/IEC 13873 service architecture 6
6.2.2 H.450.3 service architecture 7
6.2.3 Scenarios for interworking 7
7 Protocol interworking – General requirements 8
8 Protocol interworking – Messages and APDUs 8
8.1 Scenario A1 8
8.2 Scenario A2 10
8.3 Scenario B1 11
8.4 Scenario B2 12
8.5 Scenario C1 12
8.6 Scenario C2 13
8.7 Scenario D1 13
8.8 Scenario D2 14
8.9 Scenario E1 14
8.10 Scenario E2 15
8.11 Scenario F1 15
8.12 Scenario F2 16
8.13 Scenario G1 16
8.14 Scenario G2 17
Annexes
A- Implementation Conformance Statement (ICS) proforma 18
B- Example message sequence diagrams 28
© ISO/IEC 2001 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of patent rights.
ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 21411 was prepared by ECMA (as ECMA-309) and was adopted, under a special “fast-track
procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national
bodies of ISO and IEC.
Annex A forms a normative part of this International Standard. Annex B is for information only.
© ISO/IEC 2001 – All rights reserved
v
Introduction
This International Standard is one of a series of Standards defining the interworking of services and signalling protocols
deployed in Corporate telecommunication Networks (CNs). The series uses telecommunication concepts as developed by
ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as defined by ISO/IEC.
This International Standard defines the signalling protocol interworking for call diversion supplementary services between a
Private Integrated Services Network (PISN) and a packet-based private telecommunications network based on the Internet
Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point (QSIG) and that
the protocols for the IP-based network are based on ITU-T Recommendation H.323.
This International Standard is based upon the practical experience of ECMA member companies and the results of their active
and continuous participation in the work of ISO/IEC JTC 1, ITU-T, ETSI and other international and national standardization
bodies. It represents a pragmatic and widely based consensus.
© ISO/IEC 2001 – All rights reserved
vi
INTERNATIONAL STANDARD ISO/IEC 21411:2001(E)
Information technology - Telecommunications and information exchange between
systems - Corporate telecommunication networks - Signalling interworking between
QSIG and H.323 - Call diversion supplementary services
1Scope
This International Standard specifies signalling interworking between “QSIG” and “H.323” in support of call diversion
supplementary services within a Corporate telecommunication Network (CN).
“QSIG” is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges (PINX)
within a Private Integrated Services Network (PISN). The Q reference point is defined in ISO/IEC 11579-1. A PISN provides
circuit-switched basic services and supplementary services to its users. QSIG is specified in other Standards, in particular
ISO/IEC 11572 (call control in support of basic services), ISO/IEC 11582 (generic functional protocol for the support of
supplementary services) and a number of standards specifying individual supplementary services. ISO/IEC 13873 specifies the
QSIG protocol in support of call diversion services.
“H.323” is a set of signalling protocols for the support of voice or multimedia communication within a packet network, in
particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 signalling
protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or directly. An endpoint
can be a terminal or a gateway to another network. H.323 is an “umbrella” recommendation referring to various ITU-T
recommendations, in particular Recommendations H.225.0 and H.245 (basic communication capabilities) and
Recommendation H.450.1 (generic functional protocol for the support of supplementary services). Recommendation H.450.3
specifies the H.323 protocol in support of call diversion services.
NOTE - H.450.3 applies only to the 1998 version of H.323 (also known as H.323 version 2) and to later versions.
In both ISO/IEC 13873 (QSIG) and ITU-Recommendation H.450.3 (H.323), the call diversion supplementary services are Call
Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply (SS-CFNR) and Call
Deflection (SS-CD). These supplementary services apply during call establishment and provide diversion of an incoming call to
another destination.
Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP network, or
a call originating at a user of an IP network to terminate at a user of a PISN. This International Standard provides the following
additional capabilities:
� a call originating from a PISN and destined for a user of an H.323 network to be diverted by the H.323 network to an
alternative destination;
� a call originating from an H.323 network and destined for a user of a PISN to be diverted by the PISN to an alternative
destination;
� a call destined for a user of a PISN to be diverted to an alternative destination where that alternative destination is in an
H.323 network;
� a call destined for a user of an H.323 network to be diverted to an alternative destination where that alternative destination
is in a PISN.
This International Standard is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG
and an IP network employing H.323.
2 Conformance
In order to conform to this International Standard, a gateway shall satisfy the requirements identified in the Implementation
Conformance Statement (ICS) proforma in annex A.
3 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this
International Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.
However, parties to agreements based on this International Standard are encouraged to investigate the possibility of applying
the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative
document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards.
© ISO/IEC 2001 – All rights reserved
ISO/IEC 11572:2000, Information technology - Telecommunications and information exchange between systems - Private
Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol
ISO/IEC 11579-1:1994, Information technology - Telecommunications and information exchange between systems - Private
integrated services network - Part 1: Reference configuration for PISN Exchanges (PINX)
ISO/IEC 11582:1995, Information technology - Telecommunications and information exchange between systems - Private
Integrated Services Network - Generic functional protocol for the support of supplementary services - Inter-exchange
signalling procedures and protocol
ISO/IEC 13873:1995, Information technology - Telecommunications and information exchange between systems - Private
Integrated Services Network - Inter-exchange signalling protocol - Call diversion supplementary services
ISO/IEC 21409:2001, Information technology - Telecommunications and information exchange between systems - Corporate
telecommunication networks - Signalling interworking between QSIG and H.323 - Generic functional protocol for the support
of supplementary services
ITU-T Rec. H.225.0:1998 (or later edition), Call signalling protocols and media stream packetization for packet-based
multimedia communication systems
ITU-T Rec. H.245:1998 (or later edition), Control protocol for multimedia communication
ITU-T Rec. H.323:1998 (or later edition), Packet-based multimedia communications systems
ITU-T Rec. H.450.1:1998, Generic functional protocol for the support of supplementary services in H.323
ITU-T Rec. H.450.3:1998, Call diversion supplementary service for H.323
4 Definitions
For the purposes of this International Standard, the following definitions apply.
4.1 External definitions
This International Standard uses the following terms defined in other documents:
– Call (ISO/IEC 21409)
– Corporate telecommunication Network (CN) (ISO/IEC 21409)
– Endpoint (ITU-T Rec. H.323)
– Gatekeeper (ITU-T Rec. H.323)
– IP network (ISO/IEC 21409)
– Private Integrated Services Network (PISN) (ISO/IEC 21409)
– Private Integrated services Network eXchange (PINX) (ISO/IEC 11579-1)
Additionally the definitions in ISO/IEC 13873 and ITU-T Recommendation H.450.3 apply as appropriate.
4.2 Other definitions
4.2.1 Association D : Signalling association between entity D and entity G.
4.2.2 Association E : Signalling association between entity E and entity G.
4.2.3 Association F : Signalling association between entity F and entity G.
4.2.4 Association G : Signalling association between entity G and entity H.
4.2.5 Entity A : Signalling entity at the PINX or H.323 endpoint serving the calling user (user A).
4.2.6 Entity B : Signalling entity at the PINX serving the diverting user (user B) or H.323 entity that invokes diversion on
behalf of user B.
4.2.7 Entity B’ : Signalling entity at the H.323 endpoint serving user B.
4.2.8 Entity C : Signalling entity at the PINX or H.323 endpoint serving the diverted-to-user (user C).
4.2.9 Entity D : Signalling entity at the PINX or H.323 endpoint serving an activating user.
© ISO/IEC 2001 – All rights reserved
4.2.10 Entity E : Signalling entity at the PINX or H.323 endpoint serving a deactivating user.
4.2.11 Entity F : Signalling entity at the PINX or H.323 endpoint serving an interrogating user.
4.2.12 Entity G : Signalling entity for activation / deactivation / interrogation at a PINX or H.323 endpoint serving a diverting
endpoint.
4.2.13 Entity H : Signalling entity for restriction checking at a PINX or H.323 endpoint serving a diverted-to endpoint.
4.2.14 Gateway : A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG.
4.2.15 Leg A : Call segment that lies between entity A and the rerouting entity.
4.2.16 Leg B : Call segment that lies between the rerouting entity and entity B.
4.2.17 Leg B’ : Call segment that lies between entity B and entity B’.
4.2.18 Leg C : Call segment that lies between the rerouting entity and entity C.
4.2.19 Rerouting entity : Signalling entity that initiates the rerouting of a call towards user C and clears the call towards user
B.
4.2.20 Scenario A1 : Interworking arrangement in which entity A (PINX A) is in the PISN and the rerouting entity is in the IP
network.
4.2.21 Scenario A2 : Interworking arrangement in which entity A (endpoint A) is in the IP network and the rerouting entity is
in the PISN.
4.2.22 Scenario B1 : Interworking arrangement in which entity B (PINX B) is in the PISN and the rerouting entity is in the IP
network.
4.2.23 Scenario B2 : Interworking arrangement in which entity B (diverting endpoint or its gatekeeper) is in the IP network
and the rerouting entity is in the PISN.
4.2.24 Scenario C1 : Interworking arrangement in which entity C (PINX C) is in the PISN and the rerouting entity is in the IP
network.
4.2.25 Scenario C2 : Interworking arrangement in which entity C (endpoint C) is in the IP network and the rerouting entity is
in the PISN.
4.2.26 Scenario D1 : Interworking arrangement in which entity D (PINX D) is in the PISN and entity G (endpoint G) is in the
IP network.
4.2.27 Scenario D2 : Interworking arrangement in which entity D (endpoint D) is in the IP network and entity G (PINX G) is
in the PISN.
4.2.28 Scenario E1 : Interworking arrangement in which entity E (PINX E) is in the PISN and entity G (endpoint G) is in the
IP network.
4.2.29 Scenario E2 : Interworking arrangement in which entity E (endpoint E) is in the IP network and entity G (PINX G) is in
the PISN.
4.2.30 Scenario F1 : Interworking arrangement in which entity F (PINX F) is in the PISN and entity G (endpoint G) is in the IP
network.
4.2.31 Scenario F2 : Interworking arrangement in which entity F (endpoint F) is in the IP network and entity G (PINX G) is in
the PISN.
4.2.32 Scenario G1 : Interworking arrangement in which entity G (PINX G) is in the PISN and entity H (endpoint H) is in the
IP network.
4.2.33 Scenario G2 : Interworking arrangement in which entity G (endpoint G) is in the IP network and entity H (PINX H) is
in the PISN.
© ISO/IEC 2001 – All rights reserved
5 Acronyms
APDU Application Protocol Data Unit
CN Corporate telecommunication Network
ICS Implementation Conformance Statement
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
SS-CD Supplementary Service Call Deflection
SS-CFB Supplementary Service Call Forwarding Busy
SS-CFNR Supplementary Service Call Forwarding No Reply
SS-CFU Supplementary Service Call Forwarding Unconditional
6 Service architecture
6.1 Service architecture for invocation and operation
6.1.1 ISO/IEC 13873 service architecture
The QSIG protocol for call diversion invocation and operation is based around four signalling entities or PINX types:
� entity A – the PINX serving the calling user (user A);
� entity B – the PINX serving the diverting user (user B);
� entity C – the PINX serving the diverted-to user (user C);
� rerouting entity – the PINX that initiates the rerouting of the call towards user C and clears the call towards user B.
Where a user is in another network, the role of entity A, entity B or entity C is performed by the other network, the gateway
PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway PINX.
This can be represented diagrammatically as shown in figure 1.
Entity B
Leg B
Leg A
Entity A
Rerouting
entity
Entity C
Leg C
Figure 1 – Call diversion architecture for QSIG
From this it can be seen that there are three segments or “legs” to the call:
� leg A from entity A to the rerouting entity;
� leg B from the rerouting entity to entity B;
� leg C from the rerouting entity to entity C.
The QSIG protocol supports each of these three legs.
The rerouting entity is constrained to be collocated with (in the same PINX as) entity A or entity B (or both if entity A and
entity B are collocated). In addition, entity C can be collocated with the rerouting entity (and therefore with entity A and/or
entity B). When an entity is collocated with the rerouting entity, the leg of the call concerned is internal to the physical PINX
and therefore the QSIG protocol for that leg does not apply.
© ISO/IEC 2001 – All rights reserved
6.1.2 H.450.3 service architecture
The architecture shown above for QSIG applies also to H.450.3, except that PINXs are replaced by H.323 entities as follows:
� entity A – the calling endpoint;
� entity B – the entity that invokes diversion on behalf of the diverting user;
� entity B’– the diverting endpoint;
� entity C – the diverted-to endpoint;
� rerouting entity – the entity that initiates the rerouting of the call towards user C and clears the call towards user B.
Where a user is in another network, the role of entity A, entities B and B’ or entity C is performed by the other network, the
gateway, or the two in combination. However, from the H.450.3 point of view the role is performed by the gateway.
This can be represented diagrammatically as shown in figure 2:
Leg B’
Entity B Entity B’
Leg B
Leg A
Entity A
Rerouting
entity
Entity C
Leg C
Figure 2 – Call diversion architecture for H.323
From this it can be seen that there are four segments or “legs” to the call:
� leg A from entity A to the rerouting entity;
� leg B from the rerouting entity to entity B;
� leg B’ from entity B to entity B’;
� leg C from the rerouting entity to entity C.
The H.450.3 protocol supports each of these four legs.
Entity B is either collocated with entity B’ at the diverting endpoint or is located separately in a gatekeeper acting on behalf of
the diverting endpoint, e.g. for situations where B' is switched off since B' can be a PC.
The rerouting entity can be collocated with entity A or entity B. Alternatively it can be at a separate device such as a gatekeeper
or proxy.
6.1.3 Scenarios for interworking
The architectures for QSIG and H.450.3 are very similar. The only difference is the absence of entity B’ and leg B’ from the
QSIG architecture. This is not a fundamental difference, but merely reflects the fact that entity B’ and leg B’ are outside the
scope of QSIG and therefore no QSIG protocol is required for leg B’. Normally leg B’ would correspond to the PISN access.
This means that the H.450.3 architecture is applicable to the inter-networking situation between an IP network and a PISN,
where one or more of the users involved are served by the IP network and the others are served by the PISN.
In figure 2 interworking between H.450.3 and QSIG could theoretically occur on any of the four legs. However, interworking
on leg B’ is of less practical use (a network is unlikely to invoke diversion on behalf of a diverting user in another network),
and also is not possible because there is no support for leg B’ in QSIG. Therefore in practice the possible points of
interworking occur on legs A, B and C.
For each of the three possible points of interworking, two scenarios arise, depending on which side of the interworking point
the PISN lies. This gives 6 scenarios in total that need to be considered:
� Scenario A1: Entity A (PINX A) in PISN, rerouting entity in IP network;
� Scenario A2: Entity A (endpoint A) in IP network, rerouting entity in PISN;
© ISO/IEC 2001 – All rights reserved
� Scenario B1: Entity B (PINX B) in PISN, rerouting entity in IP network;
� Scenario B2: Entity B (diverting endpoint or its gatekeeper) in IP network, rerouting entity in PISN;
� Scenario C1: Entity C (PINX C) in PISN, rerouting entity in IP network;
� Scenario C2: Entity C (endpoint C) in IP network, rerouting entity in PISN.
It is possible for more than one scenario to apply to the same call. For example, if entity A and the rerouting entity are in a
PISN and entities B and C are in the same IP network or different IP networks, interworking according to scenario B2 will
apply on leg B and interworking according to scenario C2 will apply on leg C.
A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view of the
IP network and an end PINX from the point of view of the PISN.
Multiple scenarios can also occur because of multiple (chained) diversions.
6.1.4 Determination of the location of the rerouting entity when interworking
The particular scenario (or scenarios) that applies depends not only on the location of the users concerned but also on the
location of the rerouting entity. In each of the scenarios it is possible to locate the rerouting entity within the gateway. However,
functionally the rerouting entity is separate from the point of interworking and belongs to user B’s network. When this occurs,
interworking occurs on leg A (scenario A1 or A2).
The possibility of siting the rerouting entity at the gateway arises when the gateway receives a rerouting request (QSIG or
H.450.3 callRerouting invoke APDU) from entity B. Instead of creating a rerouting entity at the gateway, the gateway can
choose to pass the rerouting request on into the other network towards entity A. In this case interworking occurs on leg B
(scenario B1 or B2).
In either case, interworking can also occur on leg C (scenario C1 or C2) if entity C is not in the same type of network as the
rerouting entity.
The gateway’s decision whether to provide the rerouting entity is an implementation matter. This can, but need not, take
account of the address of user C. The behaviour of the rerouting entity, if provided at the gateway, is outside the scope of this
International Standard and is assumed to be in accordance with the requirements of ISO/IEC 13873 (for rerouting requests
received from the PISN) or in accordance with the requirements of H.450.3 (for rerouting requests received from the IP
network).
6.2 Service architecture for activation, deactivation and interrogation
6.2.1 ISO/IEC 13873 service architecture
The QSIG protocol for call diversion activation, deactivation and interrogation is based around three signalling entities or
PINX types:
� entity D – a PINX serving an activating user;
� entity E – a PINX serving a deactivating user;
� entity F – a PINX serving an interrogating user;
� entity G – a PINX serving a diverting user;
� entity H – a PINX serving a diverted-to user.
Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway PINX or the
two in combination. However, from the QSIG point of view the role is performed by the gateway PINX.
This can be represented diagrammatically as shown in figure 3.
© ISO/IEC 2001 – All rights reserved
Entity D
Association D
Association E Association G
Entity E Entity G Entity H
Association F
Entity F
Figure 3 – Call diversion activation / deactivation / interrogation architecture for QSIG
From this it can be seen that there are four associations between entities:
� association D between entity D and entity G;
� association E between entity E and entity G;
� association F between entity F and entity G;
� association G between entity G and entity H.
Associations D, E and F apply to activation, deactivation and interrogation respectively. Association G applies to activation and
allows entity G to check with entity H whether there are any restrictions that prevent activation of diversion.
The QSIG protocol supports each of these four associations.
6.2.2 H.450.3 service architecture
The architecture shown above for QSIG applies also to H.450.3, except that PINXs are replaced by H.323 entities as follows:
� entity D – an activating endpoint;
� entity E – a deactivating endpoint;
� entity F – an interrogating endpoint;
� entity G – a diverting endpoint or gatekeeper;
� entity H – a diverted-to endpoint.
Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway, or the two
in combination. However, from the H.450.3 point of view the role is performed by the gateway.
As for QSIG, there are four associations: D, E, F and G.
The H.450.3 protocol supports each of these four associations.
6.2.3 Scenarios for interworking
Because the architectures for QSIG and H.450.3 are the same, this architecture is applicable to the inter-networking situation
between an IP network and a PISN, where one or more of the users involved are served by the IP network and the others are
served by the PISN.
In figure 3, interworking between H.450.3 and QSIG can occur on any of the four associations.
For each of the four possible points of interworking, two scenarios arise, depending on which side of the interworking point the
PISN lies. This gives 8 scenarios in total that need to be considered:
� Scenario D1: Entity D (PINX D) in PISN, entity G (endpoint G) in IP network;
� Scenario D2: Entity D (endpoint D) in IP network, entity G (PINX G) in PISN;
� Scenario E1: Entity E (PINX E) in PISN, entity G (endpoint G) in IP network;
© ISO/IEC 2001 – All rights reserved
� Scenario E2: Entity E (endpoint E) in IP network, entity G (PINX G) in PISN;
� Scenario F1: Entity F (PINX F) in PISN, entity G (endpoint G) in IP network;
� Scenario F2: Entity F (endpoint F) in IP network, entity G (PINX G) in PISN;
� Scenario G1: Entity G (PINX G) in PISN, entity H (endpoint H) in IP network;
� Scenario G2: Entity G (endpoint G) in IP network, entity H (PINX H) in PISN.
A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view of the
IP network and an end PINX from the point of view of the PISN.
7 Protocol interworking – General requirements
Protocol interworking between H.323 and QSIG for call diversion supplementary services shall be in accordance with ISO/IEC
21409, as modified by the requirements of clause 8.
When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the
mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance with
ISO/IEC 21409, where applicable. Optional elements of one protocol that have no corresponding element in the other protocol
shall be discarded if received.
8 Protocol interworking – Messages and APDUs
In the rules specified below for the different scenarios, the following shall apply:
1. If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a FACILITY
message to be sent at that time, the action to be taken is an implementation matter.
2. If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that message being
transmitted and that message is not to be transmitted (owing to basic call interworking considerations), the action to be
taken is an implementation matter.
3. If the required action is dependent on the call independent signalling connection extending or being able to be extended
into the other network and this cannot be achieved, the action to be taken is an implementation matter.
Annex B shows in diagrammatic form some typical message sequences for some of the scenarios identified in this International
Standard.
8.1 Scenario A1
A gateway that supports scenario A1 shall behave in accordance with the rules of table 1, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting entity, whether this
be located in the gateway or in a separate physical entity in the IP network.
© ISO/IEC 2001 – All rights reserved
Table 1 – Message and APDU handling requirements for scenario A1
Rule Condition Required action
1 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 divertingLegInformation1 invoke APDU in divertingLegInformation1 invoke APDU if the QSIG call
the backward direction, no H.323 CONNECT state permits.
message having been received.
2 Receipt of an H.323 CONNECT message containing If a QSIG CONNECT message is to be transmitted,
an H.323 divertingLegInformation1 invoke APDU. include in the QSIG CONNECT message a QSIG
divertingLegInformation1 invoke APDU.
3 Receipt of an H.323 ALERTING message containing If a QSIG ALERTING message is to be transmitted,
an H.323 divertingLegInformation3 invoke APDU. include in the QSIG ALERTING message a QSIG
divertingLegInformation3 invoke APDU.
4 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 divertingLegInformation3 invoke APDU in divertingLegInformation3 invoke APDU if the QSIG call
the backward direction, no H.323 CONNECT state permits.
message having been received.
5 Receipt of an H.323 CONNECT message containing If a QSIG CONNECT message is to be transmitted,
an H.323 divertingLegInformation3 invoke APDU. include in the QSIG CONNECT message a QSIG
divertingLegInformation3 invoke APDU.
© ISO/IEC 2001 – All rights reserved
8.2 Scenario A2
A gateway that supports scenario A2 shall behave in accordance with the rules of table 2, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, whether this be
located in the gateway or in a separate physical entity in the PISN.
Table 2 – Message and APDU handling requirements for scenario A2
Rule Condition Required action
1 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG divertingLegInformation1 invoke APDU in the H.323 divertingLegInformation1 invoke APDU if the
backward direction, no QSIG CONNECT message H.323 call state permits.
having been received.
2 Receipt of a QSIG CONNECT message containing a If an H.323 CONNECT message is to be transmitted,
QSIG divertingLegInformation1 invoke APDU. include in the H.323 CONNECT message an H.323
divertingLegInformation1 invoke APDU.
3 Receipt of a QSIG ALERTING message containing a If an H.323 ALERTING message is to be transmitted,
QSIG divertingLegInformation3 invoke APDU. include in the H.323 ALERTING message an H.323
divertingLegInformation3 invoke APDU.
4 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG divertingLegInformation3 invoke APDU in the H.323 divertingLegInformation3 invoke APDU if the
backward direction, no QSIG CONNECT message H.323 call state permits.
having been received.
5 Receipt of a QSIG CONNECT message containing a If an H.323 CONNECT message is to be transmitted,
QSIG divertingLegInformation3 invoke APDU. include in the H.323 CONNECT message an H.323
divertingLegInformation3 invoke APDU.
6 Receipt of a QSIG NOTIFY message containing Transmit an H.323 FACILITY message containing an
notification “call is diverting” (NOTE 1). This can be H.323 divertingLegInformation1 invoke APDU if the
accompanied by notification “pss1IeNotification” H.323 call state permits (NOTE 2).
with embedded public ISDN Redirection number
information element.
7 Receipt of a QSIG CONNECT message containing If an H.323 CONNECT message is to be transmitted,
no QSIG divertingLegInformation3 invoke APDU, include in the H.323 CONNECT message an H.323
subsequent to transmitting an H.323 FACILITY divertingLegInformation3 invoke APDU.
message containing an H.323
divertingLegInformation1 invoke APDU in
accordance with rule 6.
NOTE 1 - This can arise as a result of the PISN routing the call on into a public ISDN, where diversion occurs.
NOTE 2 - If no embedded public ISDN Redirection number information element is received, mandatory element nominatedNr
in the H.323 divertingLegInformation1 invoke APDU shall be coded to indicate that no address is available.
© ISO/IEC 2001 – All rights reserved
8.3 Scenario B1
A gateway that supports scenario B1 shall behave in accordance with the rules of table 3, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting entity, whether this
be located in the gateway or in a separate physical entity in the IP network, or the receipt of a QSIG message from entity B.
Table 3 – Message and APDU handling requirements for scenario B1
Rule Condition Required action
1 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG callRerouting invoke APDU in the backward H.323 callRerouting invoke APDU if the H.323 call state
direction, no QSIG CONNECT message having been permits.
received.
2 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 callRerouting return result APDU in callRerouting return result APDU if the QSIG call state
response to an H.323 callRerouting invoke APDU. permits.
3 Receipt of an H.323 RELEASE COMPLETE Transmit a QSIG DISCONNECT message containing a
message containing an H.323 callRerouting return QSIG callRerouting return result APDU if the QSIG call
result APDU in response to an H.323 callRerouting state permits.
invoke APDU.
4 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 callRerouting return error APDU in callRerouting return error APDU if the QSIG call state
response to an H.323 callRerouting invoke APDU. permits.
5 Receipt of an H.323 RELEASE COMPLETE Transmit a QSIG DISCONNECT message containing a
message containing an H.323 callRerouting return QSIG callRerouting return error APDU if the QSIG call
error APDU in response to an H.323 callRerouting state permits.
invoke APDU.
6 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 cfnrDivertedLegFailed invoke APDU in the cfnrDivertedLegFailed invoke APDU if the QSIG call state
forward direction permits.
© ISO/IEC 2001 – All rights reserved
8.4 Scenario B2
A gateway that supports scenario B2 shall behave in accordance with the rules of table 4, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, whether this be
located in the gateway or in a separate physical entity in the PISN, or receipt of an H.323 message from entity B.
Table 4 – Message and APDU handling requirements for scenario B2
Rule Condition Required action
1 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 callRerouting invoke APDU in the callRerouting invoke APDU if the QSIG call state permits.
backward direction, no H.323 CONNECT message
having been received.
2 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG callRerouting return result APDU in response H.323 callRerouting return result APDU if the H.323 call
to a QSIG callRerouting invoke APDU. state permits.
3 Receipt of a QSIG DISCONNECT message Transmit an H.323 RELEASE COMPLETE message
containing a QSIG callRerouting return result APDU containing an H.323 callRerouting return result APDU if
in response to a QSIG callRerouting invoke APDU. the H.323 call state permits.
4 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG callRerouting return error APDU in response to H.323 callRerouting return error APDU if the H.323 call
a QSIG callRerouting invoke APDU. state permits.
4 Receipt of a QSIG DISCONNECT message Transmit an H.323 RELEASE COMPLETE message
containing a QSIG callRerouting return error APDU containing an H.323 callRerouting return error APDU if
in response to a QSIG callRerouting invoke APDU. the H.323 call state permits.
6 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG cfnrDivertedLegFailed invoke APDU in the H.323 cfnrDivertedLegFailed invoke APDU if the H.323
forward direction. call state permits.
8.5 Scenario C1
A gateway that supports scenario C1 shall behave in accordance with the rules of table 5, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting entity, whether this
be located in the gateway or in a separate physical entity in the IP network, or receipt of a QSIG message from entity C.
Table 5 – Message and APDU handling requirements for scenario C1
Rule Condition Required action
1 Receipt of an H.323 SETUP message containing an If a QSIG SETUP message is to be transmitted, include in
H.323 divertingLegInformation2 invoke APDU. the QSIG SETUP message a QSIG
divertingLegInformation2 invoke APDU.
2 Receipt of a QSIG ALERTING message containing a If an H.323 ALERTING message is to be transmitted,
QSIG divertingLegInformation3 invoke APDU. include in the H.323 ALERTING message an H.323
divertingLegInformation3 invoke APDU.
3 Receipt of a QSIG FACILITY message containing a Transmit an H.323 FACILITY message containing an
QSIG divertingLegInformation3 invoke APDU in the H.323 divertingLegInformation3 invoke APDU if the
backward direction, no QSIG CONNECT message H.323 call state permits.
having been received.
4 Receipt of a QSIG CONNECT message containing a If an H.323 CONNECT message is to be transmitted,
QSIG divertingLegInformation3 invoke APDU. include in the H.323 CONNECT message an H.323
divertingLegInformation3 invoke APDU.
© ISO/IEC 2001 – All rights reserved
8.6 Scenario C2
A gateway that supports scenario C2 shall behave in accordance with the rules of table 6, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, whether this be
located in the gateway or in a separate physical entity in the PISN, or the receipt of an H.323 message from entity C.
Table 6 – Message and APDU handling requirements for scenario C2
Rule Condition Required action
1 Receipt of a QSIG SETUP message containing a If an H.323 SETUP message is to be transmitted, include
QSIG divertingLegInformation2 invoke APDU. in the H.323 SETUP message an H.323
divertingLegInformation2 invoke APDU.
2 Receipt of an H.323 ALERTING message containing If a QSIG ALERTING message is to be transmitted,
an H.323 divertingLegInformation3 invoke APDU. include in the QSIG ALERTING message a QSIG
divertingLegInformation3 invoke APDU.
3 Receipt of an H.323 FACILITY message containing Transmit a QSIG FACILITY message containing a QSIG
an H.323 divertingLegInformation3 invoke APDU in divertingLegInformation3 invoke APDU if the QSIG call
the backward direction, no QSIG CONNECT state permits.
message having been received.
4 Receipt of an H.323 CONNECT message containing If a QSIG CONNECT message is to be transmitted,
an H.323 divertingLegInformation3 invoke APDU. include in the QSIG CONNECT message a QSIG
divertingLegInformation3 invoke APDU.
8.7 Scenario D1
A gateway that supports scenario D1 shall behave in accordance with the rules of table 7, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity D or an H.323 message
from entity G.
Table 7 – Message and APDU handling requirements for scenario D1
Rule Condition Required action
1 Receipt of a QSIG activateDiversionQ invoke APDU If the call independent signalling connection extends or is
carried on a call independent signalling connection. able to be extended into the IP network, transmit an H.323
activateDiversionQ invoke APDU.
2 Receipt of an H.323 activateDiversionQ return result Transmit a QSIG activateDiversionQ return result APDU.
APDU carried on a call independent signalling
connection in response to an H.323
activateDiversionQ invoke APDU.
3 Receipt of an H.323 activateDiversionQ return error Transmit a QSIG activateDiversionQ return error APDU.
APDU carried on a call independent signalling
connection in response to an H.323
activateDiversionQ invoke APDU.
© ISO/IEC 2001 – All rights reserved
8.8 Scenario D2
A gateway that supports scenario D2 shall behave in accordance with the rules of table 8, by carrying out the required action
when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity D or a QSIG message
from entity G.
Table 8 – Message and APDU handling requirements for scenario D2
Rule Condition Required action
1 Receipt of an H.323 activateDiversionQ invoke If the call independent signalling connection extends or is
APDU carried on a call independent signalling able to be extended into the PISN, transmit a QSIG
connection. activateDiversionQ invoke APDU.
2 Receipt of a QSIG activateDive
...