Open

USER GUIDE 1 (40)

Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

User Guide for H.323 Gateway

Copyright

© Copyright Telefonaktiebolaget LM Ericsson, 2006

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design, and manufacturing.

Ericsson shall have no liability for any errors or damages of any kind resulting
from the use of this document.

Abstract

The H.323 Gateway function enables Engine Integral Network to serve as an

H.323 gateway providing connectivity, on both, signalling and bearer level,
between H.323 networks and ISUP, BICC, SIP, SIP-T or H.323 networks.

Contents
1 General................................................................................................2
1.1 Revision History ..................................................................................2
1.2 Glossary ..............................................................................................2
1.3 Scope ..................................................................................................4
1.4 Introduction..........................................................................................7
2 How to Use ........................................................................................18
3 Configuration .....................................................................................30
4 References ........................................................................................35
Open
USER GUIDE 2 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

1 General
1.1 Revision History

Version
Date Comments
Signature
A This is a new document.
2005-09-16
ETKTPZ
PB1 Document is updated to reflect changes introduced as
2006-01-27 part of CN-G1:
- Possibility to add/remove destination IP addresses
to/from IPG during operation for both types of RHOST.
- Possibility to define local and remote port number for
call signalling for RHOST of type gateway when
corresponding IPG contains more than one destination IP
address.

1.2 Glossary

1.2.1 Concepts

Engine Integral Network

Engine Integral Network is a server-based multi-service network solution

providing a full set of telephony services. It comprises the following principal
network elements:

• Telephony Server (TeS)

• Multi-Service Gateway (MSG)
• Multi-Service Core Switch
• Management Solution (MN-OSS)
• Engine Access Ramp (EAR)

Telephony Server

The Telephony Server controls the Media Gateway (MGW) application in the
MSG in order to provide support for voice and narrowband data services. It
comprises three main parts:

• Call Control Function (CCF)

• Media Gateway Inter-connect (MGW-IC)
• Mediation Logic (ML).

Call Control Function

The CCF is based on the AXE platform and it handles call control and
telephony functions such as termination of call control signalling, number and
routing analysis, charging analysis, supplementary services, etc.
Open
USER GUIDE 3 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Server port

Server port is a TCP/UDP port used by the server to listen for incoming
requests.

Client port

Client port is a TCP/UDP port used by the client to initiate a request to server.

Well-known port

A port number that has been allocated by an international authority in charge

of the assignment of port numbers for a particular networking protocol and
related transport protocol. This number is guaranteed to be unique in the
context of the respective protocol. The well-known port number for
H.225.0/RAS signalling over UDP is 1719 while the well-known port number
for H.225.0/call signalling over TCP is 1720.

Inbound H.323 call

A call that enters the H.323 network through an H.323 gateway.

Outbound H.323 call

A call that leaves the H.323 network through an H.323 gateway.

Endpoint

An endpoint is an H.323 device that can call and be called. It generates

and/or terminates information streams. H.323 gateway and terminal are
endpoints.

H.323 Gateway

An H.323 gateway is an endpoint in H.323 network providing real time, two-

way communication between H.323 network on one side and switched circuit
or packet based network on the other side.

Gatekeeper

The gatekeeper is an H.323 entity providing address translation and

controlling access to the H.323 network for endpoints. In addition, it can
provide services such as bandwidth management and gateways location to
endpoints.

H.323 entity

H.323 entity is any H.323 component, including endpoints and gatekeepers.

H.323 zone
Open
USER GUIDE 4 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

H.323 zone is the collection of all H.323 entities managed by a single

gatekeeper. A zone has one and only one gatekeeper. It may be independent
of network topology and may be comprised of multiple network segments
connected using routers or other devices.

Administrative domain

An administrative domain is a collection of H.323 entities administered by one

administrative entity (such as one operator). An administrative domain can
consist of one or more gatekeepers (that is, one or more zones).

Transport Address

Transport address is a transport layer address of an H.323 entity consisting of

IP address and port number.

H.323

H.323 is an ITU-T recommendation describing structure and functioning of

packet-based multimedia communication systems. It is an umbrella
recommendation encompassing, among others, H.225.0 and H.245
recommendations.

H.225.0

H.225.0 is an ITU-T recommendation describing how audio, video, data, and

control information on a packet-based network can be managed to provide
conversational services in H.323 equipment.

H.245

H.245 is an ITU-T recommendation defining procedures to allow the

exchange of audiovisual and data capabilities, to request the transmission of
a particular audiovisual and data mode, to manage the logical channels used
to transport the audiovisual and data information, to establish which terminal
is the master terminal and which is the slave terminal for the purposes of
managing logical channels, to carry various control and indication signals, to
control the bit rate of individual logical channels and the whole multiplex, and
to measure the round trip delay, from one terminal to the other and back.

RAS

Registration, Admission and Status, a part of H.225.0 recommendation

describing procedures pertinent to exchange of registration, admission,
bandwidth change and status messages.

1.2.2 Abbreviations

ADI Adaptation Direction

BICC Bearer Independent Call Control

Open
USER GUIDE 5 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

CCF Call Control Function

COD Command Description

CP Central Processor

DTMF Dual Tone Multi-Frequency

EAR Engine Access Ramp

EIN Engine Integral Network

EM Extension Module

EP Endpoint

GARP Generic Application Resource Processor

GK Gatekeeper

GW Gateway

HW Hardware

ICMP Internet Control Message Protocol

IP Internet Protocol

IPG Internet Protocol Group

ISDN Integrated Services Digital Network

ISUP ISDN User Part

International Telecommunications Union -
ITU-T
Telecommunications
LHOST Local Host

MGW Media Gateway

MGW-IC Media Gateway Inter-connect

ML Mediation Logic

MN-OSS Management Solution

MSG Multi-Service Gateway

OPI Operational Instruction

Open
USER GUIDE 6 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

POD Printout Description

RAS Registration, Admission and Status

RHOST Remote Host

RP Regional Processor

RPB-S Regional Processor Buss of Serial type

RSU Regional Software Unit

SCTP Stream Control Transmission Protocol

SIP Session Initiation Protocol

SIP-T Session Initiation Protocol for Telephony

TCP Transmission Control Protocol

TeS Telephony Server

UDP User Datagram Protocol

VoIP Voice Over IP

1.3 Scope

This document provides a brief general overview of the H.323 Gateway

function applicable to Engine Integral Network. However, it focuses on
description of capabilities, operation and configuration of the call control
signalling component of the H.323 Gateway function applicable to CCF as
one of the components of Telephony Server. In addition, it explains
relationship between H.323 network setup and managed objects as building
blocks for configuration of call control signalling part of the H.323 Gateway.
Configuration of other TeS and EIN components, implementing bearer control
related part of the H.323 Gateway function, is out of the scope of this
document.

Complete operator procedure for handling of signalling part of the H.323

Gateway function is provided through the relevant Customer Documentation
(OPIs, ADIs, CODs, PODs). This document replaces neither operation and
maintenance documents nor Function Specifications.
Open
USER GUIDE 7 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

1.4 Introduction

1.4.1 General

The H.323 Gateway function enables interconnection with H.323 VoIP

networks, thus, providing a real time, bothway communication between H.323
network on one side and ISUP, BICC, SIP, SIP-T or H.323 network on the
other side. The function is invoked on a per call basis and enables voice,
voice-band data and T.38 fax inbound and outbound H.323 calls. Detailed list
of H.323 Gateway capabilities is provided in [FS1].

ISUP
network H.323
network
SIP/SIP-T
network EIN H.323
network
H.323
network H.323
BICC network
network

Figure 1. Supported interworking scenarios

The H.323 Gateway supports the following signalling protocols from H.323
family:

• H.225.0, comprising RAS and Call signalling

• H.245

While H.225.0 Call signalling and H.245 are used between TeS, as an
endpoint of gateway type, and peer endpoint (gateway, gatekeeper), H.225.0
RAS signalling is used exclusively between TeS and corresponding
gatekeeper. The H.323 Gateway function supports transfer of H.225.0 Call
signalling and H.245 signalling over TCP, while transfer of H.225.0 RAS
signalling is supported over UDP. For detailed protocol information, please,
refer to [PS1] and [PS2].

The H.323 Gateway supports non-call related and call related RAS signalling.
Non-call related RAS signalling constitutes procedures used to register and
unregister TeS, as an endpoint of gateway type, with the gatekeeper. In
addition, the gatekeeper can request unregistration of TeS using non-call
related RAS signalling.

Call related RAS signalling constitutes procedures to obtain admission for the
call from the gatekeeper, to request the gatekeeper to perform address
translation and to inform the gatekeeper of the call status or call release. The
gatekeeper can use RAS signalling to request call status or force call release.
Open
USER GUIDE 8 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Call signalling is used towards peer H.323 endpoint in order to establish and
release calls and to provide call status. Also, bearer can be established and
released using call signalling, in case remote peer supports such procedure.
Detailed call setup related information is available in [FS2].

H.245 signalling is used towards peer H.323 endpoint in order to establish,

modify and release bearer and to transfer DTMF digits out of band. For
detailed bearer setup related information, please, turn to [FS3].

The H.323 Gateway function supports simultaneous connection to multiple

H.323 networks each of which can comprise H.323 zones (controlled by the
gatekeeper) or only H.323 gateways. Two supported types of H.323 networks
are illustrated in Figure 2 and Figure 3. Other networks that TeS is
connected to are not presented in the figure for the reasons of simplicity.

It should be noted that this document is based on the assumption that

recommended configuration, in which connected H.323 network is actually an
administrative domain or its subset, is followed. Other configurations,
although possible, are considered neither as illustrational nor as good starting
point for understanding the function as aforementioned one.

GW
GW
GK

TeS
GW

GW

GK
GW

GW

H.323 network H.323 zone

Figure 2. H.323 network comprising H.323 zones

Open
USER GUIDE 9 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

GW
GW GW

TeS
GW
GW
GW

H.323 network

Figure 3. H.323 network comprising only H.323 gateways

Towards each H.323 network, TeS is acting as a separate endpoint of

gateway type. The H.323 Gateway function provides configuration of TeS on
an endpoint level, thus, enabling customized behavior per H.323 network.

1.4.2 Managed Object Model

Characteristics of the H.323 Gateway and connected H.323 networks have to

be configured in TeS. Managed objects model, used for this purpose, has to
be understood to perform this task correctly. The model, built using managed
objects as building blocks, is presented in Figure 4. In addition, managed
objects are described subsequently.
Open
USER GUIDE 10 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

N:1
DEVICE ROUTE

1:1

EP

1:1

1:1
IPG RHOST

M:N

1:1
IPPORT LHOST

1:1 1:1

IP EQM
CP
1:1

IP EM H.323 EM
RP

1:1 1:1
GARP HW

Figure 4. Managed objects model

Existing AXE concept of bothway routes is used by the H.323 Gateway

function for routing and analysis of incoming and outgoing calls. H.323
devices are pure software devices with no relation to hardware and their
connection to the H.323 route enables static allocation of call capacity to
particular route.

TeS, as H.323 gateway in an H.323 network, is internally represented by an

Endpoint (EP) object. One EP object is created for every H.323 network that
TeS is connected to, thus, enabling control of TeS’s behavior and its
identification in particular H.323 network.

Internet Protocol Group (IPG) is another ‘one per H.323 network’ object and
it enables definition of IP addresses of remote peers belonging to a particular
network. In addition to its numerical value, ‘source’ and/or ‘destination’
property can be defined for each IP address. Based on this property, IPG is
internally divided in two sub-groups: source and destination IP addresses.
Note that at least one destination IP address has to be defined in an IPG
while RHOST is connected to it.
Open
USER GUIDE 11 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

For H.323 networks comprising only H.323 gateways, the H.323 Gateway
function uses both sub-groups and offers outgoing calls only to gateways
defined as destinations and accepts incoming calls only from gateways
defined as sources. This offers significant flexibility since each H.323 gateway
can be defined as source, destination or source and destination for H.323
calls.

For H.323 networks comprising H.323 zones, the H.323 Gateway function
does not use sub-group of source IP addresses, because it does not perform
filtering of incoming calls based on source IP address. Responsibility for
admitting incoming, as well as, outgoing calls, lies with the gatekeeper
controlling the corresponding zone.

The H.323 Gateway function supports only manual gatekeeper discovery

procedure. Thus, IP addresses of gatekeepers in connected H.323 network
have to be manually provisioned as destination addresses in IPG. In addition,
since the H.323 Gateway requests gatekeeper to perform translation of the B-
number into IP address of the destination H.323 endpoint for outgoing calls,
IP addresses of the peer H.323 gateways are not to be configured in TeS.

Remote host (RHOST) is also an object created per H.323 network. It

defines type of connected H.323 network and groups local network interfaces
to be used for signalling towards particular network.

The H.323 Gateway function uses GARP board as signalling terminal

providing a physical IP network interface. The network interface, provided by
GARP through onboard Ethernet card, is abstracted by the IPPORT object.
The IP address of the interface is defined on IPPORT object together with
other Ethernet and IP properties. Multiple GARP boards, each providing a
single network interface, can be used per connected H.323 network. Thus,
TeS is able to operate as multi-homed H.323 gateway.

One instance of H.323 RP software and one instance of IP RP software are

loaded on one GARP. Mentioned software units are represented by H.323 EM
and IP EM objects, respectively.

IP EQM is an equipment owner of the IP EM, whereas, Local Host (LHOST)

is an equipment owner of the H.323 EM. In addition, selection of local network
interfaces for signalling towards particular H.323 network is enabled through
connection of LHOST objects to RHOST object. The H.323 Gateway function
offers the possibility to select all available GARP boards or just a subset for
one RHOST. This means that one GARP board can be used for several
H.323 networks, but, it is also possible to reserve it for specific (premium
customer) H.323 network.
Open
USER GUIDE 12 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

1.4.3 Transport Addresses

For H.323 networks comprising zones, TeS, using the H.323 Gateway
function, registers its available RAS and call signalling transport addresses
with the gatekeeper in every zone. Addresses are registered after every
restart and whenever set of working transport addresses out of those
provisioned for particular H.323 network changes (due to GARP failure or
recovery). In addition, registration procedure is initiated in certain cases not
related to changes in the set of working transport addresses such as:

• At manual deblocking of an EP
• After gatekeeper-initiated unregistration procedure is concluded.
• At any time registration is considered lost by the H.323 Gateway or
gatekeeper has indicated loss of registration

The H.323 Gateway registration with a gatekeeper can be valid for a limited
time. In such a case, the H.323 Gateway function will refresh its registration
prior to expiration time. Note that this only extends validity of an existing
registration including registered transport addresses.

The registration procedure is performed using RAS signalling towards well-

known RAS port at configured IP address of the gatekeeper. The TeS is using
dedicated (unique across all H.323 zones) transport addresses for reception
of RAS and call signalling from every H.323 zone. Since the same network
interfaces (having the same IP address) can be used towards multiple H.323
networks, each zone will have a dedicated port number.

The H.323 Gateway function automatically assigns unique port numbers

(equal for RAS and call signalling), to be used for reception of signalling from
every zone (server ports), during H.323 Gateway configuration. These port
numbers are assigned from an operator controllable range. For more details
regarding related AXE parameters, refer to [AI10]. In addition, it is possible to
manually assign port numbers to be used for reception of RAS and call
signalling from H.323 networks comprising a single H.323 zone.

Gatekeeper itself uses registered RAS transport addresses for sending call
related and non-call related RAS signalling towards gateway. On the other
hand, the gatekeeper can, during admission procedure, provide one of the
TeS’s registered call signalling transport addresses to another gateway
originating the call. In this case, peer gateway communicates directly with
TeS and this is referred to as ‘direct call model’. Another option is for the
gatekeeper to route the call signalling itself and use TeS’s address as
destination address for call signalling. Such model is called ‘gatekeeper
routed call model’. The H.323 Gateway function supports both models.

The H.323 Gateway uses server port for RAS signalling as client port, that is,
the same port number is used for incoming and outgoing RAS signalling.
Client ports for call signalling (used for outgoing calls) are dynamically opened
and port number is seized from the operator controllable range. For more
details regarding related AXE parameters, refer to [AI10]. Calls are destined
to the address provided by the gatekeeper during admission procedure.
Open
USER GUIDE 13 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

In addition, the H.323 Gateway function supports call establishment without

performing admission procedure. This type of call setup is utilized if the
gatekeeper has pre-granted TeS access to an H.323 zone for incoming,
outgoing or both types of calls during registration procedure. If access has
been pre-granted for outgoing calls, outgoing calls are setup towards call
signalling transport addresses of the gatekeeper provided through registration
procedure. Similarly, in case access has been pre-granted for incoming calls,
calls incoming from gatekeeper’s call signalling transport addresses are setup
without performing admission procedure. Calls from other addresses (as in
case of direct call model) are subjected to admission procedure. However, the
H.323 Gateway function can be configured to always perform admission
procedure for incoming calls.

Described usage of port numbers and different call models are illustrated in
the figure below. Please note that only server ports are marked with colored
circles.

GW

GK

TeS

GW

GK

GW

H.323 network H.323 zone

Call direction Call related RAS signalling

Automatically assigned port for Automatically assigned port for

call signalling RAS signalling

Port for call signalling as provided Well-known port for RAS signalling
during admission procedure

Figure 5. Illustration of port number usage and call models

Open
USER GUIDE 14 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

As opposed to H.323 networks comprising zones, H.323 networks comprising

only gateways do not offer the possibility of registering and distributing
transport addresses. Thus, TeS’s call signalling transport addresses
configured for particular H.323 network comprising only gateways have to be
manually provisioned at each peer gateway that will offer H.323 calls to TeS.

For such networks, the H.323 Gateway function accepts incoming calls on the
well-known port number for call signalling (server port). However, it is possible
to manually configure port number for call signalling server port at TeS for
H.323 network comprising only H.323 gateways.

Similarly, H.323 Gateway uses well-known port number for call signalling as
server port at peer gateways when establishing outgoing calls. But it is
possible to manually configure port number used as call signalling server port
at peer gateways. Client ports for call signalling in TeS (used for outgoing
calls) are dynamically opened and port number is seized from the operator
controllable range. For more details regarding related AXE parameters, refer
to [AI10].

GW

GW
GW

TeS

GW

GW

GW
GW

GW

H.323 network Well-known port

Configured port
Call direction

Figure 6. Example of port number usage (GW network)

Open
USER GUIDE 15 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

1.4.4 Fault Resilience

The H.323 Gateway function encompasses different levels of complementing

mechanisms for fault resilience. The mechanisms take advantage of multiple
network interfaces or nodes in order to cope with possible failures during
operation.

1.4.4.1 Local Hardware Fault Resilience

Resilience of the H.323 Gateway function to faults in local hardware is based

on multiple network interfaces. IPPORTs, providing local network interfaces,
can operate in stand-alone mode only. A stand-alone mode, as opposed to
redundant IPPORT pair mode, does not provide protection against hardware
failure. Therefore, provisioning multiple IPPORTs for each EP ensures fault
resilient operation.

AXE

EP 1 EP 2 EP 3

RHOST 1 RHOST 2 RHOST 3

IPPORT 1 LHOST 1 IPPORT 2 LHOST 2 IPPORT 3 LHOST 3

GARP 1 GARP 2 GARP 3

Figure 7. Configuration resilient to faults in local hardware

The mechanism of provisioning multiple IPPORTs per EP can, also, be used

to provide scalable call capacity per connected H.323 network and effectively
deal with increased traffic volume. The H.323 Gateway function supports
connection of up to 16 IPPORTs.

The H.323 Gateway function incorporates load-balancing function. This

function balances the traffic load across available IPPORTs. Thus, when an
EP is provisioned with multiple IPPORTs, the H.323 Gateway function selects
least loaded available IPPORT for an outgoing call. During this selection, total
traffic load (from all provisioned EPs) is considered.
Open
USER GUIDE 16 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

1.4.4.2 Remote Peer Fault Resilience

The H.323 Gateway function supports connections to H.323 networks,

offering robustness in end-to-end service through usage of multiple physical
or logical devices. For H.323 networks comprising H.323 gateways, only static
method of manual provisioning addresses of multiple peer gateways is
supported, while for networks comprising H.323 zones, in addition to method
of manual provisioning addresses of gatekeepers, the H.323 Gateway
function supports dynamic method, so called Alternate Gatekeepers
procedure.

Multiple H.323 Gateways/Zones

For calls towards H.323 network containing multiple destination gateways or

zones, the H.323 Gateway function supports two methods of selecting
destination gateway or zone:

• Master Destination method

• Percentage Distribution method

Using the first method, all outgoing calls will be offered to one gateway/zone.
Other destination gateways/zones serve only as a backup. See below for
description of call re-routing to a different destination. The second method
offers possibility of distributing outgoing traffic between certain destination
gateways/zones according to provisioned percentage distribution assigned to
corresponding destination IP addresses. For this method, all gateways/zones
not offered the call initially could serve as backup if particular call fails.

GW

GW
GW

GW

TeS

H.323 network Initial call attempts

Repeated call attempts

Figure 8. Master Destination method illustration

Open
USER GUIDE 17 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

GW 30% GW
GW
50%
20%
0%

GW
GW
GW
0%

TeS

H.323 network Initial call attempts

Repeated call attempts

Figure 9. Percentage Distribution method illustration

The H.323 Gateway function allows definition of destination gateways/zones

as belonging to multiple H.323 network. This enables multiple instances of all
destination gateways/zones from the same H.323 network to be configured in
TeS, thereby, allowing for differentiated routing of outgoing H.323 calls.

Regardless of the selection method used, the H.323 Gateway provides an

option of re-routing the call (call reattempt) to the next gateway/zone, in case
of unsuccessful call attempt. Next destination gateway/zone is selected in
Round Robin fashion starting from the gateway/zone initially selected. An
unsuccessful call will be re-routed to all defined destinations in particular
H.323 network unless the number of allowed call attempts is limited using
parameter NCALLAT. For more details on this parameter, refer to [AI8]. Using
this mechanism, the H.323 Gateway provides resilience to faults in peer
gateways or gatekeepers.

Please note that H.323 Gateway function does not in any way verify whether
called terminal is reachable through all destination gateways/zones or not.
Such network architecture is assumed by this solution.

Incoming calls are accepted from all gateways defined as part of source sub-
group of IPG (defined in 1.4.2) corresponding to particular H.323 network
comprising only gateways. Similarly, for calls received over any of the network
interfaces registered with gatekeepers controlling the zones contained in
particular H.323 network, the H.323 Gateway function will initiate call
admission procedure with the respective gatekeeper. This allows for similar
call re-routing function to be deployed by the node in the cooperating network
in case of fault in transit H.323 gateway/zone.
Open
USER GUIDE 18 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

GW

GW

GW
GW

GW

TeS

H.323 network Initial call attempts

Repeated call attempts

Co-oper. network

Figure 10. Call re-routing by the interworking network

Alternate Gatekeepers Procedure

This procedure is supported only for H.323 networks comprising a single

H.323 zone, that is, controlled by only one gatekeeper. IP address of the
gatekeeper is provisioned as part of the H.323 Gateway configuration.
However, for the sake of ensuring availability, redundancy and scalability,
gatekeeper functionality in particular zone can be provided using multiple
physical or logical devices. These are referred to as Alternate Gatekeepers.

As a part of Alternate Gatekeepers procedure, each gatekeeper can provide

addresses of its Alternate Gatekeepers to endpoints using RAS signalling.
The H.323 Gateway function accepts these addresses only from the primary
gatekeeper for corresponding zone/H.323 network (one that is configured in
TeS). Moreover, it is capable of storing addresses of up to 4 alternate
gatekeepers with highest priority.

In case of a fault of the currently used gatekeeper, the H.323 Gateway

function starts using appropriate Alternate Gatekeeper (according to indicated
priority), thus, enabling fault resilient operation. It should be noted that H.323
Gateway function uses one and only one gatekeeper in particular zone at a
time.

In addition, gatekeeper can explicitly request redirection to alternative

gatekeeper. The H.323 Gateway supports only permanent redirection.

As an option, the Alternate Gatekeepers procedure, controlled by the AXE

parameter ALTGKIGNORED, can be completely disabled. For more details,
refer to [AI11].
Open
USER GUIDE 19 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

2 How to Use
2.1 Printouts

In order to facilitate usage of the H.323 Gateway function and due to large
number of managed objects, corresponding data and relationships, a number
of printouts are grouped in this chapter and organized according to related
objects.

2.1.1 RP and EM Data

Printout of the RP data and its state is ordered by means of EXRPP

command. As an example, printout of RP data and state is ordered for RP
with address 2.

EXRPP:RP=2;

The ‘RP DATA’ printout is received as a result.

Printout of Regional Software Units loaded on specified RP together with

connected EMs is ordered by means of EXRUP command. As an example,
printout of loaded RSUs is ordered for RP with address 2.

EXRUP:RP=2;

The ’RP SOFTWARE UNIT DATA’ printout is received as a result.

Printout of various RP board data is ordered by means of EXRIP command.

As an example, printout of RP board data is ordered for RP with address 2.

EXRIP:RP=2;

The ‘RP BOARD DATA’ printout is received as a result.

Printout of EM state and associated device for one or several EMs is ordered
by means of EXEMP command. As an example, printout of EM state is
ordered for all EMs connected to the RP with address 2.

EXEMP:RP=2,EM=ALL;

The ‘EM DATA’ printout is received as a result.

2.1.2 IPPORT Data

Printout of related configuration data for connected IPPORT is ordered by

means of IHCOP command. As an example, printout of configuration data is
ordered for IPPORT with equipment number 2 and Ethernet interface number
2.

IHCOP:IPPORT=IP-1-2;

The ‘IP PORT CONNECTION DATA’ printout is received as a result.

Open
USER GUIDE 20 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Printout of blocking and operational state of an IPPORT is ordered by means

of IHSTP command. As an example, printout of blocking and operational state
is ordered for all connected IPPORTs.

IHSTP:IPPORT=ALL;

The ‘IP PORT STATE’ printout is received as a result.

2.1.3 RHOST and LHOST Data

Printout of binding state and bound IP address, as well as, associated RP for
specified LHOST is ordered by means of H3SBP command. As an example,
printout of binding state and related data is ordered for LHOST with
equipment number 1.

H3SBP:LHOST=H3STH-1;

The ‘H323 SIGNALLING TRANSPORT BINDING STATE’ printout is received.

Printout of RHOST data, LHOSTs connected to specified RHOST or RHOSTs

connected to specified LHOST is ordered by means of H3SRP command. As
an example, printout of all LHOSTs connected to RHOST (DUBLIN) together
with corresponding IP addresses is ordered.

H3SRP:RHOST=DUBLIN,RL;

The ‘H323 SIGNALLING TRANSPORT REMOTE HOST DATA’ printout is

received as a result.

2.1.4 IPG Data

Printout of detailed IPG data including IPG state, all connected IP addresses
and percentage distribution is ordered by means of IFIGP command. In
addition, the same command can be used to obtain IPGs that certain IP
address is connected to. Printout ‘IP GROUP DATA’ is received as a result in
both cases. As an example, printout of detailed IPG data is ordered for IPG 1.

IFIGP:IPG=IPG-1;

Printout of all remote destination IP addresses and assigned percentages for

an IPG for which the percentage change procedure is initiated is ordered by
means of IFFSP command.

IFFSP;

Printout ‘IP GROUP IP ADDRESS FREQUENCY SET DATA’ is received as a

result.
Open
USER GUIDE 21 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

2.1.5 EP Data

Printout of EP data, its state and connections to route and RHOST is ordered
by means of H3EPP command. As an example, printout of EP data is ordered
for all defined EPs.

H3EPP:EP=ALL;

The ‘H323 ENDPOINT DATA’ printout is received as a result.

2.1.6 Route and Device Data

Printout of route data is ordered by means of EXROP command. As an

example, route data printout is ordered for all H.323 routes.

EXROP:DETY=HACORE;

The ‘ROUTE DATA’ printout is received as a result.

Printout of all functions having references to the specified route is ordered by

means of EXRFP command. The command, also, orders a printout of all
interworking routes. As an example, this printout is ordered for outgoing
H.323 route H3231O.

EXRFP:R=H3231O;

The ‘ROUTE FUNCTIONS’ and ‘ROUTE INTERDEPENDENCIES’ printouts

are received as a result of this command.

Printout of device data and connections state is ordered by means of EXDEP

command. As an example, printout of device data is ordered for all devices
connected to the route H3231O.

EXDEP:R= H3231O;

The ‘DEVICE DATA’ printout is received as a result.

Printout of state of devices is ordered by means of STDEP command. As an

example, printout of states of devices is ordered for H.323 devices 1 – 2048.

STDEP:DEV=HACORE-1&&-2048;

The ‘DEVICE STATE DETAILS’ printout is received as a result.

Printout of detailed device state in specified routes is ordered by means of

STRDP command. The device states are given in printouts ‘DEVICE STATE
SURVEY’ and ‘DEVICE STATE DETAILS’. As an example, printout of device
state details is ordered for all devices connected to the route (H3231O) that
are seized for H.323 calls.

STRDP:R=H3231O,STATE=BUSY&INCO;
Open
USER GUIDE 22 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Printout of state survey for devices connected to specified route is ordered by

means of STRSP command. The ‘DEVICE STATE SURVEY’ printout is
received as a result. As an example, printout of state survey is ordered for all
devices connected to the route H3231O.

STRSP:R=H3231O;

Printout of detailed device state for blocked H.323 devices is ordered by

means of STBSP command. The ‘DEVICE STATE DETAILS’ printout is
received as a result. As an example, printout of detailed device state is
ordered for all manually blocked H.323 devices.

STBSP:DETY=HACORE,BLSTATE=MBL;

2.2 Changing the Set of LHOSTs

As per default, RHOST is connected to all defined LHOSTs. This can be

changed and a RHOST can be connected to specific LHOSTs by means of
H3SRC command. Prerequisite for this is that EP is not connected to it. The
procedure for disconnecting EP from the RHOST is described in 3.3.1. Note
that this procedure requires stoppage of H.323 traffic for relevant EP/RHOST.

As an example of this procedure, RHOST (DUBLIN), that was connected to

all defined LHOSTs (from H3STH-1 up to H3STH-6), is connected to specified
LHOSTs and effectively disconnected from LHOST H3STH-2.

H3SRC:RHOST=DUBLIN,LHOST=H3STH-1&-3&&-6;

When connection to LHOST H3STH-2 is to be restored, command H3SRC is

to be issued again with full set of LHOSTs:

H3SRC:RHOST=DUBLIN,LHOST=H3STH-1&&-6;

A distinction should be made between being connected to specifically listed

LHOSTs (even though all LHOSTs are listed) and being connected to all
defined LHOSTs (as per default) in respect of addition of a new LHOST.

Adding a new LHOST automatically defines it as connected to all RHOSTs

being, as per default, connected to all defined LHOSTs. On the other hand,
for RHOSTs connected to specifically listed LHOSTs, new LHOST has to be
manually added following the procedure described in this chapter.

In addition, it should be noted that once RHOST is connected to a list of

specified LHOSTs, it is not possible to go back and to connect it to all defined
LHOSTs.
Open
USER GUIDE 23 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

2.3 Changing the Port Numbers

Depending on the type of RHOST and number of remote peers (as described
in 1.4.3), local and remote server port number for call signalling and local
server port number for RAS can be manually assigned to RHOST. If required,
configured port numbers can be changed but only when corresponding EP is
manually blocked and without traffic.

As an example of this procedure, local and remote server port number for call
signalling are changed for RHOST of gateway type (DUBLIN). In addition,
local server port number for call signalling and for RAS is changed for RHOST
of gatekeeper type (CORK).

H3SRC:RHOST=DUBLIN,LCS=1589,RCS=2500;
H3SRC:RHOST=CORK,LCS=1560,LRAS=2090;

2.4 Changing the Local IP Address

In order to change local IP address of an LHOST (H3STH-2), corresponding

changes have to be done to IPPORT connected to the same RP as LHOST in
question. Before the change can be performed, LHOST has to be unbound
from its current IP address. This, in turn, requires that none of the defined
RHOSTs is connected to this particular LHOST. This can be verified using
H3SRP command requesting LHOST connections:

H3SRP:LHOST= H3STH-2,LR;

In case there are connected RHOSTs, procedure described in 2.2 has to be

performed for all of them before proceeding with subsequent actions.
Otherwise, H3SBP can be used to determine the current IP address that
LHOST is bound to:

H3SBP:LHOST=H3STH-2;

Then, LHOST can be unbound, IP address changed and LHOST bound to the
new address:

H3SBE:IPADD=”159.107.227.183”,LHOST=H3STH-2;
IHCOC:IPPORT=IP-6-2,IPADD1=”159.107.227.207”;
H3SBI: IPADD=”159.107.227. 207”,LHOST=H3STH-2;

Following these actions, RHOSTs can be connected to the particular LHOST

according to procedure described in 2.2.

Note that other IPPORT parameters, such as subnet mask, MTU or address
of the default gateway, can be modified during operation according to the
procedure defined in [OPI21] regardless of the bounding state of the LHOST.
Open
USER GUIDE 24 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

2.5 Changing IP Addresses of Remote Peers

IP addresses of remote peers in H.323 network are grouped together and

defined in corresponding IPG. The H.323 Gateway function provides the
procedure for addition and removal of IP addresses to/from IPG that can be
used in order to update the function according to changes in connected H.323
networks.

For H.323 networks comprising only H.323 gateways, this procedure can be
used to change supported direction of H.323 calls. Thus, it is possible to
restrict the traffic (on a remote gateway basis) to incoming or outgoing only or
allow bothway traffic, according to bilateral agreements. This possibility can
be useful for blocking incoming traffic from non-paying operators but allowing
traffic outgoing towards these operators.

However, if RHOST is connected to IPG, the procedure can only be executed

under certain conditions:
• Source IP addresses can be added and/or removed online.
• Destination IP addresses can be added/removed online, but it is not
allowed to remove the last destination IP address from an IPG.

In addition, successful addition or removal of IP address to/from an IPG that

has a Percentage Distribution selection method erases defined percentages
and reverts the IPG to using Master Destination selection mode.

As an example, destination IP address is added to IPG having 4 destination

IP addresses that is connected (via RHOST) to active EP. In addition, all
source IP addresses are deleted from the same IPG. Consequently, incoming
H.323 calls are no longer accepted from particular H.323 network.

IFIAI:IPG=IPG-4,IPADD=”159.108.227.156”;
IFIAE:IPG=IPG-4,SOURCE;

2.6 Changing Selection Mode and Frequency Distribution

As described in 1.4.4.2/Multiple H.323 Gateways/Zones, the H.323 Gateway

supports two methods of selecting a destination for outgoing H.323 call:

• Master Destination selection method

• Percentage Distribution selection method

It, also, supports online switching between selection methods, as well as,
changing the percentage distribution. These changes take effect immediately
upon completion of the procedure. Execution of the procedure is defined in
[OPI6] and this chapter will, as an example, present a command sequence
required to change selection method from Master Destination to Percentage
Distribution as depicted in Figure 9.

IFIGP:IPG=IPG-4;
Open
USER GUIDE 25 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

The first destination IP address listed in result printout is IP address of the

master destination and will be assigned 50% of total outgoing traffic for
corresponding EP. Remaining 50% will be split between two subsequent
destinations, while two remaining destinations will serve only as backup
destinations and will be assigned 0%. The change is executed through a
command procedure initiated with IFFPI and terminated with IFFPE
command:

IFFPI:IPG=IPG-4;
IFFSC:IPADD=”159.108.227.156”,FREQ=50;
IFFSC:IPADD=”159.108.227.157”,FREQ=30;
IFFSC:IPADD=”159.108.227.158”,FREQ=20;
IFFSC:IPADD=”159.108.227.159”,FREQ=0;
IFFSC:IPADD=”159.108.227.160”,FREQ=0;
IFFSP;
IFFPE;

2.7 ICMP Echo Request

After RP is manually deblocked, basic availability/reachability of the remote

peer can be tested using ICMP Echo Request also known as ‘ping’.
Command IHPRI is used for this purpose. Result printout ‘IP PORT PING
REQUEST RESULT’ indicates whether the request message was
successfully echoed or not. Bear in mind that ICMP traffic is often filtered out
by firewalls or packet filters.

IHPRI:IPPORT=IP-6-2,RIP=”159.108.227.156”;

2.8 Changing the EP Properties

EP properties define its identification, call capacity and behavior in H.323

network. An EP is initiated with default properties that can be changed online.
The exceptions to this are identification related properties that, due to
signalling procedures involved, require manual blocking of an EP and
subsequent manual deblocking. For a list of EP properties, as well as, for their
description and valid values, refer to [COD1].

TA and VCESP parameters define identification of the TeS as an H.323

gateway in particular H.323 network comprising H.323 zones. Values of
Terminal Alias (TA) (H.323 ID type) and e164 supported prefix for voice
capabilities (VCESP), if defined, will be registered with the gatekeepers in
corresponding H.323 network. As an example, the EP (NYTES) is assigned
an H.323 ID and supported prefix for voice technology 6#.

H3EPC:EP=NYTES,TA=”GW1[at]MCI.COM”,VCESP=”6#”;1

1
The text ‘[at]’ is used instead of @ sign in the example to prevent Word from interpreting the TA parameter as an
email address and, thereby, hiding the proper parameter syntax.
Open
USER GUIDE 26 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Parameters MAXI and MAXO can be used to limit number of simultaneous

incoming and/or outgoing calls for particular EP. Number of devices
connected to corresponding route and manually deblocked defines the
number of total simultaneous calls. For more details on call capacity as
defined by connected and manually deblocked devices, refer to 2.10.

Another aspect of MAXI and MAXO parameters usage is reservation of

specific number of calls/devices for incoming or outgoing traffic. This is
especially useful for routes with dominant incoming or outgoing traffic.

Reserved for Reserved for MAXO

outgoing calls outgoing calls
MAXO
Total
number of
connected Unused devices
and
deblocked
MAXI devices
Reserved for MAXI Reserved for
incoming calls incoming calls

Figure 11. Illustration of MAXI and MAXO settings

The H.323 Gateway function offers these as a means for engineering traffic
levels to and from H.323 networks. However, it doesn’t control soundness of
parameter settings. It is left to the operator to utilize the parameters in a
sensible fashion. For example, it doesn’t make any sense to set MAXI or
MAXO parameter to a value higher than the number of devices connected to
the route and manually deblocked. Similarly, if number of devices connected
to corresponding route and manually deblocked is higher than the value of
(MAXI + MAXO), the total number of simultaneous calls is defined by the sum
(MAXI + MAXO) and additional devices will not carry traffic.

As an example, incoming and outgoing traffic levels are limited for a route
having 12000 devices connected and manually deblocked.

H3EPC:EP=NYTES,MAXI=8000,MAXO=10000;

By this command, 4000 devices are reserved for outgoing traffic while 2000
devices are reserved for incoming traffic.

Parameters KATIME, PGARQ, RMNR and RRT are RAS related parameters
that define behavior of TeS as an H.323 gateway in particular H.323 network
comprising H.323 zones.

KATIME parameter defines how often will H.323 Gateway function refresh the
registration of the TeS as H.323 gateway in case its registration with the
gatekeeper is valid for a limited time.
Open
USER GUIDE 27 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

PGARQ parameter can be used to specify behavior of the H.323 Gateway

function in respect to pre-granted admission procedure as described in 1.4.3.

Since RAS signalling is transferred over UDP, messages are not delivered
reliably by the TCP/IP stack. Therefore, the H.323 Gateway function
implements the retransmission of RAS messages as defined by H.225.0
recommendation. Parameters RMNR and RRT are related to retransmission
and define whether retransmission will be performed at all, how many times
will a message be retransmitted before message sending is considered failed
and time period between retransmissions.

Parameter MWC defines whether remote peer will be requested, through call
signalling, to withhold sending of media stream before it sends Connect
message.

2.9 ‘No RAS Signalling’ Configuration

In case connected H.323 network consists of H.323 zones but operator, for
whatever reason, does not want to use RAS signalling between TeS as H.323
gateway and gatekeepers controlling corresponding zones, the H.323
Gateway function should be configured as connected to H.323 network
comprising only H.323 gateways.

H3SRI:RHOST=DUBLIN,IPG=IPG-4,TYPE=GW;

Consequently, the H.323 Gateway function will behave as this is an H.323

network comprising only H.323 gateways and will not utilize RAS signalling. In
addition, as TeS has not registered any RAS addresses at corresponding
gatekeepers, gatekeepers will not apply RAS signalling towards it.

Such configuration, of course, means that call signalling transport addresses

of corresponding EP have to be manually provisioned at gatekeepers
controlling zones in this network. Gatekeepers can distribute manually
provisioned transport addresses, using RAS signalling, to other gateways in
the network. Another option is for transport addresses to be manually
provisioned at all gateways that will apply direct call signalling model and
send calls directly to TeS.

At TeS side, the H.323 Gateway function has to be manually configured with
call signalling transport addresses of all gateways that TeS will accept
incoming calls from and of all gateways that TeS will offer outgoing calls to.
For detailed description of remote peers’ addresses handling and source and
destination properties, refer to IPG description in 1.4.2.

As TeS is not aware of gatekeepers in this configuration, call signalling

addresses of gatekeepers should be configured together with addresses of
gateways in IPG, if gatekeepers are capable of routing the calls themselves.

As an example, configuration of IPG corresponding to an H.323 network

comprising a single zone (one gatekeeper) is presented.
Open
USER GUIDE 28 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

IP address of the gatekeeper (159.108.227.186) is configured in IPG together

with IP addresses of destination gateways (159.108.227.156 -
159.108.227.159). Therefore, outgoing calls will be offered to gatekeeper only
(Master Destination selection method) or to gatekeeper and gateways (if
Percentage Distribution selection method is subsequently administered).

IFIAI:IPG=IPG-4,IPADD=”159.108.227.186”;
IFIAI:IPG=IPG-4,IPADD=”159.108.227.156”;
IFIAI:IPG=IPG-4,IPADD=”159.108.227.157”;
IFIAI:IPG=IPG-4,IPADD=”159.108.227.158”;
IFIAI:IPG=IPG-4,IPADD=”159.108.227.159”;

Additionally, IP address of the gatekeeper is configured together with IP

addresses of source gateways. Consequently, calls routed through the
gatekeeper will be accepted by the H.323 Gateway function.

IFIAI:IPG=IPG-4,IPFIRST=”159.108.227.156”, IPLAST=”159.108.227.165”;
IFIAI:IPG=IPG-4,IPFIRST=”159.108.227.186”, IPLAST=”159.108.227.186”;

Please note that IPG is configured before RHOST is connected to it. For a
detailed explanation of the H.323 Gateway function configuration, turn to
chapter 3.

2.10 Changing the Call Capacity of an H.323 Route

Call capacity of an H.323 bothway route is defined by the number of devices

connected to the route and manually deblocked. Therefore, call capacity
assigned for particular H.323 network is basically defined on a route level.
The H.323 Gateway function provides additional functions for call capacity
control defined on EP level and described in 2.8 (MAXI/MAXO parameters).

Call capacity of an H.323 route can be properly sized using commands for
manual blocking/deblocking (BLODI/BLODE) of connected devices and for
connecting/disconnecting (EXDRI/EXDRE) devices to/from the route during
operation (online) without any disturbances to the ongoing traffic.

In order to increase the call capacity of a route, a number of devices,

according to desired increase, shall be connected to the route and manually
deblocked. Prerequisite for this is availability of H.323 devices not already
connected to another route. This will, in most cases, require an increase in
size of corresponding data files. For more specific information regarding
device file size increase and data file size dependency, refer to [AI6] – [AI9].

As an example, a route capacity will be increased for 2000 calls/devices. The

size of device/task data files has to be increased accordingly (previous data
file size in HACSPH, HA245PH and HACORE was 68000).

SAAII:SAE=500,BLOCK=HACSPH,NI=70000;
SAAII:SAE=500,BLOCK=HA245PH,NI=70000;
SAAII:SAE=500,BLOCK=HACORE,NI=70000;
Open
USER GUIDE 29 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

If this is a route towards H.323 network comprising H.323 zones (RHOST of

GK type), size increase of task data file is required in HARASPH block as well
(previous size 50000):

SAAII:SAE=500,BLOCK=HARASPH,NI=52000;

Finally, devices can be connected to the route and manually deblocked. Note
that a maximum of 32 devices can be manually deblocked with one BLODE
command.

EXDRI:R=H323O&H323I,DEV=HACORE-68000&&-69999;
BLODE:DEV= HACORE-68000&&-68031;
BLODE:DEV= HACORE-68032&&-68063;
…..

In order to decrease the call capacity, devices have to be manually blocked. If

this decrease is not of temporary nature, devices are normally disconnected
from the route after being released from any ongoing calls. Subsequently,
devices can be connected to another route in order to increase its call
capacity or file size of corresponding files is reduced and unused memory
released. Manual blocking command has the same limitation as manual
deblocking command, and, therefore, usually, it has to be repeated a number
of times.

2.11 Fault Cases

The H.323 Gateway function is capable of detecting faults related to RP

board, its interfaces and connected EMs on several levels. If a fault in RP is
detected, alarm printout ‘RP FAULT’ is received. Actions to be taken in such a
situation are described in [OPI17]. In case faulty situation is detected for
IPPORT/IP EM (either due to the fault in Ethernet connection, missing
mandatory RSU for handling of IP stack or communication fault between CP
and RP), alarm printout ‘IP PORT FAULT’ is received. Corresponding actions
to be taken are described in [OPI18].

Certain fault indicating events for H.323 EMs are handled through ‘Event
Reporting and Disturbance Supervision’ function (see [FS5]) as described in
[FS4]. If the H.323 Gateway function detects loss of communication with
H.323 EM during operation, it will start communication test. Depending on the
result, it will report one of the following two events:

• 1066 - indication to the operator that H.323 EM connected to indicated RP

has had problems with congestion but is responsive now.
• 1067 - indication to the operator that H.323 EM connected to indicated RP
is not responsive and that it is suspected faulty.

When loss of communication is detected, the H.323 Gateway will immediately

inhibit signalling traffic towards corresponding H.323 EM. The traffic will be
resumed upon successful test completion or when communication with the
H.323 EM has been restored.
Open
USER GUIDE 30 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

It is strongly recommended to activate Event Reporting function for two

events listed in [FS4] as a part of the H.323 Gateway function configuration
according to the procedure presented below.

For the former event, it is recommended to store reports in the ‘Temporary’

list with maximum number of reports being set to 1 and without any filtering.
This will yield ‘EVENT REPORTING RESULT’ printout for each and every
report immediately after its detection.

For the latter event, it is recommended to store reports in the ‘Permanent’ list
with maximum number of reports being set to 16. As for the former event,
neither time nor number filtering shall be ordered. In addition, it is
recommended to set single alarm threshold to the value 0. Such setting will
result in ‘EVENT REPORTING THRESHOLD REACHED’ alarm being
received for every reported occurrence of event 1067.

Prior to activation of the Event Reporting, Event Reports data file should be
increased sufficiently. For more detailed information, refer to [AI12]. Event
reporting for above listed events should be activated with specified event
reporting data according to the procedure defined in [OPI19]. Some additional
information regarding the procedure, including examples, can be found in
[ADI4].

When ‘EVENT REPORTING THRESHOLD REACHED’ alarm is received,

event report should be printed and alarm reset without any changes to event
reporting data according to procedure described in [OPI20]. Additionally,
event log should be printed as an input for fault analysis and RP should be
manually blocked and deblocked:

DIRRP:RP=2;
BLRPI:RP=2,FORCED;
BLRPE:RP=2;

3 Configuration
3.1 General

This chapter describes administrative actions that must be performed in order

to initialize the H.323 Gateway function and prepare it for the operation. In
addition, administrative actions that must be performed in order to stop and
terminate function execution are described as well.

The H.323 Gateway function can be divided in two general sub-functions:

H.323 Signalling Transport and H.323 Application. Configuration of the H.323
Gateway function is organized with this division in mind.

3.2 Initialization of the H.323 Gateway Function

In order to be able to use the H.323 Gateway function, it has to be correctly

initialized. This process includes the following tasks:
Open
USER GUIDE 31 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

• Data files configuration

• Hardware configuration
• H.323 Signalling Transport configuration
• H.323 Application configuration

Listed tasks are explained in detail in corresponding subchapter. Please note

that initialization of the H.323 Gateway function is described for only one
connected H.323 network, as procedure is the same for every network. Note
that connection of multiple H.323 networks introduces higher capacity
requirements.

3.2.1 Data Files Configuration

As a prerequisite for subsequent tasks in initialization of the H.323 Gateway

function, sufficient space in related data files must be ensured. This is
performed by increasing size of the size alterable files listed in the table
below. In addition to configuration related data files, traffic sensitive files that
must be increased in order to run H.323 calls are listed in a separate table.
More detailed information regarding the data files, their purpose and relations
between the files can be found in Application Information documents of
relevant blocks ([AI1-AI9]).

Block name SAE number Application Information

RPADM 304 [AI1]

RPADM 1822 [AI1]

RPDI 304 [AI2]

RPDI 807 [AI2]

IP 600 [AI3]

IP 601 [AI3]

IP 602 [AI3]

H3STH 503 [AI4]

H3STH 504 [AI4]

IPG 611 [AI5]

IPG 612 [AI5]

IPG 613 [AI5]

IPG 614 [AI5]

HACSPH 500 [AI6]

Open
USER GUIDE 32 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Block name SAE number Application Information

HA245PH 500 [AI7]

HACORE 500 [AI8]

HACORE 504 [AI8]

HACORE 612 [AI8]

HACORE 613 [AI8]

HARASPH 613 [AI9]

Table 1. Configuration related size alterable data files

Block name SAE number Application Information

H3STH 500 [AI4]

H3STH 502 [AI4]

HACSPH 647 [AI6]

HA245PH 647 [AI7]

HARASPH 500 [AI9]

HARASPH 647 [AI9]

Table 2. Traffic initialization related size alterable data files

3.2.2 Hardware Configuration

The first step in initializing the function is to equip the magazines with
sufficient number of RP boards that will be used for H.323 signalling and to
connect power and bus cables. It should be noted that used RP boards must
be of type GARP (e.g. GARP1A). Usage of multiple RP boards is
recommended for the reasons of scalability and fault resilience.

Subsequently, RP boards have to be defined and configured with required

Regional Software Units (RSUs). The procedure is executed according to
[OPI1], except for the manual deblocking of the RP, which is performed at
later point in time.

Since GARP type of RP board is used, RPs will be connected to Regional

Processor Bus of Serial type (RPB-S). Also, physical addresses of RP boards
(that is, RPB branch number, magazine number and slot number) are
required to perform this procedure.
Open
USER GUIDE 33 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

All RP boards have to be loaded with the following Operating System RSUs:

• RPFDR
• RPIFDR
• INETR
• GPEXR

In addition, all RP boards will host two Application RSUs:

• IPR
• H3STHR

The next step is definition and connection of Extension Modules (EMs)

required for the H.323 Gateway. This and subsequent actions will be
presented for only one RP. By means of EXEMI command, two EMs are
defined and connected to application RSUs previously loaded on the same
RP board. The two equipment owners (IP EQM and LHOST) are defined at
the same time.

Note that EM0 is, usually, used for IP EM while EM1 is used for H3STH EM.
Definition of other EMs, in addition to those mentioned above, is not
recommended due to capacity reasons (to reserve GARP capacity for
handling of H.323 signalling).

Although GARP boards do not belong to RPD-family of RP boards, the

above-described procedure of connecting EMs is executed according to
[OPI2] with the exception of manual deblocking of RP that is performed later.
In addition, note that command for EM deblocking (BLEME) is not applicable
for GARP boards and that blocking state of EMs is controlled by manual
de/blocking of the GARP.

More details on this procedure, including examples, can be found in [ADI1].

3.2.3 H.323 Signalling Transport Configuration

As a first step, external IP physical interface of the GARP board is defined

and configured. IPPORT, as an abstraction of the physical Ethernet interface
of the GARP board, has to be initiated and connected to the IP EM previously
defined on particular GARP. As part of this procedure, IP address, as one of
the IPPORT parameters, has to be configured. It should be noted that H.323
Gateway function uses only one IP address per IPPORT. Thus, configuring
second IP addresses for IPPORT, although possible, is superfluous and not
recommended. In addition, only one Ethernet board on GARP is available as
an external IP network interface and it always has Ethernet interface number
2. Subsequent to its connection, IPPORT is deblocked and taken into service.

The procedure is executed according to [OPI3]. Prerequisite for this

procedure is enabled usage of IPPORT by the H.323 Gateway function
through AXE parameter SLIH323. For more details regarding the parameter,
refer to [AI10].
Open
USER GUIDE 34 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Subsequently, LHOST, as owner of the H323 EM connected to particular

GARP, has to be connected to corresponding IPPORT and registered as a
user of the IP address defined for that IPPORT. The procedure is defined in
[OPI4]. After execution of this procedure, GARP shall be manually deblocked
and taken into service using BLRPE command. This will, as well, deblock the
EMs connected to particular GARP.

Following this, IP addresses of the remote peers belonging to a particular

network have to be defined and grouped into IPG. Addresses of remote
destinations are entered as individual IP addresses, whereas, addresses of
remote sources are entered in form of IP address range. The procedure is
executed according to [OPI5]. It should be noted that Master Destination
selection method, with first defined destination being master destination, is
initially set for IPG. However, selection method can be changed to the
Percentage Distribution method according to [OPI6] at this point. More details
on this procedure, including examples, can be found in [ADI2].

After IPG is configured, RHOST is to be defined and connected to it. In

addition to addresses of remote peers (grouped in IPG), RHOST must be
defined with the name and the type. Depending on type of the RHOST
(GW/GK), port numbers to be used for local and remote server ports for call
and RAS signalling, as described in 1.4.3, can be defined, as well. The
procedure is executed according to [OPI7]. More details on this procedure,
including examples, can be found in [ADI3].

Newly defined RHOST is, by default, connected to all provisioned LHOSTs

and will, consequently, use all available network interfaces and full call
capacity. However, set of connected LHOSTs can, at this time, be limited
according to procedure defined in [OPI8]. Of course, this will scale down the
call capacity for particular H.323 network.

3.2.4 H.323 Application Configuration

As a final step in the H.323 Gateway function initialization, H.323 Application

must be configured and H.323 traffic initialized. This procedure includes
definition of H.323 EP, its configuration and connection to RHOST, as well as,
H.323 route definition, configuration and connection to H.323 EP. For
parameters defining EP properties, refer to [COD1] and for supported route
parameters to [AI8].

In addition, desired call capacity has to be statically allocated to a particular

H.323 route by connecting and deblocking H.323 devices. Subsequently, the
routing analysis has to be changed to include the new route.

Finally, the route and the EP are deblocked, thereby, enabling H.323 traffic. In
addition to configuration steps described in previous chapters, prerequisite for
this step is definition of Media Gateway Groups to be used for H.323 calls
over the particular route. Procedure described above is executed according to
[OPI9].
Open
USER GUIDE 35 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

3.3 Termination of the H.323 Gateway function

The procedure described in this chapter is to be executed in order to

terminate the H.323 Gateway function. It comprises the following tasks:

• H.323 Application termination

• H.323 Signalling Transport termination
• Hardware disconnection
• Data files size reduction

Listed tasks are explained in detail in corresponding subchapter. Please note

that termination of the H.323 Gateway function is described for only one
connected H.323 network, as procedure is the same for all connected H.323
networks.

3.3.1 H.323 Application Termination

Before other actions can be performed, the H.323 traffic has to be stopped.
Manual EP blocking is used for this purpose. When traffic is completely
stopped, route has to be disconnected from the EP, the EP has to be
disconnected from the RHOST and deleted. Subsequently, H.323 devices
connected to the route have to be manually blocked and disconnected from
the route. Before the route is deleted, it has to be removed from the routing
analysis. This procedure is executed according to [OPI10].

3.3.2 H.323 Signalling Transport Termination

As a first step for this task, RHOST has to be disconnected from the
corresponding IPG, from connected LHOSTs and deleted according to
[OPI11]. Then, IPG has to be deleted by deleting all defined source and
destination IP addresses of the remote peers according to [OPI12].

At this point, RP is manually blocked by means of BLRPI command. Note that

this will also manually block EMs (H323 and IP) connected to particular RP.
Subsequently, LHOST, as owner of the H323 EM connected to particular
GARP, has to be deregistered as a user of the IP address defined for the
IPPORT and disconnected from it. The procedure is defined in [OPI13].

As a final step in this task, IPPORT has to be blocked, disconnected from the
corresponding IP EM and deleted. This procedure is executed according to
[OPI14]. Note that this OPI is not written in generic fashion (it is SCTP
oriented), and some actions are not applicable to H.323 Gateway. However,
those actions will be skipped because, after executing previous actions,
LHOST is no longer registered as a user of the IP address on IPPORT (state
of IPPORT is not BUSY). In addition, when End point is mentioned in the OPI
it, actually, refers to SCTP End point, not H.323 EP.

3.3.3 Disconnection of Hardware

A final step in terminating the H.323 Gateway function is disconnection of the

hardware. This task comprises two steps: disconnection of EMs and
disconnection of RP.
Open
USER GUIDE 36 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

Both EMs (H323 and IP EM) connected to RP used for the H.323 Gateway
have to be disconnected. As GARP type of RP board is used by this function,
manual blocking of EMs is not applicable. In addition, RP of GARP type is
connected to RP bus of serial type (RPB-S). The procedure is executed
according to [OPI15].

Subsequently, loaded RSUs are unloaded and RP is disconnected according

to [OPI16]. Following this action, power and bus cables can be disconnected
and RP removed.

3.3.4 Data File Size Reduction

Following the previous steps in the H.323 Gateway termination procedure,

size of data files listed in Table 1 and Table 2 shall be adjusted accordingly in
order to release unused memory.

3.4 AXE Parameters

Some of the AXE parameters used by the H.323 Gateway function are
mentioned in this document. However, the complete set of used AXE
parameters and corresponding descriptions can be found in the following
Application Information documents:

• [AI10] – all listed parameters

• [AI11] – parameters ALTGKIGNORED, AORUENCODING,
CALLPROCTIMER, COUNTN100, DEFREGTIMER, T302, T303, T304,
T310, TIME101, TIME103, TIME106 and TIME109.

4 References
4.1 Function Specifications

[FS1] H.323 Gateway

[FS2] H.323 Call Setup

[FS3] H.323 Bearer Setup

[FS4] Event Reporting and Disturbance Supervision in H.323 Transport Handler

[FS5] Event Reporting and Disturbance Supervision

4.2 Protocol Specifications

[PS1] Protocol Specification for H.225.0

[PS2] H.245 Protocol Specification

4.3 Adaptation Directions

[ADI1] Allocation Data: Connection of RP EM

Open
USER GUIDE 37 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

[ADI2] Traffic Data: Internet Protocol Group Data Administration

[ADI3] Traffic Data: Handling of H.323 Signalling Transport

[ADI4] Supervision Data: Event Reporting

4.4 Operational Instructions

[OPI1] RP, Connect

[OPI2] RPD EM, Connect

[OPI3] IP Port, Connect

[OPI4] H.323, Signalling Transport, IP Address Binding, Initiate

[OPI5] IP Address Selection Function, IP Address, Define

[OPI6] IP Address Selection Function, IP Address Frequency Set, Define

[OPI7] H.323, Signalling Transport, Remote Host, Define

[OPI8] H.323, Signalling Transport, Remote Host, Change

[OPI9] H.323, H.323 Route, Connect

[OPI10] H.323, H.323 Route, Disconnect

[OPI11] H.323, Signalling Transport, Remote Host, Delete

[OPI12] IP Address Selection Function, IP Address, Delete

[OPI13] H.323, Signalling Transport, IP Address Binding, End

[OPI14] IP Port, Disconnect

[OPI15] EM for RP, Disconnect

[OPI16] RP, Disconnect

[OPI17] RP FAULT

[OPI18] IP PORT FAULT

[OPI19] Event Reporting, Initiate

[OPI20] EVENT REPORTING THRESHOLD REACHED

[OPI21] IP Port, Change

4.5 Command Descriptions

[COD1] H3EPC: H.323, Endpoint, Change

Open
USER GUIDE 38 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

[COD2] EXRPP: Exchange Data Functions RP, Print

[COD3] EXRUP: Exchange Data Functions, RP Software Unit Data, Print

[COD3] EXRIP: Exchange Data, RP Board Information, Print

[COD4] EXEMP: Exchange Data, EM, Print

[COD5] IHCOP: IP Transport, IP Port Connection, Print

[COD6] IHSTP: IP Transport, State, Print

[COD7] H3SBP: H.323, Signalling Transport Bind, Print

[COD8] H3SRP: H.323, Signalling Transport Remote Host, Print

[COD9] IFIGP: IP Address Selection Function, IP Group, Print

[COD10] IFFSP: IP Address Selection Function, IP Address Frequency Set

Specification, Print

[COD11] H3EPP: H.323, Endpoint, Print

[COD12] EXROP: Exchange Data, Route Data, Print

[COD13] EXRFP: Exchange Data, Route Functions, Print

[COD14] EXDEP: Exchange Data, Device Data, Print

[COD15] STDEP: Device State For Devices, Print

[COD16] STRDP: Device State For Routes Details, Print

[COD17] STRSP: Device State For Routes Survey, Print

[COD18] STBSP: Device State Blocking Situation, Print

[COD19] H3SRC: H.323, Signalling Transport Remote Host, Change

[COD20] H3SBE: H.323, Signalling Transport Bind, End

[COD21] IHCOC: IP Transport, IP Port Connection, Change

[COD22] H3SBI: H.323, Signalling Transport Bind, Initiate

[COD23] IFIAI: IP Address Selection Function, IP Address, Initiate

[COD24] IFIAE: IP Address Selection Function, IP Address, End

[COD25] IFFPI: IP Address Selection Function, IP Address Frequency Set Procedure,

Initiate
Open
USER GUIDE 39 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

[COD25] IFFSC: IP Address Selection Function, IP Address Frequency Set

Specification, Change

[COD26] IFFPE: IP Address Selection Function, IP Address Frequency Set Procedure,

End

[COD27] IHPRI: IP Transport, Ping Request, Initiate

[COD28] H3SRI: H.323, Signalling Transport Remote Host, Initiate

[COD29] BLODI: Blocking Of Devices, Initiate

[COD30] BLODE: Blocking Of Devices, End

[COD31] EXDRI: Exchange Data, Connection of Devices to Route, Initiate

[COD32] EXDRE: Exchange Data, Connection of Devices to Route, End

[COD33] SAAII: Size Alteration of Data Files, Alteration Increase, Initiate

[COD34] DIRRP: Diagnostic Function, RP Event Record, Print

[COD35] EXEMI: Exchange Data Function, EM, Initiate

[COD36] BLEME: Blocking Functions, Blocking of EM, End

[COD37] BLRPI: Blocking of RP, Initiate

[COD38] BLRPE: Blocking of RP, End

4.6 Printout Descriptions

[POD1] RP DATA

[POD2] RP SOFTWARE UNIT DATA

[POD3] RP BOARD DATA

[POD4] EM DATA

[POD5] IP PORT CONNECTION DATA

[POD6] IP PORT STATE

[POD7] H323 SIGNALLING TRANSPORT BINDING STATE

[POD8] H323 SIGNALLING TRANSPORT REMOTE HOST DATA

[POD9] IP GROUP DATA

[POD10] IP GROUP IP ADDRESS FREQUENCY SET DATA

[POD11] H323 ENDPOINT DATA

Open
USER GUIDE 40 (40)
Prepared (also subject responsible if other) No.

ETKTPZ 2/1553-AXE 106 06/5 Uen

Approved Checked Date Rev Reference

ETK/DAP (I. Sinovcic) PC-AXE 2006-02-24 B

[POD12] ROUTE DATA

[POD13] ROUTE FUNCTIONS

[POD14] ROUTE INTERDEPENDENCIES

[POD15] DEVICE DATA

[POD16] DEVICE STATE DETAILS

[POD17] DEVICE STATE SURVEY

[POD18] IP PORT PING REQUEST RESULT

[POD19] RP FAULT

[POD20] IP PORT FAULT

[POD21] EVENT REPORTING RESULT

[POD22] EVENT REPORTING THRESHOLD REACHED

4.7 Application Information

[AI1] RP Administration for RPS Changeable Exchange Adaptation

[AI2] RP Diagnostic Function Changeable Exchange Adaptation

[AI3] IP Port Handler Changeable Exchange Adaptation

[AI4] H.323 Signalling Transport Handler Changeable Exchange Adaptation

[AI5] Internet Protocol Group Changeable Exchange Adaptation

[AI6] H.323 Application Call Signalling Protocol Handler Changeable Exchange

Adaptation

[AI7] H.323 Application H.245 Protocol Handler Changeable Exchange Adaptation

[AI8] H.323 Application Core Changeable Exchange Adaptation

[AI9] H.323 Application RAS Protocol Handler Changeable Exchange Adaptation

[AI10] Parameter Set H3THC Changeable Exchange Adaptation

[AI11] Parameter Set TSSC Changeable Exchange Adaptation

[AI12] Event Reporting Changeable Exchange Adaptation