Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-333 — Private Integrated Services Network (PISN) - Mapping functions for the tunnelling of QSIG through H.323 networks (December 2003)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational functions integrated mapping network networks pisn

ecma, standard, ecma international, specification, ecma-333, ecma 333, 333, private, integrated, services, network, pisn, mapping, functions, for, the, tunnelling, qsig, through, h.323, networks

ECMA-333 2nd Edition / December 2003

Private Integrated Services Network (PISN) Mapping Functions for the Tunnelling of QSIG through H.323 Networks

Standard ECMA-333 2nd Edition / December 2003

Private Integrated Services Network (PISN) Mapping Functions for the Tunnelling of QSIG through H.323 Networks

Ecma International IW

ECMA-333.doc

Rue du Rhône 114

06.09.2004 14:38

CH-1204 Geneva

T/F: +41 22 849 6000/01

www.ecma-international.org

Brief history

This Standard is one of a series of Ecma 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 particular 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 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 JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. The second edition is fully compatible with the first edition. It specifies one part of the procedures of the optional semi-permanent scenario in more detail

The December 2003 General Assembly adopted this, 2 nd edition, of ECMA-333.

Table of contents 1

Scope

Conformance

References

Definitions

4.1

External definitions

4.2 Other definitions 4.2.1 Call 4.2.2 Channel 4.2.3 Inter-PINX Connection (IPC) 4.2.4 Inter-PINX Link (IPL) 4.2.5 PINX roles

2 2 2 2 2 2

L i s t o f a c r o n ym s

Introduction

6.1

Reference configuration

6.2

Specific scenarios

6.3

Relationship with H.323 gateways

Capabilities at the Q reference point

Capabilities at the C reference point

Mapping functions

9.1

General requirements

9.2

Mapping of the DQ-channel

9.3 Mapping of the UQ-channel(s) 9.3.1 On-demand scenario 9.3.2 Semi-permanent scenario

6 6 6

IPC control procedures

10.1

Protocol identification

10.2

Registration with gatekeeper

10.3

Systems without gatekeeper

10.4 H.323 call establishment 10.4.1 Call admission 10.4.2 Outgoing call establishment

7 7 8 -i -

10.4.3

Incoming call establishment

10.5

Transfer of inter-PINX signalling information

10.6

H.323 call clearing

Scenario specific procedures

11.1

On-demand scenario

11.2

Semi-permanent scenario

A n n e x A - I m p l e m e n t a t i o n C o n f o rm a n c e S t a t e m e n t ( I C S ) P r o f o r m a

Annex B - Examples of message sequences

- ii -

Scope This 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 Realtime Transport Protocol (RTP). The inter-PINX signalling protocol is assumed to be QSIG, as specified in ECMA-143, ECMA-165 and other standards. The 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 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 Standard. This Standard is applicable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX signalling protocol.

Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Implementation Conformance Statement (ICS) proforma in Annex A.

References The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to Ecma Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the Ecma reference. ECMA-133

Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)

ECMA-143

Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)

ECMA-165

Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)

ITU-T Rec. H.225.0

Call signalling protocols and media stream packetization for packet based multimedia communications 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 protocols (QSIG) in H.323 -1-

Definitions

4.1

External definitions For the purpose of this Standard the following definitions apply:

4.2

–

Call independent signalling connection

(ECMA-165)

–

C reference point

(ECMA-133)

–

Gatekeeper

(ITU-T Rec. H.323)

–

Gateway, Trunking Gateway

(ITU-T Rec. H.323)

–

Intervening network

(ECMA-133)

–

Logical channel

(ITU-T Rec. H.323)

–

Preceding PINX

(ECMA-165)

–

Private Integrated Services Network

(ECMA-133)

–

Private Integrated services Network eXchange

(ECMA-133)

–

Q reference point

(ECMA-133)

–

Subsequent PINX

(ECMA-165)

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 ECMA-143 and ECMA-165.

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

DQ-Channel A channel used to convey call control information between the Q reference points of two peer PINXs.

4.2.2.2

UQ-Channel 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.

-2-

4.2.5.2

6 6.1

Accepting PINX The PINX that accepts an IPL establishment request.

List of acronyms GK

Gatekeeper

ICS

Implementation Conformance Statement

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

Introduction Reference configuration ECMA-133 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 Q-channel, and one or more user information channels, each known as a U Q-channel; see Figure 1. One or more IPLs can be established between the same pair of PINXs. PINX Switching and Call Control functions

Q reference point

PINX

Q reference point DQ-channel BQ-channel

Switching and Call Control functions

BQ-channel

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 Q-channel and the U Q-channels at the Q reference point onto one or more IPCs at the C reference point.

-3-

6.2

Specific scenarios This 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 Standard.

A single IPL requires a single signalling connection, for support of the D Q-channel, and one pair of UDP streams per U Q-channel. The main inter-PINX connection scenario described in this 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 DQchannel. The pair of UDP streams used to provide an inter-PINX user connection (U Q-channel) is established as H.323 logical channel(s). An IPL may have multiple U Q-channels. Figure 2 illustrates these concepts. PINX Switching and Call Control functions

Q reference point DQ-channel

C reference point Mapping functions

IVN (IP network using H.323)

C reference point

H..225.0 call signalling channel

Mapping functions

Q reference point DQ-channel

BQ-channel

Pair of UDP streams

BQ-channel

Pair of UDP streams

BQ-channel

PINX Switching and Call Control functions

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 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 / depacketization, and signalling interworking. The latter mainly enables QSIG to be tunnelled over an H.323 call, as specified in more detail in subsequent clauses. -4-

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 PISN call segment

Switching and Call Control functions

PINX

H.323 gateway

PISN call segment

H.323 gateway

Switching and Call Control functions

PINX PISN call segment

H..323 call

Figure 3 - Example of the relationship between PISN call and H.323 call

Capabilities at the Q reference point For each instance of the Q reference point: –

one signalling channel (D Q) for carrying the inter-PINX Layer 3 signalling protocol, and

–

zero, one or more user channels (U Q)

are provided. NOTE If the D Q -channel is used only to support QSIG call-independent signalling connections, no UQ -channels are required.

For a U Q-channel the following bearer capability shall be provided: –

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 Q-channel the following bearer capability shall be provided: –

transfer mode: packet mode;

–

information transfer rate: implementation-dependent;

–

information transfer capability: unrestricted digital information.

The functions to map D Q- and U Q-channels to an inter-PINX connection (IPC) at the C reference point are described in Clause 9.

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 Qchannel. A pair of H.323 logical channels for media transport serves as the IPC for a U Q-channel. -5-

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 Q-channels required at the time.

9 9.1

Mapping functions General requirements For each IPL terminating at a PINX, the PINX shall provide mapping functions for:

9.2

–

mapping of the D Q-channel onto a packet mode IPC as provided by the H.323 call signalling channel with embedded QSIG tunnel;

–

mapping of the U Q-channel(s) onto the corresponding IPC(s) with an information transfer rate of 64 kbit/s as provided by H.323 logical channels (pair(s) of UDP streams).

Mapping of the D Q -channel The signalling carriage mechanism (see 6.3 of ECMA-143) 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 ECMA-143 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 Q -channel(s) The PINX shall map each U Q-channel to a pair of unidirectional H.323 logical channels with suitable transport capabilities. The mapping function is responsible for proper packetization, depacketization, 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 UQ-channel mapped to this pair. NOTE Other alternatives, e.g. a bi-directional logical channel or multiple U Q -channels for nx64 kbit/s, are outside the scope of this Standard.

9.3.2

Semi-permanent scenario For each U Q-channel the PINX shall establish a pair of unidirectional logical channels using RTP over UDP. The session identifier "n" assigned to this pair by the master side (in the range 1...255) shall be the number of the U Q-channel mapped to this pair. See H.323 and H.245 for more information. NOTE 1 The number of established U Q -channels can be either static or dynamically adapted to the actual call load, assuming one channel per call. NOTE 2 Other alternatives, e.g. use of bi-directional logical channels or multiple U Q -channels per call in case of nx64 kbit/s, are outside the scope of this Standard.

-6-

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 10.4.1

H.323 call establishment 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. 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 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.

set

the

QSIG

object

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. -7-

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 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 Q-channel(s) as specified in 9.3, and the PINX shall be prepared to send and receive tunnelled QSIG 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.

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. -8-

NOTE 1 This 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 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 the active state. After clearing of the H.323 call, the PINXs should not unregister from their gatekeepers as long as they are ready to establish new calls.

11 11.1

Scenario specific procedures On-demand scenario When required by the presence of a PISN call request, the preceding PINX shall establish an H.323 call towards the subsequent PINX as described in 10.4, embedding the QSIG SETUP message in the H.323 Setup message. Further QSIG messages shall be exchanged according to 10.5. The Channel identification information element in the embedded QSIG SETUP message shall include the U Q-channel number as specified in 9.3.1; the call references in the H.225.0 Setup message and in the embedded QSIG SETUP message are independent of each other. If call admission procedures apply the preceding PINX shall include the received called party number in the destinationInfo field of the ARQ message. The preceding PINX shall reject the PISN call if admission fails or the H.323 call cannot be established for any other reason. The H.323 call shall remain active during the lifetime of the PISN call. At the end of the PISN call the H.323 call shall be cleared by either side (usually by the side sending the final QSIG call clearing message). If the H.323 call fails and recovery cannot be achieved the PINX detecting the failure shall clear the PISN call locally. H.323 recovery procedures are an implementation matter outside the scope of this Standard. The procedures above shall also apply in the case of a connection oriented bearer independent signalling connection. The corresponding H.323 call shall be established as a call independent signalling connection (see H.323 Annex M.1). Logical channels are not required. A U Q-channel shall be established as required by using the logical channel procedures of ITU-T Rec. H.245. Usually a U Q-channel requires the opening of two unidirectional logical channels, one in each direction, although the use of a single bi-directional channel is possible under certain circumstances (see ITU-T Rec. H.323 for details). The fast connect procedure of H.323 shall be the first choice for opening logical channels. H.245 tunnelling or a separate H.245 channel are only needed if fast connect is not possible or if more extensive H.245 signalling is required. All open logical channels shall be closed when the PISN call is released. If a logical channel cannot be opened or is closed unexpectedly the PINX detecting the problem shall clear the PISN call. The parameters used when opening the logical channels are outside the scope of this Standard but shall be chosen according to the required bearer capability of the U Q-channel. If the PISN call is cleared as a result of QSIG restart procedures the H.323 call shall also be released.

11.2

Semi-permanent scenario An H.323 call may be established between two PINXs independent of a PISN call, using the procedures of Clause 10. This H.323 call can be used for multiple PISN calls between the two -9-

PINXs, both simultaneously and consecutively. The maximum number of concurrent PISN calls is an implementation issue. The Channel identification information element in an embedded QSIG SETUP message shall include the number of the U Q-channel to be used as specified in 9.3.2; the call references in the H.225.0 message and in the embedded QSIG message are independent of each other. The call references of the QSIG messages are used to distinguish between different PISN calls. NOTE 1 The QSIG call references are unique within the context of the underlying H.323 call. Multiple H.323 calls over the same interface will have different callIdentifier values.

A PISN call can be established from either side by embedding the QSIG SETUP and all subsequent messages in H.225.0 Facility messages. All QSIG messages will be transported in H.225.0 Facility messages, i.e. no QSIG SETUP message will be embedded in the H.225.0 Setup message. All U Q-channels shall be established by means of H.245 logical channel procedures. U Q-channels shall be added or dropped dynamically as needed, on a per-PISN-call basis, using H.245 tunnelling within H.225.0 messages. Other methods of logical channel establishment are outside the scope of this Standard. NOTE 2 Each PINX has to open one unidirectional logical channel (the one it intends to transmit on) of the pair comprising a U Q -channel.

For call establishment from the master side PINX to the slave side PINX (master and slave roles having been determined by the usual H.245 procedure when the IPL was established as an H.323 call), the master side PINX shall tunnel an H.245 OpenLogicalChannel message with session identifier "n" for its transmit logical channel in the same Facility message that carries the QSIG SETUP message with channel number "n". The slave side PINX shall respond by tunnelling two H.245 messages – OpenLogicalChannelAck for the receive logical channel and OpenLogicalChannel with session identifier "0" for its own transmit logical channel – in the Facility message that carries the first QSIG response message (e.g. CALL PROCEEDING). The master side PINX shall finalise logical channel establishment by returning a Facility message containing a tunnelled OpenLogicalChannelAck message with session identifier "n" for the receive logical channel. This case is illustrated in Figure 4.

Master

Slave Facility (Setup(Ch#=n), OLC(SessID=n))

Facility (CallProc(Ch#=n), OLCAck, OLC(SessID=0))

Facility (OLCAck(SessID=n))

Figure 4 – UQ Channel mapping for a call in the direction master to slave

For call establishment from the slave side PINX to the master side PINX, the slave side PINX shall tunnel an H.245 OpenLogicalChannel message with session identifier "0" for its transmit logical channel in the same Facility message that carries the QSIG SETUP message with channel number "n". The master side PINX shall respond by tunnelling two H.245 messages – OpenLogicalChannelAck with session identifier "n" for the receive logical channel and OpenLogicalChannel also with session identifier "n" for its own transmit logical channel – in the - 10 -

Facility message that carries the first QSIG response message (e.g. CALL PROCEEDING). The slave side PINX shall finalise logical channel establishment by returning a Facility message containing a tunnelled OpenLogicalChannelAck message for the receive logical channel. This case is illustrated in Figure 5.

Master

Slave Facility (Setup(Ch#=n), OLC(SessID=0))

Facility (CallProc(Ch#=n), OLCAck(SessID=n), OLC(SessID=n)) Facility (OLCAck)

Figure 5 – UQ Channel mapping for a call in the direction slave to master

If the channel number "n" proposed by the slave side PINX is not acceptable to the master side PINX (e.g. in case of crossing SETUP messages indicating the same channel number) 10.3 of ECMA-143 shall apply, with the master side PINX acting as "A" side and the slave side PINX as "B" side. The slave side PINX should always indicate "preferred" in the Channel identification information element, allowing the master side PINX to select a different value "n" in its response to the slave side PINX if necessary. The H.323 call can be maintained as long as desired even if no PISN calls are active. If the H.323 call fails and recovery cannot be achieved this terminates the IPL. Any PISN calls active at the time of failure shall be cleared. H.323 recovery procedures are an implementation matter outside the scope of this Standard. If a logical channel required for a PISN call cannot be opened or is closed unexpectedly the PINX detecting the problem shall release the PISN call. The H.323 call shall not be cleared as a result of QSIG restart procedures, but resources that are occupied by the PISN call(s) affected by the restart shall be released.

- 11 -

- 12 -

Annex A (normative)

Implementation Conformance Statement (ICS) Proforma

A.1 Introduction A.1.1 Purpose of an ICS proforma The supplier of an implementation which is claimed to conform to this Standard shall complete the following Implementation Conformance Statement (ICS) proforma. A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities and options have been implemented for a given specification. The ICS can have a number of uses, including use: –

by the implementor, as a check list for implementations to reduce the risk of unintended nonconformance, e.g. through oversight;

–

by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's ICS proforma;

–

by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible ICS;

–

by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

A.2 Instructions for completing the ICS proforma A.2.1 General structure of the ICS proforma The ICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this item is dependent on the support marked for the referenced item). The “Status” column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: I

informational, irrelevant or out-of-scope - this capability is outside the normative scope of the standard to which this ICS proforma applies and is not subject to conformance testing in this context;

mandatory (the capability is required for conformance to the standard);

N/A

not applicable - in the given context, it is impossible to use the capability; no answer in the support column is required,

- 13 -

optional (the capability is not required for conformance to the standard, but if the capability is implemented it is required to conform to the specification in this Standard);

O.<n>

qualified optional - in this case, <n> is an integer that identifies a unique group of related optional items; if no additional qualification is indicated, the support of at least one of the optional items is required for conformance to this Standard; otherwise, the qualification and logic of the selection among the optional items is defined below the table explicitly;

excluded or prohibited - there is a requirement not to use this capability in a given context.

Answers to the questionnaire items are to be provided in the “Support” column, by simply marking an answer to indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. Where a support column box is left blank, no answer is required. If a "prerequisite line" (see A.2.4 below) is used after a subclause heading or table title, and its predicate is false, no answer is required for the whole subclause or table, respectively.

A.2.2 Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception Information.

A.2.3 Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.

A.2.4 Further indications of the ICS proforma tables In addition to the columns of a table, the following information may be indicated: "Prerequisite line" A prerequisite line after a subclause heading or table title indicates that the whole subclause or the whole table is not required to be completed if the predicate is false. "Qualification" At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the description of the status "qualified optional" in subclause in A.2.1. "Comments" This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided separately (without using this box).

- 14 -

A.3 Identification of the implementation A.3.1 Implementation Identification Supplier (note 1) Contact point for queries about the ICS (note 1) Implementation Name(s) and Version(s) (note 1, note 2) Other information necessary for full identification - e.g., name(s) and version(s) for machines and/or operating systems; System name(s) NOTE 1 Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. NOTE 2 The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model).

- 15 -

A.3.2 Specification for which this ICS applies Title

Private Integrated Services Network (PISN) Mapping Functions for the tunnelling of QSIG through H.323 networks

Version

1.0

Corrigenda Implemented (if applicable) Addenda Implemented (if applicable) Amendments Implemented (if applicable) Have any exception items been required ?

No[ ] Yes[ ] (The answer Yes means that the implementation does not conform to this Standard) (Note)

Date of Statement Note: In this case, an explanation shall be given of the nature of non-conformance either below or on a separate sheet of paper. Nature of non-conformance (if applicable):

- 16 -

A.4 General requirements Item

Question: Does the implementation ...

Condition for status

act as initiating PINX

O.1

[ ]Yes [ ]No

act as accepting PINX

O.1

[ ]Yes [ ]No

support the on-demand scenario

[ ]Yes

support the semi-permanent scenario

[ ]Yes [ ]No

A4.1

Maximum number of concurrent PISN calls

Value: ............

support a packet network interface with H.323 protocol stack with QSIG tunnelling

[ ]Yes

support general mapping requirements

9.1

[ ]Yes

support mapping of the D Q-channel

9.2

[ ]Yes

support mapping of the U Q-channel in the on-demand scenario

9.3.1

[ ]Yes

support mapping of U Q-channels in the semi-permanent scenario

9.3.2

[ ]Yes

Comments

- 17 -

Status

Reference

Support

A.5 Procedures Item

Question: Does the implementation ...

Condition for status

Status

Reference

Support

support IPC control functions protocol identification

10.1

[ ]Yes

support IPC control functions with registration with gatekeeper

O.1

10.2

[ ]Yes [ ]No

support IPC control functions without gatekeeper

O.1

10.3

[ ]Yes [ ]No

support IPL establishment with GK – call admission

10.4.1

[ ]Yes

support IPL establishment – outgoing call

10.4.2

[ ]Yes

support IPL establishment – incoming call

10.4.3

[ ]Yes

support fast connect for U Q-channel establishment

O.2

10.4.2 10.4.3

[ ]Yes [ ]No

support separate H.245 procedures for U Q-channel establishment

O.2

10.4.2 10.4.3

[ ]Yes [ ]No

support transfer of inter-PINX signalling

10.5

[ ]Yes

B10

support clearing of H.323.call

10.6

[ ]Yes

B11

support on-demand scenario specific procedures

11.1

[ ]Yes

B12

support semi-permanent scenario specific procedures

11.2

[ ]Yes

Comments

- 18 -

A.6 Coding Item

Question: Does the implementation ...

Condition for status

Status

Reference

Support

include QSIG object identifier in RRQ

10.2

[ ]Yes

include QSIG object identifier in ARQ

10.4.1

[ ]Yes

include QSIG-specific H.225.0-UUIE element values in Setup or Facility and receive them in all messages

10.4.2, 10.5, 11.1

[ ]Yes

receive QSIG-specific H.225.0-UUIE element values in Setup or Facility and include them in backwards messages or Facility

10.4.3, 10.5, 11.1

[ ]Yes

include and receive all QSIG messages in H.225.0 Facility messages

B12

11.2

[ ]Yes

Comments

- 19 -

- 20 -

Annex B (informative)

Examples of message sequences

List of Abbreviations used in the message sequences: DL

Data Link

Protocol Control

mapping function / Gateway

call reference

channel number

cpn

called party number

The following convention is used for message names: QSIG and H.225.0/RAS message names are all upper case, H.225.0 call control message names are lower case with the first letter in upper case.

B.1 Successful call setup B.1.1 Enbloc sending Figure B.1 shows an example message sequence for a successful call between two PINXs where the called party number in the original QSIG SETUP message is complete. RAS procedures are optional. The call signalling follows the direct call model, i.e. the signalling is not routed via a gatekeeper.

- 21 -

ARQ DL-DATA-REQ (SETUP (CR1, ch1))

ACF Setup (CR2, fastStart, SETUP (CR1, ch1))

GK ARQ Call Proceeding (CR2)

ACF

Facility (CR2, CALL PROC (CR1, ch1))

DL-DATA-IND (CALL PROC (CR1, ch1))

Alerting (CR2, fastStart, ALERTING (CR1))

DL-DATA-IND

DL-DATA-IND (SETUP (CR1, ch1)) DL-DATA-REQ (CALL PROC (CR1, ch1)) DL-DATA-REQ (ALERTING (CR1))

(ALERTING (CR1)) DL-DATA-IND (CONNECT (CR1))

Connect (CR2, fastStart, CONNECT (CR1))

DL-DATA-REQ (CONNECT (CR1))

Media established

Figure B.1 - Enbloc setup, successful call, direct call model, with fast connect

- 22 -

B.1.2 Overlap sending Figure B.2 shows an example message sequence for a successful call between two PINXs where the called party number in the original QSIG SETUP message is not complete. RAS procedures are optional. The call signalling follows the gatekeeper routed model. Note that due to the large number of options in H.323 there are many more scenarios possible.

ARQ DL-DATA-REQ (SETUP (CR1, ch1))

ACF (Setup (CR2,

(Setup (CR3,

(Setup (CR4,

...fastStart, SETUP (CR1, ch1)) Call Proc (CR2)

ARQ ACF

Call Proc (CR3)

Call Proc (CR4) DL-DATA-IND (SETUP (CR1, ch1)) DL-DATA-IND

Facility (CR2,

Facility (CR4,

... SETUP ACK (CR1, ch1))

(SETUP ACK (CR1, ch1)) DL-DATA-REQ (INFO (CR1, cpn))

Facility (CR3,

Facility (CR2,

Facility (CR3,

Facility (CR4,

...INFO (CR1, cpn)) DL-DATA-IND

Facility (CR2,

(ALERTING (CR1)) DL-DATA-IND (CONNECT (CR1))

Facility (CR4,

Alerting (CR2,

Alerting (CR3,

DL-DATA-IND (INFO (CR1, cpn)) DL-DATA-REQ (CALL PROC (CR1))

... CALL PROC (CR1))

(CALL PROC (CR1)) DL-DATA-IND

Facility (CR3,

DL-DATA-REQ (SETUP ACK (CR1,ch1))

Alerting (CR4,

... fastStart, ALERTING (CR1))

DL-DATA-REQ (ALERTING (CR1))

Connect (CR4, DL-DATA-REQ (CONNECT (CR1)) ... fastStart, CONNECT (CR1))

Connect (CR2,

Connect (CR3,

Media established

Figure B.2 - Overlap sending, successful call, GK routed call model, with fast connect

- 23 -

B.2 Normal call clearing Figure B.3 shows an example of call clearing from the active state. Clearing is initiated from the called side. For clearing from the calling side the flow is mirrored.

Active call

DL-DATA-IND

DL-DATA-REQ

Facility (CR2, DISCONNECT (CR1))

(DISCONNECT (CR1))

(DISCONNECT (CR1)) DL-DATA-REQ (RELEASE (CR1))

Facility (CR2, RELEASE (CR1))

DL-DATA-IND

Rel Com (CR2, REL COM (CR1))

(REL COM (CR1)) DRQ

DL-DATA-IND (RELEASE (CR1))

DL-DATA-REQ (REL COM (CR1))

DRQ DCF

DCF

Figure B.3 - Normal call clearing by called side

- 24 -

ECMA-333 — Private Integrated Services Network (PISN) - Mapping functions for the tunnelling of QSIG through H.323 networks (December 2003)

Related documents