ISO/IEC 23290:2002

Information technology — Telecommunications and information exchange between systems — Private Integrated Services Network — Mapping functions for the tunnelling of QSIG through H.323 networks

ISO/IEC 23290:2002 specifies functions for using an H.323 packet network in order to interconnect two Private Integrated services Network eXchanges (PINXs) forming part of a Private Integrated Services Network (PISN). Interconnection is achieved by carrying the inter-PINX signalling protocol over the H.323 call signalling channel, making use of the protocol tunnelling facilities of H.323, and inter-PINX user information (e.g., voice) over logical channels established through H.323. Each logical channel usually represents a unidirectional media stream conveyed by means of the Real-time Transport Protocol (RTP). The inter-PINX signalling protocol is assumed to be QSIG, as specified in ISO/IEC 11572, ISO/IEC 11582 and other International Standards. ISO/IEC 23290:2002 provides for an on-demand type of interconnection, where a separate H.323 call is established at the start of each PISN call and cleared down at the end of that call. A semi-permanent scenario where a single H.323 call with an indefinite lifetime carries QSIG on behalf of many PISN calls is described as an additional option. In the scenarios covered in ISO/IEC 23290:2002, the PINXs participating in a call are not necessarily aware of the H.323 network providing the interconnection, and the features available are those of the QSIG network. This is different from a scenario where true interworking between QSIG and H.323 (i.e. QSIG-H.323-QSIG) is used to connect two PISNs or two parts of the same PISN. In this latter case all networks participate in a call on equal terms, and features are limited to those available in all networks and supported by the gateways. This latter scenario is outside the scope of ISO/IEC 23290:2002. ISO/IEC 23290:2002 is applicable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX signalling protocol.

Technologies de l'information — Télécommunications et échange d'information entre systèmes — Réseau privé avec intégration de services — Fonctions d'application pour l'emploi de l'action tunnel de QSIG à travers les réseaux H.323

General Information

• Status: Withdrawn
• Publication Date: 09-Dec-2002
• Withdrawal Date: 09-Dec-2002
• 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: 9599 - Withdrawal of International Standard
• Completion Date: 07-Oct-2004

Relations

• Revised: ISO/IEC 23290:2004 - Information technology — Telecommunications and information exchange between systems — Private Integrated Services Network (PISN) — Mapping functions for the tunnelling of QSIG through H.323 networks
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 23290
First edition
2002-12-15


Information technology —
Telecommunications and information
exchange between systems — Private
Integrated Services Network — Mapping
functions for the tunnelling of QSIG
through H.323 networks
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Réseau privé avec intégration de
services — Fonctions d'application pour l'emploi de l'action tunnel de
QSIG à travers les réseaux H.323




Reference number
ISO/IEC 23290:2002(E)
©
ISO/IEC 2002

---------------------- Page: 1 ----------------------
ISO/IEC 23290:2002(E)
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 2002
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.org
Published in Switzerland

ii © ISO/IEC 2002 — All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 23290:2002(E)

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 Call 2
4.2.2 Channel 2
4.2.3 Inter-PINX Connection (IPC) 2
4.2.4 Inter-PINX Link (IPL) 2
4.2.5 PINX roles 2
5 List of acronyms 3
6 Introduction 3
6.1 Reference configuration 3
6.2 Specific scenarios 3
6.3 Relationship with H.323 gateways 4
7 Capabilities at the Q reference point 5
8 Capabilities at the C reference point 5
9 Mapping functions 5
9.1 General requirements 5
9.2 Mapping of the D -channel 6
Q
9.3 Mapping of the U -channel(s) 6
Q
9.3.1 On-demand scenario 6
9.3.2 Semi-permanent scenario 6
10 IPC control procedures 6
10.1 Protocol identification 6
10.2 Registration with gatekeeper 6
10.3 Systems without gatekeeper 6
10.4 H.323 call establishment 6
10.4.1 Call admission 6
10.4.2 Outgoing call establishment 7
10.4.3 Incoming call establishment 7
10.5 Transfer of inter-PINX signalling information 8
10.6 H.323 call clearing 8
11 Scenario specific procedures 8
11.1 On-demand scenario 8
11.2 Semi-permanent scenario 8
© ISO/IEC 2002 — All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 23290:2002(E)
Annexes
A - Implementation Conformance Statement (ICS) Proforma 10
B - Examples of message sequences 16
iv © ISO/IEC 2002 — All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 23290:2002(E)
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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. 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 document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 23290 was prepared by ECMA (as ECMA-333) 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.

© ISO/IEC 2002 — All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 23290:2002(E)


Introduction
This International Standard is one of a series of standards defining mapping functions in exchanges of Private Integrated
Services Networks required for the utilization of intervening network scenarios. The series uses the ISDN concepts as
developed by ITU-T (formerly CCITT) and is also within the framework of standards for open systems interconnection as
defined by ISO.
This International Standard specifies mapping functions for the type of scenarios where two or more PINXs are interconnected
via on-demand connections using an H.323 packet network as the IVN.
The 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.



vi © ISO/IEC 2002 — All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 23290:2002(E)


Information technology - Telecommunications and information exchange between
systems - Private Integrated Services Network - Mapping functions for the tunnelling
of QSIG through H.323 networks


1 Scope
This International Standard specifies functions for using an H.323 packet network in order to interconnect two Private

Integrated services Network eXchanges (PINXs) forming part of a Private Integrated Services Network (PISN).
Interconnection is achieved by carrying the inter-PINX signalling protocol over the H.323 call signalling channel, making use

of the protocol tunnelling facilities of H.323, and inter-PINX user information (e.g., voice) over logical channels established
through H.323. Each logical channel usually represents a unidirectional media stream conveyed by means of the Real-time

Transport Protocol (RTP). The inter-PINX signalling protocol is assumed to be QSIG, as specified in ISO/IEC 11572,
ISO/IEC 11582 and other International Standards.

The International Standard provides for an on-demand type of interconnection, where a separate H.323 call is established at
the start of each PISN call and cleared down at the end of that call. A semi-permanent scenario where a single H.323 call with
an indefinite lifetime carries QSIG on behalf of many PISN calls is described as an additional option.

In the scenarios covered in this International Standard, the PINXs participating in a call are not necessarily aware of the H.323
network providing the interconnection, and the features available are those of the QSIG network. This is different from a
scenario where true interworking between QSIG and H.323 (i.e. QSIG–H.323–QSIG) is used to connect two PISNs or two
parts of the same PISN. In this latter case all networks participate in a call on equal terms, and features are limited to those
available in all networks and supported by the gateways. This latter scenario is outside the scope of this International Standard.
This International Standard is applicable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX
signalling protocol.
2 Conformance
In order to conform to this International Standard, a PINX shall satisfy the requirements identified in the Implementation
Conformance Statement (ICS) proforma in annex A.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the
the edition cited applies. For undated references, the latest edition of the referenced document (including any
amendments) applies.
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:2002, 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
ITU-T Rec. H.225.0, Call signalling protocols and media stream packetization for packet-based multimedia communication
systems (2000 or later)
ITU-T Rec. H.245, Control protocol for multimedia communication (2000 or later)
ITU-T Rec. H.323, Packet-based multimedia communications systems (2000 or later)
ITU-T H.323 annex M.1, Tunnelling of signalling protocol (QSIG) in H.323
© ISO/IEC 2002 — All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC 23290:2002(E)
4 Definitions
4.1 External definitions
For the purpose of this International Standard the following definitions apply:
– Call independent signalling connection (ISO/IEC 11582)
– C reference point (ISO/IEC 11579-1)
– Gatekeeper (ITU-T Rec. H.323)
– Gateway, Trunking Gateway (ITU-T Rec. H.323)
– Intervening network (ISO/IEC 11579-1)
– Logical channel (ITU-T Rec. H.323)
– Preceding PINX (ISO/IEC 11582)
– Private Integrated Services Network (ISO/IEC 11579-1)
– Private Integrated services Network eXchange (ISO/IEC 11579-1)
– Q reference point (ISO/IEC 11579-1)
– Subsequent PINX (ISO/IEC 11582)
4.2 Other definitions
4.2.1 Call
4.2.1.1 H.323 call
A call as defined in ITU-T Rec. H.323, i.e. a point-to-point communication between two H.323 endpoints. Here specifically a
call in the H.323 network between two gateways.
4.2.1.2 PISN call
A call as defined in ISO/IEC 11572 and ISO/IEC 11582.
4.2.1.3 Call segment
A portion of a (PISN) call between two entities taking part in that call. The smallest segment is between adjacent entities, e.g.
between two PINXs across one Inter-PINX link.
4.2.2 Channel
A means of bi-directional transmission of user or signalling information between two points.
4.2.2.1 D -Channel
Q
A channel used to convey call control information between the Q reference points of two peer PINXs.
4.2.2.2 U -Channel
Q
A channel used to convey user information between the Q reference points of two peer PINXs.
4.2.3 Inter-PINX Connection (IPC)
A connection provided by an IVN between two C reference points used to transport inter-PINX information from the PISN
control plane and/or the PISN user plane.
4.2.4 Inter-PINX Link (IPL)
A link between the Q reference points of two PINXs, comprising the totality of signalling transfer and user information
transfer means.
4.2.5 PINX roles
4.2.5.1 Initiating PINX
The PINX that initiates an IPL establishment request.
4.2.5.2 Accepting PINX
The PINX that accepts an IPL establishment request.
2 © ISO/IEC 2002 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 23290:2002(E)
5 List of acronyms
GK Gatekeeper
ICS Implementation Conformance Statement
IP Internet Protocol
IPC Inter-PINX Connection
IPL Inter-PINX Link
IVN Intervening Network
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
QSIG Signalling system for the Q reference point
RAS Registration, Admission and Status
RTP / RTCP Real Time Protocol / Real Time Control Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
6 Introduction
6.1 Reference configuration
ISO/IEC 11579-1 defines a reference configuration for a PINX. Logically the switching and call control functions of a PINX
communicate over an instance of the Q reference point with a peer PINX. This communication is known as an Inter-PINX
Link (IPL) and comprises a signalling channel, known as a D -channel, and one or more user information channels, each
Q
known as a U -channel; see figure 1. One or more IPLs can be established between the same pair of PINXs.
Q

PINX PINX
Q reference
Q reference
point
point
Switching Switching
and Call
and Call
D -channel
Q
Control
Control
functions
functions
B -channel
Q
B -channel
Q
Inter-PINX link

Figure 1 – IPL concept

There are many ways of implementing an IPL. In general, the IPL uses services of another network, known as an Intervening
Network (IVN). A PINX interfaces to the IVN at the C reference point. The IVN provides connections, known as Inter-PINX
Connections (IPCs) between the C reference points of the peer PINXs. Mapping functions within each PINX map the
D -channel and the U -channels at the Q reference point onto one or more IPCs at the C reference point.
Q Q
6.2 Specific scenarios
This International Standard specifies mapping functions for use when the IVN is an H.323 packet network that is used to
provide the following types of IPC:
– a signalling connection for carrying signalling information; and
– a pair of UDP streams, one stream in each direction, for carrying user information over RTP.
NOTE - Other means of transporting user information can be used, e.g. T.38 fax without RTP, an ATM virtual channel, or a bi-directional
TCP connection instead of UDP streams. See H.323 for more details. These cases are outside the scope of this International Standard.
© ISO/IEC 2002 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC 23290:2002(E)
A single IPL requires a single signalling connection, for support of the D -channel, and one pair of UDP streams per U -
Q Q
channel.
The main inter-PINX connection scenario described in this International Standard is an on-demand connection scenario. This
means that an IPL is established whenever a PISN call segment is to be set up between two PINXs and released when the
PISN call ends. An optional semi-permanent scenario is also described, where multiple concurrent or consecutive PISN calls
can use the same IPL.
In both scenarios the signalling connection is established by means of an H.323 call, using the protocol tunnelling facilities
provided by H.225.0 and H.323 annex M.1. The H.225.0 call signalling connection in conjunction with the tunnelling of the
QSIG signalling is used to provide the D -channel. The pair of UDP streams used to provide an inter-PINX user connection
Q
(U -channel) is established as H.323 logical channel(s). An IPL may have multiple U -channels.
Q Q
Figure 2 illustrates these concepts.
PINX IVN (IP network using PINX
C reference
Q reference C reference Q reference
H.323)
point
point point point
Switching Mapping H.225.0 call Mapping Switching
functions signalling channel functions
and Call and Call
D -channel D -channel
Q Q
Control Control
functions functions
BQ-channel Pair of UDP streams BQ-channel
B -channel Pair of UDP streams B -channel
Q Q
Inter-PINX connections
Inter-PINX link

Figure 2 – H.323 as intervening network (IVN)

IPCs in support of these scenarios can be established and released at any time under the control of either PINX. In case of IPC
failure, the H.323 network may reject a call establishment request or release an already established call.
A single PINX can terminate a multiplicity of IPLs leading to the same and/or different peer PINXs. Each IPL comprises a
single H.323 call.
6.3 Relationship with H.323 gateways
Each PINX connected to another PINX via an H.323 network represents a trunking gateway in H.323 terms. The H.323
gateway functionality is part of the mapping functions of the PINX. No specific implementation is implied by this
International Standard. The gateway function may be fully integrated or decomposed into several components (e.g. media
gateway controller and media gateway), as explained in H.323.
The tasks of the gateway include the handling of user data or media, e.g. packetization / de-packetization, and signalling
interworking. The latter mainly enables QSIG to be tunnelled over an H.323 call, as specified in more detail in subsequent
clauses.
Figure 3 shows an example of the relationship between a PISN call and the underlying H.323 call which provides the inter-
PINX link for one segment of the PISN call.

PINX
PINX PINX PINX
Switching
Switching
and Call
and Call
PISN call
PISN call PISN call
Control
Control
segment
segment segment
functions H.323
H.323 functions
gateway
gateway
H.323 call

Figure 3 – Example of the relationship between PISN call and H.323 call
4 © ISO/IEC 2002 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 23290:2002(E)
7 Capabilities at the Q reference point
For each instance of the Q reference point:
– one signalling channel (D ) for carrying the inter-PINX Layer 3 signalling protocol, and
Q
– zero, one or more user channels (U )
Q
are provided.
NOTE - If the D -channel is used only to support QSIG call-independent signalling connections, no U -channels are required.
Q Q
For a U -channel the following bearer capability shall be provided:
Q
– transfer mode: circuit mode;
– information transfer rate: 64 kbit/s;
– information transfer capability: speech or 3,1 kHz audio;
– user information layer 1 protocol: G.711 A or µ law.
Other bearer capabilities may also be provided (e.g. 64 kbit/s unrestricted digital information, or transfer rates other than 64
kbit/s).
For a D -channel the following bearer capability shall be provided:
Q
– transfer mode: packet mode;
– information transfer rate: implementation-dependent;
– information transfer capability: unrestricted digital information.
The functions to map D - and U -channels to an inter-PINX connection (IPC) at the C reference point are described in
Q Q
clause 9.
8 Capabilities at the C reference point
A PINX shall support a packet network interface suitable for multimedia communication according to ITU-T recommendation
H.323. The protocol stack shall conform to ITU-T recommendations H.323, H.225.0 and H.245 and shall support protocol
tunnelling according to H.323 annex M.1.
NOTE - This means that the following protocols are used:
• H.225.0 RAS, if a gatekeeper is present, over UDP/IP;
• H.225.0 call control signalling, with embedded QSIG tunnel, over TCP/IP;
• H.245 within fastStart elements and/or embedded in H.225.0 call control or explicit over TCP/IP;
• RTP/RTCP over UDP/IP.
The protocol tunnelling capability of the H.323 call signalling channel serves as the IPC for the D -channel. A pair of H.323
Q
logical channels for media transport serves as the IPC for a U -channel.
Q
For the on-demand scenario a new H.323 call is established every time a PISN call occurs and cleared when the PISN call
finishes.
For the optional semi-permanent scenario the same H.323 call serves multiple concurrent or consecutive PISN calls. In this
case logical channels are dynamically opened and closed according to the number of U -channels required at the time.
Q
9 Mapping functions
9.1 General requirements
For each IPL terminating at a PINX, the PINX shall provide mapping functions for:
– mapping of the D -channel onto a packet mode IPC as provided by the H.323 call signalling channel with embedded
Q
QSIG tunnel;
– mapping of the U -channel(s) onto the corresponding IPC(s) with an information transfer rate of 64 kbit/s as provided by
Q
H.323 logical channels (pair(s) of UDP streams).
© ISO/IEC 2002 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO/IEC 23290:2002(E)
9.2 Mapping of the D -channel
Q
The signalling carriage mechanism (see 6.3 of ISO/IEC 11572) is provided by the protocol tunnelling facilities of H.323.
There is no layer 2 frame structure. The PINX shall embed a complete QSIG message in the appropriate data structure of the
transporting H.225.0 message without segmentation.
The services and primitives listed in ISO/IEC 11572 clause 6.3 can be mapped to the sending and receipt of appropriate
H.225.0 messages. Details are left to the implementation.
9.3 Mapping of the U -channel(s)
Q
The PINX shall map each U -channel to a pair of unidirectional H.323 logical channels with suitable transport capabilities.
Q
The mapping function is responsible for proper packetization, de-packetization, transcoding etc. of media data.
9.3.1 On-demand scenario
The PINX shall establish a single pair of unidirectional logical channels using RTP over UDP , and assign session identifier
"1" to it, which shall also be the number of the U -channel mapped to this pair.
Q
NOTE - Other alternatives, e.g. a bi-directional logical channel or multiple U -channels for nx64 kbit/s, are outside the scope of this
Q
International Standard.
9.3.2 Semi-permanent scenario
For each U -channel the PINX shall establish a pair of unidirectional logical channels using RTP over UDP. The session
Q
identifier "n" assigned to this pair by the master side (in the range 1.255) shall be the number of the U -channel mapped to
Q
this pair. See H.323 and H.245 for more information.
NOTE 1 - The number of established U -channels can be either static or dynamically adapted to the actual call load, assuming one channel
Q
per call.
NOTE 2 - Other alternatives, e.g. use of bi-directional logical channels or multiple U -channels per call in case of nx64 kbit/s, are outside
Q
the scope of this International Standard.
10 IPC control procedures
10.1 Protocol identification
This clause makes reference to an object identifier identifying the QSIG protocol, here called QSIG object identifier. The
value of this object identifier is
{iso (1)  identified-organization (3)  icd-ecma (0012) private-isdn-signalling-domain (9)}.
10.2 Registration with gatekeeper
If a gatekeeper exists in the H.323 domain the PINX shall register as a gateway with its gatekeeper in accordance with ITU-T
Rec. H.323 and H.225.0 before sending or receiving any calls. The PINX can detect the gatekeeper to register with by using
one of the methods described in Recs. H.323 and H.225.0.
The gatekeeper will then
• assist in identifying the peer PINX from a call's destination number, and
• provide other PINXs with the IP address of this PINX.
The PINX shall set the terminalType.supportedTunnelledProtocols.id.tunnelledProtocolObjectID to the QSIG object
identifier in the Register Request message (RRQ) to inform the gatekeeper that it is able to handle QSIG signalling.
10.3 Systems without gatekeeper
In scenarios without a gatekeeper each PINX has to know the IP address(es) of its potential peer(s), e.g. through static
configuration.
10.4 H.323 call establishment
10.4.1 Call admission
If the initiating PINX has registered with a gatekeeper and has not received pre-granted admission for outgoing calls in the
RCF message from the gatekeeper, the PINX shall send an ARQ message to the gatekeeper prior to call establishment.
NOTE 1 - ARQ may still be sent in the case of pre-granted admission, too.
6 © ISO/IEC 2002 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC 23290:2002(E)
NOTE 2 - Pre-granted admissions only make sense if a suitable call signalling transport address is known a priori, e.g. the signalling
transport address of the GK if all calls are routed via the gatekeeper.
The ARQ message shall contain:
• desiredTunnelledProtocol.id.tunnelledProtocolObjectID set to the QSIG object identifier;
• destinationInfo with an alias address of the intended destination (i.e. an alias address sufficient to identify the peer
PINX). The format is implementation dependent, e.g. a number in the form of partyNumber.privateNumber or
partyNumber.e164Number.
On receipt of an ACF message in response, the initiating PINX shall attempt to establish the H.323 call according to 10.4.2.
The ACF message may contain the QSIG object identifier in field destinationType.supportedTunnelledProtocols,
indicating that the destination is a gateway that can act as accepting PINX.
On receipt of an H.225.0 Setup message, if the accepting PINX has registered with a gatekeeper and has not received pre-
granted admission for incoming calls in the RCF message from the gatekeeper, the PINX shall send an ARQ message to the
gatekeeper. On receipt of an ACF message in response, the accepting PINX shall accept the H.323 call request subject to
conditions described in 10.4.3 below.
If admission fails the accepting PINX shall reject the H.323 call.
10.4.2 Outgoing call establishment
The initiating PINX shall send an H.225.0 Setup message to the call signalling address received in the ACF message or known
a priori. The Setup message shall contain:
• the sourceInfo.supportedTunnelledProtocols.id.tunnelledProtocolObjectID field set to the QSIG object identifier;
• optionally fastStart elements as required for the immediate provision of logical channels;
• called party number information, e.g. copied from the ACF or the QSIG SETUP message, according to H.323 rules (i.e.
Called party number information element or element destinationAddress);
• optionally the element tunnelledSignallingMessage with the QSIG object identifier in tunnelledProtocolID, the
complete QSIG SETUP message in messageContent, and tunnellingRequired either present (if H.323 interworking is
not possible) or absent (if H.323 interworking is possible).
NOTE 1 - If fastStart is not included H.245 procedures can be used later on to open the required logical channels.
NOTE 2 - If supported, the initiating PINX can use H.323 interworking as a fallback if QSIG tunnelling is not possible. This is outside the
scope of this International Standard.
Further call establishment shall follow H.323, H.225.0 and H.245. If successful, the logical channel(s) opened for the H.323
call shall be mapped to U -channel(s) as specified in 9.3, and the PINX shall be prepared to send and receive tunnelled QSIG
Q
messages according to 10.5.
10.4.3 Incoming call establishment
A gateway receiving an H.225.0 SETUP that was sent according to 10.4.2 shall accept the H.323 call if
• the gateway is able to handle the call (no resource constraints, admission granted), and
• tunnelling of QSIG is supported, i.e. the gateway can act as accepting PINX.
Call processing shall then follow H.323, H.225.0 and H.245. In addition an embedded QSIG SETUP message shall be passed
to QSIG protocol control. The gateway shall also include the QSIG object identifier in
destinationInfo.supportedTunnelledProtocols.id.tunnelledProtocolObjectID in all H.225.0 messages sent back to the
originating side up to and including Connect. Logical channels shall be opened by means of fast connect if required by the
presence of fastStart elements in the received Setup message.
NOTE - If fastStart is not present H.245 procedures can be used later on to open the required logical channels.
The PINX shall be prepared to send and receive tunnelled QSIG messages according to 10.5.
If the gateway does not support QSIG tunnelling and an embedded QSIG SETUP message was present with the
tunnellingRequired flag set the H.323 call shall be released according to H.323.
© ISO/IEC 2002 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO/IEC 23290:2002(E)
10.5 Transfer of inter-PINX signalling information
QSIG messages shall be passed between the two peer PINXs according to H.323 annex M.1, embedded as complete messages
in tunnelledSignallingMessage.messageContent of H.225.0 call control or H.225.0 Facility messages, together with the
QSIG object identifier in tunnelledProtocolID. The sending PINX shall embed a single QSIG message in the proper H.225.0
message and transmit the H.225.0 message immediately. Only in the semi-permanent scenario a single H.225.0 Facility
message may convey several QSIG messages – belonging to different PISN calls – at the same time.
Segmentation shall not be used.
NOTE 1 - This International Standard assumes transparent transport of QSIG messages by gatekeepers in case of gatekeeper routed H.323
calls.
NOTE 2 - Since the H.323 tunnelling mechanism allows only a single protocol to be tunnelled per H.323 call no other protocol can be
tunnelled besides QSIG if this International Standard applies.
10.6 H.323 call clearing
The H.323 call shall be released from either side according to H.323. Clearing of the H.323 call terminates the IPCs provided
by that call. Therefore clearing shall only be initiated if no PISN call using these IPCs is in th
...