Temporary Document 21 (GEN)

ITU - Telecommunication Standardization Sector

STUDY GROUP 16
Geneva, 5 15 February 2002
Question(s): 2, 3, 11, 14/16
SOURCE*:

Rapporteur

TITLE:

Draft Recommendation G.799.1 V65.0

__________________
This is the full text of the Recommendation that appears in GEN 7 : Liaison statement:
Request for comments on G.799.1 support of modem over IP
ABSTRACT:
This contribution constitutes a revision of draft Recommendation G.799.1, Functionality and
Interface Specifications for GSTN Transport Network Equipment for Interconnecting GSTN
and IP Networks, incorporating the changes that were agreed to at meeting.
1. Introduction:
Question 7 of Study Group 15 has been created to produce a new Recommendation on the
functionality and interface specifications for GSTN transport network equipment for
interconnecting GSTN and IP networks.
Currently there is no globally recognised equipment standard defining the functionality or interface
characteristics of Network-Network Interfaces designed for connection GSTN and IP based
networks. Not only does this jeopardize the voice quality that results from such interconnection, but
also it unnecessarily complicates the network operators task of selecting and configuring such
equipment.
This document constitutes a draft Recommendation that addresses the various functionality, interface and
interworking aspects of this equipment.

Full text only in electronic version

* Contact:

Jerry Skene
Tellabs, OY (Finland)

Tel:
+1 703 724-7302
Fax:
+1 703 724-7202
E-mail: jerry.skene@ties.itu.int

Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the
Member States of the ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU
related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of the
ITU-T.

ITU-T\SG_DOC\SG16\FEB02\GEN\GEN-021.DOC

Recommendation G.799.1

Summary
Voice and voice-band traffic in international networks has traditionally been transported by circuit
switched systems and equipment. With the advent of the networks optimized for the transport of
Internet Protocol (IP), and as a result of its considerable growth and pervasive nature, more and
more voice traffic is expected to be carried over IP networks.
Given that voice and voice-band services remain a significant part of telecommunications, there is a
need to ensure a high quality of service for voice carried in part or wholly via IP. This
Recommendation defines interfaces and functionality for equipment that interconnect GSTN and
networks optimized for the transport of IP, such that they will provide the degree of voice quality
and interoperability required.
Introduction and Background
Keywords
Gateway, IP gateway, TDM-IP gateway, signalling interface, bearer interface, voice gateway, Voice
Over IP, internet protocol, internet gateway, end-to-end transmission performance, fax over IP,
media gateway, media gateway controller, TDM, VoIP, voice quality, quality of service, echo
canceller, speech coding, TIGIN.
Scope
This Recommendation covers the requirements of equipment that interconnects GSTN networks and
networks optimized for the transport of IP. Such equipment is referred to in this document as a
TIGIN gateway. The Recommendation describes functionality, transport interfaces, coding
protocols, signalling interfaces, and OA&M interfaces of these devices. Support is provided for calls
from IP to GSTN, GSTN to IP, IP to IP and GSTN to GSTN. While such TIGIN gateways may
support multimedia traffic and Remote Access Server (RAS) functionality, this Recommendation
covers only voice, and voice-band data, facsimile, narrowband digital data, address and signalling
tones. traffic requirements. Support of other media such as digital data and video are left for further
study. In this sense, a TIGIN gateway is a subset of a Media Gateway.
This Recommendation does not define any new protocols or network architectures, but rather refers
to existing protocols and architectures. It also does not specify a level of performance, as this will be
covered by other Recommendations referenced by this document. Operation and management
procedures are outside the scope of this Recommendation.
TIGIN Gateways are assumed to support bulk interconnection between GSTN and IP networks, and
are not intended to connect directly to Simple Endpoint Type devices. They are considered to be a
trunking and not an access gateway. Support of ATM on the GSTN interface is not specifically
defined in this release.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

FUNCTIONALITY AND INTERFACE SPECIFICATIONS FOR GSTN TRANSPORT

NETWORK EQUIPMENT FOR INTERCONNECTING GSTN AND IP NETWORKS
(Geneva, 2001)
1
1.1

References
Normative References

The following ITU-T Recommendations, and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision; all
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published.

ITU-T Recommendation E.370 (10/00) Service principles when public circuit switched
international telecommunication networks interwork with IP-based networks

ITU-T Recommendation G.109 (09/99) Definition of categories of speech transmission

quality

ITU-T Recommendation G.168 (04/00), Digital network echo cancellers

ITU-T Recommendation G.177 (09/99) - Transmission planning for voiceband services

over hybrid Internet/PSTN connections

ITU-T Recommendation G.701 (03/93) - Vocabulary of Digital Transmission and

Multiplexing and Pulse Code Modulation (PCM) Term

ITU-T Recommendation G.703 (10/98) Physical characteristics of hierarchical digital

interfaces

ITU-T Recommendation G.704 (10/98) Synchronous frame structures used at 1544, 6312,
2048, 8488 and 44,736 kbits/s hierarchical levels

ITU-T Recommendation G.707 (10/00), Network Node Interface for the Synchronous
Digital Hierarchy (SDH)

ITU-T Recommendation G.711 (1988) - Pulse code modulation (PCM) of voice

frequencies

ITU-T Recommendation G.711 Appendix I, (09/1999), A high quality low-complexity

algorithm for packet loss concealment with G.711

ITU-T Recommendation G.711 Appendix II, (02/2000), A comfort noise payload definition
for ITU-T G.711 use in packet-based multimedia communication systems

ITU-T Recommendation G.723.1 (03/96), Dual rate speech coder for multimedia
communications transmitting at 5.3 and 6.3 kbit/s

ITU-T Recommendation G.723.1 Annex A, (11/1996), A silence compression scheme for

G.729 optimized for terminals conforming to Recommendation V.70

ITU-T Recommendation G.726 (12/90) - 40, 32, 24, 16 kbit/s Adaptive Differential Pulse
Code Modulation (ADPCM)

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

ITU-T Recommendation G.729 (03/96) - Coding of speech at 8 kbit/s using conjugatestructure algebraic-code-excited linear-prediction

ITU-T Recommendation G.729 Annex B - (11/96), Silence compression scheme

ITU-T Recommendation G.784 (06/99) - Synchronous Digital Hierarchy (SDH)

management

ITU-T Recommendation G.813, (08/96) - Timing characteristics of SDH equipment slave

clocks

ITU-T Recommendation G.957 (06/99) - Optical interfaces for equipments and systems
relating to the synchronous digital hierarchy

ITU-T Recommendation G.965, (03/95) - V-INTERFACES AT THE DIGITAL LOCAL

EXCHANGE (LE) V5.2 INTERFACE (BASED ON 2048 kbit/s) FOR THE
SUPPORT OF ACCESS NETWORK (AN)

ITU-T Recommendation H.225.0 (11/00) - Call signalling protocols and media stream
packetization for packet-based multimedia communication systems

ITU-T Recommendation H.323 (02/98) - Packet based multimedia communication system

ITU-T Recommendation H.245 (02/00) - Control protocol for multimedia communication

ITU-T Recommendation H.248 (10/00) - Gateway Control Protocol

CCITT Recommendation I.233.1 (1991), Frame mode bearer services: ISDN frame
relaying bearer service.

ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer specification:

Type 1 AAL

ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) type 2
specification

ITU-T Recommendation I.363.5 (08/96) - B-ISDN ATM Adaptation Layer specification:

Type 5 AAL

ITU-T Recommendation M.3100 (07/95) Generic Network Information Model

ITU-T Recommendation Q.2 (11/88) - Signal receivers for automatic and semi-automatic
working, used for manual working

ITU-T Recommendation Q.55 (12/99) Signalling Between Signal Processing Network

Equipment (SPNE) and International Switching Centres (ISC)

ITU-T Recommendation Q.109 (11/88) - Transmission of the answer signal in international

exchanges

ITU-T Recommendation Q.115 (12/99) - Logic for the control of echo control devices

ITU-T Recommendation Q.400 (11/88) - Forward line signals

Recommendation T.38 (06/98) - Procedures for real-time Group 3 facsimile

communication over IP networks

ITU-T Recommendation V.18 (11/00) - Operational and interworking requirements for

DCES operating in the text telephone mode

IEEE Standard 802-1990 - IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

IETF RFC 1332 (05/92), The PPP Internet Protocol Control Protocol, (Proposed Standard)
IETF RFC 1661 (07/94) The Point-to-Point Protocol (PPP) (Standard)

IETF RFC 1812 (06/95), Requirements for IP Version 4 Routers, June 1995 (Proposed
Standard)

IETF RFC 1889 (01/96), RTP: A Transport Protocol for Real-Time Applications (Proposed
Standard)

IETF RFC 2131 (03/97), Dynamic Host Configuration Protocol, (Draft Standard)

IETF RFC 2225 (04/98), Classical IP and ARP over ATM, (Proposed Standard)

IETF RFC 2427 (09/88) Multiprotocol Interconnect over Frame Relay (Standard)

IETF RFC 2579 (04/99) Textual Conventions for SMIv2 (Standard)

IETF RFC 2615 (06/99) PPP over SONET/SDH (Proposed Standard)

IETF RFC 2684 (09/99), Multiprotocol Encapsulation over ATM Adaption Layer 5,
(Proposed Standard)

IETF RFC 2719 (10/99), Framework Architecture for Signalling Transport, (Informational)

IETF RFC 2833 (05/00), RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals, (Proposed Standard)

ISO/IEC TR 8802-1:1997 Information technology -- Telecommunications and information

exchange between systems -- Local and metropolitan area networks -- Specific
requirements -- Part 1: Overview of Local Area Network Standards

ISO/IEC 8802-3:2000 Information technology -- Telecommunications and information

exchange between systems -- Local and metropolitan area networks -- Specific
requirements -- Part 3: Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications

1.2

Informative References

ITU-T Recommendation G.806 (10/00) Characteristics of transport equipment

Description methodology and generic functionality

ITU-T Recommendation Y.1310 (02/00), Transport of IP Over ATM In Public Networks

ITU-T Recommendation Q.931 (05/98) ISDN User-Network Interface Layer 3

Specification for Basic Call Control

ITU-T Recommendation V.32 (03/93), A family of 2-wire, duplex modems operating at

data signalling rates of up to 9600 bit/s for use on the general switched telephone network
and on leased telephone-type circuits

ITU-T Recommendation V.34 (02/98), A modem operating at data signalling rates of up to

33 600 bit/s for use on the general switched telephone network and on leased point-topoint 2-wire telephone-type circuits

IETF RFC 2472 - IP Version 6 over PPP( proposed standard)

1.3

Terms and Definitions

For terms and definitions not appearing in this section, see Recommendation G.701 (03/93),
Vocabulary of Digital Transmission and Multiplexing and Pulse Code Modulation (PCM) Terms.
general switched telephone network (GSTN):

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

This network includes ATM, PSTN, ISDN, wireless networks and private networks.
media gateway (MG):
The media gateway converts media provided in one type of network to the format required in
another type of network. For example, a MG could terminate bearer channels from a switched
circuit network (e.g., DS0s) and media streams from a packet network (e.g., RTP streams in an IP
network). This gateway may be capable of processing audio, video and T.120 alone or in any
combination, and will be capable of full duplex media translations. The MG may also play
audio/video messages and performs other IVR functions, or may perform media conferencing. For
the purpose of this Recommendation, the term media gateway refers to a voice gateway.
media gateway controller (MGC):
Controls the parts of the call state that pertain to connection control for media channels in a media
gateway
simple endpoint type devices (SET):
See H.323 Annex F.
TIGIN Gateway
A voice gateway complying with this Recommendation
voice gateway (VG):
A voice gateway is a subset of a media gateway that deals with voice and voiceband traffic only, and
not data or video traffic.
1.4

Abbreviations

This Recommendation uses the following abbreviations.

ATM

Asynchronous Transfer Mode

DHCP Dynamic Host Configuration Protocol

DS0

Digital Signal, level 0

DTMF Dual Tone Multi-Frequency

DTX

Discontinuous Transmission

GSTN General Switched Telephone Network

IETF

Internet Engineering Task Force

IP

Internet Protocol

ITU

International Telecommunication Union

MG

Media Gateway

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

MGC

Media Gateway Controller

MGCP Media Gateway Control Protocol

NMS

Network Management System

PCC

Per Call Control

PCM

Pulse Code Modulation

PPP

Point to Point Protocol

PSTN Public Switched Telephone Network

RTCP Real Time Control Protocol
RTP

Real Time Protocol

SCN

Switched Circuit Network

SDH

Synchronous Data Hierarchy

SET

Simple Endpoint Type

SNMP Simple Network Management Protocol

TCP

Transmission Control Protocol

TDM

Time Division Multiplex(ing)

TFO

Tandem Free Operation

TIGIN Transport Network Equipment for Interconnecting GSTN and IP Networks

TMN

Telecommunication Management Network

UDP

User Datagram Protocol

VBD

Voiceband Data

VoIP

Voice over IP

General Description of GSTN Transport Network Equipment for Interconnecting GSTN

and IP Networks (TIGIN)

In practice, a TIGIN gateway may be composed of multiple pieces of equipment, each with
specialized functions, such as signalling interfaces, voice compression/decompression, packetization,
etc. Figure 1 illustrates some of the functions performed in a gateway. This Recommendation does
not specify how these functions are to be performed, nor does it specify the specific
interconnections, which may be implemented between functions. It is recognized that the functions
of a media gateway controller (MGC) may be combined with those of a TIGIN gateway in the same
physical device. In this situation, certain interfaces described in this Recommendation may not be
present. This Recommendation does not cover the requirements of such a controller.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

note 1

Call Control
note 4
TDM
Bearer
Interface
note 4
TDM
Signalling
Interface
note 4
Q.55 Signalling
Interface

note 1

Bearer Control

note 1

Network Management
System

Synchronization
Time Division
Multiplexed
Network
Interface

Signal
Processing
Functions
TDM Signalling
Interface
note 2
Q.55 Echo
Canceller control
Interface
note 3

Backhaul Signalling via H.248

or MGCP (optional) Note 1.

P
a
c
k
e
t
i
z
e
r

Internet
Protocol
Interface

IP Bearer
Interface
note 1

Switching Function

note 1: these may or may not share the same external interface
note 2: optional. Only required when inband signalling on TDM interface is supported.
note 3: optional
note 4: these may or may not share the same external interface

Figure 1/G.799.1: Illustration of functions performed by a TIGIN gateway.

Each of the elements included in the above block diagram is described in detail in the following
sections.
3

Interfaces

The overall relationship between the TIGIN gateway and other devices and protocols in the network
is illustrated in figure 2.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

SS7

GSTN
TDM
Network

- Signalling transport over IP

- SIP
MEDIA
GATEWAY
SIGNALLING
CONTROLLER
GATEWAY
(MGC)

H.323
Gateway

- H.248, see section 3.3.1

- MGCP (optional)

Signalling
transport over IP
See section 3.3.2

TIGIN
GATEWAY
(G.799.1)
Functionality
(see section 4)

Network
Optimized for
Internet
Protocol

IP Bearer Interface
(see section 3.1)

TDM Bearer Interface

(see section 3.2)

Management Interface (see

section 3.5)

TDM Signalling Interface

(see section 3.4)

Figure 2/G.799.1 Relationship between TIGIN gateway and other IP-related standards

3.1

IP Bearer Interfaces

The IP interface block in the block diagram in Figure 1 provides the transmission facility interface for
the network element to the IP network. It terminates all the lower layers and much or all of the
upper layers of the incoming signal from the IP network. It also performs alarm detection and
performance monitoring of the interface layers. It then sends the data to the Packetizer block for
further processing. It performs the inverse function in the transmitting direction towards the IP
network.
The layers of the IP bearer interface should conform to at least one of the interface types from the
following section. Voice and voiceband data and higher layers on this interface should conform to
that specified in H.323. Higher layer protocols may include any of the following: TRP, UDP, and
RTCP. Facsimile traffic may use ITU-T Recommendation T.38.
Figure 3.1 shows layers of TIGIN IP bearer interface model.
Application Transparent Voice

Upper
Layers
Transport
Layer

Tones

RTP

FAX TIGIN
Control

Management

Signalling
System No.
7 Transport

T.38

SNMP/TMN

M2UA*

H.248/MGCP

UDP (User Datagram Protocol)

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

SCTP

06.10.15

10

IP Layer

IP (Internet Protocol)

Lower
Layers

Physical and Data Link

Figure 3/G.799.1- IP Bearer Interface Protocol Layers

* Editors Note: This depends upon the results of a liaison sent to SG11 and IETF.
Figure 3 shows only a basic stack. Additional function for Quality of Service (QoS), security, header
compression, etc. may be added.
3.1.1 Lower Layers
This Recommendation does not restrict using of any lower layer protocol intended for IP packet
transmission and approved by an internationally recognized standards body.
Lower layer interface performs link protection, alarm detection and performance monitoring of the
interface layers as define in appropriate standards.
3.1.2 IP Layer
IP protocol should conform to IETF RFC 791, RFC 950, RFC 919 and RFC 920.
Support of MPLS is for further study.
Support of IP V6 is for further study.
IP network topology, IP packet distribution and routing protocols are not the subject of this
Recommendation.
3.1.3 Transport Layer
UDP protocol is used as transport layer protocol and it should conform to IETF RFC 768.
SCTP protocol is used for transport PSTN signalling messages over IP networks and it should
conform to IETF RFC 2960.
TCP protocol (RFC 793) may be optionally used for non time critical applications.
3.1.4 Upper Layers
RTP protocol is used for transparent signal transmission and for voice and tones transmission as
IETF RFC 1889 describes. IETF RFC 1889 also defines RTCP (Real Time Control Protocol) as a
companion control protocol for RTP.
A TIGIN gateway should support both transparent G.711 and T.38 fax protocol for fax transmission.
Other types of application interfaces are described later in this section.
3.1.5 Layer 3
Layer 3 protocols may include any of the following:
DHCP - IETF RFC 2131
IP V4 Router - IETF RFC 1812

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

11

Support of IP V6 (IETF RFC 2472 - IP Version 6 over PPP ) is for further study.
3.1.6 Layer 2
Layer 2 protocols may include any of the following:
PPP (x.ip)
Frame Relay I.233ATM I.363.1, I.363.2, I.363.5
IP over PPP, as per IETF - RFC 1661
IP over Frame Relay, as per IETF -

RFC 2427

IP over ATMIP over PPP over SDH, as per IETF - RFC 2615
3.1.7 Layer 1
Layer 1 protocols may include any of the following:
G.704, G.707, G.703, G.957, ISO/IEC 8802-3, ISO/IEC 8802-1
3.2

GSTN (TDM) Bearer Interfaces

The TDM interface block in the block diagram in Figure 1 provides the transmission facility interface
for the network element to the GSTN network. The physical layer of the TDM bearer interface
should consist of at least one of the interface types in the table below. Voice and voiceband coding
on this interface should conform to G. 711. Mechanisms for tandem coder avoidance are for further
study.
Layer 1 G.704, G.707, G.703, G.806, G.957
3.3

Call Control Interfaces

3.3.1 Per Call Control (PCC)

PCC describes the interface between the TIGIN and the MGC that provides for real-time per call
control of TIGIN. The MGC is the control element that interworks between the signalling network
and TIGIN, providing the TIGIN with the real-time per-call control signals.
The PCC protocol defines the messaging between the MGC and TIGIN and allows for the following
capabilities such as:

Establish, modify, and release connections within the TIGIN, including originating and
terminating addresses (e.g. TDM-TDM, TDM-IP)

Query the status of connections or resources within the TIGIN

Notification of call-related alarms or failures

Continuity Check

Transfer of certain GSTN Signalling information for MF and CAS based protocols carried on
the TDM link

PCC allows the MGC to specify the internal TIGIN resources required in the connection path (Echo
control, DTMF detection, Modem/Fax detection, etc.). It also allows for the setting of per call

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

12

features and parameters required based on call type and interoperability needs. . These parameters
may include some or all of the followingsuch as:

Real time call processing event notification, including the control of echo cancellers

Silence Suppression activation

Comfort Noise Generation

Jitter Buffer size

Selection of and/or negotiation of codec (e.g. G.711, G.723.1, G.729). Selection of different
codecs on the GSTN and IP interfaces implies performing a transcoding function (e.g., G.711
to G.729). It is recommended that ITU-T Recommendation H.245 be used for codec
negotiation.

Packet size selection

Mechanisms for supporting the above features are for further study. Selection of these
mechanisms will affect voice quality. See sections 4.1, 4.2 & 4.3 for more information on this
topic.
Upon completion of a call, as specified in H.248 PCC protocols, TIGIN should be capable of
supplying, upon request, statistics related to the call, for example:

Number of packets sent

Number of octets sent

Number of packets received

Number of octets received

Average Inter-arrival jitter

Average transmit delay

Average receive delay

Packet loss

Mechanisms for supporting the above features are for further study. Selection of these mechanisms
will affect voice quality. See sections 4.1, 4.2 & 4.3 for more information on this topic.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

13

The upper layer protocol used should conform to one of the following:

H.248

MGCP (RFC 2705) optional

Note: If H.248 is not used, then certain gateway capability such as NLP control of integrated echo
cancellers may not be available.
. Lower layer protocols should conform to one of those listed in sections 3.1.1, 3.1.2, or 3.1.3. Use
of the MGCP protocol on this interface is for further study.
Examples of protocols that may be used on this interface include:

IEEE Std 802-1990, IEEE Standards for Local and Metropolitan Area Networks: Overview
and Architecture

1 Gbps Ethernet

TCP or UDP/IP

Any link layer protocol approved by an internationally recognized standards body

The PCC interface may share the same circuit as the IP bearer interface.
3.3.2 Signalling over IP
A framework architecture for signalling transport over IP networks may be found in IETF RFC2719.
3.3.2.1 Out-of-band signalling
As described in H.248, TIGIN interfaces to the Signalling Gateway through the Media Gateway
Controller (which is referred in H.248 as the Call Agent). As a consequence, the Media Gateway
Controller implements the "signalling" layers of the H.323 standard, and presents itself as an "H.323
Gatekeeper" or as one or more "H.323 Endpoints" to the H.323 systems.
Signalling exchanges with the Media Gateway Controller are done through H.225/RAS and
H.225/Q.931.
Possible negotiation of logical channels and transmission parameters with the Media Gateway
Controller are done through H.245.
3.3.2.2 In-band signalling
There are some applications that require support for in-band signalling:

Internet telephony gateway that detects the DTMF signals on the incoming circuits and sends
the appropriate digits as RTP payload (see IETF RFC-2833)

Internet end system such as an "Internet phone" can emulate DTMF functionality without
generating precise tone pairs and without imposing the burden of tone recognition on the
receiver

When the coder used destroys the in-band signalling information (like G.723.1)

In such cases, the support for in-band signalling will be done in accordance with IETF RFC-2833.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

14

3.3.2.3 Signalling Backhaul

The Signalling Backhaul interface exists between the TIGIN Gateway and the Media
Gateway Controller. Its purpose is to transfer GSTN signalling information that arrives at the
TDM interfaces of the TIGIN Gateway to the MGC and vice versa.
In some cases the Signalling Backhaul interface exists between the TIGIN Gateway and the
Signalling Gateway. In such cases the requirements on the TIGIN Gateway are no different
from the general case (termination on MGC).
Signalling Backhaul exists for two families of GSTN signalling, namely Common Channel
Signalling and MF/CAS Based Signalling. Each case is handled in a different manner.
3.3.2.3.1 Signalling Backhaul for Signalling System No. 7
For backhaul of common channel signalling a common reliable transport protocol, SCTP
(RFC 2960), may be used.
For encapsulating the higher layers of GSTN signalling protocols, MTP3 (see Q.704) the
MTP2 User Adaptation Layer (M2UA see draft-ietf-sigtran-m2ua-10.txt) may be used.
3.3.2.3.2 Signalling Backhaul for MF and CAS-based Signalling
For the backhaul of the call control information associated with MF and CAS based GSTN
signalling protocols (such as R1, R2, robbed bit signalling) then H.248 or MGCP packages
defined for the Per Call Control protocols defined in 3.3.1 may be used.
Note that the information carried in the PCC packages is a translation of the GSTN signalling
and not a copy of the signalling, as would be the case for Signalling System No. 7 backhaul.
3.4

TDM Signalling Interface

TDM Bearer signalling is accomplished by means of signalling on the TDM bearer interface.
TDM Bearer Signalling may be accomplished by means of signalling on the TDM bearer
interface. TDM bearer signalling interfaces supported by this recommendation should
conform to national standards.
The following paragraphs describe the responsibility of the TIGIN Gateway when it supports
TDM Bearer Signalling interfaces.

3.4.1 SS7 Signalling Links

When SS7 signalling links (e.g. associated links carried in E1 TS16) are connected to the
TIGIN Gateway then the Gateway should terminate the MTP Link layer (MTP2) in
accordance with Q.703 and should transport the higher layers (MTP3 and above) between
itself and the MGC/SG as described in 3.3.2.3.1.
If non-associated links are deployed in the GSTN then these will not be handled by the
TIGIN Gateway as they will be delivered directly to the SG or MGC.
3.4.2 CAS & MF Based Signalling
When CAS and MF based signalling is connected to the TIGIN Gateway (such as R1, R2,
robbed bit signalling) then the Gateway should detect/generate the signalling and provide
interworking between the signalling and H.248/MGCP as described in 3.3.2.3.2.
TDM signalling interfaces supported by this Recommendation should conform to national standards
and are for future study.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

15

If SS7 A link is used, then signalling on the TDM bearer interface is not used.
Support of the following and other signalling types is for further study:

SS7 Signalling

Q.931

R1 Q.2

R2 Q.400

V 5.2 (G.965)

Channel Associated as per G.704

3.5

Management Interface

Both TMN and SNMP management interfaces are for further study.
4
4.1

TIGIN Functionality
Signal Processing Functions

The network element supports voice-related features as described in this section. Some or all of the
voice feature functions listed in this section may be utilized during a call. The PCC message specifies
which functions should be used on a call.
As an example, silence suppression and comfort noise generation may be requested on a call that
uses G.711 coding. The network element in that case would take the GSTN data, interpret it as
G.711 coding and generate packets to the IP network using G.711 coding only if it detects speech
activity. In the reverse direction, it would receive packets from the IP network, interpret them as
G.711 encoded PCM, convert the packets into a synchronous (TDM) stream and send it to the
GSTN network. During the time packets are not received it would generate comfort noise G.711
PCM values and send it to the GSTN network.
In addition, other signal processing features supported by the network element could include the
following:

Continuity Check tone generation and detection

Continuity Check loop-back

Signal processing functions may affect voice quality. See sections 3.3.1 & 4.3 for more information
on this topic.
4.1.1 Echo Control
In compliance with ITU-T Recommendation G.177, Transmission Planning for voiceband services
over hybrid internet/PSTN connections, a voice-over-IP connection traversing a hybrid is required to
include a G.168 compliant echo canceller. Since the echo canceller needs to have a constant delay for
its echo path, it should be placed so that the echo path is on the TDM side of the interface that
includes the hybrid. Issues that need to be addressed are:

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

16

Issues related to modem and other voice-band data signals

Tail Capacity

Network Operators and Service Providers should ensure that echo cancellation is applied in the most
appropriate location for the specific configuration. The echo canceller should be associated with the
TIGIN gateway in one of three possible configurations, as outlined in the following sections.
It should be reinforced that all voice connections involving GSTN to IP interworking involving a
hybrid require echo cancellation and the Network Operator or Service Provided choosing to utilize
either configuration B or C below should ensure that an echo canceller is provisioned on the TDM
bearer side of the hybrid Internet/ GSTN connection.
4.1.1.1 TIGIN Internal Echo Control Configuration A
In this configuration the echo canceller is integrated into the TIGIN gateway itself as shown in
Figure 3. With this configuration, H.248 messages conveying are generated by the Q.115 echo
control logic in the MGC and are sent to the TIGIN gateway. The TIGIN gateway then directly
controls the internal echo canceller function in accordance with the messages received. For this
configuration, the echo canceller function within the TIGIN gateway is required and the Q.55/Q.52
process is optional but not used.

SS7

MEDIA
GATEWAY
CONTROLLER
(MGC)

SIGNALLING
GATEWAY

Q.115 echo control logic

H.248,
MGCP (optional)

GSTN
TDM
Network
TDM bearer

Echo

Echo
canceller
function

TIGIN
GATEWAY
(G.799.1)

IP Network

IP bearer

Figure 3/G.799.1: Echo canceller integrated into TIGIN gateway Configuration A

4.1.1.2 TIGIN External Echo Control With Q.55/Q.52 Control Configuration B

In this configuration the echo canceller is directly associated with and controlled by the TIGIN
gateway, as shown in Figure 4 below. With this configuration, H.248 messages conveying are
generated by the Q.115 echo control logic information in the MGC and are sent to the TIGIN
gateway. The TIGIN gateway then converts the messages into appropriate protocol data units and
sends them to the associated external echo canceller. The conversion processes are described in sub-

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

17

section 4.1.1.2.1. For this configuration, the echo canceller function within the TIGIN gateway is
optional but not used, and the Q.55 process is mandatory.

SS7

MEDIA
GATEWAY
CONTROLLER
(MGC)

SIGNALLING
GATEWAY

Q.115 echo control logic

GSTN
TDM
Network

Echo

H.248,
MGCP (optional)
TDM bearer
TIGIN
Associated
Echo
canceller

Q.55
process

TIGIN
GATEWAY
(G.799.1)

IP Network

IP bearer
Q.55 control
protocol

Echo canceller association

Figure 4/G.799.1: TIGIN External Echo Control With Q.55 Control

Configuration B

4.1.1.2.1 Echo Canceller Control Procedures

When the echo cancellation function is not integrated into the TIGIN gateway, but is located on a
TDM trunk of the gateway and is controlled by the TIGIN gateway, the following procedures should
be used. These procedures define the mapping between H.248 messages received by the TIGIN
gateway from the media gateway controller and Q.55 protocol data units transmitted to the
associated external echo canceller.
Echo canceller enable procedure:
When the H.248 package responsible for controlling echo cancellers is received with the value set to
on for a specific TDM DS0 channel, the Q.55 protocol data unit enable echo cancellation for
channel n, as defined in Annex H/Q.55, where n is the DS0 channel specified by the H.248
message, is transmitted on the Q.55 echo control interface of the TIGIN gateway.
Echo canceller disable procedure:
When the H.248 package responsible for controlling echo cancellers is received with the value set to
off for a specific TDM DS0 channel, the Q.55 protocol data unit disable echo cancellation for
channel n, as defined in Annex H/Q.55, where n is the DS0 channel specified by the H.248
message, is transmitted on the Q.55 echo control interface of the TIGIN gateway.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

18

4.1.1.3 GSTN Switch Associated Echo Control Configuration C

In this configuration the echo canceller is not directly associated with or controlled by the TIGIN
gateway. Instead, the echo canceller is associated with and may be controlled by a switch in the
GSTN as shown in Figure 5 below.
If the GSTN switch controls the echo canceller, it may either be controlled via a Q.55 interface, or,
via some other control mechanism. If the GSTN switch controls the associated echo canceller via
Q.55, echo control messages are generated as a result ofby the Q.115 echo control logic information
in the GSTN switch and are sent to the GSTN switch-associated echo canceller. For this
configuration, while the echo canceller function and/or Q.55 process within the TIGIN gateway may
exist, they are not used.
It should be noted that the Q.115 echo control logic in the MGC will request the disablinge of a
canceller associated with the TIGIN gateway, if any is present, as in this particular case one has
already been provisioned in the GSTN.

SIGNALLING
GATEWAY

SS7

Q.115 echo
control logic

Echo canceller
association
H.248,
MGCP (optional)

TDM bearer

GSTN
TDM
Network

Q.55 (or
other)
control
process

MEDIA
GATEWAY
CONTROLLER
(MGC)
[Q.115 echo control logic]

GSTN switch
Associated
Echo
Canceller

TIGIN
GATEWAY
(G.799.1)

Echo
Q.55 (or other)
control protocol

IP Network

IP bearer

Figure 5/G.799.1: Non-TIGIN Associated Echo Control Configuration C

4.1.1.4 Media Gateway Controller Direct Control - Configuration D

It is possible for the MGC to directly control the echo canceller, without going through the media
gateway, as shown in figure 6. In this scenario, there is a direct connection vie an H.248 connection
from the MGC to the echo canceller.
Echo control messages are generated by the Q.115 echo control logic in the MGC and are sent to
the echo canceller over an H.248 connection. As in the above configuration, while the echo canceller
function and/or Q.55 process within the TIGIN gateway may exist, they are not used. It should be
noted that the Q.115 echo control logic in the MGC will disable a canceller integrated into the

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

19

TIGIN gateway, if any is present, as in this particular case one has already been provisioned in the
GSTN.

SS7

SIGNALLING
GATEWAY

MEDIA
GATEWAY
CONTROLLER
(MGC)
[Q.115 echo control logic]

Q.115 echo
control logic

H.248,
MGCP

GSTN
TDM
Network

Q.55 (or
other)
control
process

Echo
Canceller
Echo

TIGIN
GATEWAY
(G.799.1)

IP Network

IP bearer
TDM bearer

Figure 6/G.799.1: Direct Control of Echo Canceller by MGC Configuration D

4.1.2 Voice Coding

Voice codec used (e.g. G.711, G.723.1, G.729)
As a minimum, a TIGIN gateway should include a G.711 codec (for both A and mu-laws). In order
to allow tandem coder avoidance for calls from and to cellular networks, the TIGIN gateway should
optionally include voice codecs commonly used in cellular networks. The included codecs should be
those used in the specific cellular network to which the gateway is directly attached.
Delay caused by voice coding should be kept to a minimum (see G.114 Annex A for calculation of
delay figures).
Voice coding (e.g. G.729 through G.711 to G.726 )
There should be a method of ensuring synchronous reset capability of low bit rate voice coders. For
codecs of this type, using an external synchronous reset will be beneficial to voice quality,
particularly at the transient from silence to active speech when the codec is used in the DTX
condition. If generic SID comfort noise insertion is used with a low bit rate coder, synchronous reset
between encoder and decoder should be employed.
Delay caused by voice coding should be kept to a minimum.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

20

4.1.3 Digital Speech Interpolation

Silence suppression and comfort noise generation can be either internal or external to the codec.
Internal Silence Suppression and Comfort Noise Generation
Silence Suppression
Silence suppression should be supported according to the speech codecing used, e.g. G.711
Appendix II, G.729 Annex B for G.729, or G.723.1 Annex A for G.723.
Comfort Noise Generation
Comfort noise generation should be supported according to the speech codec coding used, e.g.
G.711 Appendix II for G.711, G.729 Annex B for G.729, or G723.1 Annex A for G.723.1.
External Silence Suppression and Comfort Noise Generation
Voice coding (e.g. G.729 through G.711 to G.726 )
There should be a method of ensuring synchronous reset capability between encoder and decoder of
G.726, G.727, G.728 and G.729 when external comfort noise generation is used with these codecs.
In these cases an external synchronous reset will be beneficial to voice quality, particularly at the
transient from silence to active speech when the codec is used in the DTX condition. If generic SID
comfort noise insertion is used with a low bit rate coder, synchronous reset between encoder and
decoder should be employed.

4.1.4 Tones and Announcements

Tone generation
Tone generation is for further study.
Tone detection
Tone detection is for further study.
Announcements (optional)
Support of announcements is for further study.
4.1.5 Facsimile and data handling
Fax modem bypass
Fax modem bypass is for further study.
Fax modem relay
Fax modem relay is for further study.
Data modem bypass
Data modem bypass is for further study.
Data modem relay
Data modem relay is for further study.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

21

4.1.6 Speech Reconstruction

Voice coders in a TIGIN gateway should follow established rules for speech reconstruction under
conditions of lost packets. Packet loss concealment techniques should be provided for all codecs
supported by the TIGIN Gateway, e.g., G.711 Appendix II, G.729, G.723.1and G.728 Annex I. It
should be noted that G.729 and G.723.1 have packet loss concealment capabilities embedded into
their respective decoders.
4.1.7 Voice encryption
Methods of supporting voice encryption are for further study.
4.1.8 Distributed Speech Recognition and Distributed Speaker Verification
Methods of supporting Distributed Speech Recognition and Distributed Speaker Verification are for
further study.
4.1.9 GSTN signal type classification
The use of speech compression algorithms may impair non-voice signals (e.g. Voiceband Data signals
(VBD) or DTMF). A classification process should be provided to distinguish between the following
types of signals existing in GSTN:

Voice signals.

Voiceband Data signals (e.g.: Facsimile machines, Dial-Up modems etc.)

The classification process comprises of a set of detectors and a State-Machine.

4.1.10 Detectors
The primary method of new call detection is via messages received from the per-call-control
signalling link to the MGC, via H.248 or other signalling over IP (for further study). If new call
indication is not available through this link, then the TIGIN gateway will determine new call status
through signal processing of the speech channel.
The media gateway pre-processing function should use the following detectors:

New Call Indicator

Speech Detector

Voiceband (VBD) Detectors (e.g.: V.34 detector, V.32 detector, Facsimile detector, etc.).

End of VBD Detectors.

4.1.11 State Machine

The state machine illustrated in the figure 7 defines the two basic states and the transition conditions.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

22

VBD Detectors
Voice

VBD
New Call Detectors
or
Speech Detector
or
End of VBD Detectors

Figure 7/G.799.1 - Signal Classification process State Machine diagram

4.1.11.1 Voice state

Voice State is the default state of the Signal Classification process State Machine.

4.1.11.2 VBD state

The transition from Voice state to VBD state is performed when the VBD Detectors classify an input
signal as VBD.
When End of VBD Detectors find the end of the VBD transmission, or a speech signal is detected by
the Speech Detector or there is a New-Call indication, a transition to the Voice State is performed.
4.1.12 Input pre-processing
The input signal pre-processing function examines the activity/type and state transitions originating
from the intermediate trunk classification process.
According to the classification process results, the media gateway should perform the necessary
operations to convert the signals to IP according to the requirements of H.323.
Methods of compressing fax, modem and other data signals are for further study.

4.2

Voiceband Quality

See section 4.1.3 for handling of silence suppression and comfort noise generation. ITU-T
Recommendation G.177 should be followed to ensure adequate end-to-end speech quality.
Definitions of categories of voice transmission quality may be found in ITU-T Recommendation
G.109.
4.2.1 Tandem Free Operation
It is highly recommended that a single codec pair be used end to end.
High quality speech codecs operating at low to medium rates (4 to 16 kbps) have been a primary
factor in making packet voice networks, including VoIP and Wireless networks practical. As different
packet networks will be interfaced with one another, the tandeming of speech codecs will be very

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

23

common in the near future. Tandem speech codecs may degrade speech quality considerably. As a
result, many tandem free operation (TFO) standards have been developed under different standard
organizations to avoid additional speech coding and decoding in a communication link. The TFO
standards were based on the same approach and were originally intended for Wireless services.
However, TFO standards are also applicable to any packetized networks including IP networks.
To avoid tandeming speech codecs and improve speech quality, a G.799.1 gateway should support
the TFO protocol as defined in the following standards:
3GPP2 A.S0004-0.1, 3GPP2 Tandem Free Operation Specification, Version 1.0.0,
and
3G TS 28.062, Inband Tandem Free Operation (TFO) of Speech Codes; Stage 3 Service
Description
When G.799.1 gateways interconnect mobile networks using the first of these standards at one end
and the second at the other end, interworking of the two TFO techniques is necessary. To provide
high quality digitized voice services through seamless interworking across different networks, there
is a need to consolidate these different TFO standards. This is a subject for further study.
4.2.2 Packet size selection
The choice of packet size is a trade-off between transport efficiency, quality and delay. The delay
associated with codec processing and packetization should be kept as short as possible. Gateways
should adhere to ITU-T Recommendation G.177 in this regard. When multiple frames of a speech
codec are allocated to the same packet, packet loss concealment techniques become less effective
and as a result may possibly lower end-to-end speech quality when packet loss is encountered.Packet
size should be an integer multiple ofmatched to the codec frame length. To accomplish this objective
when G.729 or G.729A is used, two frames per packet should be considered as the maximum packet
size. Similarly, G.711 may be used with packet sizes of 10 ms (80 frames) or 20 ms (160 frames) to
achieve this objective. Finally, when G.723.1 is used, only one frame should be included in each
packet. The 7.5 ms look-ahead and the 30 ms frame size of G.723.1 results in a combined voice
buffering and processing delay of between 37.5 ms and 67.5 ms (depending on the computational
power available), thus contributing to difficulty of interactive communications.
The 30 ms frame size of G.723.1 results in voice collection and coding delay of at least 60 ms,
contributing to difficulty of interactive communications.

4.3

Voiceband Data Quality

4.3.1 Voiceband data modems

Methods of ensuring quality operation with voiceband data modems are for further study.
4.3.2 Facsimile
Methods of ensuring quality operation with facsimile traffic are for further study.
4.3.3 Text telephones
Methods of ensuring quality operation with text telephones are for further study.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

24

4.4

Switching

The TIGIN Gateway shall provide the ability to switch calls in the direction of the PSTN and in the
direction of the IP network. Switch control based on general call control and allows establish,
modify and release connection within the TIGIN.
Some details on methods of switching, and a discussion on switching philosophy are included in
MSF-ARCH-001.00-FINAL IA Multiservice Switching Forum Implementation Agreement of the
Multiservice Switching Forum.
Editors Note: The above reference document may become normative text depending on Q7s
conclusions on this issue following discussion on the Q7 discussion board and/or an interim
meeting.
This item is for further study.
4.5

Conference Bridging

A TIGIN gateway is not required to support conference bridging.

4.6

Clock Recovery and synchronization

A TIGIN gateway requires a clock recovery circuit that would allow it to generate a precise local
clock and keep this clock synchronised to a remote TDM clock. A synchronisation mechanism
improves the quality of voice at the reception and it is vital for the transport of data through RTP
trunking.
Timing information may be transported between two Circuit Switch domains:

over the IP network (using the timestamp mechanism provided by the RTP encapsulation)

other methods (e.g. those used for hierarchical timing distribution in SDH networks as
specified in G.813, "Timing characteristics of SDH equipment slave clocks (SEC) ")

For interoperability reasons, TIGIN implementations which use methods for synchronising the local
TDM clock based on timing information transported over the IP networks, should be based on
information made available by the approved protocols rather then using proprietary schemes. Such
information, for example, is the RTP timestamp (see RFC 1889). Methods of determining the
resolution of the timestamp are for future study.
Similar to the case of hierarchical master-slave SCN synchronisation methods, it is recommended
that a primary and a secondary synchronisation reference input be provided to each clock (e.g. two
independent sources of IP/UDP/RTP packets that could be used for extracting timing information).
The remainder of this section is for information purposes only:
As described in IETF RFC-1889 the randomly initialised RTP timestamp is a 32-bit field that must be
updated such that it reflects the sampling instance of the first octet in the RTP data packet.
Consequently, there is a direct relation between the rate of the TDM clock at the sending TIGIN and
the rate of the RTP packets being filled up, sent over the IP network, and, the rate of their arrival at
the receiving TIGIN. At the receive end, the arrival of an RTP packet could be timestamped based on
the TDM clock of the Circuit Switch domain interfacing to the local (receiving) TIGIN.
The difference between the packet arrival times and the difference between RTP packet timestamps
could be algorithmically processed to extract information for adjusting the local TDM clock- see
IETF RFC-2833-RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

25

4.7

Management System

The Management System Interface performs the functions to administer the system on a non-real
time (non per-call) basis with respect to the following subsections. Further details for each of the
management functions outlined in the following sub-sections are included in the general (e.g., ITU-T
M.3100) and technology specific (e.g., ITU-T G.784, IETF RFC 2579) recommendations.
Support of TMN and SNMP management systems are for further study.
4.7.1 Configuration Management
For further study. Issues to be considered include the management of:

TDM interface features such as line rates, frame formats

IP interface features

Packetizer options such packet loss mitigation scheme, which are not needed to be controlled on
a per call basis.

echo canceller options

Voice feature options

clock recovery

and all other configurable parameters

4.7.2 Fault Management

For further study. Issues to be considered include the management of:

Equipment faults

Facility faults at TDM and IP sides

4.7.3 Performance Management

For further study. Issues to be considered include:

Facility performance monitoring

Congestion control

Traffic management

4.7.4 Security Management

Security management including key management is for further study.
4.7.5 Accounting
No accounting functions are supported in a TIGIN gateway. Note that this does not imply that
signals such as on-hook, off-hook, etc., that support or provide information necessary for certain
accounting type functions (e.g., call billing) do not need to be conveyed or supported. Rather, that
the TIGIN Gateway itself does not provide any direct accounting functionality such as call billing,
etc.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

26

4.7.6 Maintenance Testing

The TIGIN Gateway shall provide the ability to monitor calls and place test calls in the direction of
the GSTN and in the direction of the IP network.
The monitor and intrusive access point shall provide a test access point on a per TIGIN Gateway
basis and not on a per-shelf or per-rack basis, i.e., one per TIGIN Gateway. This test access
capability shall support all features and services provided by the TIGIN Gateway.
4.7.6.1 Non-intrusive Monitor Access:
The monitor access shall provide the ability to connect to a specific port/address/call and monitor
one or both directions of an active call simultaneously (figure 8). It shall be possible to monitor a
specific port or connection within the TIGIN Gateway allowing a port to be monitored before a call
is active on the port. When an active call is placed on the port, the monitor shall remain active. The
monitor access may provide either/or a TDM or IP output and will depend on the actual
implementation of the TIGIN Gateway.
In the non-intrusive monitoring case, there is no requirement that signalling be monitored.

TIGIN Gateway
TDM

IP
Test Access Port
(TDM and/or IP)

Figure 8.

Non-intrusive Monitor Access

4.7.6.2 Intrusive Monitor Access:

The intrusive test access shall allow test calls to be made in either direction. The intrusive test
access shall allow the user to connect to a specific port/address and place a call to a destination
either in the direction of the GSTN or the IP network. The intrusive test access may provide
either/or a TDM or IP output and will depend on the actual implementation of the TIGIN Gateway.
In the case where the Test Access Port is TDM (e.g., Figure 9A), a TDM/IP conversion function is
required to access the IP data port or stream.
The specific point within the IP path where access is placed should be the last IP point prior to any
speech processing functions.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

27

Gateway Functions

TDM

IP
TDM / IP

Test Access Port

(TDM )

Figure 9A. Intrusive Test Access TDM Test Access Port

In the case where the Test Access Port is IP (e.g., Figure 9B), a TDM/IP conversion function is
required to access the TDM data port or stream.
The specific point within the TDM path where access is placed should be prior to any speech
processing functions.

Gateway Functions

TDM

IP

TDM / IP

Test Access Port

(IP )

Figure 9B. Intrusive Test Access IP Test Access Port

If TDM is provided, the interface shall be E1/T1 (G.703, G.704) and signalling shall be ISDN, CAS,
R1, or R2, and V 5.2 (Q.931, G.704, Q.300 Q.399, Q.400 Q.499, and G.965). If an IP output
is provided, the interface shall be as specified within section 3.1 of this document (G.799.1) and
signalling shall be accomplished via H.248 signalling messages sent to/from the TIGIN Gateway as
with any other IP port.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

28

In the case of SS7 signalling arrangements, the signalling to set up calls is done via the H.248 path to
the MGC.
The functions provided by the management system should not overlap with those provided by per
call control.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

29

Appendix I: Overview of the location of TIGIN gateways in end to end connections

Figure I1 shows a functional block diagram of transport network equipment for interconnecting
GSTN terminals and IP Terminals (hereinafter abbreviated TIGIN).

(1)
GSTN - TIGIN
signalling

GSTN
Terminal.

GSTN
Terminal.

(2)

GSTN

TIGIN
Gateway
(G.7991.)

IP
Network
to TIGIN
signalling

Network
Optimized
for
Transport
of Internet
Protocol

H.323
Terminal

H.323
Terminal

(3)

(4)

Bearer Interface
signalling

Figure I1: Location of TIGIN and possible connection types of interest in this
Recommendation. Four connection types are shown. See text for details.

The terminals attached to the Internet are assumed to have H.323 functionality from the point of
view of voice and voice-band data transmission. These terminals may be connected to the IP network
via a direct connection (e.g., Ethernet, Token Ring, etc.) or a dial-up connection (e.g., modem and
PPP link). The IP and GSTN sections are interconnected through a GSTN/IP gateway, called a
TIGIN. For convenience, this gateway is designated with a single box in Figure I1.
The specific functions of the gateway will depend on whether the direction of transmission is from
the IP Network to the GSTN or vice versa. In particular, the functions in the gateway include (but
are not limited to):
Call originating on the IP Network and terminating on GSTN

Reception, interpretation and generation of relevant signalling messages

Packet disassembly (including IP stack)

Speech decoder (including error concealment, comfort noise, silence insertion, etc.)

Management or regulation of delay variation

Echo cancellation

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

30

Call originating on the GSTN and terminating on IP Network

Reception, interpretation and generation of relevant signalling messages

Speech encoder (including silence removal, comfort noise decisions, etc.)

Packet assembly (including IP stack)

Management or regulation of delay variation

Echo cancellation

Four connection arrangements are considered in this Recommendation, each of which is shown in
Figure I1. They are:
1. GSTN Terminal H.323 Terminal (GSTN Terminal GSTN TIGIN IP Network
H.323 Terminal)
2. H.323 Terminal GSTN Terminal (H.323 Terminal IP Network TIGIN GSTN
GSTN Terminal)
3. H.323 Terminal H.323 Terminal (H.323 Terminal IP Network TIGIN IP Network
H.323 Terminal)
4. GSTN Terminal GSTN Terminal (GSTN Terminal GSTN TIGIN GSTN GSTN
Terminal)
Each of these four connection arrangements requires the use of one gateway. Hence, connections
that are purely GSTN-based or are strictly H.323-to-H.323 using only the Internet are not the
subject of this Recommendation. Situations in which multiple or tandem gateways are used are
covered by combinations of connections 1 through 4 (e.g. a combination of 1 & 2 would be GSTN
Terminal GSTN TIGIN #1 IP Network TIGIN #2 GSTN GSTN Terminal). More
complex arrangements may be envisaged but it is not considered necessary to describe them in detail
as they can be made up of these above cases.
Appendix II. Performance / Interworking
Performance / interworking issues include:
a. Ability to vary the packet size on a per call basis
Voice samples are accumulated and buffered into a packet, and a packet is sent when it
becomes full. The size of the packet can be controlled by PCC messages, but the network
must ensure that they are the same on both ends of a connection. In addition, the capability
to vary the packet size on a per call basis must be supported by the PCC protocol, and is
outside the scope of this of document.
b. Silence suppression / Comfort noise generation when used in conjunction with codecs that do
not describe them.
c. Real time control protocol (RTCP)
d. Packet loss mitigation scheme

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

31

e. Jitter buffer size

Variation in the arrival of packets into the TIGIN (packet delay variation) must be
accommodated by a jitter buffer. The size of the jitter buffer must be selected based on the
quality goals for the network. In addition, the type of data being transported may affect the
selection of the jitter buffer size. For example, voice transmission is tolerant to packet loss
but not to excessive delay, whereas voice-band data or data is tolerant to delay but not to
packet loss.
f. Transmission delay
Delay through the TIGIN should be minimized. In addition, the TIGIN should be tolerant to
the overall delay produced by the network.
Appendix III: TIGIN Equipment Arrangements
The basic interworking arrangements between IP networks and GSTN networks is shown in the
figure III.1:

GSTN Terminal
General Switched
Telephone Network

TIGIN Gateway
(G.799.1)

H.323 Terminal

IP Network

Figure III.1/G.799.1 GSTN Terminal interworking with H.323 Terminal

Other cases may exist such as:

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

32

Network optimized
for transport of
internet protocol

TIGIN
Gateway
(G.799.1)

TIGIN
Gateway
(G.799.1)

GSTN Terminal

GSTN Terminal
General Switched
Telephone Network

General Switched
Telephone Network

Figure III2/G.799.1 - GSTN Terminals interconnected through network optimized for

transport of IP

or

General Switched
Telephone Network

TIGIN
Gateway
(G.799.1)

TIGIN
Gateway
(G.799.1)

H.323 Terminal

H.323 Terminal
Network optimized
for transport of
internet protocol

Network optimized
for transport of
internet protocol

Figure III3/G.799.1 - H.323 Terminals interconnected through GSTN Network

In the latter two cases, the interworking functions will remain the same so will not be dealt with
further.

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15

33

Equipment Arrangements including TIGIN

The equipment arrangements for TIGIN would be:
TIGIN
Gateway
(G.799.1)

Interoffice
Transmission

IP Router/Switch

Multiplex

Multiplex

Telephony
Switch

Figure III4/G.799.1 - Proposed IP/GSTN Equipment Arrangement

The Multiplex and Interoffice Transmission are optional depending on the relative locations of the IP
and Telephony Switches.
_______________

/var/www/apps/conversion/tmp/scratch_4/288934581.doc

06.10.15