Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-332 — Corporate telecommunication networks - Signalling interworking between QSIG and H.323 - Basic services (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

basic corporate ecma ecmainternational networks qsig signalling telecommunication

ecma, standard, ecma international, specification, ecma-332, ecma 332, 332, corporate, telecommunication, networks, signalling, interworking, between, qsig, and, h.323, basic, services

S tandard ECMA-332

December 2001

Standardizing Information

and

Communication

Systems

Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 Basic Services

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]

S tandard ECMA-332

December 2001

Standardizing

Information

and

Communication

Systems

Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 Basic Services

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW

Ecma-332.doc

07-01-02 16,41

Brief History

This Standard is one of a series of ECMA 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. It has been produced under ETSI work item DTS/ECMA-00216. This particular Standard defines the signalling protocol interworking for basic 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 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. This ECMA Standard is contributed to ISO/IEC JTC1 under the terms of the fast-track procedure, for adoption as an ISO/IEC International Standard.

This ECMA Standard has been adopted by the General Assembly of December 2001.

- i -

Table of contents 1

Scope

Conformance

References

Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Gateway 4.2.2 I P n e tw o r k 4.2.3 Rin g - b a c k to n e

2 2 2 2 2 2

Acronyms

Architecture

General requirements

Message mapping requirements 4 8 . 1 Me s s a g e v a lid a tio n a n d h a n d lin g o f p r o to c o l e r r o r s 4 8 . 2 Ca ll e s ta b lis h me n t f r o m Q S I G to H . 3 2 3 5 8.2.1 Ca ll e s ta b lis h me n t f r o m Q S I G to H . 3 2 3 u s in g a d mis s io n p r o c e d u r e s 5 8.2.2 Ca ll e s ta b lis h me n t f r o m Q S I G to H . 3 2 3 w ith o u t a d mis s io n p r o c e d u r e s 9 8 . 3 Ca ll e s ta b lis h me n t f r o m H . 3 2 3 to Q S I G 12 8.3.1 R e c e i p t o f a n H . 2 2 5 . 0 S E T U P me s s a g e 12 8.3.2 A d d itio n a l me s s a g e s r e la tin g to o v e r la p s e n d in g 13 8.3.3 R e c e i p t o f a Q S I G C A L L P R O C E E D I N G me s s a g e 14 8.3.4 R e c e i p t o f a Q S I G A L E R T I N G me s s a g e 14 8.3.5 R e c e i p t o f a Q S I G C O N N E C T me s s a g e 14 8 . 4 P RO G RE S S me s s a g e s a n d P r o g r e s s in d ic a to r in f o r ma tio n e le me n ts 14 8.4.1 R e c e i p t o f a P r o g r e s s i n d i c a t o r i n f o r ma t i o n e l e me n t i n a Q S I G me s s a g e 14 8.4.2 R e c e i p t o f a P r o g r e s s i n d i c a t o r i n f o r ma t i o n e l e me n t i n a n H . 2 2 5 . 0 me s s a g e 14 8.4.3 T r a n s mis s io n o f P r o g r e s s in d ic a to r in f o r ma tio n e le me n t in s u p p o r t o f g a te w a yp r o v id e d r in g - b a c k to n e . 14 8.5 Call clearing 14 8.5.1 Call clearing initiated by QSIG 14 8.5.2 Call clearing initiated by H.323 14

9 9.1 9.2 9.3 9.4

Numbering requirements S u p p o r te d n u mb e r in g p la n s a n d typ e s o f n u mb e r Ma p p in g n u mb e r s f r o m Q S I G to H . 3 2 3 Ma p p in g n u mb e r s f r o m H . 3 2 3 to Q S I G H a n d lin g o f p r e s e n ta tio n a n d s c r e e n in g in d ic a to r s

15 15 15 16 17

- ii -

9.5

H a n d lin g o f s u b a d d r e s s e s

Security requirements

11 Requirements for support of basic services 11.1 Ca lls f r o m Q S I G to H . 3 2 3 11.2 Ca lls f r o m H . 3 2 3 to Q S I G

17 18 19

Media channel establishment

13 Requirements for the support of group 3 fax in accordance with H.323 annex D 13.1 S ta r t o f f a x tr a n s mis s io n 13.2 E n d o f f a x tr a n s mis s io n

20 20 20

Requirements for the support of DTMF

Requirements for the provision of ring-back tone

Annex A - Implementation Conformance Statement (ICS) proforma

A n n e x B - Ex a m p le m e s s a g e s e q u e n c e s

Scope This Standard specifies signalling interworking between “QSIG” and “H.323” in support of basic services within a corporate telecommunication network (CN). “QSIG” is a signalling protocol that operates at the Q reference point between Private Integrated services Network eXchange (PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133. A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other ECMA Standards, in particular ECMA-143 (call control in support of basic 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). This Standard specifies signalling interworking for basic services that provide a bidirectional transfer capability for speech, DTMF, facsimile and modem media between a PISN employing QSIG and a private IP network employing H.323. This Standard specifies requirements for establishing user information (audio) connections between the PISN and the IP network, but protocols for transmitting audio in the IP network and for signalling in order to establish and close down audio transmission in the IP network are outside the scope of this Standard. Supplementary services are outside the scope of this Standard. Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of a private IP network, or a call originating at a user of a private IP network to terminate at a user of a PISN. Interworking between a PISN employing QSIG and a public IP network employing H.323 is outside the scope of this Standard. However, the functionality specified in this Standard is in principle applicable to such a scenario when deployed in conjunction with other relevant functionality (e.g., number translation, security functions, etc.). Although two such gateways can operate as peers on either side of an IP network (whereby the IP network provides interconnection between two PISNs), special support for this situation (e.g., tunnelling of QSIG information through the IP network) is outside the scope of this Standard. Although two such gateways can operate as peers on either side of a PISN (whereby the PISN provides interconnection between two IP networks), special support for this situation (e.g., tunnelling of H.323 information through the PISN) is outside the scope of this Standard. This Standard is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and a private IP network employing H.323.

Conformance In order to conform to this Standard, a gateway 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)

- 2 -

ECMA-143

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

ECMA-155

Private Integrated Services Networks - Addressing (International Standard ISO/IEC 11571)

ECMA-253

Private Integrated Services Network (PISN) - Mapping Functions for the Employment of 64 kbit/s Circuit Mode Connections with 16 kbit/s Sub-Multiplexing (International Standard ISO/IEC 17310)

ECMA-289

Private Integrated Services Network (PISN) - Mapping Functions for the Employment of 64 kbit/s Circuit Mode Connections with 8 kbit/s Sub-Multiplexing (International Standard ISO/IEC 17311)

ECMA-307

Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 - Generic Functional Protocol for the Support of Supplementary Services (International Standard ISO/IEC 21409)

ITU-T Rec. H.225.0 version 4

Call signalling protocols and media stream packetization for packet-based multimedia communication systems (11/2000)

ITU-T Rec. H.235 version 2

Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals (11/2000)

ITU-T Rec. H.245 version 7

Control protocol for multimedia communication (11/2000)

ITU-T Rec. H.323 version 4

Packet-based multimedia communications systems (11/2000)

Definitions For the purposes of this Standard, the following definitions apply.

4.1

External definitions This Standard uses the following terms defined in other documents: – Call

(ECMA-307)

– Corporate telecommunication network (CN)

(ECMA-307)

– Endpoint

(ITU-T Rec. H.323)

– Gatekeeper

(ITU-T Rec. H.323)

– Private Integrated Services Network (PISN)

(ECMA-307)

– Private Integrated services Network eXchange (PINX)

(ECMA-133)

Additionally the definitions in ECMA-143 and ITU-T Recommendation H.323 apply as appropriate.

4.2

Other definitions

4.2.1

G a t e wa y A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG.

4.2.2

I P n e t wo r k A network, unless otherwise stated a CN, offering connectionless packet-mode services based on the Internet Protocol (IP) as the network layer protocol.

4.2.3

R in g - b a c k t o n e An in-band tone or announcement played to the calling user during the alerting of the called user.

- 3 -

Acronyms CN

Corporate telecommunication network

ICS

Implementation Conformance Statement

Internet Protocol

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

Architecture This Standard specifies signalling protocol interworking aspects of a gateway between a PISN employing QSIG signalling and an IP network employing H.323 signalling. The gateway appears as a PINX to other PINXs in the PISN. The gateway appears as an H.323 endpoint to other H.323 entities in the IP network, these being: •

other endpoints (terminals, gateways or multipoint control units) that originate calls via the gateway to the PISN and terminate calls via the gateway from the PISN;

•

gatekeepers, including the gatekeeper with which the gateway registers and other gatekeepers involved in call routing.

This environment is illustrated in figure 1.

Gatekeeper s

IP network

PISN

Gateway

Endpoint

Inter-PINX link

PINX

Figure 1 - Environment In addition to the signalling interworking functionality specified in this Standard, it is assumed that the gateway also includes the following functionality: •

one or more physical interfaces on the PISN side supporting one or more inter-PINX links, each link providing one or more constant bit rate channels for media information and a reliable layer 2 connection for transporting QSIG signalling messages; and

•

one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2 protocols, IP as the network layer protocol and UDP and TCP as transport layer protocols, these being used for the transport of media information and H.323 signalling protocols;

•

a means of transferring media information in each direction between the PISN and the IP network, including, as a minimum, packetization of media information sent to the IP network and de-packetization of media information received from the IP network.

NOTE The gateway can be decomposed as described in 6.3.1 of H.323. In this case, the signalling interworking aspects of the gateway, as specified in this Standard, can be expected to reside in the Media Gateway Controller (MGC). The protocol model relevant to signalling interworking functionality of a gateway is shown in figure 2.

- 4 -

Interworking function H.225.0 H.225.0 RAS call control IP network

H.245

QSIG layer 3 PISN

UDP/TCP IP IP network lower layers

PISN lower layers

F ig u r e 2 – P r o t o c o l m o d e l The relevant signalling protocols on the IP network side of the gateway are: •

H.225.0 Registration, Admission and Status (RAS);

•

H.225.0 call control, for the purpose of establishing and clearing down sessions between endpoints; and

•

H.245, for the purpose of supervising resources during a session.

The interworking function therefore provides interworking between QSIG on the PISN side and H.225.0 RAS, H.225.0 call control and H.245 on the IP network side.

General requirements In order to conform to this Standard, a gateway shall support QSIG in accordance with ECMA-143 and shall support H.323 in accordance with H.323 version 4 or later (including H.225.0 version 4 or later and H.245 version 7 or later). The gateway shall be able to interoperate with other H.323 entities in accordance with the provisions of H.323 version 4. The gateway shall support calls from QSIG to an H.323 endpoint and calls from an H.323 endpoint to QSIG. The gateway shall be able to discover and register with a gatekeeper. The means of doing this is outside the scope of this Standard, but should be in accordance with H.323 RAS procedures. The procedures specified in this Standard for call establishment apply after successful registration. The gateway may also be able to operate without registering with a gatekeeper. In this case the means by which the gateway maps QSIG numbers to IP addresses for routing calls from QSIG to an H.323 endpoint is outside the scope of this Standard. For operation with a gatekeeper, the gateway shall be able to employ admission and disengage procedures. The gateway may support pre-granted admission procedures. For operation with a gatekeeper, the gateway shall be able to support both direct call signalling and gatekeeper-routed call signalling. Unless pre-granted admission procedures apply, choice of call signalling method shall be in accordance with instructions from the gatekeeper at the time of admission.

8 8.1

Message mapping requirements Message validation and handling of protocol errors The gateway shall validate received QSIG messages in accordance with the requirements of ECMA-143 and shall act in accordance with ECMA-143 on detection of a QSIG protocol error. The gateway shall validate received H.225.0 messages in accordance with the requirements of ITU-T recommendation H.323 and H.225.0 and shall act in accordance with H.323 and H.225.0 on detection of an H.225.0 protocol error. Requirements of this clause for acting on a received QSIG or H.225.0 message apply only to a received message that has been successfully validated. NOTE These rules mean that an error detected in a received message will not be propagated to the other side of

- 5 -

the gateway. However, there can be an indirect impact on the other side of the gateway, e.g., the initiation of call clearing procedures. The gateway shall handle the QSIG RESTART, RESTART ACKNOWLEDGE, STATUS and STATUS ENQUIRY messages and the QSIG Restart indicator and Call state information elements in accordance with ECMA-143 and shall not propagate these items to the H.323 side of the gateway. NOTE There can, however, be an indirect impact on the H.323 side of the gateway, e.g., the initiation of call clearing procedures. The gateway shall handle the QSIG Channel identification information element in accordance with ECMA-143 and shall not propagate this information element to the H.323 side of the gateway. The gateway shall handle locally any QSIG information elements from codesets other than codeset 0 and shall not propagate these information elements to the H.323 side of the gateway. The QSIG Facility and Notification indicator information elements are outside the scope of ECMA-143 and are therefore outside the scope of this present Standard. The gateway shall handle the H.225.0 STATUS and STATUS INQUIRY messages and the H.225.0 Call state information element in accordance with H.323 and H.225.0 and shall not propagate these items to the QSIG side of the gateway. NOTE There can, however, be an indirect impact on the QSIG side of the gateway, e.g., the initiation of call clearing procedures. The gateway shall handle locally any H.225.0 messages and information elements that do not have QSIG equivalents specified in ECMA-143 (e.g., USER INFORMATION message, Display information element) and shall not propagate these items to the QSIG side of the gateway. Interworking requirements for other messages and information elements are specified in the remainder of this Standard.

8.2

Call establishment from QSIG to H.323 The gateway shall support call establishment using admission procedures as specified in 8.2.1. The gateway may also support call establishment without admission procedures as specified in 8.2.2 for use in the following circumstances: −

if the gateway has not registered with a gatekeeper; or

−

if the gateway has registered with a gatekeeper and pre-granted admission applies for H.323 calls established by the gateway.

8.2.1

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g a d m is s io n p r o c e d u r e s The gateway shall support call establishment using en bloc sending as specified in 8.2.1.1. The gateway shall support call establishment using QSIG overlap sending either: −

by digit collection and the use of H.323 en bloc sending, as specified in 8.2.1.2; and/or

−

by using H.323 overlap sending, as specified in 8.2.1.3.

Examples of message sequences are shown in B.2 in annex B. 8.2.1.1

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g a d m is s io n p r o c e d u r e s a n d e n b lo c sending The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending complete information element or the gateway receives a QSIG SETUP message and is able to determine that the number in the Called party number information element is complete. NOTE The means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry.

- 6 -

8.2.1.1.1

8.2.1.1.2

8.2.1.1.3

Receipt of H.225.0 ARJ message If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ARJ message, the gateway shall initiate QSIG call clearing procedures. The gateway shall derive the QSIG cause number used from the rejectReason value in the H.225.0 ARJ message as specified in table 1. For rejectReason values not in table 1, the choice of appropriate QSIG cause number is an implementation matter (e.g., 31 "normal unspecified" or 41 "temporary failure"). Table 1 – Mapping of rejectReason values to cause numbers

H.225.0 rejectReason value in ARJ

QSIG cause number

calledPartyNotRegistered

20 "subscriber absent"

requestDenied

58 "bearer capability not presently available"

resourceUnavailable

47 "resource unavailable, unspecified"

qosControlNotSupported

49 "Quality of Service not available"

incompleteAddress

28 “invalid number format (address incomplete)”

exceedsCallCapacity

17 "user busy"

8.2.1.1.4

Receipt of an H.225.0 CALL PROCEEDING message If the gateway receives an H.225.0 CALL PROCEEDING message, no action need be taken.

8.2.1.1.5

Receipt of an H.225.0 ALERTING message If the gateway receives an H.225.0 ALERTING message it shall send a QSIG ALERTING message.

8.2.1.1.6

Receipt of an H.225.0 CONNECT message If the gateway receives an H.225.0 CONNECT message it shall send a QSIG CONNECT message.

8.2.1.2

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g a d m is s io n p r o c e d u r e s a n d o v e r la p sending in QSIG only The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete information element, is able to determine that the number in the Called party

- 7 -

number information element is incomplete and is able, as further digits are received, to determine when the number is complete. NOTE The means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry. 8.2.1.2.1

Receipt of QSIG SETUP message On receipt of a QSIG SETUP message containing no Sending complete information element, if the gateway determines that the number in the Called party number information element is incomplete it shall transmit a QSIG SETUP ACKNOWLEDGE message and await receipt of further number digits.

8.2.1.2.2

8.2.1.2.3

Tr a n s m is s io n o f H . 2 2 5 . 0 A R Q m e s s a g e When the gateway determines that the number received is complete, it shall transmit an H.225.0 ARQ message to the gatekeeper with the contents of the Called party number information element from the QSIG SETUP message and appended number digits from QSIG INFORMATION messages in the destinationInfo element of the ARQ using choice partyNumber. The gateway shall also transmit a QSIG CALL PROCEEDING message.

8.2.1.2.4

Receipt of H.225.0 ACF message The requirements of 8.2.1.1.2 apply.

8.2.1.2.5

Receipt of H.225.0 ARJ message The requirements of 8.2.1.1.3apply.

8.2.1.2.6

Receipt of an H.225.0 CALL PROCEEDING message The requirements of 8.2.1.1.4 apply.

8.2.1.2.7

Receipt of an H.225.0 ALERTING message The requirements of 8.2.1.1.5 apply.

8.2.1.2.8

Receipt of an H.225.0 CONNECT message The requirements of 8.2.1.1.6 apply.

8.2.1.3

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g a d m is s io n p r o c e d u r e s a n d o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3 The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete information element, is unable to determine whether the number in the Called party number information element is complete and is unable, as further digits are received, to determine when the number is complete.

8.2.1.3.1

Receipt of QSIG SETUP message On receipt of a QSIG SETUP message containing no Sending complete information element, if the gateway is unable to determine whether the number in the Called party number information element is complete, the gateway shall transmit an H.225.0 ARQ message to the gatekeeper in accordance with 8.2.1.3.2. The gateway shall also transmit a QSIG SETUP ACKNOWLEDGE message.

8.2.1.3.2

Tr a n s m is s io n o f H . 2 2 5 . 0 A R Q m e s s a g e When transmitting an H.225.0 ARQ message to the gatekeeper, the gateway shall place the contents of the Called party number information element from the QSIG SETUP message and appended

- 8 -

number digits from any QSIG INFORMATION messages in the destinationInfo element of the ARQ message using choice partyNumber. NOTE Appended number digits from QSIG INFORMATION messages apply only if this is not the first time an ARQ is sent (see 8.2.1.3.5 and 8.2.1.3.6). 8.2.1.3.3

R e c e i p t o f Q S I G I N F O R M A T I O N m es s a g e w h i l e a w a i t i n g r e s p o n s e t o H . 2 2 5 . 0 ARQ message On receipt of a QSIG INFORMATION message while awaiting a response to an H.225.0 ARQ message, the gateway shall save the number digits from the Called party number information element. If the QSIG INFORMATION message contains a Sending complete information element, the gateway shall transmit a QSIG CALL PROCEEDING message.

8.2.1.3.4

Receipt of H.225.0 ACF message If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ACF message, the gateway shall transmit an H.225.0 SETUP message to the transport address contained in the destCallSignallingAddress element of the ACF message. For the Called party number information element and/or the destinationAddress element in the H.225.0 SETUP (see 9.2), the gateway shall use the contents of the destinationInfo element, if present in the ACF message, or otherwise the contents of the destinationInfo element in the most recent ARQ message. In either case the gateway shall append any number digits saved from QSIG INFORMATION messages received since the H.225.0 ARQ message was transmitted. If a QSIG CALL PROCEEDING message has been sent, the gateway shall include a Sending complete information element in the H.225.0 SETUP message and omit element canOverlapSend. If a QSIG CALL PROCEEDING message has not been sent the gateway shall include element canOverlapSend with value TRUE and omit the Sending complete information element.

8.2.1.3.5

Receipt of H.225.0 ARJ message If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ARJ message with value incompleteAddress in the rejectReason element, behaviour depends on whether further called party number digits have been received in QSIG INFORMATION messages since the H.225.0 ARQ message was sent and whether a QSIG CALL PROCEEDING message has been sent. If further digits have been received, the gateway shall transmit another H.225.0 ARQ message to the gatekeeper in accordance with 8.2.1.3.2. If no further digits have been received and no QSIG CALL PROCEEDING message has been sent, the gateway shall retain the call awaiting further called party number digits. Otherwise the gateway shall initiate QSIG call clearing procedures using cause number 28 “invalid number format (address incomplete)” in the QSIG Cause information element. If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ARJ message with a value other than incompleteAddress in the rejectReason element, the gateway shall initiate QSIG call clearing procedures. The QSIG cause number used shall be derived from the rejectReason value in the H.225.0 ARJ message as specified in table 1 in 8.2.1.1.3.

8.2.1.3.6

Receipt of QSIG INFORMATION message following receipt of H.225.0 ARJ message with rejectReason incompleteAddress On receipt of a QSIG INFORMATION message following receipt of an H.225.0 ARJ message with rejectReason incompleteAddress, the gateway shall transmit another H.225.0 ARQ message to the gatekeeper in accordance with 8.2.1.3.2. If the QSIG INFORMATION message contains a Sending complete information element, the gateway shall transmit a QSIG CALL PROCEEDING message.

8.2.1.3.7

R e c e i p t o f Q S I G I N F O R M A T I O N m es s a g e f o l l o w i n g t r a n s m i s s i o n o f H . 2 2 5 . 0 SETUP message On receipt of a QSIG INFORMATION message following transmission of an H.225.0 SETUP message and prior to receipt of any responding message, the gateway shall save the number digits from the Called party number information element. If the QSIG INFORMATION message contains a Sending complete information element, the gateway shall transmit a QSIG CALL PROCEEDING message.

- 9 -

8.2.1.3.8

Receipt of H.225.0 SETUP ACKNOWLEDGE message On receipt of an H.225.0 SETUP ACKNOWLEDGE message the gateway shall permit the transmission of H.225.0 INFORMATION messages. If any QSIG INFORMATION messages have been received since transmission of the H.225.0 SETUP message, the gateway shall transmit an H.225.0 INFORMATION message in accordance with 8.2.1.3.10.

8.2.1.3.9

Receipt of QSIG INFORMATION message following receipt of H.225.0 SETUP ACKNOWLEDGE message On receipt of a QSIG INFORMATION message following receipt of an H.225.0 SETUP ACKNOWLEDGE message and prior to receipt of an H.225.0 CALL PROCEEDING, ALERTING, CONNECT or RELEASE COMPLETE message, the gateway shall transmit an H.225.0 INFORMATION message in accordance with 8.2.1.3.10. If the QSIG INFORMATION message contains a Sending complete information element, the gateway shall transmit a QSIG CALL PROCEEDING message.

8 . 2 . 1 . 3 . 1 0 Tr a n s m is s io n o f H . 2 2 5 . 0 I N F O R M A TI O N m e s s a g e When transmitting an H.225.0 INFORMATION message, the gateway shall include the Called party number information element containing any number digits received from QSIG since the last H.225.0 message was transmitted (SETUP or INFORMATION), with other fields containing the same values as in the H.225.0 SETUP message. If a QSIG CALL PROCEEDING message has been sent, the gateway shall include a Sending complete information element in the H.225.0 INFORMATION message. 8.2.1.3.11 Receipt of an H.225.0 CALL PROCEEDING message If the gateway receives an H.225.0 CALL PROCEEDING message it shall stop sending H.225.0 INFORMATION messages. The gateway shall send a QSIG CALL PROCEEDING message if it has not already sent one. 8.2.1.3.12 Receipt of an H.225.0 ALERTING message If the gateway receives an H.225.0 ALERTING message it shall stop sending H.225.0 INFORMATION messages and send a QSIG ALERTING message. 8.2.1.3.13 Receipt of an H.225.0 CONNECT message If the gateway receives an H.225.0 CONNECT message it shall stop sending H.225.0 INFORMATION messages and send a QSIG CONNECT message. 8.2.2

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 wit h o u t a d m is s io n p r o c e d u r e s If admission procedures are not used, the gateway is responsible for determining the call signalling transport address to which to send an H.225.0 SETUP message. This transport address can be: − the call signalling transport address of the gatekeeper with which the gateway is registered, if registered and using pre-granted admission for H.323 calls established by the gateway; or − the call signalling transport address of the destination endpoint or other entity able to take care of routing the call to the destination endpoint. NOTE In the latter case, the means by which the transport address is determined is an implementation matter. The gateway shall support call establishment using en bloc sending as specified in 8.2.2.1. The gateway shall support call establishment using QSIG overlap sending either: −

by digit collection and the use of H.323 en bloc sending, as specified in 8.2.2.2; and/or

−

by using H.323 overlap sending, as specified in 8.2.2.3.

Examples of message sequences are shown in B.3 in annex B.

- 10 -

8.2.2.1

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g e n b lo c s e n d in g a n d n o a d m is s io n procedures The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending complete information element or the gateway receives a QSIG SETUP message and is able to determine that the number in the Called party number information element is complete. NOTE The means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry.

8.2.2.1.1

Receipt of QSIG SETUP message On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in the Called party number information element, or containing a Sending complete information element if the gateway is unable to determine whether the number is complete, the gateway shall attempt to determine the call signalling transport address to which to send an H.225.0 SETUP message. If a call signalling transport address is determined, the gateway shall transmit an H.225.0 SETUP message to that transport address. The gateway shall include the contents of the QSIG SETUP message Called party number information element in the H.225.0 SETUP message in accordance with 9.2. The gateway shall either include element canOverlapSend with value FALSE in the H.225.0 SETUP message or omit the element. The gateway shall also transmit a QSIG CALL PROCEEDING message. If the gateway is unable to determine a call signalling transport address, the gateway shall initiate QSIG call clearing procedures using cause number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber absent". On receipt of a QSIG SETUP message containing a Sending complete information element and a number that the gateway determines to be incomplete in the Called party number information element, the gateway shall initiate QSIG call clearing procedures using cause number 28 “invalid number format (address incomplete)”.

8.2.2.1.2

Receipt of an H.225.0 CALL PROCEEDING message The requirements of 8.2.1.1.4 apply.

8.2.2.1.3

Receipt of an H.225.0 ALERTING message The requirements of 8.2.1.1.5 apply.

8.2.2.1.4

Receipt of an H.225.0 CONNECT message The requirements of 8.2.1.1.6 apply.

8.2.2.2

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g o v e r la p s e n d in g in Q S I G o n ly a n d n o admission procedures The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete information element, is able to determine that the number in the Called party number information element is incomplete and is able, as further digits are received, to determine when the number is complete. NOTE The means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry.

8.2.2.2.1

- 11 -

8.2.2.2.2

Receipt of QSIG INFORMATION message On receipt of a QSIG INFORMATION message while awaiting further number digits, the gateway shall append any number digits in the Called party number information element to those number digits already received and determine whether the resulting number is complete. If still incomplete and there is no Sending complete information element in the QSIG INFORMATION message, the gateway shall await further QSIG INFORMATION messages. If the number is still incomplete and the Sending complete information element is present in the QSIG INFORMATION message, the gateway shall initiate QSIG call clearing procedures using cause number 28 “invalid number format (address incomplete)”. If the gateway determines that the number is complete, the gateway shall attempt to determine the call signalling transport address to which to send an H.225.0 SETUP message. If a call signalling transport address is determined, the gateway shall transmit an H.225.0 SETUP message to that transport address. The gateway shall include the contents of the QSIG SETUP message Called party number information element, together with further digits received in QSIG INFORMATION messages, in the H.225.0 SETUP message in accordance with 9.2. The gateway shall either include element canOverlapSend with value FALSE in the H.225.0 SETUP message or omit the element. The gateway shall also transmit a QSIG CALL PROCEEDING message. If the gateway is unable to determine a call signalling transport address, the gateway shall initiate QSIG call clearing procedures using cause number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber absent". On receipt of a QSIG INFORMATION message containing a Sending complete information element and if the gateway determines the number, including appended digits, to be incomplete, the gateway shall initiate QSIG call clearing procedures using cause number 28 “invalid number format (address incomplete)”.

8.2.2.2.3

Receipt of an H.225.0 CALL PROCEEDING message The requirements of 8.2.1.1.4 apply.

8.2.2.2.4

Receipt of an H.225.0 ALERTING message The requirements of 8.2.1.1.5 apply.

8.2.2.2.5

Receipt of an H.225.0 CONNECT message The requirements of 8.2.1.1.6 apply.

8.2.2.3

8.2.2.3.1

C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3 a n d n o a d m is s io n p r o c e d u r e s The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete information element, is unable to determine whether the number in the Called party number information element is complete and is unable, as further digits are received, to determine when the number is complete. Receipt of QSIG SETUP message On receipt of a QSIG SETUP message containing no Sending complete information element, the gateway shall try to determine the call signalling transport address to which to send the H.225.0 SETUP message, based on the digits received in the Called party number information element. If the gateway is unable to determine the call signalling transport address and does not require further digits in order to determine a call signalling transport address, the gateway shall initiate QSIG call clearing procedures using cause number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber absent". If the gateway requires further digits to determine the call signalling transport address, the gateway shall transmit a QSIG SETUP ACKNOWLEDGE message and await further digits in INFORMATION messages. If the gateway is able to determine the call signalling transport address but is unable to determine that the digits represent a complete number, the gateway shall transmit a QSIG SETUP ACKNOWLEDGE message. The gateway shall also transmit an H.225.0 SETUP message to that

- 12 -

transport address. The gateway shall include the contents of the QSIG SETUP message Called party number information element in the H.225.0 SETUP message in accordance with 9.2. The gateway shall include element canOverlapSend with value TRUE in the H.225.0 SETUP message. 8.2.2.3.2

R e c e i p t o f Q S I G I N F O R M A T I O N m es s a g e b e f o r e t r a n s m i t t i n g a n H . 2 2 5 . 0 S E T U P message On receipt of a QSIG INFORMATION message containing no Sending complete information element before transmitting an H.225.0 SETUP message, the gateway shall append any additional number digits to those number digits already received and try to determine the call signalling transport address to which to send the H.225.0 SETUP message. If the gateway is unable to determine the call signalling transport address and does not require further digits in order to determine a call signalling transport address, the gateway shall initiate QSIG call clearing procedures using cause number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber absent". If the gateway requires further digits to determine the call signalling transport address, the gateway shall await further digits in QSIG INFORMATION messages. If the gateway is able to determine the call signalling transport address but is unable to determine that the digits represent a complete number, the gateway shall transmit an H.225.0 SETUP message to that transport address. The gateway shall include the contents of the QSIG SETUP message Called party number information element, together with further digits received in QSIG INFORMATION messages, in the H.225.0 SETUP message in accordance with 9.2. The gateway shall include element canOverlapSend with value TRUE in the H.225.0 SETUP message.

8.2.2.3.3

R e c e i p t o f Q S I G I N F O R M A T I O N m es s a g e f o l l o w i n g t r a n s m i s s i o n o f H . 2 2 5 . 0 SETUP message The requirements of 8.2.1.3.7 shall apply.

8.2.2.3.4

Receipt of H.225.0 SETUP ACKNOWLEDGE message The requirements of 8.2.1.3.8 shall apply.

8.2.2.3.5

Receipt of QSIG INFORMATION message following receipt of H.225.0 SETUP ACKNOWLEDGE message The requirements of 8.2.1.3.9 shall apply.

8.2.2.3.6

Tr a n s m is s io n o f H . 2 2 5 . 0 I N F O R M A TI O N m e s s a g e The requirements of 8.2.1.3.10 shall apply.

8.2.2.3.7

Receipt of an H.225.0 CALL PROCEEDING message The requirements of 8.2.1.3.11 shall apply.

8.2.2.3.8

Receipt of an H.225.0 ALERTING message The requirements of 8.2.1.3.12 shall apply.

8.2.2.3.9

Receipt of an H.225.0 CONNECT message The requirements of 8.2.1.3.13 shall apply.

8.3

Call establishment from H.323 to QSIG Examples of message sequences are shown in B.4 in annex B.

8.3.1

Receipt of an H.225.0 SETUP message On receipt of an H.225.0 SETUP message the gateway shall carry out admission procedures in accordance with H.323 unless either: − the gateway has not registered with a gatekeeper; or − the gateway has registered with a gatekeeper and pre-granted admission applies for H.323 calls arriving at the gateway.

- 13 -

NOTE In accordance with H.323, unsuccessful admission results in rejection of the call or redirection of the call to the gatekeeper. In the latter case a further H.225.0 SETUP message will normally be received from the gatekeeper and will be handled as specified here, beginning with a further attempt at admission. On successful completion of admission procedures, or if admission procedures are not required, the gateway shall transmit a QSIG SETUP message. The gateway shall support call establishment using en bloc sending. The gateway may also support call establishment using H.323 and QSIG overlap sending. The gateway shall include the Sending complete information element in the QSIG SETUP message if any of the following circumstances applies: − the gateway does not support overlap sending; or − the H.225.0 SETUP message does not contain a canOverlapSend element or contains the element with value FALSE (NOTE); or − the H.225.0 SETUP message contains a Sending complete information element; or − the gateway is able to determine that the number included in the Called party number information element in the QSIG SETUP message is complete. NOTE The canOverlapSend element indicates the calling endpoint’s ability to support overlap sending. In other circumstances the gateway shall omit the Sending complete information element from the QSIG SETUP message and be prepared to engage in overlap sending procedures. If the gateway includes the Sending complete information element in the QSIG SETUP message, it shall respond to the H.225.0 SETUP message with an H.225.0 CALL PROCEEDING message. Otherwise it shall respond with an H.225.0 SETUP ACKNOWLEDGE message. 8.3.2

A d d it io n a l m e s s a g e s r e la t in g t o o v e r la p s e n d in g The following procedure applies only if overlap sending is supported and the Sending complete information element was omitted from the QSIG SETUP message.

8.3.2.1

R e c e i p t o f H . 2 2 5 . 0 I N F O R M A T I O N m es s a g e f o l l o w i n g t r a n s m i s s i o n o f Q S I G SETUP message On receipt of an H.225.0 INFORMATION message following transmission of a QSIG SETUP message and prior to receipt of any responding message, the gateway shall save the number digits from the Called party number information element. If the H.225.0 INFORMATION message contains a Sending complete information element, the gateway shall transmit an H.225.0 CALL PROCEEDING message.

8.3.2.2

Receipt of QSIG SETUP ACKNOWLEDGE message On receipt of a QSIG SETUP ACKNOWLEDGE message the gateway shall permit the transmission of QSIG INFORMATION messages. If any H.225.0 INFORMATION messages have been received since transmission of the QSIG SETUP message, the gateway shall transmit a QSIG INFORMATION message in accordance with 8.3.2.4.

8.3.2.3

Receipt of H.225.0 INFORMATION message following receipt of QSIG SETUP ACKNOWLEDGE message On receipt of an H.225.0 INFORMATION message following receipt of a QSIG SETUP ACKNOWLEDGE message and prior to receipt of a QSIG CALL PROCEEDING, ALERTING, CONNECT, DISCONNECT, RELEASE or RELEASE COMPLETE message, the gateway shall transmit a QSIG INFORMATION message in accordance with 8.3.2.4. If the H.225.0 INFORMATION message contains a Sending complete information element, the gateway shall transmit an H.225.0 CALL PROCEEDING message.

- 14 -

8.3.2.4

Tr a n s m is s io n o f Q S I G I N F O R M A TI O N m e s s a g e When transmitting a QSIG INFORMATION message, the gateway shall include the Called party number information element containing any number digits received in H.225.0 INFORMATION messages since the last QSIG message was transmitted (SETUP or INFORMATION), with other fields containing the same values as in the QSIG SETUP message. If an H.225.0 CALL PROCEEDING message has been sent, the gateway shall include a Sending complete information element in the QSIG INFORMATION message.

8.3.3

Receipt of a QSIG CALL PROCEEDING message If the gateway receives a QSIG CALL PROCEEDING message it shall stop sending QSIG INFORMATION messages. The gateway shall send an H.225.0 CALL PROCEEDING message if it has not already sent one.

8.3.4

Receipt of a QSIG ALERTING message If the gateway receives a QSIG ALERTING message it shall stop sending QSIG INFORMATION messages and send an H.225.0 ALERTING message.

8.3.5

Receipt of a QSIG CONNECT message If the gateway receives a QSIG CONNECT message it shall stop sending QSIG INFORMATION messages and send an H.225.0 CONNECT message. It shall also respond with a QSIG CONNECT ACKNOWLEDGE message.

8.4

PROGRESS messages and Progress indicator information elements

8.4.1

Receipt of a Progress indicator information element in a QSIG message If the gateway receives a Progress indicator information element with coding standard value 00 (CCITT standardized coding) in a QSIG ALERTING or CONNECT message, it shall forward the Progress indicator information element in the corresponding H.225.0 ALERTING or CONNECT message respectively. If the gateway receives a Progress indicator information element with coding standard value 00 (CCITT standardized coding) in a QSIG PROGRESS message, it shall forward the Progress indicator information element in an H.225.0 PROGRESS message if the H.225.0 call state permits. The gateway shall not forward a Progress indicator information element with coding standard value 01 (ISO/IEC standard) or a Progress indicator information element received in a QSIG SETUP message.

8.4.2

Receipt of a Progress indicator information element in an H.225.0 message If the gateway receives a Progress indicator information element in an H.225.0 ALERTING or CONNECT message, it shall forward the Progress indicator information element in the corresponding QSIG ALERTING or CONNECT message respectively. If the gateway receives a Progress indicator information element in an H.225.0 PROGRESS or CALL PROCEEDING message, it shall forward the Progress indicator information element in a QSIG PROGRESS message if the QSIG call state permits.

8.4.3

Transmission of Progress indicator information element in support of gatewayprovided ring-back tone. When the gateway provides ring-back tone in accordance with clause 15, it shall include a Progress indicator information element containing progress description value 8 when transmitting a QSIG ALERTING message.

8.5 8.5.1

Call clearing Call clearing initiated by QSIG On receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message that initiates call clearing, the gateway shall initiate H.323 call clearing procedures. NOTE Where call admission procedures have been used, H.323 requires disengage procedures to be employed on call clearing.

8.5.2

C a ll c le a r in g in it ia t e d b y H . 3 2 3 On receipt of an H.225.0 RELEASE COMPLETE message or an H.245 EndSessionCommand, the gateway shall initiate QSIG call clearing procedures.

- 15 -

NOTE Where call admission procedures have been used, H.323 requires disengage procedures to be employed on call clearing.

9 9.1

Numbering requirements Supported numbering plans and types of number The gateway shall comply with relevant aspects of ECMA-155 for numbering within the PISN and shall accept the following values in the numbering plan identification (NPI) field of QSIG Called party number, Calling party number and Connected number information elements: – Unknown; – ISDN/Telephony numbering plan (ITU-T Rec. E.164/E.163); – Private Numbering Plan (PNP). The gateway shall also accept in these QSIG information elements any values of the type of number (TON) field that have meaning (in accordance with ECMA-155) in conjunction with the particular value present in the NPI field. The gateway shall also accept these NPI/TON combinations in H.225.0 Called party number, Calling party number and Connected number information elements and shall accept equivalent information in H.225.0 destinationInfo (in ACF message), destinationAddress, sourceAddress and connectedAddress elements where: – choice dialedDigits is equivalent to NPI value unknown; – choice partyNumber.e164Number is equivalent to NPI value ISDN/Telephony numbering plan (ITU-T Rec. E.164/E.163); and – choice partyNumber.privateNumber is equivalent to NPI value Private Numbering Plan (PNP).

9.2

Mapping numbers from QSIG to H.323 The gateway shall have the capability to map a number received from QSIG to a number for transmission in H.225.0 without number translation and without change of NPI/TON values or equivalent. This requirement includes: −

where admission procedures are used, mapping the contents of a QSIG Called party number information element in a QSIG SETUP message and any subsequent QSIG INFORMATION messages to an H.225.0 destinationInfo element in an ARQ message (NOTE 1);

−

where admission procedures are used, mapping the contents of a QSIG Calling party number information element in a QSIG SETUP message to an H.225.0 srcInfo element in an ARQ message;

−

except where admission procedures are used and the received H.225.0 ACF message contains element destinationInfo, mapping the contents of a QSIG Called party number information element in a SETUP message and any subsequent QSIG INFORMATION messages to an H.225.0 destinationAddress element in an H.225.0 SETUP message and, unless the NPI field has value PNP, an H.225.0 Called party number information element in the same message (NOTE 2, NOTE 3);

−

mapping the contents of a QSIG Called party number information in a QSIG INFORMATION message received after the sending of an H.225.0 SETUP message to an H.225.0 Called party number information element in an H.225.0 INFORMATION message;

−

mapping the contents of a QSIG Calling party number information element with a NPI value other than PNP in a QSIG SETUP message to an H.225.0 Calling party number information element in an H.225.0 SETUP message;

−

mapping the contents of a QSIG Calling party number information element with a NPI value of PNP in a QSIG SETUP message to an H.225.0 sourceAddress element in an H.225.0 SETUP message (NOTE 4);

- 16 -

−

mapping the contents of a QSIG Connected number information element in a QSIG CONNECT message to an H.225.0 Connected number information element in an H.225.0 CONNECT message.

The above requirement does not prevent the gateway having the ability to perform number translation, provided it can be configured to operate without number translation. Means by which gateways can perform number translation are outside the scope of this Standard. NOTE 1 The destinationInfo element is of the same type (AliasAddress) as the destinationAddress element in call control messages, and therefore NPI equivalents are as specified above for destinationAddress. NOTE 2 Where destinationInfo is present in the received H.225.0 ACF message, the alias address (or addresses) it contains is used in the H.225.0 SETUP message. NOTE 3 The special requirement for PNP numbers is in accordance with 7.2.2.4 of H.225.0, which forbids the inclusion of number digits with NPI value PNP in the Called party number information element. H.323 still requires the gateway to generate an H.225.0 Called party number information element. In the absence of any other form of number available for inclusion, the information element can include all the contents of the QSIG Called party number information element with the exception of the digit field, which should be left empty. NOTE 4 The special requirement for PNP numbers is in accordance with 7.2.2.6 of H.225.0, which forbids the inclusion of number digits with NPI value PNP in the Calling party number information element. H.323 still requires the gateway to generate an H.225.0 Calling party number information element. In the absence of any other form of number available for inclusion, the information element can include all the contents of the QSIG Calling party number information element with the exception of the digit field, which should be left empty. When generating an H.225.0 Called party number information element, if the numbering plan is PNP the number digits shall be omitted. NOTE This is in accordance with 7.2.2.4 of H.225.0. The NPI and TON fields are still present in the H.225.0 Called party number information element. The entire information from the QSIG Called party number information is available in the H.225.0 destinationAddress element.

9.3

Mapping numbers from H.323 to QSIG The gateway shall have the capability to map a number received from H.225.0 to a number for transmission in QSIG without number translation and without change of NPI/TON values or equivalent. This requirement includes: −

mapping the contents of an alias address in an H.225.0 destinationAddress element in an H.225.0 SETUP message to a QSIG Called party number information element in a QSIG SETUP message or, if destinationAddress contains no alias address that can be mapped, mapping the H.225.0 Called party number information element, if present;

−

where the only addresses able to be mapped from the H.225.0 destinationAddress element and the H.225.0 Called party number information element in an H.225.0 SETUP message identify the gateway, mapping the contents of an alias address in an H.225.0 remoteExtensionAddress element, if present, to a QSIG Called party number information element in a QSIG SETUP message.

−

mapping the contents of an H.225.0 Called party number information in an H.225.0 INFORMATION message received after the sending of a QSIG SETUP message to a QSIG Called party number information element in a QSIG INFORMATION message.

−

mapping the contents of the Calling party number information element or an alias address in an H.225.0 sourceAddress element in an H.225.0 SETUP message to a QSIG Calling party number information element in a QSIG SETUP message (NOTE);

- 17 -

−

mapping the contents of the Connected number information element in an H.225.0 CONNECT message to a QSIG Connected number information element in a QSIG CONNECT message or, if the Connected number information element is not present, mapping a suitable alias address, if present in the H.225.0 connectedAddress element;

9.4

Handling of presentation and screening indicators The gateway shall pass presentation and screening indicators associated with calling party and connected numbers transparently from QSIG to H.323 and vice versa. This includes the presentation indicator and screening indicator fields in QSIG and H.225.0 Calling party number and Connected number information elements. It also includes the H.225.0 presentationIndicator and screeningIndicator elements when the numbers concerned are mapped to/from H.225.0 sourceAddress and connectedAddress elements.

9.5

Handling of subaddresses The gateway shall not pass on in an H.225.0 message any Called party subaddress, Calling party subaddress or Connected subaddress information element received in a QSIG message.

Security requirements Within a PISN, QSIG signalling information is generally regarded as inherently secure and not subject to active attacks that can lead to denial or misuse of service. When interworking between QSIG and H.323, it is important to provide a similar level of security for H.323 signalling information, in order to prevent denial or misuse of service in the PISN. The gateway shall support the baseline security profile specified in annex D of ITU-T recommendation H.235 and shall use the profile’s authentication and integrity mechanisms when communicating with a compliant gatekeeper, if required to do so by network policy and a shared secret key is available. This applies to H.225.0 RAS signalling and to H.225.0 call control signalling using the gatekeeper-routed model. The means for establishing shared secret keys is outside the scope of this Standard. NOTE This profile provides for authentication and integrity of H.225.0 messages (RAS and call control) between an endpoint (e.g., a gateway) and its gatekeeper using a shared secret key. Authentication and integrity of H.225.0 call control signalling automatically extends to any fast connect signalling and tunnelled H.245 signalling, but authentication and integrity of a separate H.245 channel is not provided. The use of the optional voice encryption profile, which is part of the basic security profile, is outside the scope of this Standard. The use of authentication and integrity mechanisms for H.225.0 call control signalling directly to an H.323 entity other than the gatekeeper with which the gateway is registered (direct call signalling) is outside the scope of this Standard. NOTE This would not be scaleable, owing to the potentially very large number of shared secrets required. The ability to support alternative or additional security measures (e.g., public key infrastructure, transport layer or IP layer security) is not precluded but is outside the scope of this Standard.

Requirements for support of basic services This Standard specifies signalling interworking for basic services that provide a bidirectional transfer capability for speech, facsimile and modem media between the two networks. These basic services are indicated in the QSIG Bearer capability information element by the field values shown in table 2:

- 18 -

T a b l e 2 – F i e l d v a l u e s w i t h i n t h e Q S I G B ea r e r c a p a b i l i t y i n f o r m a t i o n e l e m e n t f o r s p e e c h , facsimile and modem media Field

Value

Coding standard

“CCITT standardized coding” (00)

Information transfer capability

“speech” (00000) (NOTE 1), “unrestricted digital information” (01000) (NOTE 2), "restricted digital information" (01001) (NOTE 2), “3,1 kHz audio” (10000) (NOTE 1), "unrestricted digital information with tones and announcements" (10001) (NOTE 2)

Transfer mode

“circuit mode” (00)

Information transfer rate

“64 Kbit/s” (10000)

Multiplier

Octet omitted

User information layer 1 protocol

“CCITT recommendation G.711 µ-law” (00010) or “CCITT recommendation G.711 A-law” (00011)

NOTE 1 Information transfer capability “speech” is suitable only for speech, whereas information transfer capability “3,1 KHz audio” is suitable for speech, facsimile or modem data. NOTE 2 Information transfer capabilities “unrestricted digital information” and "restricted digital information" can be used for speech, in which case the user information layer 1 protocol will be present and coded as indicated in the table. Information transfer capability "unrestricted digital information with tones and announcements" can be used for speech when tones and announcements are present. These three types of bearer capability require no alteration to user information, thereby preventing the use of techniques such as compression. In addition, where QSIG is carried over an inter-PINX link that provides 16 Kbit/s or 8 Kbit/s user information channels in accordance with ECMA-253 or ECMA-289 respectively, other values can occur in the coding standard, information transfer rate and user information layer 1 fields as specified in those Standards.

11.1

Calls from QSIG to H.323 The gateway shall forward from QSIG to H.323 only calls in which the Bearer capability information element in the QSIG SETUP message has field values as shown in table 2 or as modified by ECMA-253 or ECMA-289. The gateway shall reject other calls and may also reject calls for which the information transfer capability field has the value “unrestricted digital information”, "restricted digital information" or "unrestricted digital information with tones and announcements". To reject a call, the gateway shall initiate QSIG call clearing procedures using cause number 65 “bearer capability not implemented” in the QSIG Cause information element. When forwarding a call, the gateway shall pass on the QSIG Bearer capability information element unchanged as the H.225.0 Bearer capability information element, with the following exception: fields coded in accordance with ECMA-253 or ECMA-289 shall be converted to values that conform with table 2. The gateway shall not pass on QSIG Low layer compatibility and High layer compatibility information elements. NOTE The speech encoding method used in the IP network is negotiated using H.245 or fast connect, and therefore the method and rate can differ from the method and rate indicated in the H.225.0 Bearer capability information element (in this case G.711 and 64 Kbit/s). NOTE Use of a different speech encoding method in the IP network from that used in the QSIG network can result

- 19 -

in the use of speech transcoding at the gateway. Speech transcoding can be avoided by negotiating in the IP network the same speech encoding that is used on the inter-PINX link.

11.2

Calls from H.323 to QSIG In the absence of other relevant information in the H.225.0 SETUP message (e.g., fast connect), the gateway shall forward only calls in which the Bearer capability information element in the H.225.0 SETUP message has field values as shown in table 2. The gateway shall reject other calls and may also reject calls for which the information transfer capability field has the value “unrestricted digital information”, "restricted digital information" or "unrestricted digital information with tones and announcements". To reject a call, the gateway shall initiate H.225.0 call clearing procedures using cause number 65 “bearer capability not implemented” in the H.225.0 Cause information element. When forwarding a call from H.323 to QSIG, the gateway shall code the QSIG Bearer capability information element in accordance with table 2 or, for forwarding to an inter-PINX link that provides 16 Kbit/s or 8 Kbit/s user information channels, in accordance with ECMA-253 or ECMA-289 respectively. The gateway shall not include a Low layer compatibility in the QSIG SETUP message. The gateway shall not include a High layer compatibility information element in the QSIG SETUP message except as allowed in clause 13. NOTE The speech encoding method used in the IP network is negotiated using H.245 or fast connect, and therefore the method and rate can differ from the method and rate indicated in the H.225.0 Bearer capability information element (in this case G.711 and 64 Kbit/s). NOTE Use of a different speech encoding method in the IP network from that used in the QSIG network can result in the use of speech transcoding at the gateway. Speech transcoding can be avoided by negotiating in the IP network the same speech encoding that is used on the inter-PINX link.

Media channel establishment For basic services within the scope of this Standard, except where special support for group 3 fax is being provided (clause 13), each call requires in principle the use of two audio logical channels, one in each direction. However, calls can originate or terminate at H.323 endpoints that support only one-way audio (e.g., recorded announcement devices that transmit only). The gateway shall open and maintain an audio logical channel from itself to the peer endpoint, subject to the peer endpoint having acceptable audio receive capabilities, and accept the opening of an audio logical channel from the peer endpoint, subject to the peer endpoint using an audio transmit capability that is an acceptable receive capability at the gateway. NOTE The means for achieving this include fast connect, tunnelled H.245 and, when interworking with an endpoint that supports only H.323 version 3 or earlier, a separate H.245 channel. The gateway shall maintain a connection between each established audio logical channel and the corresponding user information channel on the inter-PINX link. The gateway may initiate call clearing in accordance with 8.5 if neither a transmit nor a receive audio logical channel can be opened. NOTE Reasons for failing to establish an audio logical channel can include: •

the peer endpoint has no transmit or no receive audio capabilities;

•

the peer endpoint’s transmit or receive audio capabilities are incompatible with the gateway’s audio capabilities;

•

the gateway temporarily lacks resource compatible with the peer endpoint’s transmit or receive capabilities.

- 20 -

The gateway shall tolerate the closing and re-opening of audio logical channels during a call for reasons including but not necessarily limited to the following: change of codec, call hold, call transfer, conference formation, etc.. However, the gateway may initiate call clearing in accordance with 8.5 in the event that audio logical channels cannot be re-opened for reasons listed above.

Requirements for the support of group 3 fax in accordance with H.323 annex D Gateway support for group 3 fax in accordance with H.323 annex D is optional. If the gateway supports this capability, the requirements of this clause apply.

13.1

Start of fax transmission The gateway shall be able to monitor audio information at the start of and during a call in order to detect the presence of fax and determine the negotiated transmission rate. If the gateway detects fax it shall close audio logical channel(s) (if open) and open fax logical channel(s) in accordance with H.323 annex D. NOTE For calls from QSIG to H.323, the QSIG SETUP message can contain a High layer compatibility information element indicating group 3 fax. However, the gateway still needs to monitor audio information to detect the transmission rate before opening fax logical channels. NOTE H.323 annex D provides the following options: two unidirectional logical channels using UDP, two unidirectional logical channels using TCP or one bidirectional logical channel using TCP. The gateway shall be able to co-operate in accordance with H.323 annex D if the peer endpoint initiates the closing of audio logical channel(s) and the opening of fax logical channel(s) or the opening of fax logical channel(s) at the outset. For a call from H.323 to QSIG, if the gateway knows prior to sending the QSIG SETUP message that fax is being transmitted (e.g., because the opening of fax logical channels has been requested by means of fast connect), it may include in the QSIG SETUP message a High layer compatibility information element indicating group 3 fax.

13.2

End of fax transmission The gateway may have the ability to detect the end of fax transmission. If the gateway detects the end of fax transmission it may close the fax logical channel(s) and open audio logical channel(s). The gateway shall be able to co-operate in accordance with H.245 if the peer endpoint initiates the closing of fax logical channel(s) and the opening of audio logical channel(s).

Requirements for the support of DTMF For a call from QSIG to H.323 or from H.323 to QSIG, a gateway shall be able to detect and generate DTMF tones corresponding to characters 0-9, A, B, C, D. * and # on the user information channel of the inter-PINX link. A gateway shall support the transmission and reception of H.245 userInputIndication messages conveying characters 0-9, A, B, C, D, * and #. A gateway may support the transmission and reception of characters 0-9, A, B, C, D, * and # within RTP on special logical channels (one in each direction) in accordance with 10.5 of H.323. On detection of a DTMF tone from the inter-PINX link, the gateway shall send an H.245 userInputIndication message conveying the character concerned, unless a logical channel for transmitting DTMF characters is open, in which case the gateway shall send the character using RTP on that logical channel. On receipt of a DTMF character in a userInputIndication message or via RTP, the gateway shall generate a DTMF tone on the inter-PINX link.

- 21 -

Requirements for the provision of ring-back tone For a call from QSIG to H.323, if the gateway does not receive progress description value 1 or 8 in a Progress indicator information element in the H.225.0 ALERTING message or an earlier H.225.0 message, the gateway shall provide ring-back tone towards the calling user. Ring-back tone shall commence when the QSIG ALERTING message is sent and shall terminate when the call is answered or cleared. NOTE See 8.4.3 for requirements concerning the Progress indicator information element when providing ring-back tone. NOTE For a call from QSIG to H.323, the called endpoint can provide ring-back tone while alerting the called user. If the gateway receives progress description value 1 or 8 in a Progress indicator information element in the H.225.0 ALERTING message or an earlier H.225.0 message, the gateway need not provide ring-back tone. NOTE For a call from H.323 to QSIG, ring-back tone is normally provided by the PISN while alerting the called user. There are no gateway requirements for the provision of ring-back tone in this direction.

- 22 -

- 23 -

Annex A ( n o r ma tiv e )

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

irrelevant or out-of-scope - this capability is outside the 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,

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);

- 24 -

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

- 25 -

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

A.3.2

Specification for which this ICS applies Title

Corporate telecommunication networks – Signalling interworking between QSIG and H.323 – Basic services

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):

- 26 -

A.4

Major options Table A.1 - Major options

Item

Question: Does the implementation...

MC1

Status

Reference

Support

Support operation without registering with a gatekeeper?

[ ]Yes [ ]No

MC2

Support pre-granted admission?

[ ]Yes [ ]No

MC3

Support overlap sending in QSIG only for calls from QSIG to H.323?

O.1

[ ]Yes [ ]No

MC4

Support overlap sending in QSIG and H.323 for calls from QSIG to H.323?

O.1

[ ]Yes [ ]No

MC5

Support overlap sending from H.323 to QSIG?

[ ]Yes [ ]No

MC6

Use 16 Kbit/s user information channels on the inter-PINX link in accordance with ECMA-253?

[ ]Yes [ ]No

MC7

Use 8 Kbit/s user information channels on the inter-PINX link in accordance with ECMA-289?

[ ]Yes [ ]No

MC8

Support of fax in accordance with H.323 annex D in IP network.

[ ]Yes [ ]No

Comments:

Conditions for status

- 27 -

A.5

General requirements Table A.2 - General requirements

Item

Question: Does the implementation...

GR1

Status

Reference

Support

Support QSIG in accordance with ECMA-143?

[ ]Yes

GR2

Support H.323 version 4 and H.225.0 version 4

[ ]Yes

GR3

Support interworking with other H.323 entities in accordance with the provisions of H.323 version 4

[ ]Yes

GR4

Have an ability to discover and register with a gatekeeper

[ ]Yes

GR5

Support H.323 admission procedures during call establishment

8.2.1 and 8.3

[ ]Yes

GR6

Support call establishment without H.323 admission procedures?

MC1 OR MC2 M

8.2.2 and 8.3

[ ]Yes

GR7

Support H.323 direct call signalling

[ ]Yes

GR8

Support H.323 gatekeeper-routed signalling

[ ]Yes

GR9

Use of H.323 direct call signalling or H.323 gatekeeper-routed signalling in accordance with instructions from the gatekeeper when registered with a gatekeeper and pre-granted admission does not apply

[ ]Yes

GR10

Support call establishment from QSIG to H.323

[ ]Yes

GR11

Support call establishment from H.323 to QSIG

[ ]Yes

Comments:

Conditions for status

NOT (MC1 OR MC2)

- 28 -

A.6

Message validation and handling of protocol errors Table A.3 - Message validation and handling of protocol errors

Item

Question: Does the implementation...

MV1

MV2

Conditions for status

Status

Reference

Support

Validate received QSIG messages in accordance with ECMA-143 and act in accordance with ECMA-143 on detection of a QSIG protocol error

8.1

[ ]Yes

Validate received H.225.0 messages in accordance with H.323 and H.225.0 and act in accordance with H.323 and H.225.0 on detection of an H.225.0 protocol error

8.1

[ ]Yes

Comments:

A.7

Call establishment from QSIG to H.323 with admission procedures and en bloc sending Ta b le A . 4 - C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 wit h a d m is s io n p r o c e d u r e s and en bloc sending

Item

Question: Does the implementation...

QHA1

Status

Reference

Support

Support receipt of QSIG SETUP message

8.2.1.1.1

[ ]Yes

QHA2

Support receipt of H.225.0 ACF message

8.2.1.1.2

[ ]Yes

QHA3

Support receipt of H.225.0 ARJ message

8.2.1.1.3

[ ]Yes

QHA4

Support receipt of H.225.0 ALERTING message

8.2.1.1.5

[ ]Yes

QHA5

Support receipt of H.225.0 CONNECT message

8.2.1.1.6

[ ]Yes

Comments:

Conditions for status

- 29 -

A.8

Call establishment from QSIG to H.323 with admission procedures and overlap sending in QSIG only Ta b le A . 5 - C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 wit h a d m is s io n p r o c e d u r e s and overlap sending in QSIG only

Item

Question: Does the implementation...

Conditions for status

Status

Reference

Support

QHAO1

Support receipt of QSIG SETUP message

MC3

8.2.1.2.1

[ ]Yes

NOT MC3

N/A

MC3

NOT MC3

N/A

MC3

NOT MC3

N/A

QHAO2

QHAO3

QHAO4

Support receipt of QSIG INFORMATION message Support transmission of H.225.0 ARQ message

Support receipt of H.225.0 ACF message MC3 NOT MC3

QHAO5

QHAO6

QHAO7

QHAO8

Comments:

Support receipt of H.225.0 ARJ message MC3

Support receipt of H.225.0 CALL PROCEEDING message Support receipt of H.225.0 ALERTING message Support receipt of H.225.0 CONNECT message

[ ]N/A 8.2.1.2.2

[ ]N/A 8.2.1.2.3

NOT MC3

N/A

MC3

NOT MC3

N/A

MC3

NOT MC3

N/A

MC3

NOT MC3

N/A

[ ]Yes [ ]N/A

8.2.1.2.4

N/A M

[ ]Yes

[ ]Yes [ ]N/A

8.2.1.2.5

[ ]Yes [ ]N/A

8.2.1.2.6

[ ]Yes [ ]N/A

8.2.1.2.7

[ ]Yes [ ]N/A

8.2.1.2.8

[ ]Yes [ ]N/A

- 30 -

A.9

Call establishment from QSIG to H.323 with admission procedures and overlap sending in both QSIG and H.323 Ta b le A . 6 - C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 wit h a d m is s io n p r o c e d u r e s a n d o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3

Item

Question: Does the implementation...

Conditions for status

Status

Reference

Support

QHAOO1

Support receipt of QSIG SETUP message

MC4

8.2.1.3.1

[ ]Yes

NOT MC4

N/A

MC4

NOT MC4

N/A

QHAOO2

QHAOO3

QHAOO4

Support transmission of H.225.0 ARQ message

Support receipt of QSIG MC4 INFORMATION message while awaiting NOT MC4 response to H.225.0 ARQ message

N/A

Support receipt of H.225.0 ACF message MC4

NOT MC4 QHAOO5

QHAOO6

QHAOO7

QHAOO8

QHAOO9

Support receipt of H.225.0 ARJ message MC4

Support receipt of QSIG INFORMATION message following receipt of H.225.0 ARJ message with rejectReason incompleteAddress

Support receipt of QSIG INFORMATION message following receipt of H.225.0 SETUP ACKNOWLEDGE message

QHAOO10 Support transmission of H.225.0 INFORMATION message QHAOO11 Support receipt of H.225.0 CALL PROCEEDING message QHAOO12 Support receipt of H.225.0 ALERTING message QHAOO13 Support receipt of H.225.0 CONNECT message Comments:

8.2.1.3.2

M N/A

MC4

NOT MC4

N/A M

8.2.1.3.3

NOT MC4

N/A

MC4

NOT MC4

N/A

MC4

NOT MC4

N/A

MC4

NOT MC4

N/A

MC4

NOT MC4

N/A

MC4

NOT MC4

N/A

[ ]Yes [ ]N/A

8.2.1.3.4

[ ]Yes [ ]N/A

8.2.1.3.5

[ ]Yes [ ]N/A

8.2.1.3.6

[ ]Yes [ ]N/A

8.2.1.3.7

N/A

MC4

[ ]Yes [ ]N/A

N/A

NOT MC4

Support receipt of QSIG MC4 INFORMATION message following transmission of H.225.0 SETUP message NOT MC4 Support receipt of H.225.0 SETUP ACKNOWLEDGE message

[ ]N/A

[ ]Yes [ ]N/A

8.2.1.3.8

[ ]Yes [ ]N/A

8.2.1.3.9

[ ]Yes [ ]N/A

8.2.1.3.10

[ ]Yes [ ]N/A

8.2.1.3.11

[ ]Yes [ ]N/A

8.2.1.3.12

[ ]Yes [ ]N/A

8.2.1.3.13

[ ]Yes [ ]N/A

- 31 -

A.10 Call establishment from QSIG to H.323 using en bloc sending and no admission procedures Ta b le A . 7 - C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 wit h o u t a d m is s io n p r o c e d u r e s and en bloc sending Item

Question: Does the implementation...

Conditions for status

Status

Reference

Support

QHN1

Support receipt of QSIG SETUP message

GR6

8.2.2.1.1

[ ]Yes

NOT GR6

N/A

GR6

NOT GR6

N/A

GR6

NOT GR6

N/A

QHN2

QHN3

Comments:

Support receipt of H.225.0 ALERTING message Support receipt of H.225.0 CONNECT message

[ ]N/A 8.2.2.1.3

[ ]Yes [ ]N/A

8.2.2.1.4

[ ]Yes [ ]N/A

- 32 -

A.11 Call establishment from QSIG to H.323 using overlap sending in QSIG only and no admission procedures Ta b le A . 8 - C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g o v e r la p s e n d in g in Q S I G o n ly and no admission procedures Item

Question: Does the implementation...

Conditions for status

Status

Reference

Support

QHNO1

Support receipt of QSIG SETUP message

GR6 AND MC3

8.2.2.2.1

[ ]Yes

NOT(GR6 AND MC3)

N/A

GR6 AND MC3

NOT(GR6 AND MC3)

N/A

GR6 AND MC3

NOT(GR6 AND MC3)

N/A

GR6 AND MC3

NOT(GR6 AND MC3)

N/A

GR6 AND MC3

NOT(GR6 AND MC3)

N/A

QHNO2

QHNO3

QHNO4

QHNO5

Comments:

Support receipt of QSIG INFORMATION message

Support receipt of H.225.0 CALL PROCEEDING message

Support receipt of H.225.0 ALERTING message

Support receipt of H.225.0 CONNECT message

[ ]N/A 8.2.2.2.2

[ ]Yes [ ]N/A

8.2.2.2.3

[ ]Yes [ ]N/A

8.2.2.2.4

[ ]Yes [ ]N/A

8.2.2.2.5

[ ]Yes [ ]N/A

- 33 -

A.12 Call establishment from QSIG to H.323 using overlap sending in both QSIG and H.323 and no admission procedures Ta b le A . 9 - C a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3 a n d n o a d m is s io n p r o c e d u r e s Item

Question: Does the implementation...

Conditions for status

Status

Reference

QHNOO1

Support receipt of QSIG SETUP message

GR6 AND MC4

8.2.2.3.1

NOT(GR6 AND MC4)

N/A

QHNOO2

QHNOO3

QHNOO4

QHNOO5

QHNOO6

QHNOO7

QHNOO8

QHNOO9

Comments:

Support receipt of QSIG GR6 AND INFORMATION message before MC4 transmitting an H.225.0 SETUP message NOT(GR6 AND MC4) Support receipt of QSIG GR6 AND INFORMATION message following MC4 transmission of H.225.0 SETUP message NOT(GR6 AND MC4) Support receipt of H.225.0 SETUP ACKNOWLEDGE message

Support receipt of QSIG INFORMATION message following receipt of H.225.0 SETUP ACKNOWLEDGE message Support transmission of H.225.0 INFORMATION message

Support receipt of H.225.0 CALL PROCEEDING message

Support receipt of H.225.0 ALERTING message

Support receipt of H.225.0 CONNECT message

8.2.2.3.2

N/A M

NOT(GR6 AND MC4)

N/A

GR6 AND MC4

NOT(GR6 AND MC4)

N/A

GR6 AND MC4

NOT(GR6 AND MC4)

N/A

GR6 AND MC4

NOT(GR6 AND MC4)

N/A

GR6 AND MC4

NOT(GR6 AND MC4)

N/A

GR6 AND MC4

NOT(GR6 AND MC4)

N/A

[ ]Yes [ ]N/A

8.2.2.3.3

N/A

GR6 AND MC4

Support

[ ]Yes [ ]N/A

8.2.2.3.4

[ ]Yes [ ]N/A

8.2.2.3.5

[ ]Yes [ ]N/A

8.2.2.3.6

[ ]Yes [ ]N/A

8.2.2.3.7

[ ]Yes [ ]N/A

8.2.2.3.8

[ ]Yes [ ]N/A

8.2.2.3.9

[ ]Yes [ ]N/A

- 34 -

A.13 Call establishment from H.323 to QSIG Ta b le A . 1 0 - C a ll e s t a b lis h m e n t f r o m H . 3 2 3 t o Q S I G Item

Question: Does the implementation...

HQ1

Support receipt of H.225.0 SETUP message

HQ2

Support receipt of H.225.0 INFORMATION message following transmission of QSIG SETUP message

HQ3

HQ4

HQ5

Support receipt of QSIG SETUP ACKNOWLEDGE message Support receipt of H.225.0 INFORMATION message following receipt of QSIG SETUP ACKNOWLEDGE message Support transmission of QSIG INFORMATION message

Conditions for status

Status

Reference

Support

8.3.1

[ ]Yes

MC5

8.3.2.1.

[ ]Yes

NOT MC5

N/A

MC5

NOT MC5

N/A

MC5

NOT MC5

N/A

MC5

NOT MC5

N/A

[ ]N/A 8.3.2.2.

[ ]Yes [ ]N/A

8.3.2.3.

[ ]Yes [ ]N/A

8.3.2.4.

[ ]Yes [ ]N/A

HQ6

Support receipt of QSIG CALL PROCEEDING message

8.3.3

[ ]Yes

HQ7

Support receipt of QSIG ALERTING message

8.3.4

[ ]Yes

HQ8

Support receipt of QSIG CONNECT message

8.3.5

[ ]Yes

Comments:

- 35 -

A.14 PROGRESS message and Progress indicator information elements T a b l e A . 1 1 - P R O G R E S S m e s s a g e a n d P r o gr e s s i n d i c a t o r i n f o r m a t i o n e l e m e n t s Item

Question: Does the implementation...

PR1

Conditions for status

Status

Reference

Support

Support receipt of Progress indicator information element in a QSIG message

8.4.1

[ ]Yes

PR2

Support receipt of Progress indicator information element in an H.225.0 message

8.4.2

[ ]Yes

PR3

Support transmission of Progress indicator information element in support of gateway-provided ring-back tone

8.4.3

[ ]Yes

Status

Reference

Support

Comments:

A.15 Call clearing Table A.12 - Call clearing Item

Question: Does the implementation...

CL1

Support call clearing initiated by QSIG

8.5.1

[ ]Yes

CL2

Support call clearing initiated by H.323

8.5.2

[ ]Yes

Comments:

Conditions for status

- 36 -

A.16 Numbering requirements Table A.13 - Numbering requirements Item

Question: Does the implementation...

NU1

Conditions for status

Status

Reference

Support

Provide support for numbering plans and types of numbers

9.1

[ ]Yes

NU2

Support mapping of numbers from QSIG to H.323

9.2

[ ]Yes

NU3

Support mapping of numbers from H.323 to QSIG

9.3

[ ]Yes

NU4

Handle presentation and screening indicators

9.4

[ ]Yes

NU5

Handle subaddresses

9.5

[ ]Yes

Status

Reference

Support

[ ]Yes

Comments:

A.17 Security requirements Table A.14 - Security requirements Item

Question: Does the implementation...

SE1

Support security requirements

Conditions for status

Comments:

A.18 Requirements for support of basic services Table A.15 - Requirements for support of basic services Item

Question: Does the implementation...

BS1 BS2 Comments:

Conditions for status

Status

Reference

Support

Support basic services for calls from QSIG to H.323

11.1

[ ]Yes

Support basic services for calls from H.323 to QSIG

11.2

[ ]Yes

- 37 -

A.19 Media channel establishment Table A.16 - Media channel establishment Item

Question: Does the implementation...

ME1

Support media channel establishment

Conditions for status

Status

Reference

Support

[ ]Yes

Comments:

A.20 Requirements for the support of group 3 fax in accordance with H.323 annex D T a b l e A . 1 7 - R e q u i r e m e n t s f o r t h e s u p p o r t o f g ro u p 3 f a x i n a c c o r d a n c e w i t h H . 3 2 3 a n n e x D Item

Question: Does the implementation...

Conditions for status

Status

Reference

Support

FAX1

Support start of fax transmission

MC8

13.1

[ ]Yes

NOT MC8

N/A

MC8

NOT MC8

N/A

FAX2

Support end of fax transmission

[ ]N/A 13.2

[ ]Yes [ ]No [ ]N/A

Comments:

A.21 Requirements for the support of DTMF Table A.18 - Requirements for the support of DTMF Item

Question: Does the implementation...

MF1

MF2

Comments:

Conditions for status

Status

Reference

Support

Support DTMF transmission from PISN to IP network and vice versa using H.245 userInputIndication messages in the IP network

[ ]Yes

Support DTMF transmission from PISN to IP network and vice versa using RTP on special logical channels in the IP network

[ ]Yes [ ]No

- 38 -

A.22 Requirements for the provision of ring-back tone Table A.19 - Requirements for the provision of ring-back tone Item

Question: Does the implementation...

RBT1

Provide ring-back tone towards a calling user in the PISN

Comments:

Conditions for status

Status

Reference

Support

[ ]Yes

- 39 -

Annex B ( in f o r ma tiv e )

Example message sequences

B.1

Introduction This annex shows some typical message sequences that can occur. The message mapping requirements of clause 8 permit variations on these sequences to occur. In each diagram QSIG messages are shown as arrows on the left side of the diagram and H.225.0 messages are shown as arrows on the right side of the diagram. On the right hand side of the diagram, broken arrows represent H.225.0 RAS messages and continuous arrows represent H.225.0 call control messages.

B.2

Message sequences for call establishment from QSIG to H.323 using admission procedures The figures below show typical sequences of messages for successful call establishment from QSIG to H.323 using admission procedures. PISN

IP network

Gateway

QSIG SETUP QSIG CALL PROCEEDING

H.225.0 ARQ H.225.0 ACF

H.225.0 SETUP H.225.0 CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 3 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 using admission procedures and en bloc sending

- 40 -

PISN

IP network

Gateway

QSIG SETUP QSIG SETUP ACKNOWLEDGE QSIG INFORMATION QSIG INFORMATION H.225.0 ARQ QSIG CALL PROCEEDING H.225.0 ACF H.225.0 SETUP H.225.0 CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 4 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 using admission procedures and overlap sending in QSIG

PISN

IP network

Gateway

QSIG SETUP QSIG SETUP ACKNOWLEDGE

QSIG INFORMATION

H.225.0 ARQ H.225.0 ARJ (incompleteAddress)

QSIG INFORMATION

H.225.0 ARQ H.225.0 ACF H.225.0 SETUP

QSIG CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 CALL PROCEEDING H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 5 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g a d m is s io n p r o c e d u r e s a n d o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3 ( R A S o n ly )

- 41 -

PISN

IP network

Gateway

QSIG SETUP QSIG SETUP ACKNOWLEDGE QSIG INFORMATION

H.225.0 ARQ H.225.0 ARJ (incompleteAddress) H.225.0 ARQ H.225.0 ACF H.225.0 SETUP H.225.0 SETUP ACKNOWLEDGE

QSIG INFORMATION

QSIG CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 INFORMATION H.225.0 CALL PROCEEDING H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 6 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g a d m is s io n p r o c e d u r e s a n d o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3 ( R A S a n d c a ll c o n t r o l)

B.3

Message sequences for call establishment from QSIG to H.323 without admission procedures The figures below show typical sequences of messages for successful call establishment from QSIG to H.323 without admission procedures. PISN

IP network

Gateway

QSIG SETUP

H.225.0 SETUP

QSIG CALL PROCEEDING H.225.0 CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 7 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 using en bloc sending (no admission procedures)

- 42 -

PISN

IP network

Gateway

QSIG SETUP QSIG SETUP ACKNOWLEDGE

QSIG INFORMATION QSIG INFORMATION QSIG CALL PROCEEDING

QSIG ALERTING QSIG CONNECT

H.225.0 SETUP H.225.0 CALL PROCEEDING H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 8 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g o v e r la p s e n d in g in Q S I G ( n o a d m is s io n p r o c e d u r e s )

PISN

IP network

Gateway

QSIG SETUP QSIG SETUP ACKNOWLEDGE

QSIG INFORMATION

H.225.0 SETUP H.225.0 SETUP ACKNOWLEDGE

QSIG INFORMATION

QSIG CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 INFORMATION H.225.0 CALL PROCEEDING H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 9 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m Q S I G t o H . 3 2 3 u s in g o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3 ( n o a d m is s io n p r o c e d u r e s )

- 43 -

B.4

Message sequences for call establishment from H.323 to QSIG The figures below show typical sequences of messages for successful call establishment from QSIG to H.323. In these examples admission procedures are shown. PISN

IP network

Gateway

H.225.0 SETUP H.225.0 ARQ QSIG SETUP QSIG CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 ACF

H.225.0 CALL PROCEEDING H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 1 0 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m H . 3 2 3 t o Q S I G using admission procedures and en bloc sending

PISN

IP network

Gateway

H.225.0 SETUP H.225.0 ARQ QSIG SETUP QSIG SETUP ACKNOWLEDGE

QSIG INFORMATION QSIG INFORMATION

QSIG CALL PROCEEDING QSIG ALERTING QSIG CONNECT

H.225.0 ACF

H.225.0 SETUP ACKNOWLEDGE

H.225.0 INFORMATION H.225.0 INFORMATION

H.225.0 CALL PROCEEDING

H.225.0 ALERTING H.225.0 CONNECT

F ig u r e 1 1 – Ty p ic a l m e s s a g e s e q u e n c e f o r s u c c e s s f u l c a ll e s t a b lis h m e n t f r o m H . 3 2 3 t o Q S I G u s in g a d m is s io n p r o c e d u r e s a n d o v e r la p s e n d in g in b o t h Q S I G a n d H . 3 2 3

- 44 -

B.5

Message sequences for call clearing The figures below show typical sequences of messages for call clearing. H.323 disengagement procedures are not shown. PISN

Gateway

QSIG DISCONNECT

IP network

H.225.0 RELEASE COMPLETE

QSIG RELEASE QSIG RELEASE COMPLETE

Figure 12 – Typical message sequence for call clearing initiated from PISN

PISN

Gateway

QSIG DISCONNECT

IP network

H.225.0 RELEASE COMPLETE

QSIG RELEASE QSIG RELEASE COMPLETE

Figure 13 – Typical message sequence for call clearing initiated from IP network

Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:

+41 22 849.60.01 [email protected]

Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.

ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.

ECMA-332 — Corporate telecommunication networks - Signalling interworking between QSIG and H.323 - Basic services (December 2001)

Related documents