SIST-TS TS 101 804-2 V1.1.1:2004

• Abstract:

  Design of Test Suite Structure (TSS) and Test Purposes (TP) for H.225.0 protocol implementation in Terminal, Gatekeeper and Gateway.

• Status: Published
• Publication Date: 31-Mar-2004
• ICS: 33.020 - Telecommunications in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2004
• Due Date: 01-Apr-2004
• Completion Date: 01-Apr-2004
• Ref Project: ETSI TS 101 804-2 V1.1.1 (2002-02) - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; Technology compliance specifications; Part 2: H.225.0 conformance test specifications; Test Suite Structure and Test Purposes (TSS&TP) specification for Terminal, Gatekeeper and Gateway

SIST-TS TS 101 804-2 V1.1.1:2004 is the Slovenian version identified as identical to ETSI TS 101 804-2 V1.1.1. It specifies Test Suite Structure and Test Purposes (TSS&TP) for H.225.0 conformance testing of Terminal, Gatekeeper and Gateway implementations in TIPHON Release 3. In practice, it tells test engineers which RAS and BCC behaviours to check so they can assess H.225.0 signalling conformance and interoperability.

What does SIST-TS TS 101 804-2 V1.1.1:2004 specify?

SIST-TS TS 101 804-2 V1.1.1:2004 specifies the Test Suite Structure and Test Purposes for the H.225.0 protocol for Terminal, Gatekeeper and Gateway. The document is written for conformance testing, so its focus is on observable signalling behaviour rather than implementation design.

The scope covers procedures described in ITU-T Recommendation H.323 and ITU-T Recommendation H.225.0 as mapped in TS 101 883. The test methodology is based on ISO/IEC 9646-1, ISO/IEC 9646-2 and ISO/IEC 9646-3, which means the document is intended to support formal conformance test development.

The document is organized around:

• Clause 1, which states the scope
• Clause 2, which lists the references
• Clause 3, which defines terms and abbreviations
• Clause 4, which describes the architecture and Test Suite Structure
• Clause 5, which defines the Test Purposes and their naming and structure

What are the key requirements of SIST-TS TS 101 804-2 V1.1.1:2004?

SIST-TS TS 101 804-2 V1.1.1:2004 is mainly a test specification, so its key content is the way it organizes conformance checks and the behaviours it expects from the Implementation Under Test (IUT). The practical result is a structured set of test purposes that can be turned into test cases and executed against Terminal, Gatekeeper and Gateway roles.

Architecture and test grouping

Clause 4.1 places the items to be tested in a packet-based network using LAN with TCP/IP. Clause 4.2 then splits the Test Suite Structure into two protocol groups: RAS and BCC. RAS is further divided into Gatekeeper Discovery Request (GDR), Registration (REG), Unregistration (URG) and Request In Progress (RIP), while BCC is divided into Phase A and Phase E.

This matters because a test program can be selected by protocol, process and test type. The document also separates each group into valid (V), inopportune (I) and syntactically invalid (S) cases, so a lab can check normal operation, unexpected messages and malformed messages separately.

Test purpose identification and state model

Clause 5.1.1 defines the TP naming convention, which combines the IUT type, protocol, process, test type and a sequence number. Clause 5.1.2 says the BCC call states follow ITU-T Recommendation Q.931 for the user side.

In practice, this gives every test a traceable label and ties BCC checks to the expected call-state machine. That helps test engineers map results back to protocol behaviour and state transitions.

RAS behaviour under test

Clause 5.2.1 covers RAS test purposes for both Endpoint (TE) and Gatekeeper (GK). The TE cases check discovery, registration, unregistration and RIP handling, while the GK cases check how a gatekeeper responds to the same exchanges.

The RAS tests focus on whether the IUT:

• sends or accepts GRQ, RRQ and URQ messages in the expected situations
• reacts to GCF, GRJ, RCF, RRJ, UCF, URJ and RIP messages correctly
• handles retransmission and timer expiry, including repeated GRQ, RRQ and URQ attempts
• changes behaviour when registration is required, already completed, or no longer valid

For a reader, this means the document checks the life cycle of gatekeeper discovery, endpoint registration and unregistration, not just single messages.

BCC call setup and release behaviour

Clause 5.2.2 covers BCC for Endpoint (TE), Gatekeeper (GK) and Destination Gatekeeper (DGK). Phase A addresses call setup, and Phase E addresses call termination.

The setup tests check how the IUT handles SETUP, CALL PROCEEDING, ALERTING, CONNECT and RELEASE COMPLETE messages across states such as U0, U1, U2, U3, U4, U7, U9 and U10. They also check address handling, including E.164, H323-ID, URL-ID, transportID, email-ID and partyNumber alias addresses, plus numbering plan identification handling.

The release tests check how the IUT ends a call, closes signalling and returns to the Null call state. Timers T303 and T301 are part of these checks, so the document is not only about message content but also about retry and timeout behaviour.

Error handling

The document also gives many test purposes for inopportune and syntactically invalid messages in both RAS and BCC. These cover unknown message types, missing mandatory information elements, out-of-sequence elements, content errors, dummy call references and invalid protocol discriminator or call reference formats.

This matters in practice because conformance is not only about happy-path signalling. A compliant implementation also needs to reject malformed input or unexpected signalling in a controlled way.

What terms does SIST-TS TS 101 804-2 V1.1.1:2004 define?

• Basic Call Control (BCC) - The signalling protocol associated with DSS1 - ISDN basic call control procedures of ITU-T Q.931.
• Registration, Admission and Status (RAS) - The H.225.0 signalling area used for gatekeeper discovery, registration, admission and related control procedures.
• Implementation Under Test (IUT) - The endpoint, gatekeeper, gateway or destination gatekeeper being tested.
• Test Suite Structure (TSS) - The way the tests are grouped by protocol, process and test type.
• Test Purpose (TP) - A non-formal test description, mainly in text, that can be used as a basis for a formal test suite.
• Protocol Implementation Conformance Statement (PICS) - The feature statement used to select which test purposes apply to an implementation.
• Abstract Test Suite (ATS) - The formal test suite that can be derived from the test purposes, typically in TTCN.
• Test and Test Control Notation (TTCN) - The notation referenced for formalizing the test cases.

Who uses SIST-TS TS 101 804-2 V1.1.1:2004?

SIST-TS TS 101 804-2 V1.1.1:2004 is used by engineers and test labs that need to verify H.225.0 signalling in Terminal, Gatekeeper and Gateway products. It is also relevant to quality managers who need a conformance basis for acceptance testing and to buyers or integrators comparing interoperability claims.

In practice, it supports:

• conformance test design
• interoperability verification
• protocol implementation validation
• lab test planning against PICS-selected features
• review of endpoint, gatekeeper and gateway signalling behaviour in packet-based networks

Which standards are used with SIST-TS TS 101 804-2 V1.1.1:2004?

• ETSI TS 101 883 - Provides the TIPHON technology mapping used as the basis for the procedures covered here.
• ITU-T Recommendation H.323 - Supplies the framework and wire-protocol context for multiplexed call signalling transport.
• ITU-T Recommendation H.225.0 - Defines the call signalling and media stream packetization procedures under test.
• ETSI TS 101 804-1 - Provides the H.225.0 PICS proforma used to select and interpret the test purposes.
• ITU-T Recommendation Q.931 - Supplies the user-side call state model used for BCC behaviour.
• ISO/IEC 9646-1 - Gives the general conformance testing concepts and framework.
• ISO/IEC 9646-2 - Defines Abstract Test Suite specification methods.
• ISO/IEC 9646-3 - Defines TTCN, the notation referenced for formal test development.
• ETSI TS 101 804-3 - The companion part that contains the ATS and PIXIT proforma for the same scope.

What does the SIST-TS TS 101 804-2 V1.1.1:2004 document contain?

The document contains architecture descriptions, a test structure and a large set of textual test purposes. Figure 1 shows the network architecture, and Figure 2 shows the protocol architecture for RAS and BCC over UDP/TCP/IP.

Clause 5 includes Table 1 for the TP naming convention and Table 2 for the internal structure of a TP. The body of clause 5 then lists test purposes for RAS and BCC, organized by IUT type and by valid, inopportune and syntactically invalid behaviour.

The detailed test purposes cover discovery, registration, unregistration, call setup, call termination, timer expiry and error handling. The document also includes a short document history record.

SLOVENSKI STANDARD
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON), 3.
izdaja - Specifikacija tehnološke ustreznosti - 2. del: Specifikacija za preskušanje
skladnosti H.225.0 - Zgradba preskušalnega niza in nameni preskušanja (TSS&TP)
- Specifikacija za terminal, vratarja in prehod
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON)
Release 3; Technology compliance specifications; Part 2: H.225.0 conformance test
specifications; Test Suite Structure and Test Purposes (TSS&TP) specification for
Terminal, Gatekeeper and Gateway
Ta slovenski standard je istoveten z: TS 101 804-2 Version 1.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON) Release 3;
Technology compliance specifications;
Part 2: H.225.0 conformance test specifications;
Test Suite Structure and Test Purposes (TSS&TP)
specification for Terminal, Gatekeeper and Gateway

2 ETSI TS 101 804-2 V1.1.1 (2002-02)

Reference
DTS/TIPHON-06016-2
Keywords
gatekeeper, gateway, H.323, IP, multimedia,
supplementary service, terminal, testing,
TSS&TP, TTCN, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
[e-mail]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2001.
All rights reserved.
ETSI
3 ETSI TS 101 804-2 V1.1.1 (2002-02)
Contents
Intellectual Property Rights.4
Foreword.4
1 Scope.5
2 References.5
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.6
4 Architecture and Test Suite Structure (TSS).7
4.1 Architecture.7
4.2 Test Suite Structure (TSS).8
5 Test Purposes (TP).9
5.1 Introduction.9
5.1.1 TP naming convention.9
5.1.2 State Definitions.9
5.1.2.1 State definition for BCC.9
5.1.3 TP structure.9
5.1.4 Test strategy.10
5.2 TPs for H.225 .10
5.2.1 RAS.10
5.2.1.1 Endpoint (TE).10
5.2.1.1.1 Gatekeeper discovery request (GDR).10
5.2.1.1.2 Registration Phase (REG).11
5.2.1.1.3 Unregistration Phase (URG).12
5.2.1.1.4 Request In Progress (RIP) .12
5.2.1.2 Gatekeeper.13
5.2.1.2.1 Gatekeeper discovery request (GDR).13
5.2.1.2.2 Registration Phase (REG).14
5.2.1.2.3 Unregistration Phase (URG).15
5.2.1.2.4 Request In Progress (RIP) .15
5.2.2 BCC.16
5.2.2.1 Endpoint (TE).16
5.2.2.1.1 PHA - Call setup.16
5.2.2.1.2 PHE - Call termination .20
5.2.2.2 Gatekeeper (GK).22
5.2.2.2.1 Phase A - Call setup .22
5.2.2.2.2 Phase E - Call termination.27
5.2.2.3 Destination GK (DGK) .29
5.2.2.3.1 Phase A - Call setup .29
5.2.2.3.2 Phase E - Call termination.34
History .36

ETSI
4 ETSI TS 101 804-2 V1.1.1 (2002-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
The present document is part 2 of a multi-part deliverable covering the H225.0 protocol for Terminal, Gatekeeper and
Gateway as identified below:
Part 1: "Revision/update of H.225.0 Protocol Implementation Conformance Statement (PICS) proforma
specification for Terminal, Gatekeeper and Gateway";
Part 2: "H.225.0 conformance test specifications; Test Suite Structure and Test Purposes (TSS&TP)
specification for Terminal, Gatekeeper and Gateway";
Part 3: "H.225.0 conformance test specifications; Abstract Test Suite (ATS) and PIXIT proforma specification
for Terminal, Gatekeeper and Gateway".

ETSI
5 ETSI TS 101 804-2 V1.1.1 (2002-02)
1 Scope
The present document specifies the Test Suite Structure and Test Purposes (TSS&TP) for the H225.0 protocol for
Terminal, Gatekeeper and Gateway.
The objective of the present document is to provide conformance tests that give a greater probability of
inter-operability. The TSS&TP specification covers the procedures described in ITU-T Recommendation H.323 [2] and
ITU-T Recommendation H.225.0 [3] as specified in TS 101 883 [1].
NOTE: The present document may not cover all requirements of the current version of TS 101 883 [1], as that
mapping document has not yet reached a sufficiently stable state. Further versions of this TSS&TP
specification will follow TS 101 883 [1] completely and cover all its requirements.
The ISO standard for the methodology of conformance testing (ISO/IEC 9646-1 [6], ISO/IEC 9646-2 [7] and
ISO/IEC 9646-3 [8]) is used as basis for the test methodology.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
[1] ETSI TS 101 883: "Telecommunications and Internet protocol Harmonization Over Networks
(TIPHON) Release 3; Technology Mapping; Implementation of TIPHON architecture using
H.323".
[2] ITU-T Recommendation H.323 (2000): "Framework and wire-protocol for multiplexed call
signalling transport".
[3] ITU-T Recommendation H.225.0 (2000): "Call signalling protocols and media stream
packetization for packet-based multimedia communication systems".
[4] ETSI TS 101 804-1 (V1.1.1): "Telecommunications and Internet Protocol Harmonization Over
Networks (TIPHON) Release 3; Release PICS; Revision/Update of H.225.0 PICS for Terminal,
Gatekeeper and Gateway".
[5] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call
control".
[6] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 1: General concepts".
[7] ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 2: Abstract Test Suite specification".
[8] ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN)".
[9] ETSI TS 101 804-3: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Technology Compliance Specifications; Part 3: H.225.0 Conformance Test
Specifications; Abstract Test Suite (ATS) and PIXIT proforma for Terminal, Gatekeeper and
Gateway".
ETSI
6 ETSI TS 101 804-2 V1.1.1 (2002-02)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions defined in ITU-T Recommendation H.323 [2],
ITU-T Recommendation H.225.0 [3], ISO/IEC 9646-1 [6], ISO/IEC 9646-2 [7] and ISO/IEC 9646-3 [8] and the
following apply:
Basic Call Control (BCC): signalling protocol associated with the DSS1 - ISDN Basic Call control procedures of ITU-
T recommendation Q.931
inopportune: test purpose covering a signalling procedure where an inopportune message (type of message not
expected in the IUT current state) is sent to the IUT
syntactically invalid: test purpose covering a signalling procedure where a valid (expected in the current status of the
IUT) but not correctly encoded (unknown or incorrect parameter values) message is sent to the IUT, which shall react
correctly and eventually reject the message
test purpose: non-formal test description, mainly using text
NOTE: This test description can be used as the basis for a formal test specification (e.g. Abstract Test Suite in
TTCN). See ISO/IEC 9646-2.
valid: test purpose covering a signalling procedure where all the messages sent to or received from the IUT are valid
(expected in the current status of the IUT) and correctly encoded
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACF Admission ConFirm
ADM ADMission
APDU Application Protocol Data Unit
ARJ Admission ReJect
ARQ Admission ReQuest
ATS Abstract Test Suite
BCC Basic Call Control
BCF Bandwidth ConFirm
BRJ Bandwidth ReJect
BRQ Bandwidth ReQuest
DCF Disengage ConFirm
DGK Destination GateKeeper
DRJ Disengage ReJect
DRQ Disengage ReQuest
GCF Gatekeeper ConFirm
GDR Gatekeeper Discovery Request
GK GateKeeper
GRJ Gatekeeper ReJect
GRQ Gatekeeper ReQuest
GW GateWay
I Inopportune
IUT Implementation Under Test
LAN Local Area Network
LCF Location ConFirm
LRJ Location ReJect
LRQ Location ReQuest
MCU Multipoint Control Unit
MSI Manufacturer Specific Information
PDU Protocol Data Unit
PER Packed Encoding Rules
ETSI
7 ETSI TS 101 804-2 V1.1.1 (2002-02)
PHA PHase A: call setup signalling procedures
PHE PHase E: call termination signalling procedures
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
RAS Registration, Admission and Status
RCF Register ConFirm
REG REGistration
RIP Request In Progress
RRJ Register ReJect
RRQ Register ReQuest
S Syntactically invalid
STA STAtus
TCP Transmission Control Protocol
TE TErminal
TP Test Purpose
TSS Test Suite Structure
TTCN Testing and Test Control Notation
UCF Unregistration ConFirm
UDP User Datagram Protocol
URJ Unregistration ReJect
URQ Unregistration ReQuest
V Valid
4 Architecture and Test Suite Structure (TSS)
4.1 Architecture
The items to be tested can be one of the following: Terminal, Gatekeeper, Gateway or Destination Gatekeeper. They are
a part of a Packet Based Network using a LAN with TCP/IP (see figure 1).
Destination
Terminal Gatekeeper
Gatekeeper
LAN
TCP/IP
Gateway
Figure 1: network architecture
The Implementation Under Test (IUT, see ISO/IEC 9646-1 [6]) for which this Test purpose specification applies
consists of the H.225.0 terminal to gatekeeper signalling (RAS) and the H.225.0 call signalling (BCC) (see figure 2).
ETSI
8 ETSI TS 101 804-2 V1.1.1 (2002-02)
IUT
H.225.0 H.225.0
Terminal to Gatekeeper call signalling
signalling
RAS BCC
UDP TCP
IP
(LAN)
Figure 2: protocol architecture
4.2 Test Suite Structure (TSS)
The Test Suite Structure follows the network architecture and the protocol architecture. The first level is divided into
2 groups according to the protocol: RAS and BCC.
For the RAS protocol, each process is included in a corresponding sub-group: Gatekeeper Discovery Request (GDR),
Registration (REG), Administration (ADM), LOC (Location), BND (Bandwidth), URG (Unregistration), DRG
(Disengage) and Status (STA).
For BBC, 2 call phases are considered: phase A and phase E, each one forming a sub-group of BCC.
Finally each group is divided in 3 subgroups:
• V containing the valid test purposes;
• I containing the inopportune test purposes;
• S containing the invalid test purposes.
Protocol IUT type Process/ Test type
Phase
RAS
Endpoint (TE)
GDR
REG
URG
RIP
Gatekeeper (GK)
GDR
REG
URG
RIP
BCC
Endpoint (TE)
PHA V - I - S
PHE V - I - S
Gatekeeper (GK)
PHA V - I - S
PHE V - I - S
Destination
Gatekeeper (DGK)
PHA V - I - S
PHE V - I - S
ETSI
9 ETSI TS 101 804-2 V1.1.1 (2002-02)
5 Test Purposes (TP)
5.1 Introduction
5.1.1 TP naming convention
Table 1: TP identifier naming convention scheme
Identifier: ____
= type of IUT TE = terminal or endpoint
GK, DGK
 RAS or BCC
  if RAS: GDR, REG, URG or RIP
if BCC: PHA or PHE
  V, I or S
= sequential number (01-99)

5.1.2 State Definitions
5.1.2.1 State definition for BCC
For the BCC protocol, the call states of ITU-T Recommendation Q.931 [5] for the user side are followed.
5.1.3 TP structure
Each TP has been written in a manner, which is consistent with all other TPs. The intention of this is to make the TPs
more readable and checkable. A particular structure has been used and this is illustrated in table 2. This table should be
read in conjunction with any TP, i.e. use a TP as an example to fully understand the table.
Table 2: Structure of a single TP for H.225
TP part Text Example
Header tab TE_RAS_GDR_I_01 (see table 1)
 clause 0.0.0

Stimulus Ensure that the IUT
in the idle state
having sent a XXX message
see below for message structure on receipt of a YYY message
or to request a .
Reaction  sends, does, etc.
 .
if the action is sending
see below for message structure
, etc.
Message GRQ, RRQ, SETUP, FACILITY,
structure message containing a CONNECT, .
a)
RasAddress, callServices, …
b) or Bearer capability, Facility, .
encoded as or including
and back to a or b,
NOTE: Text in italics will not appear in TPs and text between <> is filled in for each TP and may differ from one
TP to the next.
ETSI
10 ETSI TS 101 804-2 V1.1.1 (2002-02)
5.1.4 Test strategy
As the base standard ITU-T Recommendation H.225.0 [3] contains no explicit requirements for testing, the TPs were
generated as a result of an analysis of the base standard and the corresponding PICS proforma.
The TPs are only based on conformance requirements related to the externally observable behaviour of the IUT, over
the TCP or UDP interface, and are limited to conceivable situations to which a real implementation is likely to be faced.
As indicated by the existence of the part 3 of this multi-part standard [9] (see foreword), the intention is to derive the
test purposes to an abstract test suite in TTCN. Consequently the test purposes are written in a manner, which fit the
TTCN methodology, and will consist of the textual documentation of the test cases.
5.2 TPs for H.225
All PICS items referred to in this clause are as specified in TS 101 804-1 [4].
Unless specified otherwise, the messages indicated are valid and contain at least the mandatory parameters and possibly
optional parameters.
5.2.1 RAS
5.2.1.1 Endpoint (TE)
5.2.1.1.1 Gatekeeper discovery request (GDR)
NOTE: When multicast or unicast is not specified, both modes are accepted for GRQ message.
Selection: IUT supports Discovery messages, PICS T_RM1

RAS_TE_GDR_V_01 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT having sent a valid GRQ message in unicast mode, with the gatekeeper Identifier set to a value
other than NULL, on receipt of a GCF message,
considers to have completed the GKDiscovery procedure successfully.
RAS_TE_GDR_V_02 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT having sent a valid GRQ message in multicast mode to the well-known Discovery Multicast
Address and gatekeeperIdentifier missing or set to NULL, on receipt of a GCF message,
considers to have completed its GKDiscovery procedure successfully.
RAS_TE_GDR_V_03 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT having sent a valid GRQ message in multicast mode to the well-known Discovery Multicast
Address and with gatekeeperIdentifier missing or set to NULL, on receipt of multiple GCF message from different
gatekeepers,
considers to have completed its GKDiscovery procedure successfully with one of them.
RAS_TE_GDR_V_04 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT having sent a valid GRQ message, on receipt of a GRJ message with a value in the rejectreason
field,
does not consider to have completed its GKDiscovery procedure successfully.
RAS_TE_GDR_V_05 clause 7.2.1 [2], clause 7.8 [3], clause 7.19 [3]
Ensure that the IUT having sent a GRQ message, upon the first expiry of default timer for GRQ message,
sends the same GRQ message again.
RAS_TE_GDR_V_06 clause 7.2.1 [2], clause 7.8 [3], clause 7.19 [3]
Ensure that the IUT having sent a GRQ message for the second time, on receipt of GCF message before the expiry of
timer for a GRQ message,
considers to have completed its GKDiscovery procedure successfully.
ETSI
11 ETSI TS 101 804-2 V1.1.1 (2002-02)
RAS_TE_GDR_V_07 clause 7.2.1 [2], clause 7.8 [3], clause 7.19 [3]
Ensure that the IUT having already sent a GRQ message for two times,
on the expiry of timer for a GRQ message, does not send the same GRQ again.
5.2.1.1.2 Registration Phase (REG)
RAS_TE_REG_V_01 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT before attempting a call,
sends a RRQ message.
RAS_TE_REG_V_02 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT, having completed the GKDiscovery procedure, before attempting a call,
sends a RRQ message with discoveryComplete field set to TRUE.
RAS_TE_REG_V_03 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT having sent a valid RRQ message on receipt of a RCF message,
considers to have completed its Registration procedure successfully.
RAS_TE_REG_V_04 clause 7.2.1 [2], clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT having sent a valid RRQ message on receipt of a RRJ message,
restarts a gatekeeper discovery procedure.
RAS_TE_REG_V_05 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT which is able to supply Q.931 IRR message when requested sends a RRQ message with the
withsupplyUUIE element set to TRUE and on receipt of a RCF message with the alias address for the endpoint,
considers to have completed its Registration procedure successfully.
RAS_TE_REG_V_06 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT which is not already discovered the Gatekeeper, having sent a RRQ message with the discovery
element set to FALSE on receipt of a RCF message,
considers to have completed its Registration procedure successfully.
RAS_TE_REG_V_07 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT which is not already discovered the Gatekeeper, having sent a RRQ message with the discovery
element set to FALSE on receipt of a RRJ message with the reason code of discovery required,
starts a gatekeeper discovery procedure.
RAS_TE_REG_V_08 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT whose registration has aged out, having sent a RRQ message with the discovery element set to
FALSE on receipt of a RRJ message with the reason code of discovery required,
starts a gatekeeper discovery procedure.
RAS_TE_REG_V_09 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT having sent a RRQ on receipt of a RRJ message with the reason alias address already registered,
sends a GRQ message again with a different alias address.
RAS_TE_REG_V_10 clause 7.2.2 [2], clause 7.9 [3], clause 7.19 [3]
Ensure that the IUT having sent a RRQ message, upon the first expiry of timer for a RRQ message,
sends a RRQ message again.
RAS_TE_REG_V_11 clause 7.2.2 [2], clause 7.9 [3], clause 7.19 [3]
Ensure that the IUT having sent a RRQ message for the second time, on receipt of RCF message before the expiry of
timer for a RRQ message,
considers to have completed its Registration procedure successfully.
RAS_TE_REG_V_12 clause 7.2.2 [2], clause 7.9 [3], clause 7.19 [3]
Ensure that the IUT having already sent a RRQ message for two times, upon the second expiry of timer for a RRQ
message,
does not send a RRQ message.
ETSI
12 ETSI TS 101 804-2 V1.1.1 (2002-02)
5.2.1.1.3 Unregistration Phase (URG)
NOTE: The IUT needs to have completed the registration procedure successfully for executing the following Test
purposes.
RAS_TE_URG_V_01 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT having sent a valid URQ message on receipt of an UCF,
considers to be unregistered.
RAS_TE_URG_V_02 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT, on receipt of a valid URQ message,
sends an UCF message and considers to be unregistered.
RAS_TE_URG_V_03 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT which is not registered, on receipt of a valid URQ message,
sends an URJ with the reason for rejection in the reject reason field as notCurrentlyRegistered.
RAS_TE_URG_V_04 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT, when the call is active, on receipt of a valid URQ message,
sends an URJ with the reason for rejection in the reject reason as callInProgress.
RAS_TE_URG_V_05 clause 7.2.2 [2], clause 7.10 [3], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, upon the first expiry of the timer for a URQ message,
sends the same URQ message again.
RAS_TE_URG_V_06 clause 7.2.2 [2], clause 7.10 [3], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message for the second time, on receipt of an UCF message before the
expiry of the timer for a URQ message,
considers to be unregistered.
RAS_TE_URG_V_07 clause 7.2.2 [2], clause 7.10 [3], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message for two times, upon the expiry of the timer for a URQ message,
does not send the same URQ message again.
RAS_TE_URG_V_08 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT, having sent an URQ message on receipt of an URJ with the field altGKInfo,
sends an URQ to a gatekeeperIdentifier from altGKInfo received in the URJ.
5.2.1.1.4 Request In Progress (RIP)
RAS_TE_RIP_V_01 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid GRQ message in multicast mode, on receipt of a RIP message,
restarts the timer and counter for the GRQ message.
RAS_TE_RIP_V_02 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid GRQ message in multicast mode, upon the expiry of the RIP delay,
sends a GRQ message again and restarts the timer.
RAS_TE_RIP_V_03 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid GRQ message in multicast mode, on receipt of the GCF message before the
expiry of the RIP delay,
considers to have completed the GKDiscovery procedure successfully.
RAS_TE_RIP_V_04 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid GRQ message in multicast mode, upon the first expiry of the RIP delay and on
receipt of another RIP message,
restarts the timer and counter for the GRQ message.
RAS_TE_RIP_V_05 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid RRQ message, on receipt of a RIP message,
restarts the timer and counter for the RRQ message.
ETSI
13 ETSI TS 101 804-2 V1.1.1 (2002-02)
RAS_TE_RIP_V_06 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid RRQ message, upon the expiry of the RIP delay,
sends a RRQ message again and restarts the timer.
RAS_TE_RIP_V_07 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid RRQ message, on receipt of the RCF message before the expiry of the RIP
delay,
considers to have completed the Registration procedure successfully.
RAS_TE_RIP_V_08 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid RRQ message, upon the first expiry of the RIP delay and on receipt of another
RIP message,
restarts the timer and counter for the RRQ message.
RAS_TE_RIP_V_09 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, on receipt of a RIP message,
restarts the timer and counter for the URQ message.
RAS_TE_RIP_V_10 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, upon the expiry of the RIP delay,
sends an URQ message again and restarts the timer.
RAS_TE_RIP_V_11 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, on receipt of the UCF message before the expiry of the RIP
delay,
considers to be unregistered.
RAS_TE_RIP_V_12 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, upon the first expiry of the RIP delay, sends an URQ message
and on receipt of another RIP message,
restarts the timer and counter for the URQ message.
5.2.1.2 Gatekeeper
5.2.1.2.1 Gatekeeper discovery request (GDR)
RAS_GK_GDR_V_01 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT on receipt of a valid GRQ message in unicast mode, with the gatekeeper Identifier set to a value
other than NULL, when it wants this endpoint to register with it,
sends a GCF message.
RAS_GK_GDR_V_02 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT on receipt of a valid GRQ message in multicast mode to the well-known Discovery Multicast
Address and gatekeeperIdentifier missing or set to NULL, when it wants this endpoint to register with it,
sends a GCF message.
RAS_GK_GDR_V_03 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT on receipt of a GRQ message in unicast mode, when it does not want this endpoint to register with
it,
sends a GRJ message.
RAS_GK_GDR_V_04 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT on receipt of a GRQ message in multicast mode, when it does not want this endpoint to register
with it,
sends no answer.
RAS_GK_GDR_V_05 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT on receipt of a GRQ message concerning an endpoint having already discovered it,
sends a GCF message.
RAS_GK_GDR_V_06 clause 7.2.1 [2], clause 7.8 [3]
Ensure that the IUT on receipt of a GRQ message concerning an endpoint having already registered,
sends a GCF message.
ETSI
14 ETSI TS 101 804-2 V1.1.1 (2002-02)
5.2.1.2.2 Registration Phase (REG)
RAS_GK_REG_V_01 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a valid RRQ message, when it wants this endpoint to register with it,
sends a RCF message.
RAS_GK_REG_V_02 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a valid RRQ message, when it does not want this endpoint to register with it,
sends a RRJ message.
RAS_GK_REG_V_03 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a RRQ message with the willsupplyUUIE element set to TRUE,
sends a RCF message.
RAS_GK_REG_V_04 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a RRQ message with the discovery element set to TRUE immediately after
completing GKDiscovery procedure,
sends a RCF message.
RAS_GK_REG_V_05 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a RRQ message,
sends a RCF message without the timetoLive value indicating that the Gatekeeper does not support KeepAlive
mechanism.
RAS_GK_REG_V_06 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a RRQ message,
sends a RCF message with the timetoLive value indicating that the Gatekeeper supports KeepAlive mechanism.
RAS_GK_REG_V_07 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a RRQ message from the Endpoint which is already registered to this gatekeeper with
the KeepAlive element set to TRUE before the expiry of the timetolive timer,
sends a RCF message.
RAS_GK_REG_V_08 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT, which has not already discovered the Gatekeeper, on receipt of a RRQ message with the discovery
element set to FALSE,
sends a RRJ message with the reason code of discovery required.
RAS_GK_REG_V_09 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT, on receipt of a lightweight RRQ message before the expiration of the time-to live,
reset the time to live timer.
RAS_GK_REG_V_10 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT, on receipt of a full RRQ message after the expiration of the time-to live,
sends a RCF message.
RAS_GK_REG_V_11 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of a lightweight RRQ message after the time-to-live has expired,
sends a RRJ message with the reason code fullRegistrationRequired or discovery required.
RAS_GK_REG_V_12 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the IUT on receipt of an ARQ message after the time-to-live has expired,
sends an ARJ message with the reject reason callerNotRegistered or CalledPartyNotRegistered.
RAS_GK_REG_V_13 clause 7.2.2 [2], clause 7.9 [3]
Ensure that the on receipt of a RRQ message with the alias address of an endpoint which is already registered with a
different transport address,
sends a RRJ message.
ETSI
15 ETSI TS 101 804-2 V1.1.1 (2002-02)
5.2.1.2.3 Unregistration Phase (URG)
RAS_GK_URG_V_01 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT on receipt of a valid URQ message,
sends an UCF.
RAS_GK_URG_V_02 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT on receipt of a URQ message from an Endpoint which is not registered,
sends an URJ.
RAS_GK_URG_V_03 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT on receipt of an URQ message when the call is active,
sends a URJ with the reason for rejection in the reject reason as callInProgress.
RAS_GK_URG_V_04 clause 7.2.2 [2], clause 7.10 [3]
Ensure that the IUT having sent an URQ message to the Endpoint on receipt of a UCF message,
considers that the terminal is not registered any more.
RAS_GK_URG_V_05 clause 7.2.3 [2], clause 7.13 [3], clause 7.19 [3]
Ensure that the IUT having sent a URQ message, upon the first expiry of default timer for a URQ message,
sends the same URQ message again.
RAS_GK_URG_V_06 clause 7.2.3 [2], clause 7.13 [3], clause 7.19 [3]
Ensure that the IUT having sent a URQ message for the second time, on receipt of UCF message before the second
expiry of timer for a URQ message,
considers that the terminal is not registered any more.
RAS_GK_URG_V_07 clause 7.2.3 [2], clause 7.13 [3], clause 7.19 [3]
Ensure that the IUT having already sent a URQ message for two times, upon the second expiry of timer for a URQ
message,
does not send the URQ message again.
5.2.1.2.4 Request In Progress (RIP)
RAS_GK_RIP_V_01 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, on receipt of a RIP message,
restarts the timer and counter for the URQ message.
RAS_GK_RIP_V_026 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, upon the expiry of the RIP delay,
sends a URQ message again and restarts the timer.
RAS_GK_RIP_V_03 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, on receipt of the UCF message before the expiry of the RIP
delay,
considers that the terminal is not registered any more.
RAS_GK_RIP_V_04 clause 7.2 [2], clause 7.19 [3]
Ensure that the IUT having sent a valid URQ message, upon the first expiry of the RIP delay, sends an URQ and on
receipt of another RIP message,
restarts the timer and counter for the URQ message.
ETSI
16 ETSI TS 101 804-2 V1.1.1 (2002-02)
5.2.2 BCC
5.2.2.1 Endpoint (TE)
5.2.2.1.1 PHA - Call setup
5.2.2.1.1.1 Valid
BCC_TE_PHA_V_01 clauses 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP message,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_02 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the sourceAddress field with an E.164 type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_03 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the sourceAddress field with a H323-ID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_04 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the sourceAddress field with an URL-ID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_05 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the sourceAddress field with a transportID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_06 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the sourceAddress field with an email-ID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_07 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the sourceAddress field with a partyNumber type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_08 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the destinationAddress field with an E.164 type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_09 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the destinationAddress field with a H323-ID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
ETSI
17 ETSI TS 101 804-2 V1.1.1 (2002-02)
BCC_TE_PHA_V_10 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the destinationAddress field with an URL-ID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_11 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the destinationAddress field with a transportID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_12 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the destinationAddress field with an email-ID type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_13 clauses 7.1.3, 8.1.5, 8.1.6 [2], clauses 7.1, 7.3.10 [3]
Ensure that the IUT in the Null call state U0, on receipt of a SETUP containing an User-to-user information element
including the destinationAddress field with a partyNumber type AliasAddress,
sends any of a CALL PROCEEDING, ALERTING or CONNECT message and enters the relevant call state
Incoming Call Proceeding U9, Call Received U7 or Active call state U10.
BCC_TE_PHA_V_14 clauses 8.1.
...