SoftX3000 Technical Manual-Signaling&Protocols

Chapter 1 MGCP ..............................................................................................
1-1
1.1 Overview ................................................................................................

1.1.1 Basic Concepts ..............................................................................
1.1.2 Related Terms ...............................................................................
1.1.3 Structure of Protocol Stack ............................................................
1.1.4 Implementation in SoftX3000 .........................................................
1.2 Protocol Messages .................................................................................
1.2.1 Message Types..............................................................................
1.2.2 Message Structure .........................................................................
1.3 Basic Control Procedures .......................................................................
1.3.1 Gateway Registration Procedure ...................................................
1.3.2 Successful Termination Call Procedure (in the Same MG) ...........
1.3.3 Successful Termination Call Procedure (in Different MGs) ...........
1-1
1-1
1-1
1-8
1-8
1-9
1-9
1-12
1-23
1-23
1-24
1-37
Chapter 2 H.248................................................................................................
2-1
2.1 Overview ................................................................................................

2.1.1 Basic Concepts ..............................................................................
2.1.2 Related Terms ...............................................................................
2.2.1 Message Types..............................................................................
2.3 Basic Control Procedures .......................................................................
2.3.1 Gateway Registration Procedure ...................................................
2.3.2 Gateway Cancellation Procedure ..................................................
2.3.3 Gateway Initialization Procedure ...................................................
2.3.4 Successful Termination Call Procedure .........................................
2.3.5 Successful Trunk Call Procedure...................................................
2-1
2-1
2-1
2-6
2-7
2-8
2-8
2-9
2-25
2-25
2-26
2-27
2-28
2-39
Chapter 3 SIP ...................................................................................................
3-1
3.1 Overview ................................................................................................

3.1.1 Basic Concepts ..............................................................................
3.1.2 Related Terms ...............................................................................
3.2.1 Message Types..............................................................................
3.3 Basic Message Procedures ....................................................................
3.3.1 SIP User Registration Procedure ...................................................
3-1
3-1
3-2
3-6
3-6
3-7
3-7
3-10
3-25
3-25
3.3.2 Successful SIP User Call Procedure .............................................

3.3.3 Successful SIP Trunk Call Procedure ............................................
3.3.4 Successful SIP-T Trunk Call Procedure ........................................
3-28
3-36
3-39
Chapter 4 H.323................................................................................................
4-1
4.1 Overview of H.323 ..................................................................................

4.1.1 What is H.323 ................................................................................
4.1.2 Definition of Terms .........................................................................
4.1.3 Structure of H.323 Protocol Stack ..................................................
4.1.4 H.323 Applications in SoftX3000 ...................................................
4.2 RAS Protocol ..........................................................................................
4.2.1 Overview of RAS ............................................................................
4.2.2 RAS Messages ..............................................................................
4.2.3 Basic Procedures ...........................................................................
4.3 H.225.0 Call Signaling Protocols ............................................................
4.3.1 Overview of H.225.0 ......................................................................
4.3.2 H.225.0 Messages .........................................................................
4.3.3 Message Format ............................................................................
4.3.4 Information Elements .....................................................................
4.3.5 A typical example of Q.931 message ............................................
4.4 Recommendation H.245 .........................................................................
4.4.1 Overview of H.245 .........................................................................
4.4.2 H.245 Messages ............................................................................
4.5 H.323 Call Procedures ...........................................................................
4.5.1 Successful H.323 User Call Procedure (Normal Start) ..................
4.5.2 Successful H.323 User Call Procedure (Fast Start) .......................
4.5.3 Successful H.323 Trunk Call Procedure ........................................
4-1
4-1
4-1
4-4
4-6
4-7
4-7
4-8
4-16
4-18
4-18
4-19
4-20
4-21
4-24
4-27
4-30
4-30
4-33
4-42
4-44
4-44
4-72
4-72
Chapter 5 SIGTRAN .........................................................................................
5-1
5.1 Overview ................................................................................................

5.1.1 Functions .......................................................................................
5.1.2 Terminology ...................................................................................
5.1.4 SIGTRAN Implementation in SoftX3000 ........................................
5.2 SCTP ......................................................................................................
5.2.1 Introduction ....................................................................................
5.2.2 Terminology ...................................................................................
5.2.3 SCTP Functions .............................................................................
5.2.4 SCTP Primitives .............................................................................
5-1
5-1
5-2
5-2
5-3
5-4
5-4
5-4
5-9
5-12
5.2.5 SCTP Messages ............................................................................

5.2.6 Basic Signaling Procedures ...........................................................
5.3 M2UA .....................................................................................................
5.3.1 Introduction ....................................................................................
5.3.2 Terminology: ..................................................................................
5.3.4 Implementation of M2UA ...............................................................
5.3.5 Protocol Messages ........................................................................
5.4 M3UA .....................................................................................................
5.4.1 Introduction ....................................................................................
5.4.2 M3UA Messages ............................................................................
5.5 IUA .........................................................................................................
5.5.1 Introduction ....................................................................................
5.5.2 Terminology ...................................................................................
5.5.3 Services Provided by the IUA Layer ..............................................
5.5.4 Functions Implemented by the IUA Layer ......................................
5.5.5 Structure of IUA Protocol Stack .....................................................
5.5.6 Definition of IUA Boundaries ..........................................................
5.5.7 Implementation of IUA ...................................................................
5.5.8 IUA Protocol Messages .................................................................
5.6 V5UA ......................................................................................................
5.6.1 Introduction ....................................................................................
5.6.2 Terminology ...................................................................................
5.6.3 V5UA Functions .............................................................................
5.6.4 Structure of V5UA Protocol Stack ..................................................
5.6.5 Definition of V5UA Boundaries ......................................................
5.6.6 Implementation of V5UA ................................................................
5.6.7 V5UA Protocol Messages ..............................................................
5.6.8 Basic Signaling Procedures of V5UA.............................................
5-17
5-40
5-46
5-46
5-46
5-48
5-48
5-49
5-74
5-75
5-75
5-77
5-119
5-121
5-121
5-122
5-123
5-123
5-124
5-125
5-127
5-127
5-144
5-149
5-149
5-149
5-151
5-152
5-152
5-153
5-154
5-162
Chapter 6 SS7 ..................................................................................................
6-1
6.1 Overview ................................................................................................

6.2 MTP ........................................................................................................
6.2.1 Basic Concepts ..............................................................................
6.2.2 Singnaling Message .......................................................................
6.3 ISUP .......................................................................................................
6.3.1 Overview ........................................................................................
6-1
6-2
6-2
6-4
6-3
6-3
6-6
6.3.3 Basic Signaling Flow ......................................................................

6.4 SCCP .....................................................................................................
6.4.1 Basic Concepts ..............................................................................
6.5 TCAP ......................................................................................................
6.5.1 Basic Concepts ..............................................................................
6.6 INAP .......................................................................................................
6.6.1 Basic Concepts ..............................................................................
6.6.3 Basic Signaling Flow ......................................................................
6-10
6-12
6-12
6-13
6-3
6-3
6-5
6-8
6-8
6-11
6-13
Chapter 7 R2 Signaling ...................................................................................
7-1
7.1 Basic Concepts ......................................................................................

7.1.1 Line Signaling ................................................................................
7.1.2 Register Signaling ..........................................................................
7.2 Application of R2 Signaling ....................................................................
7.3 Basic Signaling Flow ..............................................................................
7-1
7-1
7-6
7-2
7-3
Chapter 8 DSS1 Signaling and V5 Protocol ..................................................
8-1
8.1 DSS1 Signaling ......................................................................................

8.1.1 Overview of DSS1 Signaling ..........................................................
8.1.2 Basic Concepts ..............................................................................
8.1.3 Application of DSS1 .......................................................................
8.1.4 Protocol Structure of DSS1 ............................................................
8.1.5 Call Control Message.....................................................................
8.1.6 Basic Signaling Process ................................................................
8.2 V5 Protocol .............................................................................................
8.2.1 Basic Concepts ..............................................................................
8.2.2 Application of V5 Protocol ..............................................................
8.2.3 Protocol Structure of V5.2 Interface ...............................................
8.2.4 Layer 3 Protocol Message .............................................................
8.2.5 Call Control Flow of V5.2 Interface ................................................
8-1
8-1
8-1
8-7
8-8
8-10
8-13
8-15
8-15
8-19
8-19
8-22
8-27
HUAWEI
U-SYS SoftX3000 SoftSwitch System

Technical Manual Signaling & Protocols
V300R001

Technical Manual
Volume
Signaling & Protocols
Manual Version
T2-010257-20050115-C-3.07
Product Version
V300R001
BOM
31025857
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support
and service. Please feel free to contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Administration Building, Huawei Technologies Co., Ltd.,
Bantian, Longgang District, Shenzhen, P. R. China
Postal Code: 518129
Website: http://www.huawei.com
Email: support@huawei.com
Copyright 2005 Huawei Technologies Co., Ltd.
All Rights Reserved

No part of this manual may be reproduced or transmitted in any form or by any
means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks
, HUAWEI, C&C08, EAST8000, HONET,
, ViewPoint, INtess, ETS, DMC,
TELLIN, InfoLink, Netkey, Quidway, SYNLOCK, Radium,

M900/M1800,
TELESIGHT, Quidview, Musa, Airbridge, Tellwin, Inmedia, VRP, DOPRA, iTELLIN,
HUAWEI OptiX, C&C08 iNET, NETENGINE, OptiX, iSite, U-SYS, iMUSE, OpenEye,
Lansway, SmartAX, infoX, TopEng are trademarks of Huawei Technologies Co.,
Ltd.
All other trademarks mentioned in this manual are the property of their respective
holders.
Notice
The information in this manual is subject to change without notice. Every effort has
been made in the preparation of this manual to ensure accuracy of the contents, but
all statements, information, and recommendations in this manual do not constitute
the warranty of any kind, express or implied.
About This Manual

Release Notes
This manual applies to MA5100 Multi-service Access Module V100R003.
Related Manuals
The related manuals are listed in the following table.
Manual
Content

Technical Manual-System Description
It provides an overall introduction to SoftX3000, including

product features, applications and technical specifications.

Technical Manual-Architecture &
Principle
It details on the hardware architecture, component

interworking mechanism, and subsystems of alarm, billing,
and clock in SoftX3000.
U-SYS SoftX3000 SoftSwitch

System Technical Manual-Signaling
& Protocols
It serves as an referential guidance on the usage of

signaling and protocols used in SoftX3000, including
MGCP, H.248, SIP, H.323, and SIGTRAN.

Maintenance Manual- Routine
Maintenance
It guides maintenance personnel to perform daily

maintenance, monthly maintenance, and yearly
maintenance tasks on equipment.

Hardware Installation Manual
It details the installation procedure of SoftX3000 hardware

components, and matters needing attention during the
installation process.

Software Installation Manual
It covers the detailed procedure of installing SoftX3000

software, including BAM server, emergency workstation
and client, focusing on the key points that might cause
installation failure.

Operation Manual-Traffic
Measurement
It guides the engineers how to perform traffic measurement

operations and how to analyze traffic measurement results.

Operation Manual-Configuration Guide
It guides the engineers how to configure various data in

SoftX3000, including configuration steps, preparations,
database table referencing relationships, and command
parameters.

Operation Manual-Configuration
Example
It guides the engineers how to configure various data in

SoftX3000, including networking example, configuration
script, key parameters and debugging guidance.
Manual
Content

Operation Manual-Service Application
It covers the voice services, IP Centrex services,

multi-media services, IN services and value added services
supported by SoftX3000, focusing on the meaning,
operations, example and points for attention of various
services.
U-SYS iGateway Bill User Manual
It elaborates on the functioning principle of the iGateway

Bill. Also, it teaches you on how to install, maintain, and
operate the product.
Organization
This manual introduces the NGN signaling knowledge and procedures used in the
SoftX3000.
There are five chapters in the manual.
z
Chapter 1 MGCP profiles the architecture, message specifications and call

signaling procedures of MGCP.
Chapter 2 H.248 details the architecture, message specifications and call

signaling procedures of H.248.
Chapter 3 SIP presents the architecture, message specifications and call

signaling procedures of SIP.
Chapter 4 H.323 details the architecture, message specifications and call

signaling procedures of H.323 protocol stack, including RAS, H.225.0, and H.245.
Chapter 5 SIGTRAN provides the architecture, message specifications and call

signaling procedures of SIGTRAN protocol stack, including SCTP, M2UA, and
M3UA.
Chapter 6 SS7 gives a detailed description of the architecture, message

specifications and call signaling procedures of SS7.
Chapter 7 R2 Signaling elaborates the architecture, message specifications and

call signaling procedures of the R2 signaling.
Chapter 8 DSS1 and V5 focuses on the architecture, message specifications and

call signaling procedures of the DSS1 and V5 signaling.
Intended Audience
The manual is intended for the following readers:
z
NGN network planning experts
NGN network administrators
NGN system engineers
Conventions
The manual uses the following conventions:
I. General conventions
Convention
Description
Arial
Normal paragraphs are in Arial.
Arial Narrow
Warnings, Cautions, Notes and Tips are in Arial Narrow.
Boldface
Headings are in Boldface.
Courier New
Terminal Display is in Courier New.
II. Symbols
Eye-catching symbols are also used in the manual to highlight the points worthy of
special attention during the operation. They are defined as follows:
Caution,: Means reader be extremely careful during the operation.

Note: Means a complementary description.

Table of Contents
Table of Contents
Chapter 1 MGCP ............................................................................................................................ 1-1
1.1 Overview ............................................................................................................................ 1-1
1.1.1 Basic Concepts ....................................................................................................... 1-1
1.1.2 Related Terms......................................................................................................... 1-1
1.1.3 Structure of Protocol Stack ..................................................................................... 1-8
1.1.4 Implementation in SoftX3000 .................................................................................. 1-8
1.2 Protocol Messages ............................................................................................................ 1-9
1.2.1 Message Types ....................................................................................................... 1-9
1.2.2 Message Structure ................................................................................................ 1-12
1.3 Basic Control Procedures ................................................................................................ 1-23
1.3.1 Gateway Registration Procedure .......................................................................... 1-23
1.3.2 Successful Termination Call Procedure (in the Same MG) .................................. 1-24
1.3.3 Successful Termination Call Procedure (in Different MGs) .................................. 1-37
Chapter 2 H.248 ............................................................................................................................. 2-1
2.1 Overview ............................................................................................................................ 2-1
2.1.1 Basic Concepts ....................................................................................................... 2-1
2.1.2 Related Terms......................................................................................................... 2-1
2.2.1 Message Types ....................................................................................................... 2-8
2.2.2 Message Structure .................................................................................................. 2-9
2.3 Basic Control Procedures ................................................................................................ 2-25
2.3.1 Gateway Registration Procedure .......................................................................... 2-25
2.3.2 Gateway Cancellation Procedure.......................................................................... 2-26
2.3.3 Gateway Initialization Procedure........................................................................... 2-27
2.3.4 Successful Termination Call Procedure ................................................................ 2-28
2.3.5 Successful Trunk Call Procedure.......................................................................... 2-39
Chapter 3 SIP ................................................................................................................................. 3-1
3.1 Overview ............................................................................................................................ 3-1
3.1.1 Basic Concepts ....................................................................................................... 3-1
3.1.2 Related Terms......................................................................................................... 3-2
3.2.1 Message Types ....................................................................................................... 3-7
3.2.2 Message Structure ................................................................................................ 3-10
i

Table of Contents
3.3 Basic Message Procedures ............................................................................................. 3-25

3.3.1 SIP User Registration Procedure .......................................................................... 3-25
3.3.2 Successful SIP User Call Procedure..................................................................... 3-28
3.3.3 Successful SIP Trunk Call Procedure ................................................................... 3-36
3.3.4 Successful SIP-T Trunk Call Procedure ............................................................... 3-39
Chapter 4 H.323 ............................................................................................................................. 4-1
4.1 Overview of H.323 ............................................................................................................. 4-1
4.1.1 What is H.323.......................................................................................................... 4-1
4.1.2 Definition of Terms .................................................................................................. 4-1
4.1.3 Structure of H.323 Protocol Stack........................................................................... 4-4
4.1.4 H.323 Applications in SoftX3000............................................................................. 4-6
4.2 RAS Protocol ..................................................................................................................... 4-7
4.2.1 Overview of RAS ..................................................................................................... 4-7
4.2.2 RAS Messages........................................................................................................ 4-8
4.2.3 Basic Procedures .................................................................................................. 4-16
4.3 H.225.0 Call Signaling Protocols ..................................................................................... 4-18
4.3.1 Overview of H.225.0.............................................................................................. 4-18
4.3.2 H.225.0 Messages ................................................................................................ 4-19
4.3.3 Message Format ................................................................................................... 4-20
4.3.4 Information Elements ............................................................................................ 4-21
4.3.5 A typical example of Q.931 message ................................................................... 4-24
4.4 Recommendation H.245 .................................................................................................. 4-29
4.4.1 Overview of H.245................................................................................................. 4-29
4.4.2 H.245 Messages ................................................................................................... 4-32
4.5 H.323 Call Procedures..................................................................................................... 4-44
4.5.1 Successful H.323 User Call Procedure (Normal Start) ......................................... 4-44
4.5.2 Successful H.323 User Call Procedure (Fast Start).............................................. 4-72
4.5.3 Successful H.323 Trunk Call Procedure ............................................................... 4-72
Chapter 5 SIGTRAN....................................................................................................................... 5-1
5.1 Overview ............................................................................................................................ 5-1
5.1.1 Functions................................................................................................................. 5-1
5.1.2 Terminology............................................................................................................. 5-2
5.1.4 SIGTRAN Implementation in SoftX3000................................................................. 5-3
5.2 SCTP ................................................................................................................................. 5-4
5.2.1 Introduction.............................................................................................................. 5-4
5.2.2 Terminology............................................................................................................. 5-4
5.2.3 SCTP Functions ...................................................................................................... 5-9
5.2.4 SCTP Primitives .................................................................................................... 5-12
5.2.5 SCTP Messages ................................................................................................... 5-17
ii

Table of Contents
5.2.6 Basic Signaling Procedures .................................................................................. 5-40

5.3 M2UA ............................................................................................................................... 5-46
5.3.1 Introduction............................................................................................................ 5-46
5.3.2 Terminology:.......................................................................................................... 5-46
5.3.3 Structure of Protocol Stack ................................................................................... 5-48
5.3.4 Implementation of M2UA....................................................................................... 5-48
5.3.5 Protocol Messages................................................................................................ 5-49
5.3.6 Basic Signaling Procedures .................................................................................. 5-74
5.4 M3UA ............................................................................................................................... 5-75
5.4.1 Introduction............................................................................................................ 5-75
5.4.2 M3UA Messages ................................................................................................... 5-77
5.4.3 Basic Signaling Procedures ................................................................................ 5-119
5.5 IUA ................................................................................................................................. 5-121
5.5.1 Introduction.......................................................................................................... 5-121
5.5.2 Terminology......................................................................................................... 5-122
5.5.3 Services Provided by the IUA Layer ................................................................... 5-123
5.5.4 Functions Implemented by the IUA Layer........................................................... 5-123
5.5.5 Structure of IUA Protocol Stack .......................................................................... 5-125
5.5.6 Definition of IUA Boundaries ............................................................................... 5-125
5.5.7 Implementation of IUA......................................................................................... 5-127
5.5.8 IUA Protocol Messages....................................................................................... 5-127
5.5.9 Basic Signaling Procedures ................................................................................ 5-144
5.6 V5UA.............................................................................................................................. 5-149
5.6.1 Introduction.......................................................................................................... 5-149
5.6.2 Terminology......................................................................................................... 5-149
5.6.3 V5UA Functions .................................................................................................. 5-151
5.6.4 Structure of V5UA Protocol Stack ....................................................................... 5-152
5.6.5 Definition of V5UA Boundaries............................................................................ 5-152
5.6.6 Implementation of V5UA ..................................................................................... 5-153
5.6.7 V5UA Protocol Messages ................................................................................... 5-154
5.6.8 Basic Signaling Procedures of V5UA.................................................................. 5-162
Chapter 6 SS7 ................................................................................................................................ 6-1
6.1 Overview ............................................................................................................................ 6-1
6.2 MTP ................................................................................................................................... 6-2
6.2.1 Basic Concepts ....................................................................................................... 6-2
6.2.2 Singnaling Message................................................................................................ 6-4
6.3 ISUP................................................................................................................................... 6-3
6.3.1 Overview ................................................................................................................. 6-3
6.3.3 Basic Signaling Flow ............................................................................................. 6-10
6.4 SCCP ............................................................................................................................... 6-12
6.4.1 Basic Concepts ..................................................................................................... 6-12
iii

Table of Contents
6.4.2 Singnaling Message.............................................................................................. 6-13

6.5 TCAP ................................................................................................................................. 6-3
6.5.1 Basic Concepts ....................................................................................................... 6-3
6.6 INAP................................................................................................................................... 6-8
6.6.1 Basic Concepts ....................................................................................................... 6-8
6.6.2 Singnaling Message.............................................................................................. 6-11
6.6.3 Basic Signaling Flow ............................................................................................. 6-13
Chapter 7 R2 Signaling ................................................................................................................. 7-1
7.1 Basic Concepts .................................................................................................................. 7-1
7.1.1 Line Signaling.......................................................................................................... 7-1
7.1.2 Register Signaling ................................................................................................... 7-6
7.2 Application of R2 Signaling................................................................................................ 7-2
7.3 Basic Signaling Flow.......................................................................................................... 7-3
Chapter 8 DSS1 Signaling and V5 Protocol................................................................................ 8-1
8.1 DSS1 Signaling.................................................................................................................. 8-1
8.1.1 Overview of DSS1 Signaling ................................................................................... 8-1
8.1.2 Basic Concepts ....................................................................................................... 8-1
8.1.3 Application of DSS1 ................................................................................................ 8-7
8.1.4 Protocol Structure of DSS1 ..................................................................................... 8-8
8.1.5 Call Control Message............................................................................................ 8-10
8.1.6 Basic Signaling Process........................................................................................ 8-13
8.2 V5 Protocol ...................................................................................................................... 8-15
8.2.1 Basic Concepts ..................................................................................................... 8-15
8.2.2 Application of V5 Protocol ..................................................................................... 8-19
8.2.3 Protocol Structure of V5.2 Interface ...................................................................... 8-19
8.2.4 Layer 3 Protocol Message .................................................................................... 8-22
8.2.5 Call Control Flow of V5.2 Interface ....................................................................... 8-27
iv

Chapter 1 MGCP
Chapter 1 MGCP
1.1 Overview
1.1.1 Basic Concepts
RFC2705 document describes an application programming interface and a
corresponding protocol (media gateway control protocol, MGCP) for controlling Voice
over Internet Protocol (VoIP) gateways from external call control elements.
MGCP assumes a call control architecture where call control is independent of service
bearer. As shown in Figure 1-1, the call control intelligence is outside the Media
Gateways (MGs) and handled by external call control elements named Media Gateway
Controller (MGC) or Call Agent (CA). MGCP is, in essence, a master/slave protocol,
where the MGs are expected to execute commands sent by the MGCs.
MGC
Control streams
MG
Media streams
Figure 1-1 MGCP concept
1.1.2 Related Terms

I. Gateway
A gateway is a network element that provides interconnection and interworking
between networks of various architectures. In NGN architecture, NGN interworks with
other networks through certain gateways:
z
Trunk Media Gateways (TMG): that interface between the traditional telephone
network (Public Switched Telephone Network, PSTN) and a VoIP network. Such
gateways typically manage a large number of digital circuits.
Access Media Gateways (AMG): that convert media in one network to a suitable
format required by another network. For example, AMGs can achieve the
conversion between bearer channels of a circuit switched network and media
streams of a packet switched network.
Universal Media Gateways (UMG): that provide functions to convert media

streams and signaling, universally to implement Trunking Gateway (TG), built-in
Signaling Gateway (SG) and Access Gateway (AG) functions. Such gateways can
1-1

Chapter 1 MGCP
connect to a variety of devices such as PSTN switches, Private Branch

Exchanges (PBX), access networks, routers, and wireless base stations.
II. Media resource server

A Media Resource Server (MRS) is a type of gateway that supports a variety of
endpoints such as announcement server access point, interactive voice response
access point, and conference bridge access point.
SoftX3000 supports the controlling of an MGCP MRS to provide announcements and
Interactive Voice Response (IVR) services. MRS can be used to provide
announcements to all kinds of users in the system. SoftX3000 also supports digit
collection through an MRS.
III. Call agent

A Call Agent provides signaling and call processing functions. It is an external call
control element for controlling telephony gateways.
SoftX3000 provides MGCP call agent functionality. SoftX3000 can act as an access
point for MGCP E-phones and Softphones in the network, compliant with the Internet
Engineering Task Force (IETF) RFC2705 (MGCP). SoftX3000 supports Calls and
Connections management procedure as specified in Section 2.1.3 of the RFC2705
(Version 1.0).
IV. Endpoint
Endpoints are sources or sinks of data and can be physical or virtual.
Examples of physical endpoints are an interface on a trunk gateway that terminates a
trunk connected to a PSTN switch, and a port on an access gateway connected to
E-phones. An example of a virtual endpoint is an audio source in an MRS. Creation of
physical endpoints requires hardware installation, while creation of virtual endpoints
can be done by software.
V. Endpoint identifier
Endpoints are identified by endpoint identifiers. Endpoint identifiers have two
components that both are case insensitive: the domain name of the gateway that is
managing the endpoint, and a local name within that gateway. Between the
components, an at sign (@) is used as a delimiter. The syntax of the local name
depends on the type of endpoint being named. However, the local name for each of
these types is naturally hierarchical, beginning with a term that identifies the physical
gateway containing the given endpoint and ending in a term that specifies the individual
endpoint concerned. With this in mind, the following rules for construction and
interpretation of endpoint identifiers must be supported:
z
The individual terms of the naming path must be separated by a single slash (/").
1-2

z
Chapter 1 MGCP
The individual terms are character strings composed of letters, digits or other
printable characters, with the exception of characters used as delimiters (/, @),
and white spaces.
Characters used for wildcarding (*, $) can be used in local names. A term
represented by an asterisk is to be interpreted as: use ALL values of this term
known within the scope of the Media Gateway. A term represented by a dollar
sign is to be interpreted as: use ANY ONE value of this term known within the
scope of the Media Gateway.
In MGCP, the gateway is identified by a domain name, such as amg1.hauwei.com. The

local name is structured with the name of the physical interface (for example aaln) and
the terminal identifier (that is, the corresponding port number of the telephone number
accessing the Media Gateway). The terminal identifier is separated from the name of
the physical interface by a fraction bar (/).
An example is aaln/1 @ amg1.hauwei.com which is the name of an endpoint of an
AMG.
That refers to the first port of the aaln interface of the AMG with the domain name
amg1.hauwei.com.
Another example is X35V3+A4/13@gw23.example.net which is the name of an
endpoint of a TG.
That refers to the thirteenth Time Division Multiplexing (TDM) circuit on the X35V3+A4
interface of the gateway numbered 23 in the example network.
VI. Calls and connections

Connections may be either point to point or multipoint. A point to point connection is an
association between two endpoints with the purpose of transmitting data between
these endpoints. Once this association is established for both endpoints, data transfer
between these endpoints can take place. A multipoint connection is established by
connecting the endpoint to a multipoint session. Connections can be established over
several types of bearer networks.
Connections are grouped in calls. One or more connections can belong to one call.
Connections and calls are set up at the initiative of one or several MGCs.
Figure 1-2 illustrates the concepts of endpoints, connections, calls and gateways, as
well as their relations.
1-3

Chapter 1 MGCP
Figure 1-2 Relations between endpoints, connections, calls and gateways

When the two endpoints are located on gateways that are managed by the same call
agent, the creation is done through three steps as follows:
1)
The call agent asks the first gateway to create a connection on the first endpoint.
The gateway allocates resources to that connection, and responds to the
command by providing a session description. The session description contains
the information necessary for a third party to send packets towards the newly
created connection, such as IP address, User Datagram Protocol (UDP) port, and
packetization parameters.
2)
The call agent then asks the second gateway to create a connection on the
second endpoint. The command carries the session description provided by the
first gateway. The gateway allocates resources to that connection, and responds
to the command by providing a session description.
3)
The call agent uses a modify connection command to provide the second
session description to the first endpoint. Once this is done, communication can
proceed in both directions.
VII. Connection identifier

Connections managed at endpoints can be converged into calls. Connections are
created by gateways. Gateways assign unique connection identifiers to local ends.
Connection identifiers are character strings composed of hexadecimal numbers.
VIII. Call identifier

Calls are identified by unique identifiers which are created by the MGC. Call identifiers
are treated in MGCP as unstructured octet strings. Call identifiers must be unique
within the system. When an MGC builds several connections for the same call, the
connections must pertain to the same call.
IX. Names of calls agents and other entities

In MGCP, Call Agents are identified by domain names. For enhanced network reliability,
MGCP has been designed to allow the implementation of redundant Call Agents which
share the same domain name but have different network addresses, for example, IP
1-4

Chapter 1 MGCP
addresses. A gateway identifies a Call Agent through its domain name. For lower-layer
operations, the gateway fetches the list of network addresses of the Call Agent from the
domain name server, and uses an appropriate network address for communication with
the Call Agent according to specific situations. This redundancy mechanism is
significant to improve the reliability of the system.
Other entities, such as gateways and information servers, are also identified by their
domain names. Similarly, these entities can make full use of redundancy to enhance
the reliability of the system. For Call Agents and gateways, they identify these entities
through domain name.
Domain name prevents these entities from being identified directly through network
addresses, because the domain name is relatively stable while network addresses can
be easily changed. For example, if an entity is moved to a different Local Access
Network (LAN), the IP address of the entity will be changed but the domain name can
be retained. The domain name life ensures other entities can refresh the information
about the domain name of that entity in time to obtain its latest IP address.
In MGCP, Call Agents and other entities are represented by e-mail address in essence,
as in:
Call-agent@ca.example.net
indicating a Call Agent in the example network
Busy-signal@ann12.example.net indicating the busy signal in the information server

numbered 12 in the example network
X. Event and signal

The concept of events and signals is central to MGCP. A Call Agent may ask to be
notified about certain events occurring in an endpoint, such as off-hook events, on-hook
events, flash-hook events, or dialing events. A Call Agent may request certain signals
to be applied to an endpoint, such as dial tone, ringback tone, and busy tone.
Events and signals are grouped in packages. Each package is supported by a
particular endpoint.
An event name is composed of two logical parts, a package name and an event name,
separated by a slash (/). Event names and package names are case insensitive. The
package name is in fact optional. Each endpoint type has a default package associated
with it, and if the package name is excluded from the event name, the default package
name for that endpoint type is assumed. When an event is applied on a connection, the
name of the connection is added to the name of the event, using an at sign (@) as a
delimiter. In addition, the range and wildcard notation of events can be used, instead of
individual names. The asterisk sign (*), a wildcard character, can be used to denote
all connections. The dollar sign ($), a wildcard character, can be used to denote the
current, any connection.
Each signal has an associated signal type, such as on/off (OO), time-out (TO), and brief
(BR).
1-5

Chapter 1 MGCP
Table 1-1 lists some packages commonly used.

Table 1-1 Basic packages
Package
Package ID
Generic media package
DTMF package
MF package
Trunk package
Line package
Handset emulation package
RTP package
Network access server package
Announcement server package
Script package
Script
Table 1-2 lists some valid event names.

Table 1-2 Examples of event names
Event name
Meaning
l/hd
Off-hook event in the line packages
l/hu
On-hook event in the line packages
l/dl
Dial tone event in the line packages
l/hf
Flash-hook event in the line packages
l/aw
Answer tone event in the line packages
l/bz
Busy tone event in the line packages
l/wt
Call waiting tone event in the line packages
l/rg
Ringing event in the line packages
l/sl
Stutter dialtone event in the line packages
M/0
Digit 0 in the MF packages
M/[0-9]
Digits 0 to 9 in the MF packages
fh
Flash-hook event, assuming that the default line package is a default

package for the endpoint
G/rt@0A3F58
Ringback signal in the generic media packages on connection 0A3F58
G/mt
Modem detected event in the generic media packages
G/ft
Fax tone detected event in the generic media packages
1-6

Chapter 1 MGCP
Event name
Meaning
G/ld
Long duration connection event in the generic media packages. If a

connection lasts for more than an hour, this event will be detected.
[0-9*#A-D]
All digits and letters in the DTMF packages
T/$
All events in the trunk packages
R/qa@*
Quality alert event in the RTP packages in all connections
R/rt@$
Ringback event in the RTP packages on current connection
XI. Digit map

The Call Agent can ask the gateway to collect digits dialed by the user. For example, a
residential gateway collects the number that a user dials and the credit card number. An
alternative procedure is for the gateway to notify the Call Agent of the dialed digits, as
soon as they are dialed. However, such a procedure generates a large number of
interactions and occupies a large number of network resources. It is preferable to
accumulate the dialed numbers in a buffer, and to transmit them in a single message.
The problem with this accumulation approach, however, is that it is hard for the
gateway to predict how many numbers it needs to accumulate before transmission.
The solution to this problem is to load the gateway with a digit map that corresponds to
the dial plan.
This digit map is expressed using a strict syntax. It is composed of a list of digits and
letters. If collected dial sequence matches one of the defined strings, it indicates
necessary digits have been collected.
What are supported in the definition of digit strings include the digits from 0 to 9, the
letters from A to D, the pound sign #, the asterisk sign *, the letters T and x,
and the dot sign .. The digit strings separated by | are alternative number schemes.
[] indicates any of them. * indicates the sign * used in DTMF. The letter T
indicates the timer is detected time out. The letter x indicates any digit. The sign .
indicates any number of letters, including zero number of letters, can appear before it.
# indicates the sign # used in DTMF.
For example, using the phone on our disk, we can dial the following numbers:
Table 1-3 Examples of digit map
0
Local operator
00
Long distance operator
xxxx
Local extension number
8xxxxxxx
Local number
xxxxxxx#
Shortcut to local number at other corporate sites
1-7

Chapter 1 MGCP
*xx
Star services
91xxxxxxxxxx
Long distance number
9011 + up to 15 digits
International number
The dial plan described above results in the following digit map:
(0T| 00T|[1-7]xxx|8xxxxxxx|xxxxxxx#|*xx|91xxxxxxxxxx|9011x.T)
1.1.3 Structure of Protocol Stack

Media Gateway Control Protocol is both a definition of commands and a definition of
signaling. By MGCP commands, the MGC can control the MG; while the MG sends the
responding signals back to the MGC. The commands and signals of MGCP are defined
as IP packets, which allow it to be underlying bearer system independent.
The structure of MGCP protocol stack is shown in Figure 1-3.
MGCP
UDP
IP
MAC
Figure 1-3 MGCP protocol stack

MGCP messages are transmitted over UDP/IP. The transport layer protocol is UDP and
the network layer protocol is IP.
1.1.4 Implementation in SoftX3000

Implementation of MGCP in SoftX3000 is illustrated in Figure 1-4.
1-8

Chapter 1 MGCP
SoftX3000
23
/ H.3
/S IP
P
C
MG
SS7
E1
CP
MRS
IP Core
n
tra
Sig
8
24
H.
SoftPhone
PSTN
G
M
MG
C
IAD
TMG8010
E-phone
E-phone
Figure 1-4 Implementation of MGCP in SoftX3000

SoftX3000 interworks with the PSTN through a Trunk Media Gateway (TMG) and
built-in Signaling Gateway (SG). The TMG achieves the conversion of voice signals
between a Circuit Switched (CS) network and a Packet Switched (PS) network, and the
SG implements the conversion of signaling between a CS network and a PS network.
The Call Agent is also known as MGC (SoftX3000), mainly used for signaling functions
related to the call process, and it controls and manages the operating procedures of the
MG and the SG. SoftX3000 controls the TMG through the H.248 protocol (H.248 is
covered in a separate chapter) and controls the MRS, AG, IAD and Softphone through
MGCP, to achieve functions such as signaling processing and call processing.
1.2 Protocol Messages

Nine types of MGCP messages in total are exchanged between MGC and MG, which
are called commands when being sent to MG or MGC, while called responses when
being returned from MG or MGC. Command and response are inseparable. After MG
has registered successfully, upon receiving a command, MG (or MGC) will return a
response immediately.
1.2.1 Message Types

I. Command
The names and meanings of MGCP commands are shown in Table 1-4. There are
connection processing and endpoint processing commands. There are nine
commands defined in this protocol.
1-9

Chapter 1 MGCP
Table 1-4 MGCP commands

Command name
Code
Description
EndpointConfiguration
EPCF
MGCMG, used to specify the encoding of the signals that will

be received by the endpoint (A-law or -law). The Call Agent uses
the command to transfer that information to the corresponding
gateway.
NotificationRequest
RQNT
Used to instruct the gateway to watch for specific events on a

specified endpoint. If it happens, the Call Agent will be notified.
Notify
NTFY
MGMGC, used by the gateway to notify the Call Agent that a

specific event requested to watch for takes place.
CRCX
MGCMG, used by the Call Agent to associate an endpoint with

a specified IP address and UDP port. Apart from that, a
CreateConnection command is also sent to the remote endpoint,
which is required to create the connection between the two
endpoints.
ModifyConnection
MDCX
MGCMG, used to change the parameters associated to a

previously established connection. This command is used by the
Call Agent to provide the first endpoint with the session
description of the second endpoint, such as IP address, UDP port
and packetization parameters. Once this process is completed,
both parties can communicate in bi-directional ways.
DeleteConnection
DLCX
MGCMG, used to delete an existing connection.
AuditEndpoints
AUEP
MGCMG, used by the Call Agent to audit the status of an

endpoint or a group of endpoints.
AuditConnection
AUCX
MGCMG, used by the Call Agent to audit the status of a

connection on an endpoint.
RestartInProgress
RSIP
MGMGC, used by the gateway to notify the Call Agent that the
gateway, or a group of endpoints managed by the gateway, is
being taken out of service or is being placed back in service.
CreateConnection
II. Response
All MGCP commands are acknowledged. The acknowledgement carries a return code
which is an integer, for which four ranges of values have been defined:
z
Values between 100 and 199 indicate a provisional response.
Values between 200 and 299 indicate a successful completion.
Values between 400 and 499 indicate a transient error.
Values between 500 and 599 indicate a permanent error.
Whether to return response parameters depends on specific commands.

The response codes that have been defined are listed in Table 1-5.
1-10

Chapter 1 MGCP
Table 1-5 MGCP response codes

Response code
Meaning
100
The transaction is currently being executed. An actual completion message will

follow on later.
200
The requested transaction was executed normally.
250
The connection was deleted.
400
The transaction could not be executed, due to a transient error.
401
The phone is already off hook.
402
The phone is already on hook.
403
The transaction could not be executed, because the endpoint does not have
sufficient resources at this time.
404
Insufficient bandwidth at this time.
500
The transaction could not be executed, because the endpoint is unknown.
501
The transaction could not be executed, because the endpoint is not ready.
502
The transaction could not be executed, because the endpoint does not have
sufficient resources.
510
The transaction could not be executed, because a protocol error was detected.
511
The transaction could not be executed, because the command contained an

unrecognized extension.
512
The transaction could not be executed, because the gateway is not equipped to
detect one of the requested events.
513
The transaction could not be executed, because the gateway is not equipped to
generate one of the requested signals.
514
The transaction could not be executed, because the gateway cannot send the
specified announcement.
515
The transaction refers to an incorrect connection-id (may have been already

deleted).
516
The transaction refers to an unknown call-id.
517
Unsupported or invalid mode.
518
Unsupported or unknown package.
519
Endpoint does not have a digit map.
520
The transaction could not be executed, because the endpoint is restarting.
521
Endpoint redirected to another Call Agent.
522
No such event or signal.
523
Unknown action or illegal combination of actions
524
Internal inconsistency in LocalConnectionOptions.
1-11

Chapter 1 MGCP
Response code
Meaning
525
Unknown extension in LocalConnectionOptions.
526
Insufficient bandwidth.
527
Missing RemoteConnectionDescriptor.
528
Incompatible protocol version.
529
Internal hardware failure.
530
CAS signaling protocol error.
531
Failure of a grouping of trunks (for example, facility failure).
1.2.2 Message Structure

I. Command format
1)
Command structure
Displayed in Figure 1-5 is the format of MGCP command, which consists of a command
line and a group of parameter lines. A line feed character distinguishes the command
line and each parameter line.
Command name
Transaction ID
Endpoint
Protocol version
Command line
Parameter name: parameter value

Parameter line
...
Figure 1-5 Structure of MGCP command

2)
Command parameters
ResponseAck (K)
The response acknowledgement attribute indicates the transaction identifiers which

have received the response command. It contains a comma separated list of
confirmed transaction-id ranges. For example:
K: 6234-6255, 6257, 19030-19044
z
BearerInformation (B)
It refers to bearer attributes. Currently only one attribute, encoding, is defined. The
code of encoding attribute is e. Its values can be set to A which represents A-law
and which represents -law. For example, a BearerInformation code is B: e:mu
z
CallId (C)
1-12

Chapter 1 MGCP
CallId is a globally unique parameter that identifies the call (or session) to which this
connection belongs. Connections that belong to the same call share the same call-id.
The call-id can be used to identify calls for reporting and accounting purposes. Call-id
identifies calls, which is expressed as a hexadecimal character string, composed of a
maximum of 32 characters.
z
ConnectionId (I)
3)
The ConnectionId parameter is expressed as a hexadecimal character string

which is composed of a maximum of 32 characters.
NotifiedEntity (N)
NotifiedEntity specifies where the notifications should be sent. When this parameter is
absent, the notifications should be sent to the originator of the NotificationRequest.
RequestIdentifier (X)
RequestIdentifier is used to correlate this request with the notifications that it triggers.
RequestIdentifier is expressed as a hexadecimal character string which is composed of
a maximum of 32 characters.
LocalConnectionOptions (L)
The local connection options describe the operational parameters that the Call Agent
suggests to the gateway. These parameters are: the packetization period in
milliseconds (encoded as the keyword p), the preferred type of compression
algorithm (encoded as the keyword a), the bandwidth in kilobits per second (encoded
as the keyword b), the echo cancellation parameter (encoded as the keyword e), the
gain control parameter (encoded as the keyword gc), the silence suppression
parameter (encoded as the keyword s), the type of service parameter (encoded as the
keyword t), the resource reservation parameter (encoded as the keyword r), the
encryption key (encoded as the keyword k), and the type of network (encoded as the
keyword nt). Each of the parameters is optional. When several parameters are
present, the values are separated by commas. Examples of connection descriptors
are:
L: p:10, a:PCMU
L: p:10, a:G726-32
L: p:10-20, b:64
L: b:32-64, e:off
z
Connection Mode (M)
The connection mode describes the mode of operation of the connection.

Table 1-6 Connection mode values and meanings
Connection mode
Meaning
sendonly
The gateway should only send packets.
recvonly
The gateway should only receive packets.
1-13

Chapter 1 MGCP
Connection mode
Meaning
sendrecv
The gateway should send and receive packets.
confrnce
The gateway should place the connection in conference mode.
inactive
The gateway should neither send nor receive packets.
loopback
The gateway should place the circuit in loopback mode.
conttest
The gateway should place the circuit in test mode.
netwloop
The gateway should place the connection in network loopback mode.
netwtest
The gateway should place the connection in network continuity test mode.
data
The gateway should use the circuit for network access for data.
RequestedEvents (R)
The RequestedEvents parameter provides the list of events that have been requested.
Each event can be qualified by a requested action, or by a list of actions. The actions,
when specified, are encoded as a list of keywords, enclosed in parenthesis and
separated by commas. Table 1-7 shows the codes for the various actions.
Table 1-7 Action codes
Code
Action
Notify immediately
Accumulate
Treat according to digit map
Swap
Ignore
Keep signal(s) active
Embedded notification request
When no action is specified, the default action is to notify the event. This means that,
for example, ft and ft(N) are equivalent. Events that are not listed are ignored.
The digit-map action can only be specified for the digits, letters and inter-digit timers in
the MF and DTMF packets, or in other packages that would define the encoding of
digits and timers.
The requested list is encoded on a single line, with event/action groups separated by
commas. Examples of RequestedEvents encoding are:
R: hu(N), hf(S,N)
R: hu(N), [0-9#T](D)
z
SignalRequests (S)
1-14

Chapter 1 MGCP
The SignalRequests parameter provides the name of the signals that have been
requested.
Several signals, for example announcement or Analogue Display Server Interface
server (ADSI) display, can be qualified by additional parameters:
the name and parameters of the announcement,
the string that should be displayed.
These parameters will be encoded as a set of UTF8 character strings, separated by
commas and enclosed within parenthesis, as in:
S: adsi("123456 Francois Gerard")
S: ann(no-such-number, 1234567)
When several signals are requested, their codes are separated by commas, as in:
S: asdi(123456 Your friend), rg
ObservedEvents (O)
The ObservedEvents parameter provides the list of events that have been observed.
Examples of observed actions are:
O: L/hu
O: 8295555T
O: 8,2,9,5,5,L/hf,5,5,T
O: L/hf, L/hf, L/hu
ConnectionParameters (P)
Connection parameters are encoded as a string of type and value pairs, where the type
is either a letter identifier of the parameter or an extension type, and the value is
decimal integer. Types are separated from value by an = sign. Parameters are
encoded from each other by commas.
Table 1-8 shows the connection parameter types.
Table 1-8 Connection parameter types
Code
Connection
parameter name
Connection parameter value
PS
Packets sent
The number of packets that were sent on the connection.
OS
Octets sent
The number of octets that were sent on the connection.
PR
Packets received
The number of packets that were received on the connection.
OR
Octets received
The number of octets that were received on the connection.
PL
Packets lost
The number of packets that were not received on the connection, as

deduced from gaps in the sequence number.
JI
Jitter
The average inter-packet arrival jitter, in milliseconds, expressed as

an integer number.
LA
Latency
Average latency, in milliseconds, expressed as an integer number.
1-15

Chapter 1 MGCP
An example of connection parameter encoding is:

P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
ReasonCode (E)
Reason codes are used by the gateway when deleting a connection to inform the Call
Agent about the reason for deleting the connection. They may also be used in a
RestartInProgress command, to inform the gateway of the Restarts reason. The
reason code is an integer number, and the values listed in Table 1-9 have been defined.
Table 1-9 Command reason codes
Reason code
Description
000
Endpoint state is nominal. (This code is used only in response to audit requests.)
900
Endpoint malfunctioning
901
Endpoint taken out of service
902
Loss of lower layer connectivity
Reason codes are three-digit numeric values. The reason code is optionally followed
by a white space and commentary, as in:
900 Endpoint malfuctioning
z
SpecificEndpointId (Z)
The endpoint identifier specified by the gateway is returned in a CreateConnection

response. The SpecificEndpointId is an optional parameter that identifies the
responding endpoint. It can be used when the EndpointId parameter referred to a any
of wildcard name. When a SpecificEndpointId is returned, the Call Agent should use it
as the EndpointId value in successive commands referring to this call.
z
RequestedInfo (F)
When a non-wildcard EndpointId is specified, the (possibly empty) RequestedInfo

parameter describes the information that is requested for the EndpointId specified. The
following endpoint information can be audited with this command:
RequestedEvents,
DigitMap,
SignalRequests,
RequestIdentifier,
NotifiedEntity,
ConnectionIdentifiers, DetectEvents, ObservedEvents, EventStates, RestartReason,

RestartDelay, ReasonCode, and Capabilities.
The RequestedInfo parameter contains a comma separated list of parameter codes.
For example, if one wants to audit the value of the NotifiedEntity, RequestIdentifier,
RequestedEvents, SiganalRequests, DigitMap, QuarantineHandling, DetectEvents,
and Capabilities parameters, the value of the RequestedInfo parameter will be:
F:N,X,R,S,D,Q,T,A
z
QuarantineHandling (Q)
1-16

Chapter 1 MGCP
The QuarantineHandling parameter specifies the handling of quarantine events, that

is, events that have been detected by the gateway before the arrival of the
NotificationRequest command, but have not yet been notified to the Call Agent. The
parameter provides a set of handling options:
whether the quarantined events should be processed or discarded. (The default is to
process them.)
whether the gateway is expected to generate at most one notification (step by step), or
multiple notifications (loop), in response to the request. (The default is exactly one.)
For example:
Q:loop
Q:process
Q:discard,loop
z
DetectEvents (T)
The list of events that are currently detected in the quarantine mode. The DetectEvent
parameter is encoded as a comma separated list of events.
For example:
T: hu,hd,hf,[0-9#*]
z
RestartMethod (RM)
The RestartMethod parameter specifies the type of restart, encoded as one of the
following keywords:
A graceful restart method indicates that the specified endpoints will be taken out of
service after the specified delay. The established connections are not yet affected, but
the Call Agent should refrain to establish new connections, and should try to gracefully
tear down the existing connections.
A forced restart method indicates that the specified endpoints are taken abruptly out
of service. The established connections, if any, are lost.
A restart method indicates that service will be restored on the endpoints after the
specified restart delay. There are no connections that are currently established on the
endpoints.
A disconnected method indicates that the endpoint has become disconnected and is
now trying to establish connectivity. The restart delay specifies the number of seconds
the endpoint has been disconnected. Established connections are not affected.
A cancel-graceful method indicates that a gateway is canceling a previously issued
graceful restart command.
For example:
RM:restart
z
RestartDelay (RD)
1-17

Chapter 1 MGCP
The restart delay parameter is expressed as a number of seconds. If the number is

absent, the delay value should be considered null.
In the case of the graceful method, a null delay indicates that the Call Agent should
simply wait for the natural termination of the existing connections, without establishing
new connections. The restart delay is always considered null in the case of the forced
method. A restart delay of null for the restart method indicates that service has already
been restored. This will typically occur after gateway startup/reboot.
z
EventStates (ES)
The EventStates parameter is encoded as a comma separated list of events.

For example:
E: hu
z
Capabilities (A)
Capabilities inform the Call Agent about endpoints capabilities when audited. The
encoding of capabilities is based on the Local Connection Options encoding for the
parameters that are common to both. The parameters used are Event Packages (v),
Modes (m), a list of supported codecs (*), type of network (nt), and so on.
In addition, capabilities can also contain a list of supported packages and a list of
supported modes.
z
The
RemoteConnectionDescriptor (RC)
RemoteConnectionDescriptor
includes
the
same
fields
as
in
the
LocalConnectionDescriptor, such as IP address, UDP port and packetization

parameters. For the CreateConnection command, this parameter may have a null
value when the information for the remote end is not known yet. This occurs because
the entity that builds a connection starts by sending a CreateConnection to one of the
two gateways involved in it. For the first CreateConnection issued, there is no
information available about the other side of the connection. This information may be
provided in SDP packets later through a ModifyConnection call.
z
LocalConnectionDescriptor (LC)
The LocalConnectionDescriptor is a session description that contains information

about IP address and port number suitable for the local connection, as defined in SDP.
4)
Command expressions
What are within the parenthesis preceded by the command name are input parameters.
Those enclosed by [] are optional.
z
EPCF (EndpointId, BearerInformation)

z
NotificationRequest
1-18

Chapter 1 MGCP
RQNT
(EndpointId,[NotifiedEntity,][RequestedEvents,]RequestIdentifier,[DigitMap,][SignalRe
quests,][QuarantineHandling,][DetectEvents,][encapsulated EndpointConfiguration])
z
Notify
NTFY (EndpointId,[NotifiedEntity,]RequestIdentifier,ObservedEvents)
z
CreateConnection
CRCX
(CallId,EndpointId,[NotifiedEntity,]LocalConnectionOptions,]Mode,[RemoteConnection
Descriptor,][Encapsulated NotificationRequest,][Encapsulated EndpointConfiguration])
z
ModifyConnection
MDCX
(CallId,EndpointId,ConnectionId,[NotifiedEntity,][LocalConnectionOptions,][Mode,][Re
moteConnectionDescriptor,][Encapsulated
NotificationRequest,][Encapsulated
EndpointConfiguration])
z
DeleteConnection
DeleteConnection from the Call Agent:

DLCX
(CallId,EndpointId,ConnectionId,[Encapsulated
NotificationRequest,][Encapsulated EndpointConfiguration])
DeleteConnection from the VoIP gateway:
DLCX (CallId,EndpointId,ConnectionId,Reason-code,Connection-parameters)
DeleteConnection from the Call Agent to delete multiple connections:
DLCX (CallId,EndpointId)
z
AuditEndpoint
AUEP (EndpointId,RequestedInfo)
z
AuditConnection
AUCX (EndpointId,ConnectionId,RequestedInfo)
z
RestartInProgress
RSIP (EndpointId,RestartMethod,[RestartDelay,][Reason-code])
5)
Command sample
The following is an MGCP command encoding sample:

CRCX 693585490 aaln/2@zd0068.com MGCP 1.0
C;a265
L:a:PCMA,P:20
M:inactive
X:65000108
R:D/[0-9*#T] (D), G/ld(N)
S:
1-19

Chapter 1 MGCP
The 1st line: The CreateConnection command. The transaction identifier is 693585490,
used to correlate this command with the responses that it triggers. It means to create a
connection between SoftX3000 and the second port of the access gateway whose
domain name is zd0068.com and the interface name is aaln. The protocol version of
MGCP is 1.0.
The 2nd line: The call identifier is a265.
The 3rd line: The local connection options. The Call Agent suggests to the gateway that
the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.
The 4th line: The connection mode is inactive, that is, neither sending nor receiving
packets. Only after the ModifyConnection command is executed, the connection mode
is changed to sendrecv.
The 5th line: The encapsulated NotificationRequest in this CreateConnection command.
The request identifier is 65000108, used to correlate this request with the notifications
that it triggers.
The 6th line: SoftX3000 requests the gateway to monitor the following events that will
happen in the endpoint: digit collection according to the rules specified by the digit map.
D/[0-9*#T] indicates the digits and letters in the DTMF packages. What are involved
are the digits from 0 to 9, the asterisk sign *, the pound sign #, and the timer identifier
T. Those characters can be part of digit strings, representing the dial keys for user.
D/[0-9*#T](D) indicates to process the digit strings dialed by user according to the
digit map. If a digit string matches at least one of available dial plans defined in the digit
map, the endpoint1 resident gateway will send the current digit string to the Call Agent.
G/ld(N) indicates if a long duration connection event in the generic media packages
happens then it is requested to notify the Call Agent. (Long duration connection refers
to a connection lasting for more than one hour.)
The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal
being sent currently.
II. Response format

1)
Response structure
Similar to the format of MGCP command, the response format is composed of a

response line, usually followed by a group of optional parameter lines. The response
line consists of the response code, transaction identifier, and an optional commentary,
which are separated by white spaces. The response code is a three-digit numeric value,
indicating the execution status of the command.
1-20

Response code
Chapter 1 MGCP
Transaction ID
Commentary (optional)
Response line

Parameter line
...
Figure 1-6 Structure of MGCP response

2)
Response parameters
The optional response parameter lines depend on the corresponding commands. For
more information, refer to the section Command parameters, earlier in this chapter.
3)
Response expressions
What are within the parenthesis preceded by the command name are response
parameter values. Those enclosed by [] are optional.
z
EPCF (ReturnCode)
z
NotificationRequest
RQNT (ReturnCode)
z
Notify
NTFY (ReturnCode)
z
CreateConnection
CRCX (ReturnCode,ConnectionId,[SpecificEndpointId,][LocalConnectionDescriptor])
z
ModifyConnection
MDCX (ReturnCode,[LocalConnectionDescriptor])
z
DeleteConnection
DeleteConnection from the Call Agent:

DLCX (ReturnCode,Connection-parameters)
DeleteConnection from the VoIP gateway:
DLCX (ReturnCode)
DeleteConnection from the Call Agent to delete multiple connections:
DLCX (ReturnCode)
z
AuditEndpoint
AUEP
(ReturnCode,EndpointIdList|{[RequestedEvents,][DigitMap,][SignalRequests,][Reques
tIdentifier,][NotifiedEntity,][ConnectionIdentifiers,][DetectEvents,][ObservedEvents,][Ev
1-21

Chapter 1 MGCP
entStates,][BearerInformation,][RestartReason,][RestartDelay,][ReasonCode,][Capabil
ities]})
z
AuditConnection
AUCX
(ReturnCode,[CallId,][NotifiedEntity,][LocalConnectionOptions,][Mode,][RemoteConne
ctionDescriptor,][LocalConnectionDescriptor,][ConnectionParameters])
z
RestartInProgress
RSIP (ReturnCode,[NotifiedEntity])
4)
Response sample
The following is a sample of connection response.

200 693585490 CRCX OK
I:1607901
v=0
c=IN IP4 191.169.4.165
m=audio 5012 RTP/AVP 8 0
a=ptime:20
The 1st line: 200 indicates the successful receipt of the command. 693585490 is a
transaction identifier which is the same as the transaction identifier contained in the
CreateConnection command that triggers this response. CRCX OK is a commentary.
The 2nd line: The connection identifier is 1607901.
The 3rd line: Null, indicating what is preceded is an SDP session description.
The 4th line: The SDP protocol version is 0. It is the local connection descriptor at this
time.
The 5th line: c in the response identifies the connection information. IN refers to
network indicator in the form of a text string. The currently defined IN is Internet. IP4
indicates the type of connection address is IP4. 191.169.4.165 represents the
network address of the gateway that has a connection with the MGC.
The 6th line: Media description. audio indicates the type of media is audio. ("audio is
used for audio connections, and nas used for data access.) 5012 is the transport
layer port number to which media streams are transmitted. RTP/AVP is the transport
layer protocol. Its value is associated with the type of address in the c line. For IP4, a
great number of media service streams are transferred over RTP/UDP. There are two
classes of protocols defined: RTP/AVP, audio/video application document, transported
over UDP; Udp, the DUP protocol. For audio and video signals, 8 0 represents the
type of media payload defined in the RTP audio/video application document. It
indicates all the formats may be used in the session but the first one is the default. At
this time, the mapping relation from RTP payload type to encoding is that 8
1-22

Chapter 1 MGCP
corresponds to the media encoding format PCMA. 0 corresponds to the media

encoding format PCM.
The 7th line: Attribute. Attribute is the basic method for SDP extension. It can be defined
as session-level attribute or media-level attribute. There are two forms of attributes:
a=<flag>, as feature attribute. It is a binary attribute, indicating the session has this
nature. For example, a=recvonly indicates the receive only feature.
a=<attribute>:<value>, as numeric value attribute. For example, a=ptime:20 indicates
the domain name of the media attribute is ptime and the value of the media attribute is
20.
1.3 Basic Control Procedures

1.3.1 Gateway Registration Procedure
The gateway must have registered to SoftX3000 before the subsequent procedures or
connections are made. An application of gateway registration procedure is illustrated in
Figure 1-7.
MG
SoftX3000
RSIP
RSIP_RSP
Figure 1-7 Example of gateway registration procedure

1)
Event 1: The MG originates an RSIP command to the MGC, reporting the MG has
completed a load or restart and requesting to register to the MGC. The following is
an RSIP encoding sample:
RSIP 836 aaln/*@iad-v2a-he.com MGCP 1.0 NSC 1.0

RM:restart
The 1st line: The RestartInProgress command. The transaction identifier is 836, used to
correlate this command with the responses that it triggers. It can be found that a restart
will take place on all endpoints of the access gateway whose domain name is
iad-v2a-he.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The restart method is restart. A restart method indicates that service will
be restored on the endpoints after the specified restart delay. There are no
connections that are currently established on the endpoints of the gateway.
2)
Event 2: The MGC sends a response to the MG registration request. The following
are RestartInProgress response samples.
Sample 1:
1-23

Chapter 1 MGCP
200 836 OK
200 indicates the successful receipt of the command. 836 is a transaction identifier
which is the same as the transaction identifier contained in the command that triggers
this response. OK is a commentary. If the MG receives this response, it indicates a
successful registration.
Sample 2:
500 836 The endpoint is unknown
500 indicates the transaction could not be executed because the endpoint is unknown.
836 is a transaction identifier which is the same as the transaction identifier contained
in the command that triggers this response. The endpoint is unknown is a
commentary. If the MG receives this response, it indicates an unsuccessful registration.
1.3.2 Successful Termination Call Procedure (in the Same MG)

An application example for a successful call procedure between two endpoints in the
same MG under the control of the same SoftX3000 is illustrated in Figure 1-8.
In the following example, it is assumed that
z
The endpoint identifier of the Endpoint1 is aaln/1@zd0068.com, which is

connected to the UserA;
The endpoint identifier of the Endpoint2 is aaln/2@zd0068.com, which is

connected to the UserB;
The UserA makes a call to the UserB, and the called party hooks on first;
The IP address of the MG is 191.169.4.165.
1-24

UserA
Chapter 1 MGCP
Endpoint1
1
Off-hook
dial-tone
dialing
SoftX3000
Endpoint2
UserB
RQNT
RQNT_RSP
NTFY
NTFY_RSP
3
RQNT
RQNT_RSP
NTFY
NTFY_RSP
CRCX
CRCX_RSP
CRCX
CRCX_RSP
7 RQNT
RQNT_RSP
Ringback tone
11
RQNT
RQNT_RSP
MDCX
MDCX_RSP
NTFY
NTFY_RSP
Ringing
Off-hook
10 MDCX
MDCX_RSP
Conversation
12 NTFY
On-hook
NTFY_RSP
13 MDCX
MDCX_RSP
15
Busy-tone
On-hook
DLCX
DLCX_RSP
17 NTFY
NTFY_RSP
18
14 DLCX
DLCX_RSP
16 RQNT
RQNT_RSP
RQNT
RQNT_RSP
Figure 1-8 MGCP call procedure between two endpoints in the same MG
1)
Event 1: SoftX3000 sends a RQNT command to the Endpoint1, requesting it to

detect the off-hook event on the endpoint. The MG acknowledges the command.
The MG keeps monitoring such an event until the user at the Endpoint1 hooks off.
RQNT encoding
RQNT 59659850 aaln/1@zd0068.com MGCP 1.0

X:6500010a
R:l/hd(N)
S:
The 1st line: The NotificationRequest command. The transaction identifier is 59659850,
used to correlate this command with the responses that it triggers. It indicates
SoftX3000 sends requests to the first port of the access gateway whose domain name
is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The request identifier is 6500010a, used to correlate this request with the
notifications that it triggers.
The 3rd line: SoftX3000 requests the MG to detect the off-hook event in the endpoint.
1-25

Chapter 1 MGCP
z
RQNT_RSP encoding
200 59659850 OK
200 indicates the successful receipt of the command. 59659850 is a transaction

identifier which is the same as the transaction identifier contained in the command that
triggers this response. OK is a commentary. Here, it indicates the MG has received
and is executing the request.
2)
Event 2: After the UserA hooks off, the Endpoint1 sends to SoftX3000 an NTFY
command which carries the message of the off-hook event happening in the
detected endpoint. SoftX3000 should acknowledge the information sent by the
Endpoint1.
NTFY encoding
NTFY 32008010 aaln/1@zd0068.com MGCP 1.0

X:6500010a
O:hd
The 1st line: The Notify command. Upon detecting a specific event happening on its first
port, the access gateway, whose domain name is zd0068.com and interface name is
aaln, notifies SoftX3000.
The 2nd line: The request identifier is 6500010a. That value is the same as the value of
the parameter contained in the RQNT command that triggers this notification. It is used
to correlate the RQNT command with the NTFY command.
The 3rd line: The MG detects the off-hook event.
z
NTFY_RSP encoding
200 32008010 OK

triggers this response. OK is a commentary. Here, it indicates SoftX3000 has received
that notification.
3)
Event 3: SoftX3000 sends a RQNT command to the Endpoint1, requesting it to

collect dialed digits according to the dial plan as well as sending the dial tone. The
Endpoint1 acknowledges the command and sends dial tone to the UserA at the
same time.
RQNT encoding

X:65000102
R:D/[0-9*#T](D),G/ld(N)
D:([1-9]xxxxxxx|0xxxxxxxxxx|*|x.# |[0-9*#].T)
S:L/dl
1-26

Chapter 1 MGCP
The 1st line: The NotificationRequest command. The transaction identifier is 59663957,
used to correlate this command with the responses that it triggers. It indicates
SoftX3000 sends requests to the first port of the access gateway whose domain name
is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The request identifier is 65000102, used to correlate this request with the
notifications that it triggers.
The 3rd line: SoftX3000 requests the MG to detect two events that will happen in the
endpoint. One event is digit collection according to the dial plan specified by the digit
map. D/[0-9*#T] indicates the digits and letters in the DTMF packages. What are
involved are the digits from 0 to 9, the asterisk sign *, the pound sign #, and the timer
identifier T. Those characters can be part of digit strings, representing the dial keys
for user. D/[0-9*#T](D) indicates to process the digit strings dialed by user according
to the digit map. If a digit string matches at least one of available dial plans defined in
the digit map, the endpoint1 resident gateway will send the current digit string to the
Call Agent. The other event: G/ld(N) indicates if a long duration connection event in
the generic media packages happens then it is requested to notify the Call Agent. (Long
duration connection refers to a connection lasting for more than one hour.)
The 4th line: Digit map. SoftX3000 delivers a dial plan to the Endpoint1 resident
gateway: ([1-9]xxxxxxx|0xxxxxxxxxx|*|x.# |[0-9*#].T). [1-9]xxxxxxx indicates user can
dial any 8-digit number started with an integer in the range of 1 to 9. 0xxxxxxxxxx
indicates any 11-digit number started with 0. * indicates each digit is reported as soon
as it is dialed. x.# indicates any length of digits are reported whenever # is dialed.
[0-9*#].T indicates any length of digits started with 0 ~ 9, * or # are reported after an
expiration.
The 5th line: The request signal, requesting the MG to acknowledge this command and
then send dial tone to the UserA.
z
RQNT_RSP encoding
200 59663957 OK

triggers this response. OK is a commentary. Here, it indicates the MG has received
and is executing the request; meanwhile it is sending the dial tone to the Endpoint1.
4)
Event 4: The Endpoint1 receives the digits according to the dial plan in the event 3.
Upon receiving all necessary digits, the Endpoint1 sends an NTFY command to
notify SoftX3000. The command carries the collected digits with the parameter
ObservedEvents. SoftX3000 acknowledges the command.
NTFY encoding

X:65000102
O:66500008
1-27

Chapter 1 MGCP
The 1st line: The Notify command. Upon detecting a specific event happening on its first
port, the access gateway, whose domain name is zd0068.com and interface name is
aaln, notifies SoftX3000.
The 2nd line: The request identifier is 65000102. That value is the same as the value of
the parameter contained in the RQNT command that triggers this notification. It is used
to correlate the RQNT command with the NTFY command.
The 3rd line: The MG detects what the UserA dials is 66500008.
z
NTFY_RSP encoding
200 32008011 OK

triggers this response. OK is a commentary. Here, it indicates SoftX3000 has received
that notification.
5)
Event 5: SoftX3000 creates a connection with the Endpoint1. The endpoint

acknowledges the command and returns the information about the connection at
the local endpoint.
CRCX encoding

C:4965
L:a:PCMA,P:20
M:inactive
X:65000106
R: G/ld(N)
S:
connection between SoftX3000 and the first port of the access gateway whose domain
name is zd0068.com and the interface name is aaln. The protocol version of MGCP is
1.0.
The 2nd line: The call identifier is 4965. The protocol supports that several connections
belonging to one call share the same call identifier. At present, Huawei design supports
that several connections belonging to one call use different call identifiers. Call identifier
is used for charging purposes.
1-28

Chapter 1 MGCP

that it triggers.
The 6th line: SoftX3000 requests the MG to detect the following event that will happen in
the endpoint: G/ld(N) indicates if a long duration connection event in the generic
media packages happens then it is requested to notify the Call Agent. (Long duration
connection refers to a connection lasting for more than one hour.)
z
CRCX_RSP encoding
200 59688530 CRCX OK

I:2008012
v=0
c=IN IP4 191.169.4.165
a=ptime:20
The 4th line: The SDP protocol version is 0. Here, what is returned is the session
description of the local endpoint (Endpoint1).
network address of the connection.
1-29

Chapter 1 MGCP
20.
6)
Event 6: SoftX3000 creates a connection with the Endpoint2. The endpoint

acknowledges the command and returns the information about the connection at
the local endpoint.
CRCX encoding

C:4a65
L:a:PCMA,P:20
M:inactive
X:65000008
R:
S:
connection between SoftX3000 and the second port of the access gateway whose
domain name is zd0068.com and the interface name is aaln. The protocol version of
MGCP is 1.0.
The 2nd line: The call identifier is 4a65. The protocol supports that several connections
belonging to one call share the same call identifier. At present, Huawei design supports
that several connections belonging to one call use different call identifiers. Call identifier
is used for charging purposes.
that it triggers.
The 6th line: SoftX3000 requests the MG to detect a specific event that will happen in
the endpoint.
z
CRCX_RSP encoding
1-30

Chapter 1 MGCP
200 59696722 CRCX OK

I:2008013
v=0
c=IN IP4 191.169.4.165
a=ptime:20
The 4th line: The SDP protocol version is 0. Here, what is returned is the session
network address of the connection.
20.
7)
Event 7: SoftX3000 requests the MG to play the ringing tone to the UserB. The MG
acknowledges the request and meanwhile plays the ringing tone to the UserB.
RQNT encoding
1-31

Chapter 1 MGCP

X:6500000a
R:
S:L/rg
The 1st line: SoftX3000 sends a request to the Endpoint2.

The 2nd line: The request identifier is 6500000a.
The 3rd line: The MG is requested to detect events that will happen in the Endpoint2.
The 4th line: The MG is requested to play the ringing tone to the UserB.
z
RQNT_RSP encoding
200 59704917 OK
Here, it indicates the MG has received and is executing the request; meanwhile it is
sending the ringing tone to the UserB.
8)
Event 8: SoftX3000 requests the MG to play the ringback tone to the UserA.
RQNT encoding

X:6500010c
R:
S:G/rt
The 1st line: SoftX3000 sends a request to the Endpoint1.

The 2nd line: The request identifier is 6500010c.
The 4th line: The MG is requested to play the ringback tone to the UserA.
z
RQNT_RSP encoding
200 59713109 OK
Here, it indicates the MG has received and is executing the request; meanwhile it is
sending the ringback tone to the UserA.
9)
Event 9: The UserB hooks off. The MG notifies the Call Agent of that event.
NTFY encoding

X:6500000a
O:hd
The 1st line: The Endpoint2 sends a notification to SoftX3000.

The 2nd line: The request identifier is 6500000a.
The 3rd line: The endpoint notifies SoftX3000 that the UserB hooked off.
z
NTFY_RSP encoding
200 32008014 OK
SoftX3000 acknowledges the receipt of the notification.
1-32

Chapter 1 MGCP
10) Event 10: SoftX3000 sends an MDCX command to the Endpoint2, requesting to
modify the connection. The command carries some connection parameters of the
Endpoint1. The Endpoint2 acknowledges the receipt of the command. Meanwhile,
it will modify the connection and stop sending the ringback tone.
z
MDCX encoding
MDCX 59721299 aaln/2@zd0068.com MGCP 1.0

C:4a65
I:2008013
L:e:on,a:PCMA,P:20
M:sendrecv
X:6500000e
R:G/ft(N),G/mt(N)
S:
v:0
c:IN IP4 191.169.4.165
m:audio 5012 RTP/AVP 8
The 1st line: SoftX3000 sends a ModifyConnection command to the Endpoint2. The
transaction identifier is 59721299.
The 2nd line: The call identifier is 4a65.
The 3rd line: The connection identifier is 2008013. The connection is created by the MG.
The MG assigns a unique connection identifier to the local end.
The 4th line: The local connection options. The Call Agent suggests to the MG that the
echo cancellation parameter is set to on, the compression algorithm is PCMA, and the
encapsulation delay is 20 milliseconds.
The 5th line: The connection mode is sendrecv.
The 6th line: The encapsulated NotificationRequest in this ModifyConnection command.
The request identifier is 6500000e, used to correlate this request with the notifications
that it triggers.
The 7th line: SoftX3000 requests the MG to detect the following events that will happen
in the endpoint: G/ft(N) indicates if a fax tone detected event in the generic media
packages happens then it is requested to notify the Call Agent; G/mt(N) indicates if a
modem detected event in the generic media packages happens then it is requested to
notify the Call Agent.
The 9th line: Null, indicating what is preceded is an SDP session description.
The 10th line: The SDP protocol version is 0. The session description carries some
connection parameters of the Endpoint1. Through the MDCX command, the
connection parameters of the Endpoint1 are provided for the Endpoint2.
1-33

Chapter 1 MGCP
The 11th line: Here, c indicates the connection information of the Endpoint1. IN refers
to network indicator in the form of a text string. The currently defined IN is Internet. IP4
network address of the connection. In general, the Call Agent provides connection
description parameters for the Endpoint2 through MGCP, such as the Endpoint1s IP
address, UDP port and RTP description.
The 12th line: Media description. audio indicates the type of media of the Endpoint1 is
audio. ("audio is used for audio connections, and nas used for data access.) 5012 is
the port number for the media of the Endpoint1. RTP/AVP is the media protocol. 8
indicates PCMA is the encoding format for the media which is negotiated by the
Endpoint1 and the Endpoint2.
z
MDCX_RSP encoding
200 59721299 MDCX OK

v:0
c:IN IP4 191.169.4.165
a:ptime:20
The 1st line: The Endpoint2 acknowledges the receipt of the MDCX command sent by
SoftX3000.
The 2nd line: The SDP protocol version is 0. Here, what is returned is the session
The 3rd line: Compared with the session description returned in the CRCX_RSP,
earlier in this chapter, it can be found that the encoding format for media, PCMA, is
determined in the MDCX_RSP. The CRCX_RSP only provided two options: PCMA and
PCM.
11) Event 11: SoftX3000 sends an MDCX command to the Endpoint1, requesting to
modify the connection. The command carries some connection parameters of the
Endpoint2. The Endpoint1 acknowledges the command, and then the UserA and
the UserB enjoy a conversation.
z
MDCX encoding

C:4965
I:2008012
L:e:on,a:PCMA,P:20
M:sendrecv
R:G/ft(N),G/mt(N)
S:
v:0
c:IN IP4 191.169.4.165
1-34

Chapter 1 MGCP
SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the

connection mode to sendrecv. The session description of the Endpoint2 is also
carried and provided for the Endpoint1.
z
MDCX_RSP encoding
200 59729491 MDCX OK

v:0
c:IN IP4 191.169.4.165
a:ptime:20
It indicates the Endpoint1 acknowledges the receipt of the MDCX command sent by
SoftX3000 and returns the session description of the local endpoint. Compared with
the session description returned in the CRCX_RSP, earlier in this chapter, it can be
found that the encoding format for media, PCMA, is determined in the MDCX_RSP. The
CRCX_RSP only provided two options: PCMA and PCM.
12) Event 12: The UserB hooks on. The Endpoint2 sends an NTFY command to
SoftX3000. SoftX3000 acknowledges the command.
z
NTFY encoding

X:6500000e
O:hu
The 1st line: The Endpoint2 detects a specified event that happened at the UserB, and
notifies SoftX3000 of the event.
The 2nd line: The request identifier is 6500000e, which is the same as the request
identifier carried in the encapsulated NotificationRequest command in the
ModifyConnection command described in the event 10. It indicates the Notify
command is triggered by the encapsulated NotificationRequest command in the
ModifyConnection command described in the event 10.
The 3rd line: The MG reports to SoftX3000 that the Endpoint2 detected an on-hook
event happening at the UserB.
z
NTFY_RSP encoding
200 32008015 OK
13) Event 13: SoftX3000 sends an MDCX command to the Endpoint2.

z
MDCX encoding

C:4a65
I:2008013
M:inactive
X:65000002
R:
S:
1-35

Chapter 1 MGCP
SoftX3000 sends an MDCX command to the Endpoint2, requesting to modify the mode
of the connection between them to inactive. In the ModifyConnection command, there
is an encapsulated NotificationRequest command with the request identifier as
65000002, indicating that the MGC requests the MG to detect the subsequent events
happening in the Endpoint2 and stop any signal played currently.
z
MDCX_RSP encoding
200 59754067 MDCX OK

v:0
c:IN IP4 191.169.4.165
a:ptime:20
14) Event 14: SoftX3000 sends a DLCX command to the Endpoint2, requesting to
delete the existing connection.
z
DLCX encoding
DLCX 59762260 aaln/2@zd0068.com MGCP 1.0

X:65000004
R:
S:
The 1st line: SoftX3000 sends a DLCX command to the Endpoint2, requesting to delete
the existing connection.
The 2nd line: In the DeleteConnection command, there is an encapsulated
NotificationRequest command with the request identifier as 65000004.
z
DLCX_RSP encoding
250 59762260 OK
250 indicates the connection is deleted. The transaction identifier is 59762260. OK

is a commentary.
15) Event 15: SoftX3000 sends a DLCX command to the Endpoint1, requesting to
delete the existing connection. The Endpoint1 acknowledges the command and
sends busy tone to the UserA at the same time.
z
DLCX encoding
DLCX 59770452 aaln/1@zd0068.com MGCP 1.0

X:65000106
R:
S:L/bz
The 1st line: SoftX3000 sends a DLCX command to the Endpoint1, requesting to delete
the existing connection.
1-36

Chapter 1 MGCP
The 2nd line: In the DeleteConnection command, there is an encapsulated

NotificationRequest command with the request identifier as 65000106.
The 3rd line: SoftX3000 requests the MG to detect events that will happen in the
Endpoint1.
The 4th line: SoftX3000 requests the MG to send the busy tone signal to the UserA.
z
DLCX_RSP encoding
250 59770452 OK
16) Event 16: SoftX3000 sends a RQNT command to the Endpoint2, requesting the
MG to detect events and signals that will happen in the Endpoint2. The involved
command encoding and response encoding are simple, and thus no more
information is provided here.
17) Event 17: The UserA hooks on. The Endpoint1 sends an NTFY command to notify
SoftX3000 of the event.
z
NTFY encoding

X:65000106
O:hu
The 1st line: The Endpoint1 detects a specified event that happened at the UserA, and
notifies SoftX3000 of the event.
The 2nd line: The request identifier is 65000106, which is the same as the request
identifier carried in the encapsulated NotificationRequest command in the
DeleteConnection command described in the event 15.
The 3rd line: The MG reports to the MGC that the Endpoint1 detected an on-hook event
happening at the UserA.
z
NTFY_RSP encoding
200 32008016 OK
18) Event 18: SoftX3000 sends a RQNT command to the Endpoint1, requesting the
MG to detect events and signals that will happen in the Endpoint1. The involved
command encoding and response encoding are simple, and thus no more
information is provided here.
1.3.3 Successful Termination Call Procedure (in Different MGs)

An application example for a successful call procedure between two telephone users in
different MGs under the control of the same SoftX3000 is illustrated in Figure 1-9. In the
following example, it is assumed that
z
The IP address of the MG1 is 191.169.3.38;
The UserA is connected to the MG1, and the corresponding endpoint identifier of
the UserA is aaln/1@iad1.huawei.com;
The IP address of the MG2 is 191.169.1.25;
1-37

z
Chapter 1 MGCP
The UserB is connected to the MG2, and the corresponding endpoint identifier of
the UserB is aaln/1@iad2.huawei.com;
The UserA makes a call to the UserB, and the called party hooks on first.
UserA
MG1
1
Off-hook
dial-tone
dialing
SoftX3000
MG2
UserB
RQNT
RQNT_RSP
NTFY
NTFY_RSP
3
RQNT
RQNT_RSP
NTFY
NTFY_RSP
CRCX
CRCX_RSP
CRCX
CRCX_RSP
7 RQNT
RQNT_RSP
Ringback tone
11
RQNT
RQNT_RSP
MDCX
MDCX_RSP
NTFY
NTFY_RSP
Ringing
Off-hook
10 MDCX
MDCX_RSP
Conversation
12 NTFY
On-hook
NTFY_RSP
13 MDCX
MDCX_RSP
15
Busy-tone
On-hook
DLCX
DLCX_RSP
17 NTFY
NTFY_RSP
18
14 DLCX
DLCX_RSP
16 RQNT
RQNT_RSP
RQNT
RQNT_RSP
Figure 1-9 MGCP call procedure between two endpoints in different MGs
It can be found that the call procedures illustrated in Figure 1-9 and Figure 1-8 are
basically same. As shown in Figure 1-9, the MGCP call procedure between two
endpoints in different MGs helps us easily understand some commands and responses,
such as CRCX and MDCX. Only the events involved those are described. For the
remaining events, refer to the section 1.3.2, earlier in this chapter.
1)
Event 5: SoftX3000 sends a CRCX command to the MG1, indicating it to create a

connection. The MG creates a connection as requested, and then sends a
CRCX_RSP as the response to SoftX3000. The response contains some
connection parameters, such as IP address, port number, bearer parameter and
connection identifier. The connection parameters describe the connection
information of the local gateway MG1. Judging from the following CRCX_RSP
encoding, the IP address refers to the IP address of the MG1: 191.169.3.38.
CRCX encoding
1-38

Chapter 1 MGCP
CRCX 269174338 aaln/1@iad1.huawei.com MGCP 1.0

C:2964
L:a:PCMA,P:20
M:inactive
X:64000002
R:G/ld(N)
S:
z
CRCX_RSP encoding
200 269174338 CRCX OK

I:1
v:0
c:IN IP4 191.169.3.38
2)
Event 6: SoftX3000 sends a CRCX command to the MG2, indicating it to create a

connection. The MG creates a connection as requested, and then sends a
CRCX_RSP as the response to SoftX3000. The response contains some
connection parameters, such as IP address, port number, bearer parameter and
connection identifier. The connection parameters describe the connection
information of the local gateway MG2. Judging from the following CRCX_RSP
encoding, the IP address refers to the IP address of the MG2: 191.169.1.25.
CRCX encoding
CRCX 269182530 aaln/1@iad2.huawei.com MGCP 1.0

C:2a64
L:a:PCMA,P:20
M:inactive
X:64000204
R:
S:
z
CRCX_RSP encoding
200 269182530 CRCX OK

I:4708075
v:0
c:IN IP4 191.169.1.25
m:audio 5004 RTP/AVP 8 0 4 18
a:ptime:20
3)
Event 10: SoftX3000 sends an MDCX command to the MG2, requesting to modify
the connection. The command carries some connection parameters of the MG1,
that is, the parameters contained in the CRCX_RSP from the MG1. Subsequently,
the connection mode is changed to be sendrecv. Judging from the following
MDCX encoding, the command carries the IP address of the MG1, that is,
1-39

Chapter 1 MGCP
191.169.3.38, and other connection information of the MG1. Through the MDCX
command, some connection parameters of the MG1 are provided to the MG2.
The MG2 sends to SoftX3000 an MDCX_RSP carrying the connection information of
the local gateway (MG2). After negotiation, the MG1 and the MG2 determine PCMA as
the encoding mode.
z
MDCX encoding
MDCX 269207107 aaln/1@iad2.huawei.com MGCP 1.0

C:2a64
I:4708075
L:e:on,a:PCMA,P:20
M:sendrecv
X:6400020a
R:
S:
v:0
c:IN IP4 191.169.3.38
z
MDCX_RSP encoding
200 269207107 MDCX OK

v:0
c:IN IP4 191.169.1.25
4)
Event 11: SoftX3000 sends an MDCX command to the MG1, requesting to modify
the connection. The command carries some connection parameters of the MG2,
that is, the parameters contained in the CRCX_RSP from the MG2. Subsequently,
the connection mode is changed to be sendrecv. Judging from the following
MDCX encoding, the command carries the IP address of the MG2, that is,
191.169.1.25, and other connection information of the MG2. Through the MDCX
command, some connection parameters of the MG2 are provided to the MG1.
The MG1 sends to SoftX3000 an MDCX_RSP carrying the connection information of

the local gateway. After negotiation, the MG1 and the MG2 determine PCMA as the
encoding mode.
At this time, both the MG1 and the MG2 know the connection information of the local
end and the opposite end. Conversation conditions are satisfied.
z
MDCX encoding
MDCX 269215299 aaln/1@iad1.huawei.com MGCP 1.0

C:2964
I:1
L:e:on,a:PCMA,P:20
X:6400000c
1-40

Chapter 1 MGCP
R:
S:
v:0
c:IN IP4 191.169.1.25
z
MDCX_RSP encoding
200 269215299 MDCX OK

v:0
c:IN IP4 191.169.3.38
1-41

Chapter 2 H.248
Chapter 2 H.248
2.1 Overview
H.248 is the same type of protocol as MeGaCo and completed by the International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) and
IETF together, used as a media gateway control protocol between a Media Gateway
Controller (MGC) and a Media Gateway (MG). The ITU-T, the IETF, the International
Softswitch Consortium (ISC), and other standardization organizations are optimizing
the H.248 protocol currently. Famous telecommunication equipment vendors are
investing much in the development and application of the H.248 protocol. Compared
with the MGCP protocol, the H.248 protocol can support more types of access
technologies and support the mobility of terminations. In addition, the H.248 protocol is
characterized by its support for network applications of much larger scale and also by
its convenience in the aspect of protocol extension. Therefore, the H.248 protocol is
more outstanding in flexibility, and thus is replacing MGCP gradually to grow to be the
standard of media gateway control protocols.
2.1.2 Related Terms

I. Termination
A Termination is a logical entity on an MG that sources and/or sinks media and/or
control streams. A Termination is described by a number of characterizing properties,
which are grouped in a set of descriptors that are included in commands. The media
stream parameters, as well as modem, and bearer parameters are encapsulated within
the Termination. Terminations have unique identities (TerminationIDs), assigned by the
MG at the time of their creation.
II. Type of Termination

There are two types of terminations: semi-permanent terminations and ephemeral
terminations. Terminations representing physical entities have a semi-permanent
existence. For example, a Termination representing a TDM channel might exist for as
long as it is provisioned in the gateway. Terminations representing ephemeral
information flows, such as RTP flows, would usually exist only for the duration of their
use.
Ephemeral Terminations are created by means of an Add command. They are
destroyed by means of a Subtract command. In contrast, when a physical Termination
2-1

Chapter 2 H.248
is Added to or Subtracted from a Context, it is taken from or to the null Context,

respectively.
III. Termination function

Terminations may have signals applied to them. Signals are MG generated media
streams such as tones and announcements as well as line signals such as hookswitch.
Terminations may be programmed to detect Events, the occurrence of which can
trigger notification messages to the MGC, or action by the MG.
Statistics may be accumulated on a Termination. Statistics are reported to the MGC
upon request (by means of the AuditValue command) and when the Termination is
taken out of the call it is in.
IV. TerminationID
Terminations are referenced by a TerminationID, which is chosen by the MG. A
wildcarding mechanism using two types of wildcards can be used with TerminationIDs.
The two wildcards are ALL and CHOOSE. ALL is used to address multiple Terminations
at a time. When ALL is used in the TerminationID of a command, the effect is identical
to repeating the command with each of the matching TerminationIDs. CHOOSE is used
to indicate to a media gateway that it must select a Termination satisfying the partially
specified Terminations. This allows, for instance, that an MGC instructs an MG to
choose a circuit within a trunk group.
For example, if there are TerminationIDs of R13/3/1, R13/3/2 and R13/3/3 in a text
encoding of the protocol, the TerminationID R13/3/* would match all of them. There are
some circumstances where ALL Terminations must be referred to. The TerminationID
* suffices, and is referred to as ALL. The CHOOSE TerminationID $ may be used
when it is required to refer to one TerminationID but it is uncertain that the Termination
exists exactly. In this way, the TerminationID R13/3/$ would match one of them.
V. Descriptor
Descriptor is a syntactic element of the protocol that groups related properties. For
instance, the properties of a media flow on the MG can be set by the MGC by including
the appropriate descriptor in a command.
VI. Termination Property

Terminations have properties. The properties have unique PropertyIDs. A series of
descriptors are composed of the properties.
There are a number of common properties for Terminations and properties specific to
media streams. The common properties are not specific to media streams and also
called the termination state properties. For each media stream, there are local
properties and properties of the received and transmitted flows. Properties not included
in the base protocol are defined in Packages. These properties are referred to by a
2-2

Chapter 2 H.248
name consisting of the PackageName and a PropertyID. Properties may be read-only

or read/write. For properties that are read/write, the MGC can set their values.
When a Termination is Added to a Context, the value of its read/write properties by
including the appropriate descriptors as parameters to the Add command. Properties
not mentioned in the Add command retain their prior values. Similarly, a property of a
Termination in a Context may have its value changed by the Modify command.
Properties not mentioned in the Modify command retain their prior values. Properties
may also have their values changed when a Termination is moved from one Context to
another as a result of a Move command.
VII. Root Termination

A special TerminationID, Root, refers to the entire MG. When Root is included in a
command as a parameter, the command can take effect on the entire gateway rather
than a Termination within it.
VIII. Context
A Context is an association between a number of Terminations. The Context describes
the topology and the media mixing and/or switching parameters if more than two
Terminations are involved in the association. There is a special Context called the null
Context. It contains Terminations that are not associated to any other Termination. For
instance, in a decomposed access gateway, all idle lines are represented by
Terminations in the null Context.
Figure 2-1 gives several examples of Termination and Context and is not meant to be
an all-inclusive illustration.
Media Gateway
Context
Context
Termination
RTP Stream
Context
Termination
RTP Stream
Termination
*
*
SCN Bearer Channel

Termination
SCN Bearer Channel
Null Context
Termination
SCN Bearer Channel
Context
Termination
RTP Stream
Termination
SCN Bearer Channel
Figure 2-1 Example of the connection model
2-3

Chapter 2 H.248
The maximum number of Terminations in a Context is an MG property. Media gateways

that offer only point-to-point connectivity might allow at most two Terminations per
Context. Media gateways that support multipoint conferences might allow three or
more Terminations per Context.
IX. Context attribute

The attributes of Contexts are:
ContextID: Context identifier, which should be 32-bit integers specified by the MG, and
be unique within the scope of the MG. The encodings of special Contexts are shown in
Table 2-1.
Table 2-1 Encodings of special Contexts
Binary
encoding
Context
Text
encoding
Meaning
Context NULL
"_"
Refers to Terminations that are not associated to

any other Termination in the MG.
Context CHOOSE
0xFFFFFFFE
"$"
Refers to requesting the MG to create a new

Context.
Context ALL
0xFFFFFFFF
"*"
Refers to all Contexts in the MG.
Topology: The topology of a Context describes the flow of media between the
Terminations within a Context. In contrast, the mode of a Termination (send/receive/_)
describes the flow of the media at the ingress/egress of the media gateway. There are
three connection values: oneway (indicating the oneway media stream between two
Terminations), bothway (indicating the bothway media stream between two
Terminations), and isolate (indicating no media stream between two Terminations). The
topology structure can only be used to describe a Context, and can be used in the
Add and Modify commands.
Priority: The priority is used for a Context in order to provide the MG with information
about a certain precedence handling for a Context. 0 represents the lowest priority and
15 represents the highest priority.
Indicator for emergency call: An indicator for an emergency call is used for a Context to
provide the MG with information about emergency handling for a Context. The MG
would preferentially handle a call using an emergency indicator.
X. Package
Different types of gateways may implement Terminations that have widely differing
characteristics. Variations in Terminations are accommodated in the protocol by
allowing Terminations to have optional Properties, Events, Signals and Statistics
implemented by MGs. To achieve MG/MGC interoperability, such options are grouped
2-4

Chapter 2 H.248
into Packages, and a Termination realizes a set of such Packages. An MGC can audit a
Termination to determine which Packages it realizes.
Properties, Events, Signals and Statistics defined in Packages, as well as parameters
to them, are referenced by identifiers (IDs).
Definition of a Package is composed of Properties, Events, Signals, Statistics, and
Procedures. Table 2-2 lists some packages commonly used.
Table 2-2 Basic packages
Package
Generic
Package ID
Description
Generic package for commonly encountered items.
Root
This package defines Gateway wide properties.
Tonegen
This package defines signals to generate audio tones. This

package does not specify parameter values. It is intended to be
extendable. Generally, tones are defined as an individual signal
with a parameter, ind, representing interdigit time delay, and a
tone id to be used with playtones. A tone id should be kept
consistent with any tone generation for the same tone. MGs are
expected to be provisioned with the characteristics of appropriate
tones for the country in which the MG is located.
Tone Detection
Package
Tonedet
This package defines events for audio tone detection. Tones are
selected by name (tone id). MGs are expected to be provisioned
with the characteristics of appropriate tones for the country in
which the MG is located.
Basic
DTMF
Generator
Package
Dg
This package defines the basic DTMF tones as signals and

extends the allowed values of parameter tl of playtone in
tonegen.
DTMF detection
Package
dd
This package defines the basic DTMF tones detection. This

package extends the possible values of tone id in the start tone
detected, end tone detected and long tone detected events.
Call
Progress
Tones Generator
Package
cg
This package defines the basic call process tones as signals and
extends the allowed values of parameter tl of playtone in
tonegen.
Call
Progress
Tones Detection
Package
cd
This package defines the basic all progress detection tones. This
package extends the possible values of tone id in the start tone
detected, end tone detected and long tone detected events.
Analog
Line
Supervision
Package
al
This package defines events and signals for an analog line.
Basic Continuity
Package
ct
This package defines events and signals for continuity test. The
continuity test includes provision of either a loopback or
transceiver functionality.
Network Package
nt
This package defines properties of network terminations

independent of network type.
Base
Package
Root
Tone Generator
Package
2-5

Package
Chapter 2 H.248
Package ID
Description
RTP Package
rtp
This package is used to support packet based multimedia data

transfer by means of the Real-time Transport Protocol (RTP).
TDM
Package
tdmc
This package is used to support TDM circuit terminations.
Circuit
Table 2-3 lists some Properties, Events, and Signals commonly used in Packages. The
general
formats
are
PackageID/PropertyID,
PackageID/EventID,
and
PackageID/Signal.
Table 2-3 Examples of PropertyIDs, EventIDs and Signals
Event
Meaning
al/fl
Flashhook event in the Analog Line Supervision Packages
al/of
Offhook event in the Analog Line Supervision Packages
al/on
Onhook event in the Analog Line Supervision Packages
al/ri
Ring signal in the Analog Line Supervision Packages
cg/bt
Busy tone signal in the Call Progress Tones Generator Packages
cg/ct
Congestion tone signal in the Call Progress Tones Generator

Packages
cg/cw
Call waiting tone signal in the Call Progress Tones Generator

Packages
cg/dt
Dial tone signal in the Call Progress Tones Generator Packages
cg/rt
Ringing tone signal in the Call Progress Tones Generator Packages
dd/ce
DigitMap Completion event in the DTMF detection Packages
nt/jit
Maximum jitter buffer in milliseconds in the Network Packages
tdmc/ec
Echo cancellation property in the TDM Circuit Packages
tdmc/gain
Gain control property in the TDM Circuit Packages

H.248 messages are transported over UDP/IP. In addition, the messages can be
transported over other transport protocols, such as Transmission Control Protocol
(TCP), Stream Control Transmission Protocol (SCTP) and Signaling System No. 7
Message Transfer Part 3-User Adaptation Layer (M3UA) borne over the IP network,
and Message Transfer Part Broadband (MTP3-B) borne over Asynchronous Transfer
Mode (ATM).
2-6

Chapter 2 H.248
The transport layer of the H.248 protocol in SoftX3000 may be UDP/TCP/SCTP borne
over IP and MTP3-B borne over ATM, as shown in Figure 2-2.
H.248
UDP/TCP/SCTP
IP
MAC
Figure 2-2 H.248 protocol stack in SoftX3000

The H.248 protocol assumes that the transport network under it is not reliable, thus the
state and reliability of a transaction is achieved by the protocol itself.

As shown in Figure 2-3, H.248 is implemented in SoftX3000 for communication
between the SoftSwitch and Trunk Media Gateways (TMGs) as well as communication
between the SoftSwitch and Access Media Gateways/Integrated Access Devices
(AMGs/IADs).
SoftX3000
.323
IP/ H
S
/
P
MGC
SoftPhone
SS7
PSTN
E1
CP
MG
MRS
IP Core
n
tra
Sig
8
24
H.
MG
CP/
H.2
48
IAD
TMG8010
E-phone
E-phone
Figure 2-3 H.248 implementation in SoftX3000

SoftX3000 communicates with the trunk gateways through the H.248 protocol.
SoftX3000 provides the H.248 MGC functionality to control Integrated Services Digital
Network User Part (ISUP) trunks in the trunk gateways. H.248 MGC provides the
following functions:
1)
RTP capability negotiation for egress and ingress gateways
The receiving and transmitting RTP capabilities of each H.248 MG will be configured.
SoftX3000 will ensure that a matching capability set between the two MGs will be used
to establish the call.
2-7

2)
Chapter 2 H.248
Management of Public Switched Telephone Network (PSTN) ISUP trunks in TMG

through the H.248 protocol
Supporting reservation of trunks on TMG
Supporting release of trunks on TMG
Supporting Hairpin connection of trunks on TMG
Supporting modification of trunk parameters
Applying tones to trunks
Supporting a trunk (or a group of trunks) going out of service and being brought
back to service
3)
Management of ephemeral RTP Terminations in TMG through the H.248 protocol
Supporting creation of ephemeral Terminations
Supporting destruction of ephemeral Terminations
Supporting modification of RTP parameters on ephemeral Terminations

2.2.1 Message Types
I. Command
The H.248 protocol defines eight commands for manipulating the logical entities of the
protocol connection model, Contexts and Terminations. Commands provide for
complete control of the properties of Contexts and Terminations.
Most commands are for the specific use of the MGC as command initiator in controlling
MGs as command responders. The exceptions are the Notify and ServiceChange
commands: Notify is sent from MG to MGC, and ServiceChange may be sent by either
entity.
H.248 commands and meanings are shown in Table 2-4.
Table 2-4 H.248 commands
Command name
Command
code
Description
Add
ADD
MGCMG. The Add command adds a Termination to a

Context. If no ContextID is specified, a Context will be first
generated and then a Termination is added into it.
Modify
MOD
MGCMG. The Modify command modifies the properties,

events and signals of a Termination.
Subtract
SUB
MGCMG. The Subtract command disconnects a

Termination from its Context and returns statistics on the
Terminations participation in the Context. The Subtract
command on the last Termination in a Context deletes the
Context.
Move
MOV
MGCMG. The Move command atomically moves a

Termination to another Context.
2-8

Command name
Chapter 2 H.248
Command
code
Description
AuditValue
AUD_VAL
MGCMG. The AuditValue command returns the current

state of properties, events, signals and statistics of
Terminations.
AuditCapabilities
AUD_CAP
MGCMG. The AuditCapabilities command returns a

collection of termination capabilities.
Notify
NTFY
MGMGC. The Notify command allows the MG to inform the

MGC of the occurrence of events in the MG.
SVC_CHG
MGCMG or MGMGC. The ServiceChange command

allows the MG to notify the MGC that a Termination or group
of Terminations is about to be taken out of service or has just
been returned to service. ServiceChange is also used by the
MG to announce its availability to an MGC (registration), and
to notify the MGC of impending or completed restart of the
MG. The MGC may announce a handover to the MG by
sending it a ServiceChange command.
ServiceChange
II. Response
All H.248 commands are acknowledged. The structure of a response is basically the
same as that of a command. TransactionID correlates a command with its response.
There are two types of responses, namely Reply and Pending. Reply indicates the
execution of the command has been completed and returns information about the
execution success or failure. Pending" indicates the command is actively being
processed but has not been completed. It is used to prevent the sender from assuming
the TransactionRequest was lost where the command will take some time to complete.

I. Command format
1)
Encapsulation format for command
A message is an information unit sent or received by the H.248 protocol. In the H.248
protocol, one ore more commands are encapsulated in a message.
A message may be encoded in a binary format or in a text format. In the case of binary
codes, specifications defined in ITU-T X.680 (ASN.1) are used for description, and BER
rules defined in X.690 for encoding; in the case of text format, RFC 2234 ABNF
specifications are followed. MGCs should support both encoding formats. MGs may
support one of or both formats. Any H.248 message shares the same structure as
shown in Figure 2-4.
2-9

Chapter 2 H.248
Megaco/H.248 message
Header
Transaction
Transaction
Req or Reply
Req or Reply
Trans Hdr
Ctx Hdr
Action
Ctx Properties
Trans Hdr
....
Transaction
Req or Reply
....
Action
Command
Descriptor
....
....
Command
Descriptor
Figure 2-4 H.248 message structure

z
Message
Messages start with a header which is followed by several transactions. The header
contains a Message Identifier (MID) and a Version Number. The MID identifies the
sender of the message which may be a domain address, domain name or device name.
Domain name is a suggested default. The Version Number identifies the version of the
protocol the message conforms to. Versions consist of one or two digits, beginning with
version 1 for the present version of the protocol.
z
Transaction
A message contains one or more transactions. The transactions in a message are

treated independently. There is no order implied.
Transactions include requests and responses, and responses are divided into two
types: TransactionReply and TransactionPending. Commands are encapsulated in
transaction requests which are described here. For the structure of transaction
responses, refer to the description later in this chapter.
There is one Transaction per request invocation. A transaction contains one or more
actions and each action includes one or more commands related to a single Context.
The structure is as follows:
TransactionRequest(TransactionId {
ContextID {Command ... Command},
...
ContextID {Command ... Command } })
z
Action
2-10

Chapter 2 H.248
Actions are related to Contexts. Actions are identified by a ContextID. In an action,

commands should be processed in order.
An action begins with the Context header (CtxHdr) in which ContextID is contained for
identifying the Context this action corresponds to. ContextID is assigned by the MG and
is unique within the scope of the MG. The MGC shall use the ContextID in all
subsequent transactions relating to that Context.
CtxHdr is followed by several commands, and these commands are related to the
Context identified by the ContextID.
z
Command
Commands are the major contents in an H.248 message. They control the Context and
Termination attributes including specifying the topology structure of the Context and
specifying the event reported by the Termination, for example, what signals and actions
can be imposed on the Termination. A command is composed of the command header
(CMDHdr) and command parameters. In the H.248 protocol, command parameters are
grouped into Descriptors.
The H.248 message mechanism is shown in Figure 2-5.
Message
TransactionID1
ContextID1
Command
CMD1
Descriptor
Des-1
Des-n
...CMDn
...
ContextIDn
TransactionIDn
Figure 2-5 Message mechanism

2)
Descriptor
The parameters to a command are termed Descriptors. A descriptor consists of a name

and a list of items. Some items may have values. Many commands share common
descriptors. Descriptors may be returned as output from a command. In any such
return of descriptor contents, an empty descriptor is represented by its name
unaccompanied by any list.
In general, the text format of descriptors is as follows:
DescriptorName=<someID>
{ parm = value, parm = value ...... }
2-11

Chapter 2 H.248
The H.248 protocol defines 19 types of descriptors. Those commonly used descriptors
are described below.
z
Modem (MD) descriptor
The Modem descriptor specifies the modem type and other parameters. The descriptor
includes the following modem types: V.18, V.22, V.22bis, V.32, V32bis, V.34, V.90, V.91,
Synchronous ISDN, and allows for extensions. By default, no Modem descriptor is
present in a Termination.
z
Mux (MX) descriptor
In multimedia calls, a number of media streams are carried on a (possibly different)

number of bearers. The multiplex (Mux) descriptor associates the media and the
bearers. The descriptor includes the multiplex type: H.221, H.223, H.226, V.76, and
possible extensions. Definition of the Mux descriptor is composed of the multiplex type
and a set of TerminationIDs representing the multiplexed inputs. For example,
Mux=H.221{ MyT3/1/2,MyT3/2/3,MyT3/3/6,MyT3/21/22}
z
Media (M) descriptor
The Media descriptor specifies the parameters for all the media streams. These
parameters are structured into two descriptors, a Termination State descriptor, which
specifies the properties of a Termination that are not stream dependent, and one or
more Stream descriptors each of which describes a single media stream.
A stream is identified by a StreamID. There are three types of Stream descriptors,
namely LocalControl, Local, and Remote. As a convenience, a LocalControl, Local, or
Remote descriptor may be included in the Media descriptor without an enclosing
Stream descriptor. In this case, the StreamID is assumed to be 1. The relationship
between these descriptors is like this:
z
Media Descriptor
TerminationStateDescriptor
Stream Descriptor
LocalControl Descriptor
Local Descriptor
Remote Descriptor
Termination State (TS) descriptor
The Termination State descriptor contains the ServiceStates property, the

EventBufferControl property and properties of a Termination (defined in Packages) that
are not stream specific. The ServiceStates (SI) property describes the overall state of
the Termination. A Termination can be in one of the following states: test (TE), out of
service (OS), or in service (IV). The test state indicates that the Termination is being
tested. The state out of service indicates that the Termination cannot be used for
traffic. The state in service indicates that a Termination can be used or is being used
for normal traffic. in service is the default state.
2-12

Chapter 2 H.248
The EventBufferControl (EB) property specifies whether events are buffered following
detection of an event in the Events descriptor, or processed immediately.
z
Stream (ST) descriptor
A Stream descriptor specifies the parameters of a single bi-directional stream. There

are three types of Stream descriptors, namely LocalControl, Local, and Remote. The
Stream descriptor includes a StreamID which identifies the stream. Streams are
created by specifying a new StreamID on one of the Terminations in a Context. A
stream is deleted by setting empty Local and Remote descriptors for the stream with
ReserveGroup and ReserveValue in LocalControl set to false on all Terminations in
the Context that previously supported that stream.
StreamIDs are of local significance between the MGC and the MG, and they are
assigned by the MGC. Within a Context, StreamID is a means by which to indicate
which media flows are interconnected: streams with the same StreamID are connected.
z
LocalControl (O) descriptor
The LocalControl descriptor contains the Mode (MO) descriptor, the ReserveGroup
(RG) and ReserveValue (RV) properties and properties of a Termination (defined in
Packages) that are stream specific.
The allowed values for the Mode property are send-only (SO), receive-only (RC),
send/receive (SR), inactive (IN) and loop-back (LB). Send and receive are with
respect to the exterior of the Context, so that, for example, a stream set to
mode=sendonly does not pass received media into the Context. Signals and Events
are not affected by mode.
The Boolean-valued Reserve properties, ReserveValue and ReserveGroup, of a
Termination indicate what the MG is expected to do when it receives a local and/or
remote descriptor.
z
Local (L) and Remote (R) descriptors
The Local descriptor refers to the media received by the MG, and the Remote
descriptor refers to the media sent by the MG.
The MGC uses Local and Remote descriptors to reserve and commit MG resources for
media decoding and encoding for the given Stream(s) and Termination to which they
apply. The MG includes these descriptors in its response to indicate what it is actually
prepared to support. The MG shall include additional properties and their values in its
response if these properties are mandatory yet not present in the requests made by the
MGC.
When text encoding the protocol, the Local and Remote descriptors consist of session
descriptions as defined in SDP (RFC 2327).
z
Events (E) descriptor
The Events descriptor contains a RequestIdentifier and a list of events that the MG is
requested to detect and report. The RequestIdentifier is used to correlate the request
2-13

Chapter 2 H.248
with the notifications that it may trigger. Requested events include, for example, fax
tones, hookflash, and on-hook and off-hook transitions.
Each event in the descriptor contains the Event name, optional actions, and optional
parameters. The Event name consists of a Package Name (where the event is defined)
and an EventID in the format of PackageName/EventID. For example, al/on indicates
the onhook event in the Analog Line Supervision Packages. Events can have
parameters which are defined and named in the Package. The actions parameter
indicates one or more possible actions to be taken at the occurrence of an event.
z
EventBuffer (EB) descriptor
The EventBuffer descriptor contains a list of events, with their parameters if any, that
the MG is requested to detect and buffer when EventBufferControl equals LockStep.
z
Signals (SG) descriptor
A SignalsDescriptor is a parameter that contains the set of signals that the MG is asked
to apply to a Termination. A SignalsDescriptor contains a number of signals and/or
sequential signal lists. A SignalsDescriptor may contain zero signals and sequential
signal lists. Signals shall be named with a Package name (in which the signal is defined)
and a SignalID in the format of PackageName/SignalID.
For example, SG{SL=0{cg/dt}}.
In which, SL is the abbreviation of SignalList, and cg/dt indicates the dial tone signal
in the Call Progress Tones Generator Packages.
There are three types of signals:
on/off: The signal lasts until it is turned off;
timeout: The signal lasts until it is turned off or a specific period of time elapses;
brief: The signal duration is so short that it will stop on its own unless a new signal is
applied that causes it to stop; no timeout value is needed.
z
Audit (AT) descriptor
An Audit command (AuditValue and AuditCapabilities commands) specifies what

information is to be audited. Possible items are:
Modem, Mux, Events, Media, Signals, ObservedEvents, DigitMap, Statistics, Packages,
and EventBuffer.
z
ServiceChange (SC) descriptor
The ServiceChange descriptor specifies the reason of a ServiceChange and contains

the following parameters:
The ServiceChangeMethod (MT) parameter specifies the type of ServiceChange that
will occur or has occurred. This parameter may be one of the six methods of
ServiceChange:
Graceful: Indicates that the specified Terminations will be taken out of service after the
specified ServiceChangeDelay; established connections are not yet affected, but the
2-14

Chapter 2 H.248
MGC should refrain from establishing new connections and should attempt to
gracefully tear down existing connections on the Termination(s) affected by the
ServiceChange command.
Forced: Indicates that the specified Termination(s) were taken abruptly out of service
and any established connections associated with them were lost.
Restart: Indicates that service will be restored on the specified Terminations after
expiration of the ServiceChangeDelay.
Disconnected: Always applied with the Root TerminationID, indicates that the MG lost
communication with the MGC, but it was subsequently restored. Since the MG state
may have changed, the MGC may wish to use the Audit command to resynchronize its
state with the MGs.
Handoff: Sent from the MGC to the MG, this reason indicates that the MGC is going out
of service and a new MGC association must be established. Sent from the MG to the
MGC, this indicates that the MG is attempting to establish a new association in
accordance with a Handoff received from the MGC with which it was previously
associated.
Failover: Sent from the MG to the MGC to indicate the primary MG is out of service and
a secondary MG is taking over.
The ServiceChangeReason (RE) parameter specifies the reason why the
ServiceChange has occurred or will occur. It consists of an alphanumeric token (IANA
registered) and, optionally, an explanatory string. The following parameter values in
Table 2-5 are defined:
Table 2-5 ServiceChangeReason values
ServiceChangeReason value
Meaning
900
Service Restored
901
Cold Boot
902
Warm Boot
903
MGC Directed Change
904
Termination malfunctioning
905
Termination taken out of service
906
Loss of lower layer connectivity
907
Transmission Failure
908
MG Impending Failure
909
MGC Impending Failure
910
Media Capability Failure
911
Modem Capability Failure
2-15

Chapter 2 H.248
ServiceChangeReason value
Meaning
912
Mux Capability Failure
913
Signal Capability Failure
914
Event Capability Failure
915
State Loss
916
Package Type Changed
917
Capability Changed
The optional ServiceChangeAddress parameter specifies the address, for example,

IP port number for IP networks, to be used for subsequent communications.
The optional ServiceChangeDelay parameter is expressed in seconds.
The optional ServiceChangeProfile parameter specifies the profile, if any, of the
protocol supported. The ServiceChangeProfile includes the version of the profile
supported.
The optional ServiceChangeVersion parameter contains the protocol version and is
used if protocol version negotiation occurs.
The ServiceChangeMGCId parameter can be returned by the MGC to the MG,
describing the MGC that should preferably be contacted for further service by the MG.
In this case, the MG shall reissue the ServiceChange command to the new MGC. The
MGC specified in a ServiceChangeMgcId, if provided, shall be contacted before any
further alternate MGCs. On a HandOff message from the MGC to the MG, the
ServiceChangeMgcId is the new MGC that will take over form the current MGC.
The optional TimeStamp parameter specifies the actual time as kept by the sender. It
can be used by the responder to determine how its notion of time differs from that of its
correspondent.
The Extension parameter may contain any value whose meaning is mutually
understood by the MG and the MGC.
z
DigitMap (DM) descriptor
A DigitMap is a dialing plan resident in the Media Gateway used for detecting and
reporting digit events received on a Termination. The DigitMap descriptor contains a
DigitMap name and the DigitMap to be assigned.
The collection of digits according to a DigitMap may be protected by three timers, that is,
a start timer (T), short timer (S), and long timer (L). The timers are configurable
parameters to a DigitMap. The start timer is started at the beginning of every digit map
use, but can be overridden.
The start timer (T) is used prior to any digits having been dialed.
2-16

Chapter 2 H.248
If the Media Gateway can determine that at least one more digit is needed for a digit
string to match any of the allowed patterns in the digit map, then the interdigit timer
value should be set to a long (L) duration, for example, 16 seconds.
If the digit string has matched one of the patterns in a digit map, but it is possible that
more digits could be received which would cause a match with a different pattern, then
instead of reporting the match immediately, the MG must apply the short timer (S), for
example, 8 seconds, and wait for more digits.
For more information on digit map, refer to MGCP protocol, earlier in this manual.
z
Statistics (SA) descriptor
The Statistics descriptor provides information describing the status and usage of a
Termination during its existence within a specific Context. The particular statistical
properties that are reported for a given Termination are determined by the Packages
realized by the Termination. By default, statistics are reported when the Termination is
Subtracted from the Context. Statistics may also be returned from the AuditValue
command, or any Add/Move/Modify command using the Audit descriptor.
z
Packages (PG) descriptor
Used only with the AuditValue command, the Packages descriptor returns a list of
Packages realized by the Termination.
z
ObservedEvents (OE) descriptor
ObservedEvents is supplied with the Notify command to inform the MGC of which
event(s) were detected. Used with the AuditValue command, the ObservedEvents
descriptor returns events in the event buffer which have not been notified.
ObservedEvents contains the RequestIdentifier of the EventsDescriptor that triggered
the notification, the event(s) detected and the detection time(s). Detection times are
reported with a precision of hundredths of a second.
z
Topology (TP) descriptor
A Topology descriptor is used to specify flow directions between Terminations in a

Context. The Topology descriptor applies to a Context instead of a Termination. The
default topology of a Context is that each Terminations transmission is received by all
other Terminations. The Topology descriptor is optional to implement.
A Topology descriptor consists of a sequence of triples of the form (T1, T2, association).
T1 and T2 specify Terminations within the Context, possibly using the ALL or CHOOSE
wildcard. The association specifies how media flows between these two Terminations
are follows:
(T1, T2, isolate) means that the Terminations matching T2 do not receive media from
the Terminations matching T1, nor vice versa.
(T1, T2, oneway) means that the Terminations that match T2 receive media from the
Terminations matching T1, but not vice versa.
2-17

Chapter 2 H.248
(T1, T2, bothway) means that the Terminations matching T2 receive media from the
Terminations matching T1, and vice versa.
Figure 2-6 shows some topology examples.
Context 1
Context 1
T2
Context 1
T2
T2
T1
T3
T1
T1
T3
T3
1. No topology descriptors
2. T1, T2 Isolate
3. T3, T2 One way
Context 1
Context 1
Context 1
T2
T2
T1
T3
4. T2, T3 One way
T1
T2
T3
5. T2,T3 Bothway
T1
T3
6. T1,T2 Bothway
Note: the direction of the arrow indicates the direction of flow
Figure 2-6 A sequence of example topologies

Table 2-6 describes the topologies shown in Figure 2-6.
Table 2-6 Topology description
Topology
Description
No topology descriptors
When no topology descriptors are included, all Terminations have a bothway

connection to all other Terminations.
T1, T2, Isolate
Removes the connection between T1 and T2.

T3 has a bothway connection with both T1 and T2.
T1 and T2 have a bothway connection to T3.
T3, T2, Oneway
4
5
A oneway connection from T3 to T2 (that is, T2 receives media flow from T3). A
bothway connection between T1 and T3.
T2, T3, Oneway
A oneway connection from T2 to T3. T1 and T3 remain bothway connected.
T2, T3 Bothway
T2 is bothway connected to T3. This results in the same as 2.
2-18

Chapter 2 H.248
Topology
Description
T1, T2, Bothway
(T2, T3 bothway and T1, T3 bothway may be implied or explicit.) All Terminations have
a bothway connection to all other Terminations.
Error (ER) descriptor
If a Transaction execution encounters an error, the reply of the command shall contain
an Error descriptor. The Notify command may also contain an Error descriptor. Errors
consist of an IANA registered error code and an explanatory string. Sending the
explanatory string is optional.
Table 2-7 Identified error codes
Error code
Meaning
400
Bad Request
401
Protocol Error
402
Unauthorized
403
Syntax Error in Transaction
406
Version Not Supported
410
Incorrect identifier
411
The transaction refers to an unknown ContextID
412
No ContextIDs available
421
Unknown action or illegal combination of actions
422
Syntax Error in Action
430
Unknown TerminationID
431
No TerminationID matched a wildcard
432
Out of TerminationIDs or No TerminationID available
433
TerminationID is already in a Context
434
Number of Terminations in a Context exceeds the maximum value
440
Unsupported or unknown Package
441
Missing RemoteDescriptor
442
Syntax Error in Command
443
Unsupported or Unknown Command
444
Unsupported or Unknown Descriptor
445
Unsupported or Unknown Property
446
Unsupported or Unknown Parameter
2-19

Chapter 2 H.248
Error code
Meaning
447
Descriptor not legal in this command
448
Descriptor appears twice in a command
450
No such property in this package
451
No such event in this package
452
No such signal in this package
453
No such statistic in this package
454
No such parameter value in this package
455
Parameter illegal in this Descriptor
456
Parameter or Property appears twice in this Descriptor
457
Missing signal or event parameter
471
Implied Add for Multiplex failure
500
Internal Gateway Error
501
Not Implemented
502
Not ready
503
Service Unavailable
504
Command Received from unauthorized entity
505
Command Received before Restart Response
510
Insufficient resources
512
Media Gateway unequipped to detect requested Event
513
Media Gateway unequipped to generate requested Signals
514
Media Gateway cannot send the specified announcement
515
Unsupported Media Type
517
Unsupported or invalid mode
518
Event buffer full
519
Out of space to store digit map
520
Media Gateway does not have a digit map
521
Termination is "ServiceChangeing"
526
Insufficient bandwidth
529
Internal hardware failure
530
Temporary Network failure
531
Permanent Network failure
532
Property, Event, Signal, and Statistics to be audited do not exist
2-20

Chapter 2 H.248
Error code
581
3)
Meaning
Does Not Exist
Command expressions
What are within the parenthesis preceded by the command name are input parameters.
Those enclosed by [] are optional.
z
ADD
ADD
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,EventBufferDescriptor][,SignalsDescriptor][,DigitMapDescriptor][,AuditDescriptor])
z
Modify
MOD
z
Subtract
SUB (TerminationID[,AuditDescriptor])
z
Move
MOV
z
AuditValue
AuditValue (TerminationID[,AuditDescriptor])
z
AuditCapabilities
AuditCapabilities (TerminationID[,AuditDescriptor])
z
Notify
Notify (TerminationID,ObservedEventsDescriptor[,ErrorDescriptor])
z
ServiceChange
ServiceChange (TerminationID,ServiceChangeDescriptor)
4)
Command sample
The following example is a text description of H.248 command.

MEGACO/1 [191.169.150.170]:2944
T=372794021{
C= - {
MF=A0{
E=369099784{
dd/ce{DigitMap=dmap1}, al/*},
2-21

Chapter 2 H.248
SG{cg/dt},
DM=dmap1{
([2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|x.F|[0-9EF].L)}}}}
The 1st line: The MeGaCo protocol version is 1. The MID is the identifier of the sender
of this message. In this case, it is the IP address of and port [191.169.150.170]:2944.
The 2nd line: The TransactionID is 372794021, used to correlate the request with the
responses that it will trigger.
The 3rd line: In this case, the encapsulated Context in this Transaction is null.
The 4th line: The Modify command, used to modify the properties, events and signals of
the Termination A0.
The 5th line: The Events descriptor with the RequestIdentifier 369099784. The
RequestIdentifier is used to correlate the request with the notifications that it may
trigger.
The 6th line: The MGC requests the MG to detect two events that will happen in the
termination A0. One event is digit collection according to the dial plan (dmap1)
specified by the digit map. The other event is detection of all events defined in the
Analog Line Supervision Packages (al).
The 7th line: The Signals descriptor. It indicates that the MGC requests the MG to send
the dial tone to the termination A0.
The 8th line: The DigitMap descriptor. The MGC delivers the dial plan (dmap1) to the
termination A0.
The 9th line: The dial plan dmap1. In the dial plan, [2-9]xxxxxx indicates that user
can dial any 7-digit number started with an integer in the range of 2 to 9. 13xxxxxxxxx
indicates any 11-digit number started with 13. 0xxxxxxxxx indicates any 10-digit
number started with 0. 9xxxx indicates any 5-digit number started with 9. 1[0124-9]x
indicates any 3-digit number started with 1 which is followed by a decimal integer
except 3. E is the letter E. [0-9EF].L indicates that any length of digits started with 0
~ 9, E or F are reported after an expiration of the long timer.
II. Response format

1)
Encapsulation format for response
The same as the encapsulation format for command. Here, we will detail two types of
transactions of responses.
Transactions include requests and responses, and responses are divided into two
types: TransactionReply and TransactionPending. For the encapsulation command of
the Transaction Request, refer to the preceding section.
z
Transaction Reply
Transaction Reply is a response of the transaction receiver to the Transaction Request.

Every transaction should have its Reply. A TransactionRequest stops being executed
2-22

Chapter 2 H.248
either if all commands in the TransactionRequest have been carried out successfully or
a failure is encountered during the execution of a non-optional command in the
TransactionRequest.
The structure of Transaction Reply is as follows:
TransactionReply(TransactionID {
ContextID { Response ...Response },
...
ContextID { Response ...Response } })
z
Transaction Pending
The receiver invokes the Transaction Pending. A Transaction Pending indicates that
the transaction is actively being processed, but has not been completed. It is used to
prevent the sender from assuming the TransactionRequest was lost where the
command will take some time to complete. The structure of Transaction Pending is as
follows:
TransactionPending (TransactionID { } )
Transactions are presented as TransactionRequests. Corresponding response to a
TransactionRequest is received in a single reply, possibly preceded by a number of
TransactionPending messages.
2)
Response descriptors
For response descriptors, refer to the description of command descriptors, earlier in

this chapter.
3)
Response expressions
What are within the parenthesis preceded by the command name are response
parameter values. Those enclosed by [] are optional.
z
ADD
ADD
or][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBuffer
Descriptor][,StatisticsDescriptor][,PackagesDescriptor])
z
Modify
MOD
z
Subtract
SUB
2-23

Chapter 2 H.248
z
Move
MOV
z
AuditValue
AuditValue
z
AuditCapabilities
AuditCapabilities
or][,SignalsDescriptor][,ObservedEventsDescriptor][,EventBufferDescriptor][,Statistics
Descriptor])
z
ServiceChange
ServiceChange (TerminationID[,ServiceChangeDescriptor])
4)
Response sample
The following is a text encoding sample of a transaction response.

MEGACO/1 [191.169.150.172]:2944
P=372794021{
C= - {
MF=A0}}
The 1st line: The MeGaCo protocol version is 1. The MID is the identifier of the sender
of this message. In this case, it is the IP address of and port [191,169,150,172]:2944.
The 2nd line: TransactionID. The TransactionID of the response is 372794021, which is
the same as the TransactionID described in the command sample, used to correlate
the command with the response.
The 3rd line: Here the Context is null.
The 4th line: Acknowledgement that the Termination A0 has received the
TransactionRequest from the MGC, indicating that the MG is executing it.
2-24

Chapter 2 H.248
2.3 Basic Control Procedures

2.3.1 Gateway Registration Procedure
An H.248 MG must register with SoftX3000 before providing services. Currently, the
supported protocol stack version is 1.0. If the protocol stack version implemented in the
opposite end is later or earlier than that, the MG responds with Error 406 Version Not
Supported, indicating a registration failure. The registration procedure is illustrated in
Figure 2-7.
MG
SoftX3000
SVC_CHG_REQ
SVC_CHG_REPLY
Figure 2-7 MG registration procedure
1)
Event 1: The H.248 MG sends a SVC_CHG_REQ message to SoftX3000 for

registration. The following is the text description of the SVC_CHG_REQ
command.
MEGACO/1 [191.169.150.172]:2944
T=3{
C= - {
SC=ROOT{
SV{
MT=RS,RE=902}}}}
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent
from the MG to the MGC. The IP address and port of the MG is
[191.169.150.172]:2944.
The 2nd line: The TransactionID is 3.
The 3rd line: Here the Context is null.
The 4th line: The ServiceChange command. The TerminationID is ROOT, indicating that
the command refers to the entire gateway.
The 5th line: The encapsulated ServiceChange descriptor in the ServiceChange
command.
The 6th line: The parameters contained in the ServiceChange descriptor, indicating the
ServiceChange method is Restart and the reason is Warm Boot.
2)
Event 2: On receipt of the registration message from the MG, the MGC sends a
reply to the MG. The following is the text description of the SVC_CHG_REPLY.
2-25

Chapter 2 H.248
MEGACO/1 [191.169.150.170]:2944
P=3{C= - {SC=ROOT{SV{}}}}
from the MGC to the MG. The IP address and port of the MGC is
[191.169.150.170]:2944.
The 2nd line: The TransactionID is 3, and the Context is null. The ServiceChange
command refers to the entire gateway, indicating that the MGC has received the
registration transaction from the MG and responds to the MG that the registration is
completed successfully.
2.3.2 Gateway Cancellation Procedure

To take out of service, an H.248 MG needs to cancel the registration to SoftX3000. The
cancellation procedure is illustrated in Figure 2-8.
MG
SoftX3000
SVC_CHG_REQ
SVC_CHG_REPLY
Figure 2-8 MG cancellation procedure
1)
Event 1: The MG sends a SVC_CHG_REQ command to SoftX3000 for

cancellation. The ServiceChangeMethod in the command is set to Graceful or
Forced. The following is the text description of the SVC_CHG_REQ command.
MEGACO/1 191.169.150.172]:2944
T= 9998 {C= - {
SC = ROOT {
SV {
MT= FO, RE = 905}}}}
[191.169.150.172]:2944.
The 2nd line: The TransactionID is 9998, and the encapsulated Context in the
Transaction is null.
The 3rd line: The ServiceChange command. The TerminationID is ROOT, indicating that
the command refers to the entire gateway.
The 4th line: The ServiceChange descriptor.
2-26

Chapter 2 H.248
The 5th line: The parameters contained in the ServiceChange descriptor, indicating that
the ServiceChange method is Forced and the reason is Termination taken out of
service.
2)
Event 2: SoftX3000 responds with a message. The following is the text description
of the SVC_CHG_REPLY.
MEGACO/1 [191.169.150.170]:2944
P=9998{C= - {SC=ROOT{ER=505}}}
[191.169.150.170]:2944.
The 2nd line: The TransactionID is 9998, and the Context is null. The ServiceChange
command refers to the entire gateway, with the Error 505 Command Received Before
Restart Response.
2.3.3 Gateway Initialization Procedure

After the MG completes a successful registration procedure, the MGC will modify the
properties of all semi-permanent Terminations of the MG contained in the null Context
and instruct the MG to detect off-hook events. At this time, the Termination can receive
or originate calls.
It is assumed that three semi-permanent Terminations including A0, A1 and A3 are
configured on the MG. The MGC will respectively send an MOD_REQ command to the
three Terminations for initialization purposes. Here we illustrate the specific message
interaction by using the Termination A0.
MG
SoftX3000
MOD_REQ
MOD_REPLY
Figure 2-9 MG Termination initialization procedure
1)
Event 1: After a successful registration, the MGC sends a modification command

to modify the properties of the Terminations of the MG in the null Context. The
following is the text description of the MOD_REQ command.
MEGACO/1 [191.169.150.170]:2944
T=372794419{C= - {
MF=A0{
E=369099777{al/*},
SG{}}}}
2-27

Chapter 2 H.248
[191.169.150.170]:2944.
The 2nd line: The TransactionID is 372794419, and a null Context is encapsulated in
the Transaction.
The 3rd line: The Modify command, to modify the properties of the Termination A0.
The 4th line: The Events descriptor with the RequestIdentifier 369099777. The MGC
requests the MG to detect all events including off-hook events in the Analog Line
Supervision Packages that will happen in the Termination A0.
The 5th line: The Signals descriptor. Here the signal is null, indicating the MGC requires
the MG to stop any signal played currently.
2)
Event 2: On receipt of the Modify command, the MG responds with a reply. The
following is the text description of the MOD_REPLY.
MEGACO/1 [191.169.150.172]:2944
P=372794419{
C= - {MF=A0}}
2.3.4 Successful Termination Call Procedure

A call setup and release procedure between two Terminations in the same MG is
illustrated in Figure 2-10. The call setup and release procedure between two
Terminations in different MGs is basically the same and thus not detailed in this chapter.
In the procedure, it is assumed that
z
The physical TerminationID of the Termination1 is A0, which is connected to the

UserA;
The physical TerminationID of the Termination2 is A1, which is connected to the

UserB;
The UserA makes a call to the UserB, and the calling party hooks on first;
The IP address and port of SoftX3000 is 191.169.200.61:2944;
The IP address and port of the MG is 191.169.150.122:2944.
2-28

UserA
Termination1
Off-hook
Chapter 2 H.248
SoftX3000
Termination2
UserB
1 NTFY_REQ
NTFY_REPLY
2 MOD_REQ
dial-tone
dialing
MOD_REPLY
3 NTFY_REQ
NTFY_REPLY
4 ADD_REQ
ADD_REPLY
5 ADD_REQ
ADD_REPLY
Ringback tone
6 MOD_REQ
7 MOD_REQ
MOD_REPLY
MOD_REPLY
8 NTFY_REQ
Ringing
Off-hook
NTFY_REPLY
9 MOD_REQ
MOD_REPLY
10 MOD_REQ
MOD_REPLY
Conversation
On-hook
11 NTFY_REQ
NTFY_REPLY
12 MOD_REQ
MOD_REPLY
13 SUB_REQ
SUB_REPLY
15 MOD_REQ
MOD_REPLY
14 MOD_REQ
MOD_REPLY
16 NTFY_REQ
Busy-tone
On-hook
NTFY_REPLY
17 SUB_REQ
SUB_REPLY
18 MOD_REQ
MOD_REPLY
Figure 2-10 H.248 call procedure between two Terminations in the same MG
1)
Event 1: Upon detecting that the UserA in the Termination A0 hooks off, the MG
sends an NTFY_REQ command to notify SoftX3000 of the off-hook event.
SoftX3000 acknowledges the receipt of the off-hook event in a reply message.
NTFY_REQ text description
MEGACO/1 [191.169.150.122]:2944
T=883{C= - {
N=A0{
OE=369109250{al/of}}}}
[191.169.150.122]:2944.
The 2nd line: The TransactionID is 883, and the encapsulated Context in the
Transaction is null.
The 3rd line: The Notify command, which refers to the Termination A0.
2-29

Chapter 2 H.248
The 4th line: The ObservedEvents descriptor. In this case, the TerminationA resident
MG detects the off-hook event and reports the event to SoftX3000. The
RequestIdentifier is 369109250, which is the same as the RequestIdentifier contained
in the request that triggers NTFY_REQ.
z
NTFY_REPLY text description
MEGACO/1 [191.169.200.61]:2944
P=883{C= - {
N=A0}}
2)
Event 2: On receipt of the off-hook event, SoftX3000 sends an MOD_REQ

command to instruct the MG to play the dial tone to the UserA at the Termination
A0 and request the MG to detect on-hook events. In addition, SoftX3000 notifies
the Termination A0 of the digit map (dmap1), based on which digits will be
collected. The Termination A0 sends an MOD_REPLY to SoftX3000 as the
response of the MOD_REQ and sends the dial tone to the UserA.
MOD_REQ text description
MEGACO/1 [191.169.200.61]:2944
T=372771555{
C= - {
MF=A0{
E=369109251{
dd/ce{DigitMap=dmap1}, al/*},
SG{cg/dt},
DM=dmap1{
([2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|x.F|[0-9EF].L)}}}}
For details of the parameters, refer to the command sample, earlier in this chapter.
z
MOD_REPLY text description
MEGACO/1 [191.169.150.122]:2944
P=372771555{
C= - {
MF=A0}}
For details of the parameters, refer to the response sample, earlier in this chapter.
3)
Event 3: The UserA dials a number. The Termination A0 collects the dialed digits
and tries to match the digit map. In the case of a successful match, the
Termination A0 sends an NTFY_REQ command to SoftX3000. SoftX3000
acknowledges the receipt of the NTFY_REQ, sent by the A0, with an
NTFY_REPLY.
MEGACO/1 [191.169.150.122]:2944
T=884{C= - {
N=A0{
OE=369109251{
2-30

Chapter 2 H.248
20030429T06132700:
dd/ce
{Meth=UM,ds=6540100}}}}}
The 1st line: The command is sent by the MG to the MGC. The IP address and port of
the MG is [191.169.150.122]:2944.
The 2nd line: The TransactionID is 884. In this case, the encapsulated Context in this
Transaction is null. SoftX3000 is designed to create a Context after the calling party
dials the called number, to avoid wasting resources in the event that the calling party
hooks off but does not dial a number or, even dials a number, the dialed number is
found inexistent or other reasons.
The 3rd line: The Notify command, which refers to the Termination A0.
The 4th line: The ObservedEvents descriptor. The RequestIdentifier is 369109251. It is
the same as the RequestIdentifier of the preceding MOD_REQ, indicating this
notification is triggered by that MOD_REQ command.
The 5th line: The TimeStamp for reporting the DigitMap event. 20030429T06132700
indicates 06:13:27 A.M. on April 29th 2003.
The 6th line: What is observed by the Termination A0 is a DigitMap Completion event in
the DTMF detection package. This event has two parameters: Termination Method
(Meth) and DigitString (ds).
The DigitMap Termination Method (Meth) has three possible values:
UM: Unambiguous match. If exactly one candidate alternative event sequence remains
and it has been fully matched, a completion event is generated indicating an
unambiguous match.
PM: Partial match. At each step, a timer is set to wait for the next event, based either on
the default timing rules given above or on explicit timing specified in one or more
alternative event sequences. If the timer expires and part or none of any candidate
alternative event sequence is satisfied, a timeout completion with partial match is
reported.
FM: Full match. If the timer expires and a member of the candidate set of alternative
event sequences is fully satisfied, a timeout completion with full match is reported.
The DigitString (ds), in this case, indicates what the UserA dials is 6540100.
z
MEGACO/1 [191.169.200.61]:2944
P=884{C= - {
N=A0}}
4)
Event 4: The MGC creates a new Context in the MG and adds a TDM Termination
and a RTP Termination in the Context. The MG responds with an ADD_REPLY
with a new allocated connection descriptor and a new RTP termination descriptor.
ADD_REQ text description
2-31

Chapter 2 H.248
MEGACO/1 [191.169.200.61]:2944
T=369363687{
C=${
A=A0{
M{O{MO=SR,RV=OFF,RG=OFF}},
E=369109253{al/*},
SG{}},
A=${
M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},
L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8}}}}}
The 1st line: The command is sent by the MGC to the MG. The IP address and port of
the MGC is [191.169.200.61]:2944.
The 2nd line: The TransactionID is 369363687.
The 3rd line: $ indicates that the MG is requested to create a new Context. $ is used
because the Context is not determined currently.
The 4th line: The ADD command, used to add the Termination A0 to the new Context.
The 5th line: The Media descriptor. The LocalControl (O) descriptor, in this case,
indicates that the Termination A0 has a send/receive mode property, OFF
ReserveGroup property, and OFF ReserveValue property.
The 7th line: The Events descriptor. The RequestIdentifier is 369109253. The MGC
requests the MG to detect all events in the Analog Line Supervision Packages that will
happen, such as on-hook events.
The 8th line: The ADD command, used to add a RTP Termination to the new Context.
The new RTP Termination is ephemeral. Because the descriptor for the RTP
Termination is not determined yet, $ is used.
The 9th line: The Media descriptor. The LocalControl (O) descriptor, in this case,
indicates that the RTP Termination has an inactive mode property, OFF
ReserveGroup property, and OFF ReserveValue property. nt/jit=40 indicates that the
maximum jitter buffer in the Network Packages is 40 milliseconds.
The 10th line: The MGC suggests a set of Local descriptor parameters for the new RTP
Termination. v=0 indicates that the SDP protocol version is 0. c=IN IP4 $ indicates
the Context information of the RTP Termination, that is, the network indicator of the
Context is Internet, the type of address for the Context is IP4, and the local IP address
is unknown currently. m=audio $ RTP/AVP 8 indicates the media description of the
new RTP Termination suggested by the MGC. audio indicates that the type of media
for the RTP Termination is audio. $ indicates that the media port number for the RTP
Termination is unknown currently. RTP/AVP is the transport layer protocol. Its value is
associated with the type of address in the c line. For IP4, a great number of media
2-32

Chapter 2 H.248
service streams are transferred over RTP/UDP. There are two classes of protocols
defined: RTP/AVP (audio/video application document, transported over UDP) and Udp
(the UDP protocol). For audio and video signals, 8 represents the type of media
payload defined in the RTP audio/video application document. It indicates that the
MGC suggests G.711A as the media encoding format for the RTP Termination.
The mapping relationship from RTP payload type to encoding defined in the H.248
protocol is as follows:
G.711U = 0; G.726 = 2; G.723, G.7231 = 4; G.711A = 8; G.729, G.729A = 18
z
ADD_REPLY text description
MEGACO/1 [191.169.150.122]:2944
P=369363687{C=286{
A=A0,A=A100000034{
L{v=0 c=IN IP4 191.169.150.122 m=audio 18300 RTP/AVP 8}}}}}
The 1st line: The command is sent by the MG to the MGC. The IP address and port of
the MG is [191.169.150.122]:2944.
The 2nd line: The TransactionID is 369363687. C=286 indicates that the requested
Context is created and the MG assigns an identifier 286 to identify the created
Context.
The 3rd line: It is confirmed that the physical Termination A0 and the ephemeral
Termination A100000034 have been added in the Context 286.
The 4th line: The Media descriptor.
The 5th line: Requested by the MGC, the MG confirms G.711A as the media encoding
format for the Termination A100000034, sets its RTP port number to be 18300, and fills
the local IP address to be 191.169.150.122.
5)
Event 5: The MGC conducts the analysis of the called number and determines the
called UserB is connected to the physical Termination A1 in the MG. Therefore,
the MGC sends an ADD_REQ, requesting the MG to add the physical Termination
A1 and a certain RTP Termination to a new Context. The MG responds with an
ADD_REPLY with a new allocated connection descriptor 287 and a new RTP
termination descriptor A100000035. Requested by the MGC, the MG determines
G.711A as the codec type for the Termination A100000035 of the MG, sets its
RTP port number to be 18296, fills the local IP address to be 191.169.150.122,
and sets the Termination A100000035 to be in the inactive mode.
MEGACO/1 [191.169.200.61]:2944
T=369363688{
C=${
A=A1{
M{O{MO=SR,RV=OFF,RG=OFF}},
2-33

Chapter 2 H.248
E=369108998{al/*},
SG{}},
A=${
M={O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},
For details of the parameters, refer to Event 4, earlier in this section.

z
MEGACO/1 [191.169.150.122]:2944
P=369363688{C=287{
A=A1,A=A100000035{

6)
Event 6: The MGC sends an MOD_REQ command to the Termination A1, to

modify the properties of the Termination A1 and request the MG to play the ringing
tone to the UserB. The MG acknowledges with an MOD_REPLY, and meanwhile
the MG plays the ringing tone to the UserB.
MEGACO/1 [191.169.200.61]:2944
T=372771561{C=287{
MF=A1{
E=369108999{al/*},
SG{al/ri}}}}
z
MEGACO/1 [191.169.150.122]:2944
P=372771561{C=287{MF=A1}}
7)
Event 7: The MGC sends an MOD_REQ command to the Termination A0, to

modify the properties of the Termination A0 and request the MG to play the
ringback tone to the UserA. The MG acknowledges with an MOD_REPLY, and
meanwhile the MG plays the ringback tone to the UserA.
MEGACO/1 [191.169.200.61]:2944
T=372771562{C=286{
MF=A0{
E=369109256{al/*},
SG{cg/rt}}}}
z
MEGACO/1 [191.169.150.122]:2944
P=372771562{C=286{MF=A0}}
2-34

8)
Chapter 2 H.248
Event 8: The called UserB hooks off. The MG notifies the MGC of the off-hook
event with an NTFY_REQ command. The MGC acknowledges with an
NTFY_REPLY.
MEGACO/1 [191.169.150.122]:2944
T=885{C=287{
N=A1{
OE=369108999{al/of}}}}
z
MEGACO/1 [191.169.200.61]:2944
P=885{C=287{N=A1}}
9)
Event 9: Through an MOD_REQ command, the MGC sends the connection

description of the RTP Termination A100000034 associated with the Termination
A0 to the RTP Termination A100000035 associated with the Termination A1, and
modifies the mode property of the RTP Termination A100000035 to be
send/receive. The MG acknowledges with an MOD_REPLY.
MEGACO/1 [191.169.200.61]:2944
T=370281195{C=287{
MF=A1{M{O{MO=SR,RV=OFF,RG=OFF,tdmc/ec=ON}},
E=369109001{al/*},
SG{}},
MF=A100000035{M{O{MO=SR,RV=OFF,RG=OFF},
L{v=0 c=IN IP4 - m=audio - RTP/AVP 8},
R{v=0 c=IN IP4 191.169.150.122 m=audio 18300 RTP/AVP 8}}}}}
the MGC is [191.169.200.61]:2944.
The 2nd line: The TransactionID is 370281195, and the ContextID is 287, that is, the
Context created for the MGC and the Termination2.
The 3rd line: The Modify command, to modify the properties of the Termination A1. M
represents the Media descriptor. O represents the LocalControl descriptor. MO=SR
indicates that the MGC modifies the mode property of the Termination A1 to be
send/receive. RV=OFF,RG=OFF indicates that both the ReserveGroup property and
the ReserveValue property are set to OFF. tdmc/ec=ON indicates that the MGC
suggests ON to be the echo canceler in the TDM Circuit Packages.
The 4th line: The MGC requests the MG to detect events that will happen in the
Termination A1, such as on-hook events.
The 6th line: The Modify command, to modify the properties of the RTP Termination
A100000035. M represents the Media descriptor. O represents the LocalControl
2-35

Chapter 2 H.248
descriptor. MO=SR indicates that the MGC modifies the mode property of the RTP
Termination A100000035 to be send/receive. RV=OFF,RG=OFF indicates that both
the ReserveGroup property and the ReserveValue property are set to OFF.
The 7th line: The Local descriptor, carrying the connection description of the local RTP
(associated with the Termination A1) Termination A100000035.
The 8th line: The Remote descriptor, carrying the connection description of the remote
RTP (associated with the Termination A0) Termination A100000034.
z
MEGACO/1 [191.165.15.122]:2944
P=370281195{C=287{
MF=A1,MF=A100000035{
M{L{v=0 c=IN IP4 191.169.150.122 m=audio 18296 RTP/AVP 8}}}}}
10) Event 10: Through an MOD_REQ command, the MGC sends the connection
A1 to the RTP Termination A100000034 associated with the Termination A0, and
modifies the mode property of the RTP Termination A100000034 to be
send/receive. The MG acknowledges with an MOD_REPLY.
At this time, the Terminations A0 and A1 know the connection information of the local
end and the opposite end. The conversation conditions are satisfied, and a
conversation can start.
z
MEGACO/1 [191.169.200.61]:2944
T=370281196{C=286{
E=369109258{al/*},
SG{}},
L{v=0 c=IN IP4 - m=audio - RTP/AVP 8},

z
MEGACO/1 [191.165.15.122]:2944
P=370281196{C=286{
MF=A0,MF=A100000034{
M{L{v=0 c=IN IP4 191.169.150.122 m=audio 18300 RTP/AVP 8}}}}}
11) Event 11: The calling party UserA hooks on. The MG sends an NTFY_REQ
command to notify the MGC. The MGC sends an NTFY_REPLY to acknowledge
the receipt of the Notify command.
z
MEGACO/1 [191.169.150.122]:2944
T=886{C=286{
2-36

Chapter 2 H.248
N=A0{OE=369109258{al/on}}}}
z
MEGACO/1 [191.169.200.61]:2944
P=886{N=A0}}
12) Event 12: On receipt of the on-hook event of the UserA, the MGC sends an
MOD_REQ command to the MG to modify the properties of the Termination A0.
The MGC also requests the MG to detect events that will happen in the
Termination A0, such as off-hook events, and modify the mode property of the
RTP Termination A100000034 to be inactive. The MG sends an MOD_REPLY to
acknowledge the receipt of the MOD_REQ and indicate the execution of the
command.
z
MEGACO/1 [191.169.200.61]:2944
T=370281199{C=286{
MF=A0{E=369109259{al/*},SG{}},
MF=A100000034{M{O{MO=IN,RV=OFF,RG=OFF}}}}}
z
MEGACO/1 [191.169.150.122]:2944
P=370281199{C=286{MF=A0,MF=A100000034}}
13) Event 13: On receipt of the on-hook event of the UserA, the MGC sends an
SUB_REQ command to the MG to subtract all semi-permanent Terminations and
ephemeral RTP Terminations from the Context 286 and thus to delete the Context
and disconnect the call. The MG sends an SUB_REPLY to acknowledge the
receipt of the SUB_REQ command.
z
SUB_REQ text description
MEGACO/1 [191.169.200.61]:2944
T=372509424{C=286{O-S=*}}
the MGC is [191.169.200.61]:2944.
The 2nd line: The TransactionID is 372509424, and the ContextID is 286. In O-S=*,
O represents Optional, S represents Subtract, and * represents All. Therefore,
O-S=* indicates to subtract all Terminations from the Context 286.
z
SUB_REPLY text description
MEGACO/1 [191.169.150.122]:2944
P=372509424{C=286{
S=A0,S=A100000034}}
14) Event 14: The MGC sends an MOD_REQ command to the MG to modify the
properties of the Termination A1. The MGC also requests the MG to detect events
that will happen in the Termination A1, such as on-hook events, and requests the
MG to send the busy tone to the Termination A1. The MG sends an MOD_REPLY
to acknowledge the receipt of the MOD_REQ, and meanwhile sends the busy tone
to the UserB.
2-37

z
Chapter 2 H.248
MEGACO/1 [191.169.200.61]:2944
T=372771569{C=287{
MF=A1{E=369109004{al/*},SG{cg/bt}}}}
z
MEGACO/1 [191.169.150.122]:2944
P=372771569{C=287{MF=A1}}
15) Event 15: After the call and the Context between the Termination A0, the RTP
Termination and the MGC are cleared, the MGC sends an MOD_REQ command
to the MG, requesting the MG to detect events that will happen in the Termination
A0, such as off-hook events. The MG sends an MOD_REPLY to acknowledge the
receipt of the MOD_REQ command. At this time, the Context is null.
z
MEGACO/1 [191.169.200.61]:2944
T=372771570{C= - {
MF=A0{E=369109261{al/*},SG{}}}}
z
MEGACO/1 [191.169.150.122]:2944
P=372771570{C= - {MF=A0}}
16) Event 16: The called party UserB hooks on. The MG sends an NTFY_REQ
command to notify the MGC. The MGC sends an NTFY_REPLY to acknowledge
the receipt of the Notify command.
z
MEGACO/1 [191.169.150.122]:2944
T=887{C=287{
N=A1{OE=369109004{al/on}}}}
The RequestIdentifier is 369109004, which is the same as the RequestIdentifier in the

MOD_REQ command described in the event 14. It indicates that the NTFY_REQ is
triggered by the MOD_REQ command in the event 14.
z
MEGACO/1 [191.169.200.61]:2944
P=887{C=287{N=A1}}
17) Event 17: On receipt of the on-hook event of the UserB, the MGC sends an
SUB_REQ command to the MG to subtract all semi-permanent Terminations and
ephemeral RTP Terminations from the Context 287 and thus to delete the Context
and disconnect the call. The MG sends an SUB_REPLY to acknowledge the
receipt of the SUB_REQ command.
z
MEGACO/1 [191.169.200.61]:2944
T=372509427{C=287{O-S=*}}
z
MEGACO/1 [191.169.150.122]:2944
2-38

Chapter 2 H.248
P=372509427{C=287{
S=A1,S=A100000035}}
18) Event 18: After the call and the Context between the Termination A1, the RTP
Termination and the MGC are cleared, the MGC sends an MOD_REQ command
to the MG, requesting the MG to detect events that will happen in the Termination
A1, such as off-hook events. The MG sends an MOD_REPLY to acknowledge the
receipt of the MOD_REQ command. At this time, the Context is null.
z
MEGACO/1 [191.169.200.61]:2944
T=372771572{C= - {
MF=A1{E=369109006{al/*},SG{}}}}
z
MEGACO/1 [191.169.150.122]:2944
P=372771572{C= - {MF=A1}}
2.3.5 Successful Trunk Call Procedure

The following example illustrates a call procedure under the control of SoftX3000,
where a PSTN user under a TMG makes a call through SoftX3000 to a user under an
AMG5000. The networking diagram is shown in Figure 2-11.
SoftX3000
H.248
Core
Networ k
MTP3+M2UA+Trunk+H.248
Voice
AMG5000
PSTN
TMG8010+SG
Figure 2-11 Networking diagram for a successful trunk call example
The call procedure is illustrated in Figure 2-12. In the procedure, it is assumed that
z
The IP address of SoftX3000 is 191.169.150.170;
The IP address of the TMG is 191.169.150.10;
The IP address of the AMG is 191.169.150.172;
The PSTN user is the calling party, and the associated PSTN switch is connected
to SoftX3000 through a TMG;
The AMG user is the called party, and the called party hooks on first.
2-39

SG
TG
Chapter 2 H.248
SoftX3000
AMG
UserB
IAM
1 ADD_REQ
2 ADD_REQ
ADD_REPLY
4 MOD_REQ
ACM
MOD_REPLY
ADD_REPLY
3 MOD_REQ
MOD_REPLY
Ringing
5 NTFY_REQ
Off-hook
NTFY_REPLY
6 MOD_REQ
MOD_REPLY
7 MOD_REQ
MOD_REPLY
ANM
8 NTFY_REQ
NTFY_REPLY
9 MOD_REQ
MOD_REPLY
10 SUB_REQ
SUB_REPLY
REL
RLC
On-hook
11 SUB_REQ
SUB_REPLY
Figure 2-12 Successful trunk call procedure
1)
Event 1: The PSTN user hooks off and dials the called number. An Initial Address
Message (IAM) is sent to the MGC through the Signaling Gateway (SG) built in the
TMG.
On receipt of the IAM, the MGC sends an ADD_REQ, requesting the TMG to add the
physical Termination A29 and a certain RTP Termination to a new Context. The TMG
responds with an ADD_REPLY with a new allocated connection descriptor 15 and a
new RTP termination descriptor A2147489806. Requested by the MGC, the TMG
determines G.723 as the codec type for the Termination A2147489806 of the TMG, sets
its RTP port number to be 13388, fills the local IP address to be 191.169.150.10, and
sets the Termination A2147489806 to be in the send/receive mode.
z
MEGACO/1 [191.169.150.170]:2944
T=369379680{C=${A=A29{M{O{MO=SR,RV=OFF,tdmc/ec=ON}}},
A=${M{O{MO=SR,RV=OFF,RG=OFF,nt/jit=40},
z
MEGACO/1 [191.169.150.010]:2944
P=369379680{C=15{A=A29,
A=A2147489806{M{ST=1{
L{v=0 c=IN IP4 191.169.150.10 m=audio 13388 RTP/AVP 4}}}}}}
2-40

2)
Chapter 2 H.248
Event 2: The MGC conducts the analysis of the called number and determines the
called UserB is connected to the physical Termination A0 in the AMG. Therefore,
the MGC sends an ADD_REQ, requesting the AMG to add the physical
Termination A0 and a certain RTP Termination to a new Context. The AMG
responds with an ADD_REPLY with a new allocated connection descriptor 218
and a new RTP termination descriptor A100000379. Requested by the MGC, the
AMG determines G.723 as the codec type for the Termination A100000379 of the
AMG, sets its RTP port number to be 18300, fills the local IP address to be
191.169.150.172, and sets the Termination A100000379 to be in the inactive
mode.
MEGACO/1 [191.169.150.170]:2944
T=369379681{C=${
A=A0{M{O{MO=SR,RV=OFF,RG=OFF}},E=369099789{al/*},SG{}},
A=${M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},
z
MEGACO/1 [191.169.150.172]:2944
P=369379681{C=218{A=A0,
A=A100000379{M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},
3)
Event 3: The MGC sends an MOD_REQ to the AMG to modify the properties of
the Termination A0. The MGC also requests the AMG to detect events that will
happen in the Termination A0, such as off-hook events, and plays the ringing tone
to the UserB. The AMG acknowledges with an MOD_REPLY, and meanwhile the
AMG plays the ringing tone to the UserB.
MEGACO/1 [191.169.150.170]:2944
T=372787554{C=218{
MF=A0{E=369099790{al/*},SG{al/ri}}}}
z
MEGACO/1 [191.169.150.172]:2944
P=372787554{C=218{MF=A0}}
4)
Event 4: The MGC sends an MOD_REQ command to the TMG, requesting the
TMG to play the ringback tone to the PSTN user. The TMG acknowledges with an
MOD_REPLY.
Subsequently, SoftX3000 sends an Address Complete Message (ACM) to the SG. On

receipt of the message, the SG transfers it to the PSTN switch through the M2UA
protocol and requests the switch to send the ringback tone to the PSTN user.
z
MEGACO/1 [191.169.150.170]:2944
T=371870051{C=15
2-41

Chapter 2 H.248
{MF=A29{SG{SL=0{cg/rt{NC={TO,OR}}}}}}}
z
MEGACO/1 [191.169.150.010]:2944
P=371870051{C=15{MF=A29}}
5)
Event 5: The UserB hooks off. The AMG sends an NTFY_REQ command to notify
the MGC. The MGC sends an NTFY_REPLY to acknowledge the receipt of the
Notify command.
MEGACO/1 [191.169.150.172]:2944
T=2470{C=218{
N=A0{OE=369099790{al/of}}}}
z
MEGACO/1 [191.169.150.170]:2944
P=2470{C=218{N=A0}}
6)

A29 of the TMG to the RTP Termination A100000379 associated with the
Termination A0 of the AMG, and modifies the mode property of the RTP
Termination A100000379 to be send/receive. The AMG acknowledges with an
MOD_REPLY.
MEGACO/1 [191.169.150.170]:2944
T=370297190{C=218{
E=369099791{al/*},SG{}},
L{v=0 c=IN IP4 m=audio RTP/AVP 4},
z
MEGACO/1 [191.169.150.172]:2944
P=370297190{C=218{
MF=A0,
MF=A100000379{M{L{v=0 c=IN IP4 191.169.150.172 m=audio 18300 RTP/AVP 4 }}}}}
7)

A0 of the AMG to the RTP Termination A2147489806 associated with the
Termination A29 of the TMG. The TMG acknowledges with an MOD_REPLY.
At this time, the Termination A29 of the TMG and the Termination A0 of the AMG know
the connection information of the local end and the opposite end. Subsequently,
SoftX3000 sends an Answer Message (ANM) to the SG. On receipt of the message, the
SG transfers it to the PSTN switch through the M2UA protocol and requests the switch
to stop sending the ringback tone to the PSTN user and set up a conversation.
2-42

z
Chapter 2 H.248
MEGACO/1 [191.169.150.170]:2944
T=370297192{C=15{
MF=A29{M{O{MO=SR,RV=OFF,RG=OFF}}},
MF=A2147489806{M{L{ v=0 c=IN IP4 m=audio RTP/AVP 4},
R{ v=0 c=IN IP4 191.169.150.172 m=audio 18300 RTP/AVP 4}
z
MEGACO/1 [191.169.150.010]:2944
P=370297192{C=15{MF=A29,MF= A2147489806}}
8)
Event 8: The called UserB hooks on. The AMG sends an NTFY_REQ command to
notify the MGC. The MGC sends an NTFY_REPLY to acknowledge the receipt of
the Notify command.
MEGACO/1 [191.169.150.172]:2944
T=2471{C=218{
N=A0{OE=369099791{al/on}}}}
z
MEGACO/1 [191.169.150.170]:2944
P=2471{C=218{N=A0}}
9)
Event 9: On receipt of the on-hook event of the UserB, the MGC sends an
MOD_REQ command to the AMG to modify the properties of the Termination A0.
The MGC also requests the gateway to detect events that will happen in the
Termination A0, such as off-hook events, and modify the mode property of the
RTP Termination A100000379 to be inactive. The MG sends an MOD_REPLY to
acknowledge the receipt of the MOD_REQ and indicate the execution of the
command.
MEGACO/1 [191.169.150.170]:2944
T=370297199{C=218{
MF=A0{E=369099776{al/*},SG{}},
MF=A100000379{M{O{MO=IN,RV=OFF,RG=OFF}}}}}
z
MEGACO/1 [191.169.150.172]:2944
P=370297199{C=218{MF=A0,MF= A100000379}}
10) Event 10: On receipt of the on-hook event of the UserB, the MGC sends an
SUB_REQ command to the AMG to subtract all semi-permanent Terminations
and ephemeral RTP Terminations from the Context 218 and thus to delete the
Context and disconnect the call. The MG sends an SUB_REPLY to acknowledge
the receipt of the SUB_REQ command.
z
MEGACO/1 [191.169.150.170]:2944
T=372525424{C=218{O-S=*}}
2-43

z
Chapter 2 H.248
MEGACO/1 [191.169.150.172]:2944
P=372525424{C=218{
S=A0,S= A100000379}}
11) Event 11: On receipt of the SUB_REQ command from the AMG, the MGC sends a
Release (REL) message to the SG. On receipt of the message, the SG transfers it
to the PSTN switch through the M2UA protocol and requests the switch to send
the busy tone to the PSTN user and release the voice circuit.
On receipt of the REL message, the PSTN switch acknowledges with a Release
Completed (RLC) message which triggers the release of the voice circuit. On receipt of
the RLC message, the SG transfers it to the MGC through the M2UA protocol.
On receipt of the RLC message, the MGC sends an SUB_REQ command to the TMG
to subtract all semi-permanent Terminations and ephemeral RTP Terminations from the
Context 15 and thus to delete the Context and disconnect the call. The TMG sends an
SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
z
MEGACO/1 [191.169.150.170]:2944
T=372525425{C=15{O-S=A29, O-S=A2147489806}}
z
MEGACO/1 [191.169.150.010]:2944
P=372525425{C=15{
S=A29,S=A2147489806}}
2-44

Chapter 3 SIP
Chapter 3 SIP
3.1 Overview
Put forward and studied by the IETF, the Session Initiation Protocol (SIP) is an
application-layer control protocol for multimedia communication over IP network, which
can be used for creating, modifying and terminating sessions with one or more
participants. These sessions include Internet multimedia conferences, Internet
telephone calls, distance learning, telemedicine, and similar applications. That is, all
interactive two-party or multiparty multimedia communication activities over the Internet
are multimedia sessions. Members in a session can communicate through multicast or
through a mesh of unicast relations, or a combination of these.
SIP is being developed and studied. On one hand, SIP learns from the design concepts
of other Internet standards and protocols and follows Internet principles such as
concision, openness, compatibility and expendability with security issues taken into
account. On the other hand, SIP fully considers the support for traditional PSTN
services including Intelligent Network (IN) services and Integrated Services Digital
Network (ISDN) services.
SIP invitations used to create sessions carry session descriptions which allow
participants to agree on a set of compatible media types. SIP supports user mobility by
proxying and redirecting requests to the users current location. Users can register their
current location. SIP is not tied to any particular conference control protocol. SIP is
designed to be independent of the underlying transport protocol and can be extended
with additional capabilities.
Being an application-layer multimedia session signaling protocol, SIP can be used to
initiate sessions as well as invite members to sessions that have been advertised and
established by other means. Sessions can be advertised using multicast protocols
such as Session Announcement Protocol (SAP), electronic mail, web pages or
Lightweight Directory Access Protocol (LDAP), among others. SIP transparently
supports name mapping and redirection services, allowing the implementation of ISDN
and IN telephony subscriber services. These facilities also enable personal mobility,
that is, the ability of end users to request and access subscribed telecommunication
services on any terminal in any location at any time. SIP supports five facets of
establishing and terminating multimedia communications:
3-1

Chapter 3 SIP
User location: determination of the end system to be used for communication.
User capabilities: determination of the media and media parameters to be used.
User availability: determination of the willingness of the called party to engage in

communications.
Call setup: "ringing", establishment of call parameters at both called and calling
party.
Call handling and control: including redirection, transfer and termination of calls.
SIP can initiate multiparty sessions using a multipoint control unit (MCU), unicast mesh,
or multicast, supporting gateway functionality between PSTN and Internet calls.
SIP can be used in conjunction with other signaling systems or protocols for call setup.
The IETF has included extensibility and compatibility of SIP with other protocols. For
example, SIP could be used to determine that the party can be reached through H.323,
obtain the H.245 gateway and user address and then use H.225.0 to establish the call.
In another example, SIP might be used to determine that the callee is reachable
through the PSTN and indicate the phone number to be called, possibly suggesting an
Internet-to-PSTN gateway be used.
SIP does not offer conference control services such as floor control or voting and does
not prescribe how a conference is to be managed, but SIP can be used to introduce
conference control protocols. SIP does not reserve resources, but can convey to the
invited system the information necessary to do this.
3.1.2 Related Terms

I. Call
A call consists of all participants in a conference invited by a common source. A SIP call
is identified by a globally unique call-ID.
For example, all participants in a conference invited by the same source comprise one
call. A point-to-point Internet telephony conversation is a kind of simplest session and
maps into a single SIP call.
In normal cases, a call is established by the calling party. More generally, a call can be
established by a third party who does not participate in the media communication,
where the calling party of the session is not the same as the inviter of the session. For
multicast conferences, if a user is invited to the same multicast session by several
people, each of these invitations will be a unique call. In an MCU-based, call-in
conference, each participant uses a separate call to invite himself to the MCU.
3-2

Chapter 3 SIP
II. Transaction
SIP is a client/server protocol. A SIP transaction occurs between a client and a server
and comprises all messages from the first request sent from the client to the server up
to a final (non-1xx) response sent from the server to the client.
A normal call consists of three transactions. Call initiation consists of two operation
requests, namely INVITE and ACK. The former requires a response. The latter is only
an acknowledgement that the final response is received; it does not require a response.
Call termination consists of one operation request, namely BYE.
III. SIP URL

To transfer protocol messages correctly, there are two significant problems in SIP to be
solved. The first problem is addressing, that is, the form of address used to identify end
users. The second problem is user location, which will be described later. SIP utilizes
the WWW technology to solve those problems.
SIP Uniform Resource Locators (URLs) are used for addressing purposes. SIP URL
syntax is defined according to the Uniform Resource Identifier (URI) guidelines
specified in the RFC 2396. Especially, the user field could be a telephone number to
support addressing of IP telephony gateway and achieve the interworking between IP
calls and the PSTN.
A SIP URL has the syntax:
SIP: Username:password@host:port; transport parameter; user parameter; method
parameter; time-to-live; server address parameter? header name=header value
SIP indicates that the SIP is used for the communication to the specified end system.
Username is composed of any characters in a form of e-mail address or telephone
number. (SoftX3000 adopts telephone number as the username.)
Host is either a domain name or an IPv4 address.
Port refers to the port number to which request message is sent. The default port is
5060, the public SIP port number.
Password can be included in a SIP URL, which is not recommended for the sake of
security.
Transport parameter indicates the used transport protocol, TCP or UDP. The default
transport parameter is UDP.
For user parameter, a function of SIP URL is to allow the host to be an IP telephony
gateway with a telephone number as the username. Because BNF syntax cannot
distinguish telephone number from general username, user parameter is added to
3-3

Chapter 3 SIP
follow the domain name. Two values are available for this field: IP and phone. When the
field is set to phone, the username is a telephone number and the corresponding end
system is an IP telephony gateway.
Method parameter refers to the method (operation) to be used.
Time-to-live (TTL) indicates the life of UDP multicast data packets. This parameter is
valid only when the transport parameter is set to UDP and the server address
parameter is set to multicast address.
Server address parameter indicates the address of the server communicating with
the user. It, usually the multicast address, overwrites the address in the host field.
Transport parameter, time-to-live, server address parameter, and method
parameter are URL parameters used only in a redirect address, that is the Contact field
which will be mentioned later.
The following are some SIP URL examples.
Sip; 55500200@191.169.1.112;
55500200 is a username. 191.169.1.112 is the IP address of an IP telephony

gateway.
Sip; 55500200@127.0.0.1:5061; User=phone;
55500200 is a username. 127.0.0.1 is the IP address of a host. 5061 is a port

number of the host. The user parameter is phone, indicating the username is a
telephone number.
Sip: alice@registrar.com; method=REGISTER;
Alice is a username. registrar.com is the domain name of a host. Register is a

method to be used.
IV. User location

User location is based on registration. After a SIP user terminal is powered on, it starts
to register to a registrar (SoftX3000). For that specific purpose, REGISTER request and
registration procedure are defined in SIP.
V. Location service
A location service is used by a SIP redirect or proxy server to obtain information about a
callees possible location(s). Location services are offered by location servers. Location
servers may be co-located with a SIP server, but the manner in which a SIP server
requests location services is beyond the scope of this document. In the U-SYS Solution
proposed by Huawei, SoftX3000 acts as a location server.
3-4

Chapter 3 SIP
VI. Proxy, Proxy server

A proxy, or proxy server, is a logical network entity that acts as both a server and a client
for the purpose of forwarding requests or responses on behalf of other clients. A proxy
server may be in one of the states: Stateless, Stateful and Call Stateful. A proxy server
attempts to forward requests to multiple addresses with a branch or cycle method.
A proxy server implements the functions of routing, authentication, charging monitoring,
call control and service provision. In the U-SYS Solution proposed by Huawei,
SoftX3000 also acts as a proxy server.
VII. Redirect server

A redirect server is a server that accepts a SIP request, maps the address into zero or
more new addresses, and returns these addresses to the client, so that the client can
directly initiate requests to these new addresses again. A redirect server implements
the routing function rather than receive or reject calls. The redirect server, in
coordination with a registration process, can support personal mobility. In the U-SYS
Solution proposed by Huawei, SoftX3000 also acts as a redirect server.
VIII. Registrar
A register is a server that accepts REGISTER requests. A registrar is typically
combined with a proxy or redirect server into a single application. A registrar needs to
store the address mapping relationship in REGISTER requests in a database for
subsequent call processes. A registrar may offer location services. In the U-SYS
Solution proposed by Huawei, SoftX3000 also acts as a registrar.
IX. User agent

A logical entity that can initiates or receive SIP requests.
X. User agent client

A user agent client (UAC) is a client application that initiates the SIP request. An
example of UAC is SIP phone.
XI. User agent server

A user agent server (UAS) is a server application that receives the SIP request. An
example of UAS is SoftX3000.
Note: The distinguishing of UAC and UAS is based on one transaction.
3-5

Chapter 3 SIP

The structure of SIP protocol stack is shown in Figure 3-1.
H.323
SIP
RTCP
RSVP
RTSP
H.263 etc.
RTP
TCP
UDP
IP
PPP
AAL3/4
Sonet
AAL5
ATM
PPP
Ethernet
V.34
Figure 3-1 SIP protocol stack

SIP is designed as part of the overall IETF multimedia data and control architecture
currently incorporating protocols such as the resource reservation protocol (RSVP) for
reserving network resources, the real-time transport protocol (RTP) for transporting
real-time data and providing quality of service (QoS) feedback, the real-time streaming
protocol (RTSP) for controlling delivery of streaming media, the session announcement
protocol (SAP) for advertising multimedia sessions through multicast and the session
description protocol (SDP) for describing multimedia sessions. However, the
functionality and operation of SIP does not depend on any of these protocols.
Transport-layer support: SIP lies in the layer above the IP layer. The network layer
protocol is IP and the transport layer protocol is TCP or UDP. UDP is preferred.

Through SIP or Session Initiation Protocol for Telephones (SIP-T), SoftX3000
interworks with other SoftSwitch systems and other SIP domain equipment such as SIP
phone and UniPhone. The implementation of SIP in SoftX3000 is illustrated in Figure
3-2.
3-6

Chapter 3 SIP
SoftX3000
SoftX3000
SIP/SIP-T
IP
SIP
IP
SIP
IP Core
Sof tPhone
Sof tPhone
Figure 3-2 Implementation of SIP in SoftX3000

3.2.1 Message Types
SIP messages are encoded in a text form. There are two types of messages: request
messages and response messages.
I. Request messages
Request messages are SIP messages sent from a client to a server, for the purpose of
invoking a particular operation. They are INVITE, ACK, OPTIONS, BYE, CANCEL and
REGISTER messages. The functions of these messages are listed in Table 3-1.
Table 3-1 Request messages
Request
message
INVITE
Function
The INVITE message indicates that the user is being invited to participate in a
session. The message body contains a description of the session to which the callee
is being invited. For two-party calls, the caller indicates the type of media it is able to
receive as well as their parameters. A success response must indicate in its
message body which media the callee wishes to receive and may indicate the media
the callee is going to send.
A server may automatically respond to an invitation for a conference the user is
already participating in, identified either by the SIP Call-ID or a globally unique
identifier within the session description, with a 200 (OK) response.
ACK
The ACK request confirms that the client has received a final response to an INVITE
request. ACK is used only with INVITE messages.
BYE
The user agent client uses BYE to indicate to the server that it wishes to release the
call.
3-7

Chapter 3 SIP
Request
message
Function
CANCEL
The CANCEL request cancels a pending request, but does not affect a completed
request. (A request is considered completed if the server has returned a final status
response.)
REGISTER
A client uses the REGISTER request to register an address with a SIP server.
OPTIONS
The OPTIONS request is used to query servers about their capabilities.
II. Response messages

Response messages are used to respond to request messages, indicating the success
or failure status of the call. The class of a response message is distinguished by a
Status-Code. The Status-Code is a 3-digit integer. The first digit of the Status-Code
defines the class of response. The last two digits indicate the response in detail. The
classification of response messages and their meanings are shown in Table 3-2.
Table 3-2 Response messages
Serial No.
1xx
2xx
3xx
4xx
Status-Code
Message functions
Informational
(provisional)
Request received, continuing to process the request.
100
Trying
180
Ringing
181
Call Is Being Forwarded
182
Queued
Success
The action was successfully received, understood, and accepted.
200
OK
Redirection
Further action needs to be taken in order to complete the request.
300
Multiple Choices
301
Moved Permanently
302
Moved Temporarily
303
See Other
305
User Proxy
380
Alternative Service
Client error
The request contains bad syntax or cannot be fulfilled at this

server.
400
Bad Request
3-8

Serial No.
5xx
Chapter 3 SIP
Status-Code
Message functions
401
Unauthorized
402
Payment Required
403
Forbidden
404
Not Found
405
Method Not Allowed
406
Not Acceptable
407
Proxy Authentication Required
408
Request Timeout
410
Gone
413
Request Entity Too Large
414
Request-URI Too Large
415
Unsupported Media Type
416
Unsupported URI Scheme
420
Bad Extension
421
Extension Required
423
Interval Too Brief
480
Temporarily Unavailable
481
Call Leg/Transaction Does Not Exist
482
Loop Detected
483
Too Many Hops
484
Address Incomplete
485
Ambiguous
486
Busy Here
487
Request Terminated
488
Not Acceptable Here
491
Request Pending
493
Undecipherable
Server error
The server failed to fulfill an apparently valid request.
500
Server Internal Error
501
Not Implemented
3-9

Serial No.
6xx
Chapter 3 SIP
Status-Code
Message functions
502
Bad Gateway
503
Service Unavailable
504
Server Time-out
505
Version Not Supported
513
Message Too Large
Global failure
The request cannot be fulfilled at any server.
600
Busy Everywhere
603
Decline
604
Does Not Exist Anywhere
606
Not Acceptable
Both the request and the response messages contain SIP header fields and SIP
message fields.
SDP message fields are added into SIP messages.

I. Request messages
1)
Request format
Figure 3-3 illustrates the format for a SIP request that consists of a start line, a message
header, and a message body. A line feed character distinguishes each parameter line in
the message header. Some parameters are optional for different request messages.
3-10

Command name
Chapter 3 SIP
Peer UPI
Protocol version
Start line
Call-ID: Field value

Form: Field value
To: Field value
CSeq: Field value
Via: Field value
Contact: Field value
Max-Forwards: Field value
Message hea
Allow: Field value

Content-Length: Field value
Supported: Field value
Figure 3-3 Structure of a SIP request message
2)
Request message parameters
The following section describes some frequently used parameter fields.

z
Call-ID
The Call-ID header field uniquely identifies a particular invitation or all registrations of a
particular client.
A single multimedia conference can give rise to several calls with different Call-IDs, for
example, if a user invites a single individual several times to the same (long-running)
conference. A user might also receive several INVITEs to the same conference or call
with different Call-IDs. The user judges the repetition of the INVITEs by identifications
in the session description, for example, session identifier and version number carried in
the o (source) field in the SDP.
Call-IDs have a generic format:
Call-ID: localID@host
3-11

Chapter 3 SIP
in which, host is a domain name defined globally or an IP address routable globally.

The local ID is composed of unique URI characters in the scope of host". Otherwise,
the local ID must be a globally unique value to ensure the global uniqueness of Call-ID.
Call-IDs are case-sensitive.
Call-ID example:
Call-Id: call-973636852-4@191.169.150.101
191.169.150.101 is the IP address of a host. call-973636852-4 is a globally unique

local ID.
z
Form
All requests and responses must contain the From header field that indicates the
initiator of the request. The server duplicates this field from the request message to
response messages.
This field has a generic format:
From:Display-name<SIP-URL>;tag=xxxx
The display-name is meant to be rendered by a human user interface. A system

should use the display name Anonymous if the identity of the client is to remain
hidden. The display-name is optional. tag is a string of hexadecimal numbers in
which the hyphen - can be added. When two user instances sharing the same SIP
address use the same Call-ID to initiate a call invitation, this tag should be used for
distinguishing purposes. The tag value must be globally unique. A user should maintain
the same Call-ID and tag value in the whole process of a call.
An example of the From field:
From: <sip:1000@191.169.200.61>;tag=1c17691
z
To
The To header field specifies the logical recipient of the request. The format of the To
header field is the same as that of the From header field except that the first key is
replaced by To. All requests and responses must contain this field.
The tag parameter in the field distinguishes different user instances that are identified
by the same SIP URL. A proxy server can concurrently deliver several requests, and
the same request might reach different instances (for example, home telephone) of the
user. Because the instances might all respond to the request, it is required to use the
tag to distinguish the responses from different instances. The tag in the To header field
is put by each instance in the response message.
Examples of the To field:
To: <Sip:1000@191.169.200.61>
To: <sip:1001@191.169.200.61>;tag=62beb3ca
3-12

Chapter 3 SIP
In SIP, Call-ID, From, and To header fields identify one call branch. When a proxy
server concurrently delivers requests, a call might have several call branches.
z
CSeq
CSeq is command sequence. A CSeq header field in a request contains a command

name and a single decimal sequence number. Request client defines the sequence
number which is unique inside the Call-ID. The initial value of the sequence number is
arbitrary. The subsequent values share the same Call-ID. For a request with a different
command name and a different message body, the CSeq sequence number should be
increased by one. A retransmitted request contains the same sequence number. The
server duplicates the CSeq value from the request to the response message, used to
correlate the request with the response it triggers.
The CSeq value (decimal sequence number) of an ACK or a CANCEL request is the
same as that of the corresponding INVITE request. The CSeq sequence number of a
BYE request should be higher than that of the corresponding INVITE request. The
server must remember the highest sequence number of an INVITE request having the
same Call-ID. Upon receipt of an INVITE request with a lower sequence number, the
server sends a response and discards the INVITE request.
Several requests concurrently delivered by the agent server have the same CSeq value.
Strictly speaking, CSeq is required for any request that is cancelled by a BYE or
CANCEL and also for continuous requests with the same Call-ID sent by the client.
An example of the CSeq field:
Cseq: 1 INVITE
z
Via
The Via header field indicates the path taken by the request. The field can avoid loops
during the transport of the request and ensure the same path taken by the responses,
for example, in firewall occasions.
The client originating a request must add its host name or network address in the Via
header field of the request. If the client does not use the default port, it must add the
used port number in the field. At requesting for forward, the proxy server must add its
address in a new Via header field that is put before the existing Via. If the proxy server
receives a request containing its address in a Via header field, the proxy server returns
a response indicating a loop detection.
When a request is passing a Network Address Translation (NAT) entity (for example,
firewall), the requested source address and the port number might be changed and
thus the Via cannot be the base for routing responses. To avoid that, the proxy server
should check the top Via header field. If the value of the top Via is different from the
previous hops address that is detected by the proxy server, the server add a receive
parameter in the Via which is thus called Via header field tagged by the receiver. For
example:
3-13

Chapter 3 SIP
Via:SIP/2.0/UDP softx3000.bell-telephone.com:5060
Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30
When the request from 10.0.0.1 passes a NAT point with the external address
191.169.12.30, the request reaches the proxy serversoftx3000.bell-telephone.com.
At noticing the mismatch between the previous hops address and the Via header field
address, the proxy server adds the actual sending address, as a receivers tag, at the
end of the top Via and then adds its own address in a new Via that is put at the topmost.
If the proxy server sends a request to multicast address, the proxy server must add a
parameter maddr in the Via to indicate that.
The proxy server or the user agent client complies with the following rules to process
the received Via:
Rule 1: The first Via header field should indicate the proxy server or the user agent
client itself. If not, the proxy server or the user agent client discards the message;
otherwise, the proxy server or the user agent client deletes the Via header field.
Rule 2: If there is no a second Via header field, the response should reach the
destination. Otherwise, proceed as follows.
Rule 3: If the second Via header field contains a maddr parameter, the proxy server or
the user agent client sends the response according to the multicast address indicated
in the parameter. The used port number is specified in the sent-by parameter. If not
specified, the proxy server or the user agent client uses a port number 5060. The
lifetime of the response should be specified in the ttl parameter. If not specified, the
proxy server or the user agent client sets it to 1.
Rule 4: If the second Via header field does not contain a maddr parameter but has a
field tagged by the receiver, the proxy server or the user agent client sends the
response to the address specified in the received parameter.
Rule 5: If there is neither a maddr parameter nor a tag, the proxy server or the user
agent client sends the response to the address specified in the sent-by parameter.
The Via header field has a generic format:
Via: sent-protocol sent-by; hidden, ttl; maddr; received; branch
The
sent-protocol
is
expressed
protocol-name/protocol-version/transport,
in
in
which
the
the
default
form
values
of
for
protocol-name and transport are SIP and UDP. The sent-by is usually the host and
port number of the sender. The hidden parameter has a key wordhidden. If there is
a hidden parameter, it indicates that the field has been encrypted by the previous proxy
for privacy purposes. For the meanings of the maddr and received parameters, see
earlier descriptions. The ttl and maddr parameters are coordinated with each other.
The branch parameter is used by the proxy server concurrently delivering requests to
3-14

Chapter 3 SIP
tag the branches. If the response reaches the destination, the proxy uses it to judge the
branch from which the response comes.
An example of the Via field:
Via:SIP/2.0/UDP191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=z9hG4b
kbc427dad6
z
Contact
The Contact header field is present in INVITE, ACK, and REGISTER requests, success
responses, call process responses, and redirection responses to provide an address
for direct communication with the user.
The Contact header field in an INVITE or ACK request indicates the location from which
the request is originated. With the field, the callee can directly send a request (for
example, BYE) to that address, instead of asking a series of proxy servers to forward
the request by using the Via header field.
A success response to INVITE might contain the Contact header field, which helps to
send the subsequent SIP requests (for example, ACK) directly to that address specified
in the field. That address usually indicates the host of the callee. If the host is behind a
firewall, that address indicates the proxy server.
Call process response to an INVITE request contains a Contact header field that has
the same meaning as the success response message. However, a CANCEL request
cannot be directly sent to that address. Instead, the CANCEL must be forwarded
through the same path of the original request.
The Contact header field in a REGISTER request indicates the reachable location of
the user. The request also defines a wildcard Contact field * that can only be used with
the expires field with a value of 0 to remove all registrations of a user. In the Contact
field, the expires parameter (optional) can also be specified to indicate the expiration
interval of the registration. If the parameter is not specified, the expires field value is
taken as its default value. If neither case is adopted, it is considered that the expiration
interval of the SIP URI is one hour.
The Contact header field in a success response to the REGISTER request returns all
locations that are currently reachable for the user.
The Contact header field in a redirect response such as Moved Temporarily, Moved
Permanently, or Address Ambiguous specifies other alternative addresses for retry,
which can be used for a response to a BYE, INVITE or OPTIONS request.
The Contact header field has a generic format:
Contact: address; q; action; expires; extension
The address is expressed in the same form as To and From. The q parameter has a
value range [0, 1] indicating the relative priority of the given location. The greater the
3-15

Chapter 3 SIP
value is, the higher the priority becomes. The action parameter is only used in a
REGISTER request, indicating the server is required to perform the proxy service or
redirection service on the subsequent requests to the client. If the Contact header field
does not contain an action parameter, the action to be performed depends on the
configurations of the server. The expires parameter indicates how long the URI is
valid either in seconds or by SIP date. The extension attribute is actually the extension
name.
An example of the Contact field:
Contact: <Sip:66500002@191.169.1.110:5061>;q=0.7;expires=3600
z
Max-Forwards
The Max-Forwards header field serves to limit the number of hops a request can transit
on the way to its destination. It consists of an integer that is decremented by one at
each hop. If the Max-Forwards value reaches 0 before the request reaches its
destination, it will be rejected with a 483 (Too Many Hops) error response.
The purpose of inserting this field is to avoid consuming proxy server resources in an
event of loop. The initial field value is 70.
The Max-Forwards header field has a generic format:
Max-Forwards: decimal integer
z
Allow
The Allow header field gives a list of request types that can all be supported by the
proxy server.
An example of the Allow field:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
z
Content-Length
The Content-Length header field indicates the size of the message body, in decimal
number of octets, sent to the recipient. Applications use this field to indicate the size of
the message body to the transferred, regardless of the media type of the entity. If the
used transport protocol is based on streams, for example, TCP, this header field must
be used.
The size of the message body does not include the Carriage Return Line Feed (CRLF)
that separates the message header from the message body. The Content-Length value
must be greater than or equal to 0. If a message does not contain a message body, the
value of the Content-Length header field must be set to 0.
SDP serves to construct the message body of a request or 2xx response.
The Content-Length header field has a generic format:
Content-Length: decimal value
3-16

Chapter 3 SIP
An example of the Content-Length header field:

Content-Length: 349
That indicates the length of the message body is 349 bytes.

z
Content-Type
The Content-Type header field indicates the media type of the message body sent to
the recipient. If the message body is not empty, the Content-Type header field must be
present. If the body is empty and a Content-Type header field is present, it indicates
that the body of the specific type has zero length (for example, an empty audio file).
An example of the Content-Type header field:
Content-Type: application/sdp
z
Supported
Transportation of a 100 provisional response defined in SIP is not reliable. In other

words, there is no guarantee that UAC can receive the provisional response sent by the
UAS.
If the response is required to carry information about media, it must be guaranteed that
the message can be reliably transported to the peer. 100rel extension provides an
appropriate mechanism for the reliable transportation of the 100 response. The
acknowledgement request method for a provisional response in 100rel is PRACK.
If the UAC supports the extension, the UAC adds a Supported: 100rel header field in
the message transmitted. If the UAS supports the extension, the UAS adds a Require:
100rel header field in the 100 response transmitted. Upon receipt of the response, the
UAC is required to send a PRACK request to the UAS, notifying the UAS of the receipt
of the provisional response. The UAS sends a 2xx response to the UAC to terminate
the acknowledgement process of the provisional response.
If a UA wants to send a provisional response carrying a SDP message body, the UAC
and the UAS must support and use the 100rel extension to guarantee the reliable
transportation of the message.
For example:
Supported: 100rel
z
User-Agent
The User-Agent header field contains information about the UAC originating the
request.
Revealing the specific software version of the user agent might allow the user agent to
become more vulnerable to attacks against software that is known to contain security
holes. Therefore, the User-Agent header field should be set to be a configurable option.
For example:
User-Agent: Softphone Beta1.5
3-17

z
Chapter 3 SIP
Expires
The Expires header field gives the relative time after which the message (or content)
expires.
For example:
Expires: 5
z
Accept-Language
The Accept-Language header field is used in requests to indicate the preferred

languages for reason phrases, session descriptions, or status responses carried as
message bodies in the response. If no Accept-Language header field is present, the
server assumes all languages are acceptable to the client.
For example:
Accept-Language: en
z
Authorization
The Authorization header field contains authentication credentials of a UA.

The following introduces a general process for a UA to request an authorization from
the server.
If the server requires authorizing the user when the UA originates a request, a nonce is
generated at the local end for this authorization and all parameters necessary for the
authorization request header field are returned to the UA to initiate a user authorization
process.
Upon receipt of the authorization request, the UA generates an encrypted response
using a particular algorithm according to the information returned from the server and
the user configurations. The UA sends the response through a new request message to
the server.
Upon receipt of the new request with the authorization response, the server firstly
checks the correctness of the nonce. If the nonce is not generated locally, the server
returns a failure message. If the nonce is generated locally but the authorization
expires, the server re-generates a nonce and re-initiates a user authorization
procedure. The earlier nonce is returned with the cnonce parameter.
If the nonce passes the verification, the server generates a response with the same
algorithm as the UA according to the nonce, username, password (the server can
obtain the password of the user from the local user information), and URI. In addition,
the server compares the generated response with the response carried in the request
message. If the responses match, the user successfully passes the authorization.
Otherwise, the authorization fails.
The Authorization field has a generic format:
3-18

Chapter 3 SIP
Authorization: method username, realm, nonce, response, URI, cnonce, algorithm

The authorization methods include digest, basic, chap-password, and carddigest.
Digest is an HTTP-digest method. Currently SoftX3000 supports only the HTTP-digest
method. SoftX3000 will support the carddigest method to achieve Uniphone card
number calls.
Username indicates the authenticated user.
Realm is used to identify the domain from which the authorization procedure is
initiated.
Nonce is an encryption factor that is generated by the entity initiating the authorization
procedure.
Response is a string of characters that the UA generates, by using a particular
algorithm, according to the nonce, username, password, and URI from the server upon
receipt of the authorization request. The string contains the encrypted password of the
user. (During the authorization procedure, the UA and the server exchange other
information, except password, in plain text in SIP messages.)
URI refers to the request-URI of the originated call request message. Upon receipt of
an authorization request, the UA has to re-originate a request that carries the
authorization response information to the server. In the request, some fields including
request-URI might be changed at a passed network server. The URI parameter in the
authorization header field serves to transfer the request-URI in the original message for
authorization purposes when the UA originates the request. This is to ensure the
correctness of the authorization procedure.
If the UA returns a new request message with the authorization response after
expiration at the server, the server has to re-generate a nonce to authenticate the user.
The nonce parameter carries the new nonce. The cnonce parameter carries the earlier
nonce to the UA.
Algorithm is used to transfer the algorithm for generating the response.
For example:
Authorization:
DIGEST
USERNAME="6540012",
REALM="huawei.com",
NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6",
URI="sip:191.169.150.30"
3)
Example of request message
The following is an example of SIP request message.

INVITE sip:66500002@191.169.1.110 SIP/2.0
From: <sip:44510000@191.169.1.116>;tag=1ccb6df3
To: <sip:66500002@191.169.1.110>
CSeq: 1 INVITE
3-19

Chapter 3 SIP
Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000
Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6
Contact: <sip:44510000@191.169.1.116:5061>
Supported: 100rel,100rel
Max-Forwards:70
Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,N
OTIFY,MESSAGE,REFER
Content-Length:230
v: 0
o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.1.116
s: Sip Call
c: IN IP4 191.169.1.95
t: 0 0
m: audio 30000 RTP/AVP 8 0 4 18
a: rtpmap:8 PCMA/8000
a: rtpmap 0 PCMU/8000
a: rtpmap 4 G723/8000
a: rtpmap 18 G729/8000
The 1st line: This is the start line of the request. It indicates an INVITE request message
for URI. The current address of the invited user is sip:66500002@191.169.1.110. The
SIP protocol version is 2.0.
The 2nd line: This is a From header field. It indicates that the address of the request
originator is <sip:44510000@191.169.1.116>. The tag is 1ccb6df3. When several
users sharing the same SIP address originate INVITEs with the same Call-ID, this is
used to distinguish the users.
The 3rd line: This is a To header field. It indicates that the address of the request
recipient is <sip:66500002@191.169.1.110>.
From the From and To header fields, we can find:
A terminal, 44510000, under the control of an MGC with the IP address 191.169.1.116
dials a terminal, 66500002, under the control of an MGC with the IP address
191.169.1.110. The terminal type might be ESL connected to SIP, H.323, Integrated
Access Device (IAD), or Access Gateway (AG).
The 4th line: This is a CSeq header field, used to correlate the INVITE request with the
triggered responses and corresponding ACK and CANCEL requests.
The 5th line: This is a Call-ID header field. This header field identifies an INVITE that is
globally unique. The Call-ID is 20973e49f7c52937fc6be224f9e52543@sx3000 in
3-20

Chapter 3 SIP
which sx3000 is the domain name of the SoftX3000 originating the call and
20973e49f7c52937fc6be224f9e52543 is the local identifier.
The 6th line: This is a Via header field. This header field indicates the path through
which the request passes. SIP/2.0/UDP represents the protocol for the transmission,
in which the protocol name is SIP, the protocol version is 2.0, and the transport layer
is UDP. 191.169.1.116:5061 indicates that the IP address of the SoftX3000, the
sender, is 191.169.1.116 and the used port is 5061. branch=z9hG4bkbc427dad6
is the branch parameter. When concurrently delivering a request, SoftX3000 tags all
the branches.
The 7th line: This is a Contact header field, indicating that the subsequent requests (for
example, BYE) can be directly sent to <sip:44510000@191.169.1.116:5061> without
the help of a Via header field.
The 8th line: This is a 100rel extension. This header field provides a reliable
transmission mechanism for 100 response.
The 9th line: This is a Max-Forwards header field, indicating that the maximum number
of hops the request can transit on the way to its destination is 70.
The 10th line: This is an Allow header field. This header field lists the types of request
messages that are supported by the SoftX3000 with a given IP address
191.169.1.116.
The 11th line: This is a Content-Type header field, indicating that the body carried in the
message is a single message body based on the SDP.
The 12th line: This is a white space. An SDP session description follows the white
space.
The 13th line: This is the SDP protocol version number. Currently it is the version 0.
The 14th line: This line contains the session owner/creator and the session identifier,
used to give the originator (username and host address) of the session, the session
identifier, and the session version number. HuaweiSoftX3000 is the username that is
used by the user to log into the originating host. If the host does not support user
identifier, this field is tagged to be a sign -. The first 1073741831 is the session
identifier. The session identifier in the form of a digit string helps the multiple tuples
(username, session identifier, network type, address type, and address) to construct
the sessions globally unique identifier. The second 1073741831 is the version
number of the session announcement, which is provided for the proxy server to detect
the latest one from the several announcements of the same session. The basic
principle is to increment that version number once the session data is modified. IN
refers to network indicator in the form of a text string. The currently defined IN is
Internet. IP4 refers to the address type in the form of a text string. Currently IP4 and
IP6 are defined. 191.169.1.116 is the IP address of the host that creates the session.
3-21

Chapter 3 SIP
If the address type is IP4, the IP address might be a full domain name or a dotted
decimal IP4 address. If the address type is IP6, the IP address might be a full domain
name or a compressed text IP6 address.
The 15th line: This line contains the session name. Each session description
necessarily has one and only one session name.
The 16th line: This line contains the connection related data. Currently the network type
and the address type are defined to be IN and IP4. 191.169.1.95 might be the IP
address of a Media Gateway (MG) (the terminal type is ESL telephone connected to an
IAD/AG) under the control of the SoftX3000 whose IP address is 191.169.1.116.
191.169.1.95 might also be the IP address of a SIP or H.323 terminal (the terminal
type is SIP or H.323 phone).
The 17th line: This line contains the time description. It provides a time segment when
the session can be activated, allowing the session to periodically occur. 0 represents
the start time. The format for the field is t:<start time><end time>. The values of start
time and end time are expressed in the decimal form of Network Time Protocol (NTP)
time values. The unit is second.
The 18th line: This line contains the media-level description. It provides information that
is suitable only for the media stream. audio refers to the media type. Currently five
types of media are defined: audio, video, application, data, and control. 30000
represents the transport-layer port to which the media stream is transmitted, that is, the
UDP port number of the MG (the terminal type is ESL phone connected to an IAD/AG)
or the UDP port number of a SIP or H.323 terminal (the terminal type is SIP or H.323
phone). RTP/AVP is the transport layer protocol. Its value is associated with the type
of address in the c line. For IP4, a great number of media service streams are
transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP,
audio/video application document, transported over UDP; Udp, the DUP protocol. 8 0
4 18 is, for audio and video, the media payload type that is defined in the RTP
audio/video application document. It means that all the formats carried in the session
might be used, but the first one is the default format for the session.
The whole line indicates that A-law PCM single-channel audio signal is used by default,
its static payload type is numbered 8 in the RTP audio/video application document, and
the signal is transmitted to a UDP port 30000.
The 19th to 22nd lines: These lines introduce rtpmap attributes, specifying the mapping
correspondence from RTP payload type to encoding. The format of such a line is a:
rtpmap:<payload type><encoding name>/<clock rate>[/<coding parameter>]. In the
format, <coding parameter> refers to the number of audio channels. This parameter is
unavailable to video signals.
3-22

Chapter 3 SIP
II. Response messages

1)
Response format
Figure 3-4 illustrates the format for a SIP response that is composed of a start line, a
message header, and a message body. A line feed character distinguishes each
parameter line in the message header. Some parameters are optional for different
response messages.
SIP/prot ocol version
Status code
Descriptive phrase
Start line
Call-ID: Field value

Form: Field value
To: Field value
CSeq: Field value
Via: Field value
Contact: Field value
Message header
Max-Forwards: Field value

Allow: Field value
Content-Length: Field value
Supported: Field value
User-Agent: Field value
Content-Type: Field value
White space
SDP
Message body
Figure 3-4 SIP response format

2)
Response message parameters
Refer to the earlier section describing the request message parameters.

3)
Example of response message
The following is an example of SIP response message.

SIP/2.0 180 Ringing
From: <sip:44510000@191.169.1.116>;tag=1ccb6df3
To: <sip:66500002@191.169.1.110>;tag=58877b85
Cseq:1 INVITE
3-23

Chapter 3 SIP
Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000
Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6
Require:100rel
RSeq:1
Contact:<sip:66500002@191.169.1.110:5061;transport=udp>
Content-Length:157
Content-Type:application/sdp
v=0
o=HuaweisoftX3000 1073741824 1073741824 IN IP4 191.169.1.110
s=Sip Call
c=IN IP4 191.169.1.135
t=0 0
m=audio 30016 RTP/AVP 8
a=rtpmap:8 PCMA/8000
The 1st line: The SIP protocol. The protocol version is 2.0. The status code is 180.
Ringing is a descriptive phrase, indicting to send the ringing tone to the callee.
The 2nd and 3rd lines: Refer to the example of SIP request.
The 4th line: This is a CSeq header field, used to correlate the INVITE request with the
triggered responses and corresponding ACK and CANCLE requests. The CSeq
header field in this response has the same meaning as that in the earlier described
request. Both are 1 INVITE, indicating the response is trigger by the previous request.
The 5th to 11th lines: Refer to the example of SIP request.
The 12th line: This is a white space. An SDP session description follows the white
space.
The 13th line: This is the SDP protocol version number. Currently it is the version 0.
The 14th line: This line contains the session owner/creator and the session identifier,
used to give the originator (username and host address) of the session, the session
identifier, and the session version number. HuaweiSoftX3000 is the username that is
used by the user to log into the originating host. If the host does not support user
identifier, this field is tagged to be a sign -. The first 1073741824 is the session
identifier. The session identifier in the form of a digit string helps the multiple tuples
(username, session identifier, network type, address type, and address) to construct
the sessions globally unique identifier. The second 1073741824 is the version
number of the session announcement, which is provided for the proxy server to detect
the latest one from the several announcements of the same session. The basic
principle is to increment that version number once the session data is modified. IN
refers to network indicator in the form of a text string. The currently defined IN is
3-24

Chapter 3 SIP
Internet. IP4 refers to the address type in the form of a text string. Currently IP4 and
IP6 are defined. 191.169.1.110 is the IP address of the host that creates the session.
The 15th line: This line contains the session name. Each session description
necessarily has one and only one session name.
The 16th line: This line contains the connection related data. Currently the network type
and the address type are defined to be IN and IP4. 191.169.1.135 might be the IP
address of an MG (the terminal type is ESL telephone connected to an IAD/AG) under
the control of the SoftX3000 whose IP address is 191.169.1.110. 191.169.1.135 might
also be the IP address of a SIP or H.323 terminal (the terminal type is SIP or H.323
phone).
The 17th line: This line contains the time description. It provides a time segment when
the session can be activated, allowing the session to periodically occur.
The 18th line: This line contains the media-level description. It provides information that
is suitable only for the media stream. audio refers to the media type. 30016
represents the transport-layer port to which the media stream is transmitted, that is, the
UDP port number of the MG (the terminal type is ESL phone connected to an IAD/AG)
or the UDP port number of a SIP or H.323 terminal (the terminal type is SIP or H.323
phone). RTP/AVP is the transport layer protocol. Its value is associated with the type
of address in the c line. For IP4, a great number of media service streams are
transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP,
audio/video application document, transported over UDP; Udp, the DUP protocol. 8 is
the media payload type defined in the RTP audio/video application document.
The 19th line: This line introduces a rtpmap attribute, specifying the mapping
correspondence from RTP payload type to encoding. The RTP payload type 8
represents PCMA.
3.3 Basic Message Procedures

3.3.1 SIP User Registration Procedure
When user powers on a SIP phone, the SIP phone must register itself to the associated
server. When the address of a SIP client changes, the SIP phone must re-register itself
to the associated server. The SIP must periodically update the registration information.
The following scenario presents how a SIP phone registers itself to the SoftX3000 to
illustrate the SIP user registration procedure.
z
The IP address of SIP Phone is 191.169.150.251;
3-25

z
Chapter 3 SIP
SIP Phone requests to register itself to SoftX3000.
SIP Phone
SoftX3000
Register
401 Unauthorized
Register
200 OK
Figure 3-5 Registration procedure between SIP entity and SIP server
1)
Event 1: SIP Phone originates a Register request to SoftX3000, notifying

SoftX3000 of an on-power event or a restart event and requesting to register to
MGC. The following is an example of Register request.
REGISTER sip:191.169.150.30 SIP/2.0

From: sip:6540012@191.169.150.30;tag=16838c16838
To: sip:6540012@191.169.150.30;tag=946e6f96
Call-Id: 1-reg@191.169.150.251
Cseq: 2762 REGISTER
Contact: sip:6540012@191.169.150.251
Expires: 100
Content-Length: 0
Accept-Language: en
Supported: sip-cc, sip-cc-01, timer
User-Agent: Pingtel/1.2.7 (VxWorks)
Via: SIP/2.0/UDP 191.169.150.251
The 1st line: This is the start line of the request. It indicates a Register request message.
The terminal is originating to register itself to the MGC whose IP address is
191.169.150.30. The SIP protocol version is 2.0.
The 2nd line: This is a From header field. It indicates that the Register originator is a
SIP Phone controlled by the MGC whose IP address is 191.169.150.30.
The 3rd line: This is a To header field. It indicates the address of the Register recipient.
In this example, the address of the Register recipient, MGC, is 191.169.150.30.
The 4th line: This is a Call-ID header field, This header field identifies an INVITE that is
globally unique. The Call-ID is 1-reg@191.169.150.251 in which 191.169.150.251 is
the IP address of SIP Phone originating the Register request and 1-reg is the local
identifier.
3-26

Chapter 3 SIP
The 5th line: This is a CSeq header field, used to correlate the Register request with the
responses it triggers.
The 6th line: This is a Contact header field. The Contact header field in the Register
request indicates the reachable location of the user. It indicates that the current IP
address of SIP Phone is 191.169.150.251 and the telephone number is 6540012.
The 7th line: This line indicates that the lifetime of the Register is 100s.
The 8th line: This line indicates that the length of the message body of the request is
null, that is, the message does not carry a session description.
The 9th line: This line indicates that English is the preferred language to mention the
reason phrase, the session description, or the status answer contents carried in the
answer message.
The 10th line: This line indicates that the message sender, a UA entity, supports sip-cc,
sip-cc01, and timer extension protocols. timer represents that the terminal supports
the session-timer extension protocol.
The 11th line: This line contains information of the user terminal that originates the
request. In this example, the information includes the type and the version number of
SIP Phone.
The 12th line: This is a Via header field. This header field indicates the path taken by
the request. SIP/2.0/UDP represents the protocol used for the transmission, in which
SIP is the protocol name, 2.0 is the protocol version number, and UDP is the
transport layer. 191.169.150.251 represents the IP address of the request sender.
2)
Event 2: SoftX3000 returns a 401 Unauthorized response, indicating that MGC

requires authenticating the user. The WWW-Authenticate field carries the
authorization method, digest, that is supported by MGC and the domain name of
MGC, huawei.com. SoftX3000 generates a nonce required for this authorization.
This response carries those parameters to the terminal to initiate an authorization
procedure.
SIP/2.0 401 Unauthorized

From: <sip:6540012@191.169.150.30>;tag=16838c16838
To: <sip:6540012@191.169.150.30>;tag=946e6f96
CSeq: 2762 REGISTER
Call-ID: 1-reg@191.169.150.251
Via: SIP/2.0/UDP 191.169.150.251
WWW-Authenticate: Digest realm="huawei.com",nonce="200361722310491179922"
Content-Length: 0
3)
Event 3: SIP Phone re-originates a Register request to SoftX3000. The request

carries an Authorization header field that contains an authorization method
(digest), SIP Phones user identifier (a telephone number in this example),
MGCs domain name, nonce, URI, and response parameters. (The contained
3-27

Chapter 3 SIP
response parameter contains a response that SIP Phone encrypts, upon receipt of
the 401 Unauthorized response message, by using a particular algorithm
according to the information returned from the server as well as the user
configurations.) The following is an example of Register request.
REGISTER sip:191.169.150.30 SIP/2.0
From: sip:6540012@191.169.150.30;tag=16838c16838
To: sip:6540012@191.169.150.30;tag=946e6f96
Call-Id: 1-reg@191.169.150.251
Cseq: 2763 REGISTER
Contact: sip:6540012@191.169.150.251
Expires: 100
Content-Length: 0
Accept-Language: en
Authorization:
DIGEST
USERNAME="6540012",
REALM="huawei.com",
NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6",
URI="sip:191.169.150.30"
Via: SIP/2.0/UDP 191.169.150.251
4)
Event 4: Upon receipt of the Register request from SIP Phone, MGC checks the
correctness of the nonce. If the received nonce is the same as that carried in the
401 Unauthorized response message, SIP Phone passes the check. Otherwise,
MGC will return a failure message. Subsequently, MGC collects the nonce,
username, password (obtained from the local user information), and URI and uses
the same algorithm as used at the terminal to generate a new response parameter.
MGC compares the new response parameter with that carried in the request
message. If they are consistent, the user successfully passes the authorization;
otherwise, the authorization fails. MGC returns a 200 OK response message,
indicating the success of the terminal authorization.
SIP/2.0 200 OK
From: <sip:6540012@191.169.150.30>;tag=16838c16838
To: <sip:6540012@191.169.150.30>;tag=946e6f96
CSeq: 2763 REGISTER
Call-ID: 1-reg@191.169.150.251
Via: SIP/2.0/UDP 191.169.150.251
Contact: <sip:6540012@191.169.150.251>;expires=3600
Content-Length: 0
3.3.2 Successful SIP User Call Procedure

An application example for a successful call procedure between two SIP users under
the control of the same SoftX3000 is illustrated in Figure 3-6.
3-28

Chapter 3 SIP

z
The IP address of SIP Phone A is 191.169.150.101;
The IP address of SIP Phone B is 191.169.150.100;
SIP Phone A originates a call to SIP Phone B, and the calling party hooks on first;
The telephone number of SIP Phone A is 1000, and the telephone number of SIP
Phone B is 1001.
SIP Phone A
1
2
3
4
SoftX3000
SIP Phone B
INVITE
100 Trying
407
ACK
INVITE
100 Trying
10 180 Ringing
12
13
200 OK
ACK
INVITE
7
8
100 Trying
180 Ringing
11
200 OK
14
ACK
Conversation
15
BYE
16
487
17
BYE
Figure 3-6 SIP call procedure between two SIP entities

1)
Event 1: SIP Phone A originates an INVITE request to MGC, requesting MGC to

invite SIP Phone B to a session. The session description of the INVITE message
carries SIP Phone As IP address (191.169.150.101), port number (8766), payload
type, encoding information matching the payload type to MGC.
INVITE sip:1001@191.169.200.61 SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674
To: sip:1001@191.169.200.61
Call-Id: call-973598097-16@191.169.150.101
Cseq: 1 INVITE
Contact: sip:1000@191.169.150.101
Content-Length: 203
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
3-29

Chapter 3 SIP

Via: SIP/2.0/UDP 191.169.150.101
v=0
o=Pingtel 5 5 IN IP4 191.169.150.101
s=phone-call
c=IN IP4 191.169.150.101
t=0 0
m=audio 8766 RTP/AVP 0 96 8
a=rtpmap:0 pcmu/8000/1
a=rtpmap:96 telephone-event/8000/1
a=rtpmap:8 pcma/8000/1
For interpretation of the lines, refer to the example of request message in the Request
Messages section.
2)
Event 2: MGC returns a 100 Trying response to SIP Phone A, notifying SIP Phone
A of the receipt of the request and also that MGC is processing the request.
SIP/2.0 100 Trying

From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>
CSeq: 1 INVITE
Call-ID: call-973598097-16@191.169.150.101
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0
3)
Event 3: MGC sends a 407 Proxy Authentication Required response to SIP Phone
A, indicating that MGC requires authenticating the user. The Proxy-Authenticate
field carries the authorization method, digest, that is supported by MGC and the
domain name of MGC, huawei.com. MGC generates a nonce required for this
authorization. This response message carries those parameters to the terminal to
initiate an authorization procedure.
SIP/2.0 407 Proxy Authentication Required

From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>;tag=de40692f
CSeq: 1 INVITE
Call-ID: call-973598097-16@191.169.150.101
Via: SIP/2.0/UDP 191.169.150.101
Proxy-Authenticate: Digest realm="huawei.com",nonce="1056131458"
Content-Length: 0
4)
Event 4: SIP Phone A sends an ACK message to MGC, acknowledging the receipt
of the final response to the INVITE request from MGC.
ACK sip:1001@191.169.200.61 SIP/2.0

Contact: sip:1000@191.169.150.101
3-30

Chapter 3 SIP
From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>;tag=de40692f
Call-Id: call-973598097-16@191.169.150.101
Cseq: 1 ACK
Accept-Language: en
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0
5)
Event 5: SIP Phone A re-originates an INVITE request to SoftX3000. The request

carries a Proxy-Authorization field that contains an authorization method (digest),
SIP Phones user identifier (a telephone number in this example), MGCs domain
name, nonce, URI, and response parameters. (The contained response
parameter contains a response that SIP Phone A encrypts, upon receipt of the 407
response message, by using a particular algorithm according to the information
returned from the server as well as the user configurations.)
INVITE sip:1001@191.169.200.61 SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674
To: sip:1001@191.169.200.61
Call-Id: call-973598097-16@191.169.150.101
Cseq: 2 INVITE
Contact: sip:1000@191.169.150.101
Content-Length: 203
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
Proxy-Authorization:
DIGEST
NONCE="1056131458",
USERNAME="1000",
REALM="huawei.com",
RESPONSE="1b5d3b2a5441cd13c1f2e4d6a7d5074d",
URI="sip:1001@191.169.200.61"
Via: SIP/2.0/UDP 191.169.150.101
v=0
o=Pingtel 5 5 IN IP4 191.169.150.101
s=phone-call
c=IN IP4 191.169.150.101
t=0 0
m=audio 8766 RTP/AVP 0 96 8
a=rtpmap:96 telephone-event/8000/1
3-31

6)
Chapter 3 SIP
Event 6: MGC returns a 100 Trying response to SIP Phone A, notifying SIP Phone
A of the receipt of the request and also that MGC is processing the request.
SIP/2.0 100 Trying

From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>
CSeq: 2 INVITE
Call-ID: call-973598097-16@191.169.150.101
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0
7)
Event 7: MGC sends an INVITE message to SIP Phone B, requesting SIP Phone
B to participate in the session. The INVITE message carries SIP Phone As
session description to SIP Phone B.
INVITE sip:1001@191.169.150.100 SIP/2.0

From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>
CSeq: 1 INVITE
Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0
Contact: <sip:1000@191.169.200.61:5061>
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,
MESSAGE,REFER
Content-Length: 183
v=0
o=HuaweiSoftX3000 1073741833 1073741833 IN IP4 191.169.200.61
s=Sip Call
c=IN IP4 191.169.150.101
t=0 0
a=rtpmap:0 PCMU/8000
8)
Event 8: SIP Phone B returns a 100 Trying response to MGC, notifying MGC of the
receipt of the request and also that SIP Phone B is processing the request.
SIP/2.0 100 Trying

From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>;tag=4239
Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000
Cseq: 1 INVITE
3-32

Chapter 3 SIP

Contact: sip:1001@191.169.150.100
CONTENT-LENGTH: 0
9)
Event 9: SIP Phone B receives the ringing tone and returns a 180 Ringing
response to MGC.
SIP/2.0 180 Ringing

From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>;tag=4239
Cseq: 1 INVITE
Contact: sip:1001@191.169.150.100
CONTENT-LENGTH: 0
10) Event 10: MGC sends a 180 Ringing response to SIP Phone A. SIP Phone A
receives the ringback tone.
SIP/2.0 180 Ringing
From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>;tag=e110e016
CSeq: 2 INVITE
Call-ID: call-973598097-16@191.169.150.101
Via: SIP/2.0/UDP 191.169.150.101
Contact: <sip:1001@191.169.200.61:5061;transport=udp>
Content-Length: 0
11) Event 11: SIP Phone B sends a 200 OK response to MGC, notifying that SIP
Phone B has successfully received and processed the INVITE request. The
message carries its IP address (191.169.150.101), port number (8766), payload
type, encoding information matching the payload type to MGC.
SIP/2.0 200 OK
From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>;tag=4239
Cseq: 1 INVITE
Content-Length: 164
Session-Expires: 36000
Contact: sip:1001@191.169.150.100
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY
3-33

Chapter 3 SIP
v=0
o=Pingtel 5 5 IN IP4 191.169.150.100
s=phone-call
c=IN IP4 191.169.150.100
t=0 0
12) Event 12: MGC sends a 200 OK response to SIP Phone A, notifying that MGC has
successfully received and processed the INVITE request, and MGC sends the
session description of SIP Phone B to SIP Phone A.
SIP/2.0 200 OK
From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>;tag=e110e016
CSeq: 2 INVITE
Call-ID: call-973598097-16@191.169.150.101
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 183
v=0
s=Sip Call
c=IN IP4 191.169.150.100
t=0 0
13) Event 13: SIP Phone A sends an ACK message to MGC, acknowledging the
receipt of the final response to the INVITE request from MGC.
ACK sip:1001@191.169.200.61:5061;transport=UDP SIP/2.0
Contact: sip:1000@191.169.150.101
From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>;tag=e110e016
Call-Id: call-973598097-16@191.169.150.101
Cseq: 2 ACK
Accept-Language: en
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0
3-34

Chapter 3 SIP
14) Event 14: MGC sends an ACK message to SIP Phone B, acknowledging the
receipt of the final response to the INVITE request from SIP Phone B.
Now, the calling and called parties know both session descriptions and then starts a
conversation.
ACK sip:1001@191.169.150.100 SIP/2.0
From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>;tag=4239
CSeq: 1 ACK
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK44cfc1f25
Max-Forwards: 70
Content-Length: 0
15) Event 15: SIP Phone A hooks on and sends a BYE message to MGC, requesting
to terminate the session.
BYE sip:1001@191.169.200.61:5061;transport=UDP SIP/2.0
From: sip:1000@191.169.200.61;tag=1c12674
To: sip:1001@191.169.200.61;tag=e110e016
Call-Id: call-973598097-16@191.169.150.101
Cseq: 4 BYE
Accept-Language: en
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0
16) Event 16: MGC returns a 487 response to SIP Phone A, indicating the termination.
SIP/2.0 487 Request Terminated
From: <sip:1000@191.169.200.61>;tag=1c12674
To: <sip:1001@191.169.200.61>;tag=e110e016
CSeq: 4 BYE
Call-ID: call-973598097-16@191.169.150.101
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0
17) Event 17: MGC receives the BYE from SIP Phone A and knows the on-hook event.
MGC sends a BYE request to SIP Phone B, requesting to terminate the session.
BYE sip:1001@191.169.150.100 SIP/2.0
From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>;tag=4239
CSeq: 2 BYE
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd
Max-Forwards: 70
Content-Length: 0
3-35

Chapter 3 SIP
18) Event 18: SIP Phone B hooks on and sends a 200 OK response to MGC,
indicating that the session is successfully terminated.
SIP/2.0 200 OK
From: <sip:1000@191.169.200.61>;tag=1fd84419
To: <sip:1001@191.169.150.100>;tag=4239
Cseq: 2 BYE
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd
Contact: sip:1001@191.169.150.100
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY
CONTENT-LENGTH: 0
3.3.3 Successful SIP Trunk Call Procedure

Figure 3-7 illustrates an example of a successful SIP trunk call procedure where two
SoftX3000s communicate with each other through SIP.
z
The IP address of SoftX3000 A is 191.169.1.112;
The IP address of SoftX3000 B is 191.169.1.110;
SIP Phone A controlled by SoftX3000 A has a telephone number 66600003;
SIP Phone B controlled by SoftX3000 B has a telephone number 5550045;
SIP Phone A originates a call to SIP Phone B, and the called party hooks on first.
SoftX3000 A
1
SoftX3000 B
INVITE
100 Trying
180 Ringing
200 OK
ACK
BYE
7 487 Request Terminated
Figure 3-7 SIP trunk call procedure

1)
Event 1: SIP Phone A controlled by SoftX3000 A hooks off and originates a call to
SIP Phone B controlled by SoftX3000 B. SoftX3000 A sends an INVITE message
to SoftX3000 B, inviting SoftX3000 to the session. The session description of the
INVITE message carries SoftX3000 As IP address (191.169.200.61), SIP Phone
3-36

Chapter 3 SIP
As IP address (191.169.200.101), port number (30014), supported payload type,

encoding information matching the payload type to SoftX3000 B.
INVITE sip:5550045@191.169.100.50 SIP/2.0
From: <sip:66600003@191.169.200.61>;tag=64e3f587
To: <sip:5550045@191.169.100.50>
CSeq: 1 INVITE
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627
Contact: <sip:008675566600003@191.169.200.61:5061>
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,
MESSAGE,REFER
Content-Length: 184
v=0
s=Sip Call
c=IN IP4 191.169.200.101
t=0 0
2)
Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A, notifying

SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing
the request.
SIP/2.0 100 Trying

From: <sip:66600003@191.169.200.61>;tag=64e3f587
To: <sip:5550045@191.169.100.50>
CSeq: 1 INVITE
Content-Length: 0
3)
Event 3: SoftX3000 B sends a 180 Ringing response to SoftX3000 A, notifying

SoftX3000 A of the ringing event at SIP Phone B.
SIP/2.0 180 Ringing

From: <sip:66600003@191.169.200.61>;tag=64e3f587
To: <sip:5550045@191.169.100.50>;tag=2dc18caf
CSeq: 1 INVITE
3-37

Chapter 3 SIP

Content-Length: 0
4)
Event 4: SoftX3000 B sends a 200 OK response to SoftX3000 A, notifying that

SoftX3000 B has successfully received and processed the INVITE request. The
message carries its IP address (191.169.100.50), SIP Phone B's IP address
(191.169.100.71), port number (40000), supported payload type, encoding
information matching the payload type to SoftX3000 A.
SIP/2.0 200 OK
From: <sip:66600003@191.169.200.61>;tag=64e3f587
To: <sip:5550045@191.169.100.50>;tag=2dc18caf
CSeq: 1 INVITE
Content-Length: 159
v=0
s=Sip Call
c=IN IP4 191.169.100.71
t=0 0
m=audio 40000 RTP/AVP 0
5)
Event 5: SoftX3000 A sends an ACK message to SoftX3000 B, acknowledging the

receipt of the final response to the INVITE request from SoftX3000 B.
ACK sip:5550045@191.169.100.50:5061;transport=udp SIP/2.0

From: <sip:66600003@191.169.200.61>;tag=64e3f587
To: <sip:5550045@191.169.100.50>;tag=2dc18caf
CSeq: 1 ACK
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK7d4f55f15
Max-Forwards: 70
Content-Length: 0
6)
Event 6: SIP Phone B hooks on. SoftX3000 B sends a BYE message to SoftX3000
A, requesting to terminate the session.
BYE sip:66600003@191.169.200.61:5061 SIP/2.0

From: <sip:5550045@191.169.100.50>;tag=2dc18caf
To: <sip:66600003@191.169.200.61>;tag=64e3f587
CSeq: 1 BYE
3-38

Chapter 3 SIP
Via: SIP/2.0/UDP 191.169.100.50:5061;branch=z9hG4bK2a292692a

Max-Forwards: 70
Content-Length: 0
7)
Event 7: SoftX3000 A returns a 487 response to SoftX3000 B, indicating the

termination.
SIP/2.0 487 Request Terminated

From: <sip:5550045@191.169.100.50>;tag=2dc18caf
To: <sip:008675566600003@191.169.200.61>;tag=64e3f587
CSeq: 1 BYE
Via: SIP/2.0/UDP 191.169.100.50:5061;branch=z9hG4bK2a292692a
Content-Length: 0
3.3.4 Successful SIP-T Trunk Call Procedure

SIP-T is not a new protocol. Based on SIP, SIP-T provides an extension mechanism of
how to achieve the interworking between SIP network and PSTN network. There are
three application models: PSTN-IP, IP-PSTN, and PSTN-IP-PSTN.
SIP-T has the following characteristics:
z
Encapsulation: SIP message body carries ISUP messages.
Mapping: mapping between ISUP signaling and SIP messages and mapping
between ISUP parameters and SIP header fields. The mapping between ISUP
signaling and SIP messages can be simply described in the following way:
IAM = INVITE
ACM = 180 RINGING
ANM = 200 OK
RLS = BYE
RLC = 200 OK
The following takes the PSTN-IP-PSTN model as an example to illustrate the call
procedure where PSTN messages are transparently transported through SIP-T
messages. A successful SIP-T trunk call procedure is shown in Figure 3-8.
3-39

Chapter 3 SIP
SoftX3000 A
SG A
SoftX3000 B
SG B
IAM
1
INVITE
IAM
2 100 Trying
AC M
3 180 Ring
AC M
AN M
4
200 OK
AN M
5
ACK
Conversation
REL
6
BYE
REL
RLC
200 OK
RLC
Figure 3-8 Successful SIP-T call procedure (PSTN-IP-PSTN)

1)
Event 1: The calling PSTN user hooks off and dials the called number. An Initial
Address Message (IAM) is sent to MGC through Signaling Gateway (SG) A
controlled by SoftX3000 A.
Upon receipt of the IAM from SG A, SoftX3000 A encapsulates the IAM into the
message body (SDP) of an INVITE message and sends it to SoftX3000 B to invite
SoftX3000 B to participate in a session. The session description of the INVITE
message carries SG As IP address (191.169.200.188), port number (30014),
supported payload type, encoding information matching the payload type to SoftX3000
B.
2)
Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A, notifying

SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing
the request.
3)
Event 3: The called PSTN user receives the ringing tone. Meanwhile, SG B sends
an Address Complete Message (ACM) to SoftX3000 B. Upon receipt of the ACM,
SoftX3000 B encapsulates the ACM in a 180 Ringing response message and
sends it to SoftX3000 A. The session description of the 180 Ringing message
carries SG Bs IP address (191.169.150.1), port number (13304), supported
payload type, encoding information matching the payload type to SoftX3000 A.
Upon receipt of the 180 Ringing message, SoftX3000 A extracts the ACM from the 180
Ringing message and transfers the extracted ACM to SG A. SG A receives the ACM,
and meanwhile the calling PSTN user receives the ringback tone.
3-40

4)
Chapter 3 SIP
Event 4: The called PSTN user hooks off. SG B sends an Answer Message (ANM)
to SoftX3000 B. Upon receipt of the ANM, SoftX3000 B encapsulates the ANM to
the message body (SDP) of a 200 OK response message and sends it to
SoftX3000 A.
Upon receipt of the 200 OK message, SoftX3000 A extracts the ANM from the 200 OK
message and transfers the extracted ANM to SG A.
5)
Event 5: SoftX3000 A sends an ACK message to SoftX3000 B, acknowledging the

receipt of the final response to the INVITE request from SoftX3000 B.
Now, a bi-directional signaling channel is set up between the calling and called parties
for them to make a conversation.
6)
Event 6: The calling PSTN user hooks on. SG A sends a Release (REL) message
to SoftX3000 A. Upon receipt of the REL message, SoftX3000 A encapsulates the
REL in the message body (SDP) of a BYE request message and sends it to
SoftX3000 B.
Upon receipt of the BYE message, SoftX3000 B extracts the REL from the BYE
message and transfers the extracted REL to SG B.
7)
Event 7: Upon receipt of the REL message, SG B knows that the calling PSTN
user has hooked on, and then transfers the REL to the associated PSTN switch.
The PSTN switch receives the message and sends the busy tone to the called
PSTN user. The called PSTN user hooks on. SG B sends a Release Complete
Message (RLC) to SoftX3000 B. Upon receipt of the RLC, SoftX3000 B
encapsulates the RLC to the message body (SDP) of a 200 OK response
message and sends it to SoftX3000 A.
Upon receipt of the 200 OK response, SoftX3000 A extracts the RLC from the 200 OK
response and transfers the extracted RLC to SG A.
3-41
Signaling & Protocols Technical Manual

Chapter 4 H.323
Chapter 4 H.323
4.1 Overview of H.323
4.1.1 What is H.323
H.323 is an ITU-T Recommendation which covers the technical requirements for
multimedia communications systems in a packet based network (PBN). H.323 entities
(call control for instance) might be used in point-to-point sessions and multipoint
conferences. The latest version of H.323 is Version 4 (V4).
H.323 describes the components of an H.323 system, including gateway (GW)
between switched circuit network (SCN) and PBN, gatekeeper (GK) for address
translation and access control, multipoint controller (MC) for controlling participation of
terminals in multipoint conferences, multipoint processor (MP) for the centralized
processing of audio, video, and/or data streams in a multipoint conference, and
multipoint control unit (MCU) for providing the capability for terminals and gateways to
participate multipoint conferences.
4.1.2 Definition of Terms

I. AAA
AAA stands for authentication, authorization, and accounting. Authentication is the
process of checking whether the user has certain permission. Authorization is the
process of granting the permission to the user, and allowing the user to access certain
network resources. Accounting is the process of recording information when the
subscriber is using a certain service. Such information is used to generate bills.
II. H.323 entity

An H.323 entity is any H.323 component, including terminals, gateways, gatekeepers,
MCs, MPs, and MCUs. Terminals, gateways and MCU are known as endpoints. An
endpoint can generate and terminate calls. It can generate and terminates media
streams.
III. H.323 terminal

An H.323 terminal is an endpoint on the network which provides real-time, two-way
communications with another H.323 terminal, gateway, or MCU. It can be integrated in
4-1

Chapter 4 H.323
a personal computer, or can be an independent device, such as Ethernet-phone or

video phone.
An H.323 entity interacts with an end user directly. It can call and be called. It can also
process media streams.
IV. Gatekeeper
The gatekeeper (GK) is an H.323 entity on the network that manages the H.323
terminals, gateways, and MCUs in a zone. A zone includes at least one terminal, and
may or may not include GWs or MCUs. A zone has one and only one GK.
The GK provides the following services and features for the H.323 endpoints:
z
Access control: Permitting the use of network resources after identity check.
Address translation: Translating between alias and network address.
Bandwidth management: Applying for initial bandwidth; controlling bandwidth

variation.
Charging management: Providing basic charging data to the billing center.
Zone management: Managing terminals, GWs and MCUs in the zone.
Call control: Providing supplementary services.
V. Gateway
An H.323 Gateway (GW) is an endpoint on the network which provides for real-time,
two-way communications between H.323 terminals on PBN and other ITU Terminals on
an SCN or to another H.323 gateway. Conceptually, a GW performs conversions of
media streams and signaling. The latter means that the GW serves as a terminal to
convert the between user signaling and H.323 control signaling. If the GW connects two
different networks, PBN and SCN for instance, it needs to convert between H.323
control signaling and signaling of the other type of network.
An H.323 GW interconnects different types of network, converts the format and content
of signaling messages, and also the communication protocol procedures and media
stream format.
VI. Multipoint conference

The components of multipoint conference are MC, MP, and MCU. They all serve for
conferencing purpose.
The multipoint controller (MC) provides for the control of three or more terminals
participating in a multipoint conference. The MC provides for capability negotiation with
all terminals to achieve common levels of communications. It may also control
conference resources such as who is multicasting video. When a terminal joins or
leaves the conference, the MC will adjust the capability set sent to all terminals.
4-2

Chapter 4 H.323
The multipoint processor (MP) processes the audio, video, and data streams in a
multipoint conference, and returns the processed streams to each terminal. Therefore,
the MP can implement the codec algorithms of all types of media streams.
The MC and MP are functional entities rather than physical ones.
The multipoint control unit (MCU) is an endpoint on the network which provides the
capability for three or more terminals and GW to participate in a multipoint conference.
It controls and manages the multipoint conference and all attended terminals, and
performs mixing or switching of audio, video and data. The MCU consists of two parts:
a mandatory MC and optional MPs.
There are two types of multipoint conferences:
z
Centralized multipoint conference
A centralized multipoint conference is one in which all participating terminals

communicate in a point-to-point fashion with an MCU. The terminals transmit their
control, audio, video, and/or data streams to the MCU. The MC within the MCU
centrally manages the conference. The MP within the MCU processes the audio, video,
and/or data streams, and returns the processed streams to each terminal. Figure 4-1
shows a typical networking model of centralized multipoint conference.
Terminal B
Terminal A
MCU
Terminal C
Figure 4-1 A networking model of centralized multipoint conference

z
Decentralized multipoint conference
A decentralized multipoint conference is one in which the participating terminals

multicast or multi-unicast their audio and video to all other participating terminals
without using an MCU. The MCU manages the control messages and data messages
only. Figure 4-2 shows a typical networking model of decentralized multipoint
conference.
4-3

Chapter 4 H.323
Terminal B
Terminal A
MCU
Terminal C
Figure 4-2 A networking model of decentralized multipoint conference

z
Hybrid multipoint conference
A hybrid multipoint conference is a mixture of centralized and decentralized multipoint

conference. Figure 4-3 shows a typical networking model of hybrid multipoint
conference.
Terminal D
Terminal E
MCU
Terminal A
Terminal B Terminal C
Terminal F
Figure 4-3 A networking model of hybrid multipoint conference
VII. Radius
Radius stands for Remote Authentication Dial-In User Service. It is an AAA protocol
widely in use. Radius specifies the format of the authentication, authorization and
accounting messages interacting at Radius server and client.
4.1.3 Structure of H.323 Protocol Stack

Figure 4-4 shows the structure of H.323 protocol stack. The three layers at the bottom
of the stack are bottom-layer protocols of PBN. In LAN, the physical layer is MAC-IPX.
In IP network, the network layer is IP. There are two types of transport-layer protocols.
One is unreliable transmission protocol like User Data Protocol (UDP), which transmits
audio-visual signals in real time, and sends registration messages to GK. The other is
reliable transmission protocol like Transmission Control Protocol (TCP), which
transmits data signals, call signaling and media control messages.
4-4

A/V
Application
Chapter 4 H.323
Terminal Control and Management
Data
Application
Conference Manager
T.125
G.7xx H.26x
RTCP
RTP
Terminal to
Gatekeeper
Signaling
(RAS)
H.225.0 Call
Signaling
Unreliable Transport (UDP)
H.245
TPKT
T.124
T.123
Reliable Transport (TCP)
Network Layer (IP)

Link Layer
Physical Layer
Figure 4-4 H.323 protocol stack

The H.323 protocol processing software includes the following parts:
z
All H.323 terminals shall have an audio codec. All H.323 terminals shall be
capable of encoding and decoding speech according to Recommendation G.711.
G.711 for PCM is mandatory and other G series Recommendations are optional.
The most frequently-used Recommendations in IP telephony are G.729A and
G.723.1.
H.260 Recommendation series, such as H.261 and H.263 specify the video
codec.
The real-time audio and video encoded signals are all encapsulated in Real-time
Transport Protocol (RTP) packets to provide timing information and datagram
serial number for the receiving end to re-organize the signal. RTCP (Real-time
Transport Control Real-time Transport Control Protocol (RTCP) is a part of RTP,
and provides QoS monitoring feature.
Recommendation T.120 is the default basis of data interoperability in multimedia

conferences.
H.225.0 is the core of H.323 protocol stack. It defines call signaling protocols and
media stream packetization for packet-based multimedia communication systems.
H.225.0 serves for call control. The principal function of H.225 is to establish call
connections and H.245 control channel between H.323 endpoints before starting a
call. H.225.0 also covers two other features: specifying the use of RTP/RTCP for
media stream packetization and synchronization; defining RAS.
RAS, which stands for Registration, Admission and Status, specifies a type of
message used between endpoint and GK. The RAS signaling function uses
4-5

Chapter 4 H.323
H.225.0 messages to perform registration, admissions, bandwidth changes,

status, and disengage procedures between endpoints and GKs.
z
Recommendation H.225.0 is drafted based on Q.931 and Q.932. ITU-T

Recommendation Q.931 is ISDN user-network interface layer-3 specification for
basic call control.
Recommendation H.245 is the control protocol for multimedia communication. It is

designed for conference communication. H.245 is the control protocol in H.323
stack, and controls the establishment, maintenance and release of channels.
RAS, H.225.0 and H.245 are used in SoftX3000. The network protocol is IP, and
the transport protocol is UDP and TCP. RAS is borne over UDP; while H.225.0
and H.245 are borne over TCP.
RAS, H.225.0 and H.245 will be detailed in the following sections.
4.1.4 H.323 Applications in SoftX3000

SoftX3000 implements multimedia communication services in H.323. Figure 4-5 shows
the H.323 applications in SoftX3000. SoftX3000 provides two H.323 interfaces.
1)
One is called SoftX3000 H.323 domain, which is the interface of H.323 terminals
under direct control of SoftX3000. SoftX3000 can serve as an H.323 GW and an
H.323 GK at the same time.
2)
The other is called H.323 domain, which interfaces the external H.323 network.
SoftX3000 serves as an H.323 GW.
H.323
GK
H.323
Terminal
SoftX
SoftX H.323 Domain
H.323
GK+GW
H.323 Domain
H.323
GW
Other Networks
H.323
GW
Figure 4-5 H.323 Applications in SoftX3000
4-6
H.323
Terminal

Chapter 4 H.323
I. SoftX3000 H.323 domain

z
SoftX3000 services as an H.323 GK in the domain. All H.323 terminals in the

domain must register at SoftX3000 before using any services provided by
SoftX3000.
SoftX3000 serves as an H.323 GW, and provides SIP, ISUP and MGCP interfaces
to other networks.
The H.323 interfaces support signaling and protocol of RAS, Q.931 and H.245.
SoftX3000 verifies the username and password retrieved from the H.323 terminal.
II. H.323 domain

z
SoftX3000, as an H.323 GW, must register at an external H.323 GK before using

the services provided in the H.323 domain.
The H.323 interfaces support signaling and protocol of RAS, Q.931 and H.245.
SoftX3000 registers the addresses of all terminals connecting through itself to the
external GK, including all H.323 terminals in the domain.
4.2 RAS Protocol

4.2.1 Overview of RAS
RAS is a part of H.225.0, which is used between endpoint and GK, and implements
management function. It includes the following seven categories of procedures:
I. GK discovery
An endpoint uses multicast mode to discover the homed GK. Afterwards, all RAS
messages will be transmitted between the endpoint and its homed GK.
II. Terminal and GW registration

It is used by an endpoint to register its information with the GK, including alias and
transmission layer address of call control channel. This procedure also includes
deregistration procedure.
III. Location request

It is used by endpoint or GK to request from corresponding GK the transmission layer
address of the call control channel of a certain endpoint.
IV. Terminal to GK admission

It is the first operation when a call is initiated, to request the GK whether the call can be
originated.
4-7

Chapter 4 H.323
V. Disengage
After a call is over, this procedure is used to notify the GK that the endpoint exits the call
and resumes free.
VI. Terminal to GK requests for changes in bandwidth

During a call, the endpoint can request to GK for changes in bandwidth, and the GK
determines whether to change.
VII. Status request

It is used by GK to request the power on/off status of terminal.
VIII. GW resource availability

It is used to report the available resources of a gateway to the GK.
4.2.2 RAS Messages

I. RAS message abbreviations
Table 4-1 Terminal and GK discovery messages
Message name
Message description
Message type
GRQ
Gatekeeper Request
Request
GCF
Gatekeeper Confirm
Response
GRJ
Gatekeeper Reject
Response
Table 4-2 Terminal and GW registration messages

Message name
Message description
Message type
RRQ
Registration Request
Request
RCF
Registration Confirm
Response
RRJ
Registration Reject
Response
Table 4-3 Terminal/GK unregistration messages

Message name
Message description
Message type
URQ
Unregistration Request
Request
UCF
Unregistration Confirm
Response
4-8

Message name
URJ
Chapter 4 H.323
Message description
Unregistration Reject
Message type
Response
Table 4-4 Terminal to GK admission messages

Message name
Message description
Message type
ARQ
Admission Request
Request
ACF
Admission Confirm
Response
ARJ
Admission Reject
Response
Table 4-5 Location request messages

Message name
Message description
Message type
LRQ
Location Request
Request
LCF
Location Confirm
Response
LRJ
Location Reject
Response
Table 4-6 Disengage messages

Message name
Message description
Message type
DRQ
Disengage Request
Request
DCF
Disengage Confirm
Response
DRJ
Disengage Reject
Response
Table 4-7 Status request messages

Message name
Message description
Message type
IRQ
Info Request
Request
IRR
Info Request Response
Response
IACK
Info Acknowledgement
Response
INAK
Information Negative Acknowledgement
Response
4-9

Chapter 4 H.323
Table 4-8 Terminal to gatekeeper requests for changes in bandwidth

Message name
Message description
Message type
BRQ
Bandwidth Request
Request
BCF
Bandwidth Confirm
Response
BRJ
Bandwidth Reject
Response
Table 4-9 GW resource availability messages

Message name
Message description
Message type
RAI
Resource Availability Indication
Request
RAC
Resource Availability Confirmation
Response
II. RAS message format

A RAS message is in text format, and consists of message name and some mandatory
and optional parameters. These parameters vary in different messages. Figure 4-6
illustrates a generic architecture of RAS message.
ITU-T Recommendation H.225.0
Message name
Parameter 1
Parameter 2
Figure 4-6 Generic architecture of RAS message
III. RAS common message elements

This section describes ASN.1 structures that are used in more than one RAS
messages.
1)
RequestSeqNum
All RAS messages include requestSeqNum. It is assigned by the request party and
increments by 1. Any associated response messages (success or failure) shall have
the corresponding requestSeqNum returned with it. Retransmitted messages shall
have the same requestSeqNum. For instance, GRQ message and the triggered GCF
or GRJ share the same requestSeqNum.
4-10

2)
Chapter 4 H.323
ProtocolIdentifier
The protocolIdentifier determines the vintage of the implementations involved. It

defines the version number of the H.225 Recommendation used.
3)
NonStandardData
It carries the non-standard information such as proprietary data that is not defined in
H.225 Recommendation.
4)
RasAddress
This is the registration and status transport address for this endpoint. RAS messages
are transmitted on top of UDP in well-known port 1719.
5)
EndpointType
It specifies the type of the endpointterminal, GW or MCU. If the H.323 element has an
MC, then the mc Boolean would be true.
6)
GatekeeperIdentifier
For RAS request messages, it identifies the GK that will respond to the request. If it is
not supplied, the request message is valid to all reachable GKs.
For RAS response messages, it identifies the GK that returns the response message.
7)
CallServices
It provides information on support of optional Q-series protocols to GK and called

terminal.
8)
EndpointAlias
It is a list of alias addresses, by which other terminals may identify this terminal. An
alias address can be an E.164 address or an H.323 identifier. An E.164 address
contains access code and telephone number, the latter of which identifies the GW. An
H.323 identifier is a string of subscriber name, E-mail name or other identifier name.
One endpoint can have multiple alias addresses corresponding to PRQ messages. All
these alias addresses are sent to GK in the PRQ messages, and are translated to the
same transport-layer address.
9)
AlternateEndpoints
When an endpoint calls another or an alias, GK returns a prioritized endpoint as called

party. Alternatively, the GK can also return a sequence of prioritized endpoint
alternatives for rasAddress, endpointType, or endpointAlias. This parameter is used to
improve call connection rate.
10) DiscoveryComplete
It is included in RRQ message. Set to TRUE if the requesting endpoint has preceded
this message with the gatekeeper discovery procedure; set to FALSE if registering only.
11) CallSignalAddress
4-11

Chapter 4 H.323
This is the registration and status transport address for this endpoint. Q.931 messages
are transmitted on top of TCP in well-known port 1720.
12) VendorIdentifier
The VendorIdentifier structure allows a vendor to identify a product. The vendor
element allows identification in terms of country code, extension, and manufacturer
code. productId and versionId are text strings that can provide product information.
For instance:
VendorIdentifier
Vendor
T35CountryCode:82
T35Extension:0
manufacturerCode:2290
productId:Cns H.323v2
versionId:2.0
13) TimeToLive
TimeToLive is a number seconds that a registration is to be considered valid. The
parameter is included in PRQ and PCF messages.
14) KeepAlive
An endpoint can send a lightweight RRQ consisting of only rasAddress, keepAlive,
endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. A gatekeeper in receipt
of RRQ with a keepAlive field set to TRUE should ignore fields other than
endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive.
15) EndpointIdentifier
16) WillRespondToIRR
When it is set to True, the Gatekeeper will send an IACK or INAK message in response
to an unsolicited IRR message with its needsResponse field set to TRUE.
17) RejectReason
It is included in RRJ message, and identifies the reason for the rejection of the
registration.
18) CallType
Using this value, called party's GK can attempt to determine 'real' bandwidth usage.
The default value is pointToPoint for all calls.
19) CallModel
H.323 Recommendation defines two transmission models for end-to-end (E2E) call
signaling. When the callModel is gatekeeperRouted, the endpoint is requesting the
GK mediated model. Either end knows the address of the other end, thus protecting the
privacy of subscribers. The GK participates in the call signaling procedure. When the
callModel is direct, the endpoint is requesting the direct terminal to terminal call model.
4-12

Chapter 4 H.323
After GK provides the transport-layer address of the called party, it no longer involves in
the call signaling procedure.
20) EndpointIdentifier
It is a GK-assigned terminal identity string, such as E.164 addresses or H323_IDs.
21) DestCallSignalAddress
It is the translated call signaling transport address of destination terminal or GK itself. It
includes IP address and port number of Q.931 messages.
22) SrcInfo
It is a sequence of alias addresses for the source endpoint, such as E.164 addresses or
H323_IDs.
23) SrcCallSignalAddress
It is the transport address used at the source for call signaling.
24) BandWidth
The parameter is used by GK to control the number of H.323 terminals accessing PBN
at the same time. The GK can reject a call when there is not enough bandwidth to
support the call.
In ARQ and ACF messages, BandWidth is the number of 100 bits requested for the
bidirectional call. For example, a 128 kbit/s call would be signalled as a request for 256
kbit/s. The bandwidth defined by GK in ACF can be less than the one defined in ARQ.
25) CallReferenceValue (CRV)
It is the CRV cited from Q.931. The call reference value is chosen at the side originating
the call and has to be locally unique. This is used by a GK to associate the ARQ with a
particular call. For instance: The call model in gatekeeperRouted, CRV at the two
signaling segmentsource terminal-GK and GK-destination terminalare different.
GK establishes the association between two CRVs, and ensures accurate transmission
of signaling messages. Nevertheless, in the same signaling segment, all H.225.0
messages of a particular call, such as call admission, call establishment,
supplementary service, bandwidth change, and call termination share the same CRV.
26) ConferenceID
It is the unique identification of the conference to which the call belongs. CID consists of
three partsendpoint network address, conference initiation time and protocol version.
Each call of a particular conference has its own call ID. All calls shares the same
conferenceID, which is adopted for all H.225.0 messages in the conference.
27) Call ID
It identifies a call. Unlike CRV, the call ID is a global parameter. In other words, from
source endpoint to GK, from source endpoint to destination endpoint, and from
destination endpoint to GK, all RAS messages and call signaling messages of a
particular call share the same call ID. The call ID serves for E2E message transmission.
4-13

Chapter 4 H.323
It can be encapsulated and transmitted in the Q.931 user-to-user messages. It can be

used in supplementary services. The call ID is assigned by the source endpoint.
28) ActiveMC
It defines whether the source endpoint has an active MC.
29) AnswerCall
If the answerCall flag is TRUE then the GK has pre-granted permission to the endpoint
to answer calls without first sending an ARQ. If the answerCall flag is FALSE, the
endpoint shall always send ARQ to get permission to answer a call.
30) WillSupplyUUIEs
If it is set to TRUE, it indicates that the endpoint will supply Q.931 message information
in IRR messages if requested by the Gk.
IV. A typical example of RAS message

This is an example of RRQ message.
registrationRequest
requestSeqNum: 969
protocolIdentifier: 0.0.8.2250.0.3
discoveryComplete: True
callSignalAddress (TransportAddress)
Item 0 (ipAddress)
ipAddress
ip: 191.169.200.31 (191.169.200.31)
port: 1720
rasAddress (TransportAddress)
Item 0 (ipAddress)
ipAddress
ip: 191.169.200.31 (191.169.200.31)
port: 1719
terminalType (EndpointType)
terminal (TerminalInfo)
mc: False
undefinedNode: False
terminalAlias (AliasAddress)
Item 0 (h323_ID)
h323_ID: 666302
Item 1 (e164)
e164: 666302
endpointVendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 82
4-14

Chapter 4 H.323
t35Extension: 0
manufacturerCode: 2290
productId: CnS H.323v2
versionId: 2.0
timeToLive: 3600
keepAlive: True
endpointIdentifier: 24-3
Line 1 indicates that the message is RRQ.

Line 2 indicates that the request sequence number is 969. The requestSeqNum is the
same as the ones in the response messages RCF and RRJ, and is used to associate
RRQ, RCF and RRJ.
Line 3 is protocolIdentifier, which defines the version number of the H.225
Recommendation used.
Line 4 is discoveryComplete, which is included in RRQ only. It is set to TRUE, which
indicates that the requesting endpoint has preceded this message with the GK
discovery procedure;
Line 5 to line 9 list the information of the endpoint that is transmitting Q.931 messages.
IP address: 191.169.200.31; port number: 1720.
Line 10 to line 14 list the information of the endpoint that is transmitting RAS messages.
IP address: 191.169.200.31; port number: 1719.
Line 15 to line 18 specify the type of the endpoint that is registering. In this example, it is
an H.323 terminal.
Line 19 to 23 are content of the terminalAlias. It can be an E.164 address or an H.323
identifier. Here, the E.164 address is a telephone number 666302, and the H.323
identifier is also 666302.
Line 24 to 30 specify information about the endpoint vendor. Here, the country code is
82, extension is 0 and manufacturer code is 2290. productId and versionId are text
strings that can provide product information.
Line 31 indicates that the registration is valid for 3600 seconds.
Line 32 has the following implications. An endpoint can send a lightweight RRQ
consisting of only rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier,
tokens and timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to
TRUE should ignore fields other than endpointIdentifier, gatekeeperIdentifier, tokens
and timeToLive. Therefore, keepAlive is set to False in the first RRQ message, and
True for all the subsequent ones.
Line 32 is endpointIdentifier.
4-15

Chapter 4 H.323
4.2.3 Basic Procedures

I. Overview of basic procedures
This section introduces three procedures:
z
GK discovery
Terminal registration and unregistration
Terminal to GK admission and disengagement
Each procedure is explained with a generic example of several events. Each process
step represents an individual event.
II. GK discovery
Endpoint
GK
GRQ
GCF
GRJ
Figure 4-7 Message flow diagram of GK discovery procedure

Here is the generic process of a GK discovery procedure:
1)
The
When the endpoint initiates, it sends a GRQ message, searching for GK.
GRQ
message
includes
parameters
endpointType,
rasAddress,
and
gatekeeperIdentifier.
2)
GK analyzes the endpoint information, determines that it is a local endpoint, and

returns a GCF message. Alternatively, GK rejects the registration request of the
endpoint, and returns a GRJ message with cause of rejection.
III. Terminal registration and unregistration

An endpont must register itself in the GK discovery procedure before it can start and
receive calls. The registration of endpoint to the GK includes the former under the
control of the latter.
4-16

Endpoint
Chapter 4 H.323
GK
ARQ
ACF
ARJ
DRQ
DCF
DRJ
Figure 4-8 Message flow diagram of terminal registration and unregistration

Here is the generic process of a terminal registration and unregistration procedure:
1)
The endpoint sends a RRQ message to the RAS address of GK. The RRQ
message
includes
two
important
parameters:
endpontAlias
and
callSignalAddress.
2)
The GK analyzes the endpoint information, determines that it is a local endpoint,

and returns a GCF message. The endpoint then informs the GK of its call signaling
transport
address.
The
GK
will
then
record
the
endpointAlias
and
callSignalAddress in translation table. When the GK finds that the endpoint is not a
locla one, it returns an RRJ message to reject the call.
3)
When the endpoint is to end the service, or change the mapping relation between
alias and address, it sends a URQ message to GK and requests for unregistration.
4)
In normal cases, GK returns a URF message for confirmation. When GK finds no

registration information of the endpoint, it returns a URJ message.
IV. Terminal to GK admission and disengagement

ARQ/ACF and DRQ/DCF are the first and last pair of messages in the whole call control
procedure. The first pair indicates the start and the last pair indicates the end of the call.
4-17

Endpoint
Chapter 4 H.323
GK
ARQ
ACF
ARJ
DRQ
DCF
DRJ
Figure 4-9 Message flow diagram of terminal to GK admission and disengagement

1)
When the endpoints initiates a call, it sends an ARQ message to GK for

authentication and address resolution. In the ARQ message, the endpoint
specifies the destination information and required bandwidth.
2)
If the GK admits the call, it returns an ACF message. The ACF message includes
two key parametersbandWidth which specifies the allowed maximum bandwidth
for the call, and destCallSignalAddress, which might be an endpoint or GK
address depending on the call model in use. Alternatively, the GK rejects the call
with an ARJ message.
3)
When the call completes, the endpoint sends a DRQ message to the GK,
requesting to disengage the call.
4)
In normal cases, GK returns a DCF message for confirmation. If the GK refuses

the request, it returns a DRJ message.
4.3 H.225.0 Call Signaling Protocols

4.3.1 Overview of H.225.0
Recommendation H.225.0 is drafted based on Q.931 and Q.932. Recommendation
Q.931 is ISDN user-network interface layer-3 specification for basic call control.
Recommendation Q.932 specifies the generic procedures for the control of ISDN
supplementary services.
4-18

Chapter 4 H.323
4.3.2 H.225.0 Messages

I. Overview of H.225.0 messages
H.225.0 basic call control messages are borrowed from Q.931 and Q.932. The former
provides a greater share. As H.225.0 call signaling messages contain no call
connection information, many Q.931 and Q.932 messages are thereby simplified here.
Here, we will focus on H.225.0 call signaling messages only.
II. Call establishment messages

Table 4-10 Description of call establishment messages
Message name
Meaning
Setup
To initiate call establishment.
Setup Acknowledge
To indicate that call establishment has been initiated, and request for
subsequent address information.
Call Proceeding
To respond to Setup message, and indicate that requested access

connection establishment has been initiated, and called number is complete.
Alerting
To indicate that the called subscriber alerting has been initiated.
Connect
To indicate acceptance of the access connection.
Progress
To indicate the progress of an access connection establishment in the event

of interworking within a private network.
III. Call clearing messages

Table 4-11 Description of call clearing messages
Message name
Release Complete
Meaning
To indicate that the equipment sending the message has released the
channel (if any) and call reference (CR).
IV. Miscellaneous messages

Table 4-12 Description of call miscellaneous messages
Message name
Meaning
Information
To provide additional information, such as subsequent called address.
Notify
To indicate information pertaining to a call, such as call suspension and

resume.
4-19

Chapter 4 H.323
Message name
Meaning
Status Enquiry
To solicit a STATUS message from the peer layer-3 entity.
Status
To respond to the STATUS ENQUIRY message, or at any time during a call

to report certain error conditions.
Facility
To convey supplementary service information to the network.
User Information
To transfer information to a remote subscriber, or to send to the subscriber to

deliver information from the other subscriber.
V. Q.932 messages
Message name
User Information
Meaning
To transfer information to a remote subscriber, or to send to the subscriber to
deliver information from the other subscriber.
4.3.3 Message Format

I. Overview of message format
Figure 4-10 illustrates the generic format of a Q.931 message.
Protocol discriminator
Length of call reference
Header
Call reference value

Message type
Flag
Content
Single-byte IE
Flag
Information element
Length
Information element
Msg units
(mandatory or
optional)
Content
Multi-byte IE
Figure 4-10 Generic architecture of Q.931 message
4-20

Chapter 4 H.323
II. Protocol descriminator

It is set to Q.931.
III. Length of call reference

When the length of call reference is set to zero, the CRV is a virtual call reference,
meaning that it is irrelevant to any call, and is used for supplementary services.
IV. Call reference value

This parameter is used to identify a call, and it is only valid in part of the call segment.
For instance: The call model in gatekeeperRouted, CRV at the two signaling
segmentssource terminal-GK and GK-destination terminalare different. GK
establishes the association between two CRVs, and ensures accurate transmission of
signaling messages. The CRV is generally used to associate multiple calls in
three-party service or multi-party service.
V. Message type
Its value is coded by Q.931, as described in Section 4.3.2.1.
4.3.4 Information Elements

I. Bearer capability
It is a mandatory information element (IE) in H.225.0, though less significant as
specified in Q.931. If this information element is received in a call between two H.323
terminals, it may be ignored by the receiver. If this information element appears in a
Setup message for a call-independent signaling connection as defined in
Recommendation H.450.1, the coding shall follow 7.2/H.450.1, which will not be
elaborated here. H.225.0 specifies bearer capability as follows:
Information transfer capability
For calls originating from an ISDN endpoint the information indicated to the gateway
shall be forwarded. This is to allow some advance information about the nature of the
connection to be forwarded to the H.323 endpoint, for example, voice only vs. data vs.
video; this would have an impact on the bandwidth required as well as on the
ability/willingness to accept the call or not.
Calls that originate from an H.323 endpoint shall use this field to indicate their wish to
place an audiovisual call. For audiovisual call, the field shall be set either to
'unrestricted digital information'. If a speech only call is to be placed, the H.323 terminal
shall set the information transfer capability to either 'speech' or to '3.1 kHz audio'.
4-21

Chapter 4 H.323
Rate multiplier
The segment shall be present if information transfer rate is set to 'multirate'. For a call
originating from an ISDN endpoint, the gateway shall simply pass on the information
that it receives from the ISDN. For a call originated from an H.323 endpoint, this shall
be used to indicate the bandwidth to be used for this call on the SCN side. If a gateway
is involved, this value shall reflect the number of external connections to be set up.
Layer 1 protocol
It is set to G.711 to indicate a voice-only call and H.221 and H.242 to indicate an H.323
videophone call.
II. Display
The network will send American Standard Code for Information Interchange (ASCII) to
subscriber to be displayed.
III. Called party number and calling party number

The calling party number is used for charging and caller number display.
The called party number is used for routing.
If the numbering plan identification is set to Private Numbering Plan in a PBN
originated call, this indicates that the E.164 address is not present in Setup message;
and the call will be routed by an alias address in the user-to-user information.
IV. Cause
It indicates the generation of the message for future diagnosis. The Cause is
mandatory in Release Complete, but optional elsewhere. The Cause information
element and the ReleaseCompleteReason (a part of the Release Complete message)
are
mutually
exclusive.
The
Cause
is
borrowed
from
Q.931,
while
ReleaseCompleteReason is for PBN.

Gateways shall map from a ReleaseCompleteReason to the Cause IE when sending a
Release Complete message to the SCN side from the PBN side. Table 4-1 shows the
mapping between the Cause IE and ReleaseCompleteReason.
Table 4-13 Mapping between the Cause IE and ReleaseCompleteReason
ReleaseCompleteReason code
Corresponding Q.931 cause value
noBandwidth
34 No circuit/channel available
gatekeeperResources
47 Resource Unavailable
unreachableDestination
3 No route to destination
4-22

Chapter 4 H.323
ReleaseCompleteReason code
Corresponding Q.931 cause value
destinationRejection
16 Normal call clearing
invalidRevision
88 Incompatible destination
noPermission
111 Protocol error, unspecified
unreachableGatekeeper
38 Network out of order
gatewayResources
42 Switching equipment congestion
badFormatAddress
28 Invalid number format
adaptiveBusy
41 Temporary Failure
inConf
17 User busy
undefinedReason
31 Normal, unspecified
The reverse mapping is not required as packet-based network entities are required to
decode the Cause IE.
V. User-User Information Element

User-User Information Element (UUIE) is the most significant IE in H.225.0 call
signaling. It shall be used by all H.323 entities to convey H.323-specific call control
information in addition to normal E2E subscriber data. The call control information is the
essence of H.323 call signaling system, and represents the call signaling capability of
the entire H.323 system. UUIE is indispensable for messages such as Setup, Alerting,
CallProceeding, Connect, Release Complete, Facility, and User Information.
Figure 4-11 shows the format of UUIE.
UUIE discriminator
UUIE length
Protocol identifier (ASN.1)
H323-UU-pdu (Mandatory)
User data (Optional)
Figure 4-11 Format of UUIE

The protocol discriminator is changed to ASN.1. It means that the user information is
changed from IA5 of Q.932 to a generic ASN.1.
4-23

Chapter 4 H.323
The user information contains two parts. The body part is h323-UU-pdu, containing the
UUIE contents of related messages, that is, the signaling information of H323. The
optional part is the user data transmitted between terminals, and the data is IA5
character string, whose maximum length is 131 bytes. It is equivalent to user-user
information defined in Q.932, but it is encapsulated in UUIE data structure defined by
ASN.1. As an element in the data sequence, it is called user data.
H.225.0 defines the contents of h323-UU-pdu in UUIE of each related message. For
example, the UUIE of Connect message contains the following contents:
z
Protocol identifier It is set by the called endpoint as the version number of H.225
protocol supported by the endpoint.
H.245 address: It is the transmission layer address of H.245 control channel of

called endpoint or GK. According to this address, the calling endpoint can
establish the H.245 control channel to the called endpoint or GK, and then
establish the required media channel. This is the major purpose of H.225.0 call.
This parameter can also be transmitted by UUIE of Alerting message or Call
Processing message.
Destination information: It is used to indicate the endpoint type, making the calling
endpoint able to determine whether the call is related to gateway.
Conference identifier: It is the conference identifier carried in Setup message.
Call identifier: It is set by calling endpoint.
4.3.5 A typical example of Q.931 message

This is an example of Setup message.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 6FD1
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Packet mode
Information transfer rate: Packet mode
User information layer 1 protocol: Recommendation H.221 and H.242
Display
Information element: Display
Length: 7
Display information: 7670000
Calling party number
4-24

Chapter 4 H.323
Information element: Calling party number

Length: 8
Type of number: Unknown
Numbering plan: E.164 ISDN/telephony numbering
Number: 7670000
Called party number
Information element: Called party number
Length: 8
Number: 7670001
User-user
Information element: User-user
Length: 126
Protocol discriminator: X.208 and X.209 coded user information
h323_uu_pdu (H323-UU-PDU)
h323_message_body (setup)
setup
sourceAddress (AliasAddress)
Item 0 (e164)
e164: 7670000
Item 1 (h323_ID)
h323_ID: 7670000
sourceInfo (EndpointType)
vendor (VendorIdentifier)
t35CountryCode: 82
t35Extension: 0
versionId: 2.0
mc: False
destinationAddress (AliasAddress)
Item 0 (e164)
e164: 7670001
activeMC: False
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
conferenceGoal (create)
4-25

Chapter 4 H.323
create: create
callType (pointToPoint)
pointToPoint: pointToPoint
sourceCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.150.171 (191.169.150.171)
port: 1074
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
mediaWaitForConnect: False
canOverlapSend: False
h245Tunneling: False
Line 1 indicates that the message is a Q.931 message.

Line 2 is protocol descriminator. Now, it is set to Q.931.
Line 3 defines the length of call reference value. It is set to 2 bytes.
Line 4 is call reference value. It is 6FD1.
Line 5 is message type. Now, it is Setup.
Line 6 to line 15 means that the caller is an H.323 endpoint, and the information
transfer capability is Unrestricted digital information. It implies that the caller is about
to make a video call. Layer 1 protocol is set to H.221/H.242, which means that the call
is an H.323 video call.
Line 16 to line 19 The network will send American Standard Code for Information
Interchange (ASCII) to subscriber to be displayed.
Line 20 to 25 The calling party number: used for charging and caller number display.
Line 26 to 31 The called party number: used for routing.
Line 32 to 33 indicates the following is UUIE.
Line 34 indicates that the UUIE length is 126 bytes.
Line 35 protocol discriminator.
Line 36 to end The UUIE contents in the Setup message. The UUIE contains the
following contents:
sourceAddress (AliasAddress): It can be an E.164 address or an H.323 identifier. Here,
the E.164 address is a telephone number 7670000, and the H.323 identifier is also
7670000.
4-26

Chapter 4 H.323
sourceInfo (EndpointType): Here, the country code is 82, extension is 0 and

manufacturer code is 2290. productId and versionId are text strings that can provide
product information.
destinationAddress (AliasAddress): It can be an E.164 address or an H.323 identifier.
Here, the E.164 address is a telephone number 7670001, and there is no H.323
identifier.
callType (pointToPoint): Using this value, called party's GK can attempt to determine
'real' bandwidth usage. Here, it is an end-to-end call.
sourceCallSignalAddress (ipAddress): It is the transmission layer address (IP address
plus TCP port number) of cal signaling channel of local endpoint. Here, the IP address
is 191.169.200.31, and the port number is 1074.
callIdentifier: the call identifier is 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4.

I. Overview of basic procedures
This section takes the example that two endpoints register with the same GK, and
describes the signaling procedures in two message transmission modes, for the
purpose of detailing the call control procedure of H.323 system.
II. Basic call setup procedure (direct routing mode)

Figure 4-12 shows the signaling procedure, and follows brief description.
Endpoint 1
GK
ARQ
ACF
Endpoint 2
Setup
4 Call proceeding
Alerting
Connect
ARQ
ACF
RAS message
Cal signaling message
Figure 4-12 Signaling procedure (direct routing) of public GK

1)
Scenario 1: Endpoint 1 (calling party) sends ARQ message to its GK through RAS
channel, to request the GK to originate a call to endpoint 2.
4-27

2)
Chapter 4 H.323
Scenario 2: The GK agrees to accept the call. It translates the transmission layer
address (IP address plus TCP port number) of call signaling channel of endpoint 2,
and the sends the address in ACF message to endpoint 1.
3)
Scenario 3: Endpoint 1 establishes call signaling channel to endpoint 2, and sends

Setup message through the channel. If the ARQ has CRV, the Setup message
and following signaling messages have the same CRV.
4)
Scenario 4: Endpoint 2 sends back Call Proceeding message, indicating that the
call has been processed. For the call between two H.323 terminals, the messages
except UUIE do not carry other information element. If the call is between H.323
terminal and ISDN terminal, that is, if endpoint 2 is a gateway, endpoint 2 will
transparently transmit the information elements from SCN side, such as bearing
capability and proceeding indicator, to endpoint 1. If endpoint 1 is an H.323
terminal, there is no explanation information. If endpoint 1 is also a gateway, such
information elements will be transmitted to the calling party at SCN side.
5)
Scenario 5: Endpoint 2 sends ARQ to the GK through RAS channel to accept the
call.
6)
Scenario 6: The GK agrees to accept and sends back ACF.
7)
Scenario 7: Endpoint 2 sends back Alerting message to endpoint 1, and waits for
answer by subscriber.
8)
Scenario 8: The subscriber answers the call. Endpoint 2 sends Connect message
to endpoint 1, and the message carries H.245 control channel TCP port number of
endpoint 2. Now , the call is set up.
If the GK does not allow endpoint 2 to accept the call, it will send back ARJ. In this case,
endpoint 2 will send Release Complete message to endpoint 1.
4-28

Chapter 4 H.323
III. Basic call setup procedure (gatekeeper routed mode)

Endpoint 1
GK
ARQ
ACF
Setup
Endpoint 2
Setup
Call proceeding5
6 Call proceeding
ARQ
ACF
Alerting
7
8
9
10 Alerting
Connect 11
12 Connect
RAS message
Call signaling message
Figure 4-13 Signaling procedure (gatekeeper routed) of public GK

Figure 4-13 shows the signaling procedure. The differences from the signaling
procedure in direct routing mode are as follows:
1)
The ACF message sent by the GK to endpoint 1 does not carry transmission layer
address of call signaling channel of endpoint 1. Instead, the ACF message carries
the transmission layer address of call signaling channel of the GK. Meanwhile, the
GK establishes the call signaling channel to endpoint 2.
2)
Afterward, the call signaling messages from endpoint 1 can only be transmitted to
the GK, which transfers the messages to endpoint 2. Because endpoint 2
establishes signaling channel only with the GK, it can only send signaling
messages to the GK, which transfers the messages to endpoint 1.
3)
After the call is set up, endpoint 2 tells the GK the H.245 control channel
transmission layer address in Connect message, but the information in Connect
message sent by the GK to endpoint 1 is up to the transmission mode of H.245
control message. If the GK uses direct routing mode to transmit media control
messages, the messages contain the H.245 control channel address of endpoint 2;
if the GK uses transfer mode, the messages contain the H.245 control channel
address of the GK. In this case, the GK has MC functions.
When either calling party or called party hooks on, a Release Complete message is
sent to the GK, which then sends a Release Complete message to the peer end. Then
TCP connection is disconnected.
4-29

Chapter 4 H.323
4.4 Recommendation H.245

4.4.1 Overview of H.245
Recommendation H.245 is the control protocol for multimedia communication. It is
designed for conference communication. H.245 is the control protocol in H.323 stack,
and controls the establishment, maintenance and release of channels.
In H.245, there are two kinds of channels defined as follows:
1)
Control channel: also called H.245 channel. Through this channel, two H.245 peer
signaling entities in different H.323 entities transmit H.245 messages to control the
establishment and release of media channel. Control channel is a reliable channel,
which corresponds to a TCP connection in IP network, and the numbers of the
connected ports are allocated dynamically. In the H.225.0 call setup procedure,
the calling and called endpoints (or GK) use Setup and Connect messages to
exchange the allocated H.245 port address. After the call is set up, H.245 control
channel is established. Each call has only one H.245 control channel, which exists
during the call and will be released after the call is over.
2)
Communication channel: also called media channel. In H.245, it is defined as

logical channel, used to transmit user communication information. Generally,
there might be multiple logical channels between two entities, and they can be
established or released when necessary. In H.245, establishment is called Open
and release is called Close. Logical channels are opened or closed by H.245, and
each logical channel is assigned with an identifier when opened. Control channel
can be regarded as a special permanent logical channel, whose channel number
is 0.
In H.323, most of logical channels are uni-directional channels, especially those in

conference call. However, T.120 data communication protocol and ordinary
point-to-point telephone communication require bi-directional channel, which is
composed of a pair of uni-directional logical channels occupying two logical channel
numbers. The H.245 OpenLogicalChannel procedure supports uni-directional channel
establishment and bi-directional channel establishment. The logical channels used to
transmit audio and video signals are unreliable channels (such as UDP channels), the
logical channels used to transmit data are reliable channels (such as TCP channel).
Their port numbers are allocated dynamically. Logical channel establishment is actually
that both parties use OLC and OLCA messages to exchange their allocated port
numbers.
Each logical channel use a specific coding algorithm and bandwidth to transmit a
specific kind of media information. In this case, both parties must negotiate these
parameters before a logical channel is established, to determine the acceptable
parameter ranges. This is the capability exchange procedure of H.245. H.245
4-30

Chapter 4 H.323
establishes logical channel according to receiving party controlling principle, and the
sending party determines channel characteristics parameters within the range defined
by receiving party. The purpose of capability exchange procedure is to tell the other end
the receive capability of the local end through proper messages. The message can also
be used to notify send capability, for the purpose of indicating a selection option of the
local end, and providing a condition when the peer end determines its receive capability.
After getting the receive capability of the peer end, the local end determines its send
mode within the range of the peer end, and start the OpenLogicalChannel procedure.
The following describes the control procedure of H.245.
3)
Capability exchange
The capability exchange procedures are intended to ensure that the only multimedia
signals to be transmitted are those that can be received and treated appropriately by
the receive terminal. This requires that the capabilities of each terminal to receive and
decode be known to the other terminal. It is not necessary that a terminal understand or
store all in-coming capabilities; those that are not understood, or can not be used shall
be ignored, and no fault shall be considered to have occurred.
The total capability of a terminal to receive and decode various signals is made known
to the other terminal by transmission of its capability set.
Receive capabilities describe the terminal's ability to receive and process in-coming
media streams. Transmitters shall limit the content of their transmitted information to
that which the receiver has indicated it is capable of receiving. The absence of a
receive capability indicates that the terminal cannot receive (is a transmitter only).
Transmit capabilities describe the terminal's ability to transmit media streams. Transmit
capabilities serve to offer receivers a choice of possible modes of operation, so that the
receiver may request the mode which it prefers to receive. The absence of a transmit
capability indicates that the terminal is not offering a choice of preferred modes to the
receiver (but it may still transmit anything within the capability of the receiver).
These capability sets provide for more than one stream of a given medium type to be
sent simultaneously. For example, a terminal may declare its ability to receive (or send)
two independent H.262 video streams and two independent G.722 audio streams at the
same time. Capability messages have been defined to allow a terminal to indicate that
it does not have fixed capabilities, but that they depend on which other modes are being
used simultaneously. For example, it is possible to indicate that higher resolution video
can be decoded when a simpler audio algorithm is used; or that either two low
resolution video sequences can be decoded or a single high resolution one. It is also
possible to indicate trade-offs between the capability to transmit and the capability to
receive.
Non-standard capabilities and control messages may be issued using the
NonStandardParameter structure. Note that while the meaning of non-standard
4-31

Chapter 4 H.323
messages is defined by individual organizations, equipment built by any manufacturer

may signal any non-standard message, if the meaning is known.
4)
Logical channel signaling procedures
An acknowledged protocol is defined for the opening and closing of logical channels
which carry the audiovisual and data information. The aim of these procedures is to
ensure that a terminal is capable of receiving and decoding the data that will be
transmitted on a logical channel at the time the logical channel is opened rather than at
the time the first data is transmitted on it and to ensure that the receive terminal is ready
to receive and decode the data that will be transmitted on the logical channel before
that transmission starts.
Logical channels should only be opened when there is
sufficient capability to receive data on all open logical channels simultaneously.

A part of this protocol is concerned with the opening of bidirectional channels. To avoid
conflicts which may arise when two terminals initiate similar events simultaneously, one
terminal is defined as the master terminal, and the other as the slave terminal. A
protocol is defined to establish which terminal is the master and which is the slave.
However, systems that use this Recommendation may specify the procedure specified
in this Recommendation or another means of determining which terminal is the master
and which is the slave.
5)
Receive terminal request logical channel closure
A logical channel is opened and closed from the transmitter side. A mechanism is
defined which allows a receive terminal to request the closure of an incoming logical
channel. The transmit terminal may accept or reject the logical channel closure request.
A terminal may, for example, use these procedures to request the closure of an
incoming logical channel which, for whatever reason, cannot be decoded. These
procedures may also be used to request the closure of a bidirectional logical channel
by the terminal that did not open the channel. Note that the receive terminal can only
request, and the closing of a channel is initiated by the transmitter side.
6)
Master-slave determination
Conflicts may arise when two terminals involved in a call initiate similar events
simultaneously and only one such event is possible or desired, for example, when
resources are available for only one occurrence of the event. To resolve such conflicts,
one terminal shall act as a master and the other terminal shall act as a slave terminal.
Rules specify how the master and slave terminal shall respond at times of conflict.
7)
Round-trip delay determination
It may be useful in some applications to have knowledge of the round-trip delay

between a transmit terminal and a receive terminal. A mechanism is provided to
measure this round-trip delay. This mechanism is very simple, only containing two
messages without parameters, delay measure request and response. The delay value
is measured by the requester according to the delay between the request and response.
4-32

Chapter 4 H.323
This mechanism may also be useful as a means to detect whether the remote terminal
is still functioning
8)
Maintenance loops
Procedures are specified to establish maintenance loops. It is possible to specify the

loop of a single logical channel either as a digital loop or decoded loop, and the loop of
the whole multiplex. This procedure is a mandatory function of gateway.
9)
Commands and indications
Commands and indications are provided for various purposes: video/audio,

active/inactive signals to inform the user; fast update request for source switching in
multipoint applications are some examples. They are not related to general procedures.
The common commands and indications include flow control command, multi-point
mode command, communication mode command, and user input indication.
4.4.2 H.245 Messages

Messages defined in this Recommendation are classified as request, response,
command and indication messages. Request messages and response messages are
used by protocol entity, comprising the protocol procedures. A request message results
in an action by the remote terminal and requires an immediate response from it. A
response message is the response to a request message. A command message
requires action but no explicit response. An indication contains information that does
not require action or response.
I. Message type
The messages used during H.245 procedures are as follows:
z
Terminal capability messages

Message name
Message type
Terminal Capability Set
Request
Terminal Capability Set Acknowledge
Response
Terminal Capability Set Reject
Response
Terminal Capability Set Release
Indication
Logical channel signaling messages

Message name
Message type
Open Logical Channel
Request
Open Logical Channel Acknowledge
Response
Open Logical Channel Reject
Response
4-33

Chapter 4 H.323
Message name
Message type
Open Logical Channel Confirm
Indication
Close Logical Channel
Request
Close Logical Channel Acknowledge
Response
Message name
Message type
Request Channel Close
Request
Request Channel Close Acknowledge
Response
Request Channel Close Reject
Response
Request Channel Close Release
Indication
Master Slave Determination messages
This set of messages is used by a protocol to determine which terminal is the master
terminal and which is the slave terminal. They can be either used or not used during
H.245 channel establishment. For IP services, it is not recommended.
Message name
Message type
Master Slave Determination
Request
Master Slave Determination Acknowledge
Response
Master Slave Determination Reject
Response
Master Slave Determination Release
Indication
Round Trip Delay messages

Message name
Message type
Round Trip Delay Request
Request
Round Trip Delay Response
Response
Maintenance Loop messages

Message name
Message type
Maintenance Loop Request
Request
Maintenance Loop Acknowledge
Response
Maintenance Loop Reject
Response
Maintenance Loop Command off
Command
4-34

1)
Chapter 4 H.323
Commands
Message name
Flow Control
Send Terminal Capability Set
Encryption
End Session
(Miscellaneous Commands)
It is used to request the far-end terminal to indicate its transmit and receive capabilities
by sending one or more TerminalCapabilitySets that contain the information requested.
This command is not sent repeatedly if not necessary. This command is used to
exchange encryption capabilities and to command the transmission of an initialization
vector (IV). This command indicates the end of the H.245 session. After transmitting
EndSessionCommand, the terminal shall not send any more of the messages defined
in this Recommendation. This is used for a variety of commands, some of which are
present in Recommendations H.221 and H.230 [5] and [10], respectively.
2)
Basic indication messages

Message name
Function Not Understood

Jitter Indication
H.225.0 Maximum Skew Indication
User Input
(Miscellaneous Indication)
Function Not Understood is used to return requests, responses and commands that
are not understood to the transmitter of them. Jitter Indication is used to indicate the
amount of jitter, as estimated by the receive terminal, of a logical channel. It may be
useful for choice of bit-rate and buffer control in video channels, or to determine an
appropriate rate of transmission of timing information. H.225.0 Maximum Skew
Indication is used to indicate to the far-end terminal the average amount of time skew
between two logical channels. It is used to indicate synchronous delay of audio and
video in conference call. The delay causes are sampling time, codec delay and send
buffer delay. "User Input is used to transmit DTMF signals, namely 0 to 9, * and #. It is
used for interworking with SCN. Miscellaneous Indication is used for a variety of
indications.
3)
Conference call related messages
4-35

Chapter 4 H.323
Message name
Message type
Conference Request
Request
Conference Response
Response
Conference Command
Command
Communication Mode Request
Request
Communication Mode Response
Response
Communication Command
Command
MCLocation Indication
Indication
(Miscellaneous Conference Indication)
Indication
Conference call related messages are used to control conference related operations,
such as requesting participant terminal lists, terminal ID, and conference ID, becoming
conference chairman, or exit conference. The conference exit command is used to end
a conference. After the command is executed, all involved calls of the conference will
be released. Communication messages are used by MC to indicate type,
communication mode (unicast or multicast) and communication address of media
channels. MC location indication is used by main MC to tell other endpoints its
address, so that it can control the conference. Miscellaneous conference indication is
used to indicate the status of receive terminal or other terminals, for example, that the
receive terminal graphics is being playing, a terminal joins or exits the conference, or
the terminal number is being allocated.
II. Message format

H.245 messages are of tree type, and they are coded in text format. The upper three
layers of an H.245 message determines the message type, and the following layers
define the specific parameters of the type. Figure 4-14 illustrates the generic format of
an H.245 message.
4-36

Chapter 4 H.323
ITU-T Recommendation H.245

Message type
Message name
Parameter 1
Parameter 2
Figure 4-14 Generic format of H.245 message
III. Message elements

This section takes several procedures to describe the common parameters in the
message.
1)
Capability exchange
The TerminalCapabilitySet messages describing transmit and/or receive capabilities of

terminal are used to list media signal operation modes supported by the terminal and
combined operation mode for processing multiple media signals at the same time.
TerminalCapabilitySet messages are of nested structure, as shown in Figure 4-15.
Sequence number
Protocol identifier
Multiplexcapability
Capability descriptor
Simultaneous capability
Capability table
Capability
descriptors
Alternative capability
Capability table entry number
Figure 4-15 Data structure of TerminalCapabilitySet message

z
Sequence number
It is used to label instances of TerminalCapabilitySet so that the corresponding

response can be identified.
z
Protocol identifier
It is used to indicate the version of Recommendation H.245.

z
Multiplex capability
it is used to indicate capabilities relating to multiplexing and network adaptation.

z
Capability table
4-37

Chapter 4 H.323
A Capability Table is a numbered list of capabilities, such as G.723 audio, G.728 audio,
and CIF H.263 video. Each capability corresponds to a table entity, which has its own
sequence number (capability number).
A capability table is shown in Figure 4-14.
Table 4-14 Capability table format
CapabilityTableEntryNumbers
Capability
Capability 0
Capability 1
The contents of each entity contains coding/decoding standards and many related
parameters. For example, each H.263 capability contains the supported image formats
and capability of any coding mode.
z
Alternative capability set
These capability numbers are grouped into AlternativeCapabilitySet structures. Each

AlternativeCapabilitySet indicates that the terminal is capable of operating in exactly
one mode listed in the set. For example, an AlternativeCapabilitySet listing {G.711,
G.723.1, G.728} means that the terminal can operate in any one of those audio modes,
but not more than one.
An alternative capability set shows a range of capabilities that can be selected.
{CapabilityTableEntryNumber0, CapabilityTableEntryNumber 1, }
z
Simultaneous capabilities
These AlternativeCapabilitySet structures are grouped into simultaneousCapabilities

structures. For example, a simultaneousCapabilities structure containing the two
AlternativeCapabilitySet structures {H.261, H.263} and {G.711, G.723.1, G.728} means
that the terminal can operate either of the video codecs simultaneously with any one of
the audio codecs. The simultaneousCapabilities set {{H.261}, {H.261, H.263}, {G.711,
G.723.1, G.728}} means the terminal can operate two video channels and one audio
channel simultaneously: one video channel per H.261, another video channel per
either H.261 or H.263, and one audio channel per either G.711, G.723.1, or G.728.
Simultaneous capabilities are the capabilities that can be performed at the same time.
{Alternative capability 0, Alternative capability 1, }
z
Capability descriptors
The terminals total capabilities are described by a set of CapabilityDescriptor

structures, each of which is a single simultaneousCapabilities structure and a
4-38

Chapter 4 H.323
capabilityDescriptorNumber. By sending more than one CapabilityDescriptor,

the terminal may signal dependencies between operating modes by describing
different sets of modes which it can simultaneously use. For example, a terminal
issuing two CapabilityDescriptor structures, one {{H.261, H.263}, {G.711, G.723.1,
G.728} } as in the previous example, and the other {{H.262}, {G.711}}, means the
terminal can also operate the H.262 video codec, but only with the low-complexity
G.711 audio codec.
Capability descriptors are shown in Table 4-15.
Table 4-15 Capability descriptors
CapabilityDescriptorNumbers
SimultaneousCapabilities
Simultaneous capability 0
Simultaneous capability 1
2)
Master-slave determination
The H.245 Master-slave determination procedures are used to resolve conflicts

between two endpoints which can both be the MC for a conference, or between two
endpoints which are attempting to open a bidirectional channel. Before a channel is
established, it is required to determine the master-slave relations.
Either terminal may initiate the master slave determination process by issuing the
DETERMINE.request.
The
message
contains
two
parameters,
StatusDeterminationNumber and TerminalType.

z
Status determination number
Each endpoint can only select one random number as the status determination number
in each call, and the value ranges from 0 to 224-1.
z
Terminal type
TerminalType is a number that identifies different types of terminal

Entity function
H.323 entity
Terminal
Gateway
GK
MCU
Entity with No MC
50
60
Entity contains an MC but no MP
70
80
120
160
Entity contains MC with data MP
90
130
170
Entity contains MC with data and

audio MP
100
140
180
Entity contains MC with data, audio

and video MP
110
150
190
4-39

Chapter 4 H.323
After the peer end receives the masterSlaveDetermination message, it starts the
determination calculation procedure. The determination principle is: the endpoint with
larger terminaltype value is "Master". If the terminaltype values are the same, the
endpoint
with
larger
StatusDeterminationNumber
is
Master.
If
the
StatusDeterminationNumbers are still the same, undetermined will be resulted.

Generally, the status can be determined. Then, the peer terminal sends back
determination acknowledge message to tell the determination result. If the status
cannot be determined, the peer terminal sends back determination reject message,
with rejection reason as same number. Then, the local terminal regenerates a
StatusDeterminationNumber, and starts master-slave determination procedure again.
Besides, in a conference call, if an MC becomes the active MC, its terminaltype value
becomes 240. An MC that is already acting as an MC shall always remain the active
MC. Therefore, once an MC has been selected as the active MC in a conference, it
shall use the Active MC value for all subsequent connections to the conference.
3)
Logical channel signaling procedure
Logical channel is opened by transmitter side. It sends a OpenLogicalChannel

message
to
the
receive
terminal,
and
the
message
contains
ForwardLogicalChannelNumber and channel parameters.

z
ForwardLogicalChannelNumber
ForwardLogicalChannelNumber must be assigned by the transmitter side, and the

acknowledge message carries this value to match the request message.
z
Channel parameters
The parameters define whether data type and media information are transmitted surely,
whether silence suppression is performed, and destination terminal tag.
If the channel is used to transmit RTP encapsulated real-time media information, such
as audio or video, the channel parameters also include the following three parameters:
Session ID
RTP session ID. An RTP session is the communication of a group of participants
through RTP. For each participant, the session is defined by a pair of transmission layer
addresses (network layer address plus RTP and RTCP ports numbers). In IP multicast
mode, the transmission layer addresses of the participants might be the same. In
unicast mode, the transmission layer addresses of the participants are different
because their network addresses are different. In a multimedia session, each media
signal is transmitted by an individual RTP session, and has its own RTCP group. The
RTP sessions are distinguished by different port pair and/or different multicast
addresses.
Media channel
4-40

Chapter 4 H.323
Used to transmit the IP address and port number of RTP encapsulated real-time media
messages, and other transmission QoS parameters.
Media control channel
Used to transmit the IP address and port number of QoS parameter messages of RTCP
encapsulated real-time signal transmission.
For more information about the above parameters, see RTP related documents.
IV. Example of H.245 message

An example of OpenLogicalChannel message is shown as follows:
request
openLogicalChannel
forwardLogicalChannelNumber: 1
forwardLogicalChannelParameters
(OpenLogicalChannel-forwardLogicalChannelParameters)
dataType (audioData)
audioData
g7231
maxAl_sduAudioFrames: 1
silenceSuppression: False
multiplexParameters (h2250LogicalChannelParameters)
h2250LogicalChannelParameters
sessionID: 1
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network:
191.169.150.171
(191.169.150.171)
tsapIdentifier: 40000
mediaGuaranteedDelivery: False
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network:
191.169.150.171
(191.169.150.171)
mediaControlGuaranteedDelivery: False
Line 1 indicates that the message is an H.245 message.

Line 2 indicates that the message is a request message.
4-41

Chapter 4 H.323
Line 3 indicates that the message name is openLogicalChannel.

Line 4: Forward logical channel number. Here the value is 1. This parameter must be
assigned by transmit party, and the acknowledge message returns this value to match
the request message.
Lines 5 and 6: Forward logical channel parameters. The parameters define whether
data type and media information are transmitted surely, whether silence suppression is
performed, and destination terminal tag.
Lines 7 to 11: Data type. Here, the data type is G.723 audio data, without silence
suppression.
Lines 12 to 13: H.225 logical channel parameter, which is mandatory because the
channel is used to transmit RTP encapsulated real-time media information, such as
audio or video.
Line 14: RTP session ID. Here the value is 1.
Lines 15 to 21: Media channel parameters. That is, the IP address and port number
used by the endpoint to transmit RTP encapsulated real-time media information. Here,
the IP address is 191,169,150,171, and the port number is 40000.
Lines 22 to s8: Media control channel parameters. That is, the IP address and port
number used by the endpoint to transmit QoS parameter message of RTCP
encapsulated real-time signal transmission. Here, the IP address is 191,169,150,171,
and the port number is 40001.

I. Capability Exchange
Endpoint A
Timeout
Endpoint B
TCSReq
TCSAck
TCSRej
TCSRel
Figure 4-16 Capability exchange procedure
4-42

Chapter 4 H.323
II. Master Slave Determination

Endpoint B
Endpoint A
Timeout
MSDReq
MSDAck
MSDRej
MSDRel
Figure 4-17 Master slave determination procedure
III. Open Logical Channel

Endpoint A
Timeout
Endpoint B
OLCReq
OLCAck
OLCRej
OLCRel
Figure 4-18 Open logical channel procedure
4-43

Chapter 4 H.323
IV. Close Logical Channel

Endpoint A
Timeout
Endpoint B
OLCReq
OLCAck
OLCRej
OLCRel
Figure 4-19 Close logical channel
V. End Session
Endpoint A
Endpoint B
ECS
ECS
Disconnect TCP connection
Figure 4-20 End session
4.5 H.323 Call Procedures

H.323 call procedure can be established in normal start and fast start mode. A complete
H.323 call needs RAS, Q.931 and H.245.
For endpoint registration procedure, see Section 4.2.3.
4.5.1 Successful H.323 User Call Procedure (Normal Start)

Figure 4-21 shows a successful call procedure (normal start) between two H.323 users
in the same SoftX3000.
The following example complies with the conventions below:
z
SoftX3000 serves as the GK, and its IP address is 191.169.150.170.
The IP address of H.323 PhoneA is 191.169.150.171.
4-44

Chapter 4 H.323
The IP address of H.323 PhoneB is 191.169.31.31.
H.323 PhoneA is the calling party, H.323 PhoneB is the called party, and the
called party first hooks on.
The phone number of H.323 PhoneA is 7670000, and the phone number of H.323
PhoneB is 7670001.
H.323 PhoneA
SoftX3000
RAS_ARQ
RAS_ACF
H.323 PhoneB
3 Q931_SETUP
4Q931_CALLPROCEEDING
5
Q931_SETUP
RAS_ARQ
RAS_ACF
8 Q931_ALERTING
9 Q931_ALERTING
10 Q931_CONNECT
11
Q931_CONNECT
12
H245_REQ_TCS
H245_REQ_TCSA 13
H245_REQ_TCS 14
15
H245_REQ_TCSA
16
H245_REQ_MSD
H245_REQ_MSDA 17
H245_REQ_MSD 18
19 H245_REQ_MSDA
H245_REQ_OLC 20
21 H245_REQ_OLCA
H245_REQ_OLC 22
23 H245_REQ_OLCA
24 H245_REQ_OLC
H245_REQ_OLCA 25
26
H245_REQ_OLC
H245_REQ_OLCA 27
Conversation
28 Q931_ReleaseComplete
RAS_DRQ
29
30
RAS_DCF
31Q931_ReleaseComplete
32
RAS_DRQ
33
RAS_DCF
Figure 4-21 Successful H.323 user call procedure (normal start)

1)
Scenario 1: H.323 PhoneA hooks off, and it sends ARQ to the GK to request
whether the call can be initiated. In the ARQ message, H.323 PhoneA gives the
4-45

Chapter 4 H.323
destination information, required bandwidth, and call ID. It should be noted that the
CallModel is gatekeeperRouted, and the GK is involved in the call signaling
procedure, while the peer endpoints do not know the addresses of each other.
admissionRequest
requestSeqNum: 1930
callModel (gatekeeperRouted)
gatekeeperRouted: gatekeeperRouted
destinationInfo (AliasAddress)
Item 0 (e164)
e164: 7670001
srcInfo (AliasAddress)
Item 0 (e164)
e164: 7670000
Item 1 (h323_ID)
h323_ID: 7670000
bandWidth: 5120
callReferenceValue: 28625
activeMC: False
answerCall: False
canMapAlias: False
willSupplyUUIEs: False
2)
Scenario 2: The GK agrees to accept the call, and sends ACF message to H.323
PhoneA. In the message, there is allowed bandwidth, and translated transmission
layer address of call signaling of destination or the transmission layer address of
call signaling of the GK. Because the CallModel is gatekeeperRouted, the call
signaling transmission layer address after translation is the transmission layer
address of call signaling of the GK (IP address plus TCP port number). The IP
address is 191.169.150.170, and the port number is 1720. Meanwhile, the GK
establishes call signaling channel to H.323 PhoneB.

admissionConfirm
requestSeqNum: 1930
bandWidth: 5120
4-46

Chapter 4 H.323
destCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.150.170 (191.169.150.170)
port: 1720
irrFrequency: 60
Item 0 (e164)
e164: 7670001
willRespondToIRR: False
uuiesRequested (UUIEsRequested)
setup: False
callProceeding: False
connect: False
alerting: False
information: False
releaseComplete: False
facility: False
progress: False
empty: False
3)
Scenario 3: H.323 PhoneA sends Setup message to the GK, to request call
establishment. In the UUIE field of the message, the transmission layer address of
the source call signaling channel is given (IP address plus TCP port number). The
IP address is 191.169.150.171, and the port number is 1074, used to receive the
Q.931 messages from the GK.
Q.931
Call reference value: 6FD1
Bearer capability
Length: 3
Transfer mode: Packet mode
Information transfer rate: Packet mode
Display
Length: 7
Display information: 7670000
4-47

Chapter 4 H.323

Length: 8
Number: 7670000
Called party number
Length: 8
Number: 7670001
User-user
Length: 126
setup
Item 0 (e164)
e164: 7670000
Item 1 (h323_ID)
h323_ID: 7670000
t35CountryCode: 82
t35Extension: 0
versionId: 2.0
mc: False
Item 0 (e164)
e164: 7670001
activeMC: False
4-48

Chapter 4 H.323
create: create
ipAddress
ip: 191.169.150.171 (191.169.150.171)
port: 1074
4)
Scenario 4: The GK sends back Call Proceeding message, indicating that the call
has been processed. The VendorIdentifier in the UUIE field of the message
indicates the vendor ID of the GK. Here, the country code is 28, extension is 21
and manufacturer code is 0. Besides, it is indicated that the GK is Huawei NGN
SoftX3000 product, whose version is SoftX3000V3.
Q.931
Call reference value: EFD1
Message type: CALL PROCEEDING (0x02)
User-user
Length: 70
h323_message_body (callProceeding)
callProceeding
destinationInfo (EndpointType)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
4-49

Chapter 4 H.323
mc: False
5)
Scenario 5: The GK receives the Setup message from H.323 PhoneA. If the GK
agrees to establish the call, it will translate and get the transmission layer address
(IP address plus TCP port number) of call signaling channel of H.323 PhoneB. The
IP address is 191.169.31.31, and the port number is 1720. Then, the GK transfers
the Setup message to H.323 PhoneB to request call establishment. In the UUIE
field of the message, the transmission layer address of the source call signaling
channel is given (IP address plus TCP port number). The IP address is
191.169.150.170, and the port number is 5011, used to receive the Q.931
messages from H.323 PhoneB.
Q.931
Call reference value: 0004
Bearer capability
Length: 4
Transfer mode: Circuit mode
Information transfer rate: Multirate (64 kbit/s base rate)
Rate multiplier: 186
Display
Length: 30
Display information: Huawei Technologies Co.,
Ltd.
Called party number

Length: 8
Type of number: National number
Number: 7670001
User-user
Length: 113
4-50

Chapter 4 H.323

setup
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
Item 0 (e164)
e164: 7670001
ipAddress
ip: 191.169.31.31 (191.169.31.31)
port: 1720
activeMC: False
create: create
ipAddress
ip: 191.169.150.170 (191.169.150.170)
port: 5011
6)
Scenario 6: H.323 PhoneB agrees to accept the call, and sends ARQ message to
the GK through RAS channel, to tell the GK it accepts the incoming call.
4-51

Chapter 4 H.323
admissionRequest
requestSeqNum: 90
Item 0 (h323_ID)
h323_ID: 7670001
Item 1 (e164)
e164: 7670001
srcInfo (AliasAddress)
<empty>
bandWidth: 5120
activeMC: False
answerCall: True
canMapAlias: False
willSupplyUUIEs: False
7)
Scenario 7: The GK agrees to accept the call, and sends ACF message to H.323
PhoneB. In the message, the GK sends the transmission layer address (IP
address plus TCP port number) of its call signaling channel to H.323 PhoneB..

admissionConfirm
requestSeqNum: 90
bandWidth: 5120
ipAddress
ip: 191.169.150.170 (191.169.150.170)
port: 1720
irrFrequency: 60
Item 0 (h323_ID)
h323_ID: 7670001
willRespondToIRR: False
uuiesRequested (UUIEsRequested)
4-52

Chapter 4 H.323
setup: False
callProceeding: False
connect: False
alerting: False
information: False
releaseComplete: False
facility: False
progress: False
empty: False
8)
Scenario 8: H.323 PhoneB sends Alerting message to the GK, indicating that the
call has arrived, and it is ringing.
Q.931
Message type: ALERTING (0x01)
User-user
Length: 36
h323_message_body (alerting)
alerting
mc: False
9)
Scenario 9: The GK transfers the Alerting message from H.323 PhoneB to H.323
PhoneA, and tells H.323 PhoneA to send ringback tone.
Q.931
User-user
Length: 70
4-53

Chapter 4 H.323

alerting
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
10) Scenario 10: H.323 PhoneB sends Connect message to the GK, and the message
carries the IP address and TCP port number of the H.245 control channel of
PhoneB. The IP address is 191.169.31.31, and the port number is 2722. Besides,
the message carries the vendor ID, product and version information of H.323
PhoneB.
Q.931
Message type: CONNECT (0x07)
User-user
Length: 81
h323_message_body (connect)
connect
h245Address (ipAddress)
ipAddress
4-54

Chapter 4 H.323
ip: 191.169.31.31 (191.169.31.31)
port: 2722
t35CountryCode: 82
t35Extension: 0
versionId: 2.0
mc: False
11) Scenario 11: The GK receives Connect message from H.323 PhoneB, and
transfers the message to H.323 PhoneA. The message carries the IP address and
TCP port number of the H.245 control channel of H.323 PhoneB. The IP address
is 191.169.31.31, and the port number is 2722. Besides, the message carries the
vendor ID, product and version information of the GK. Now , the call is set up.
Q.931
Bearer capability
Length: 3
Information transfer rate: 64 kbit/s
Display
Length: 30
User-user
Length: 93
4-55
Ltd.

Chapter 4 H.323

connect
ipAddress
ip: 191.169.31.31 (191.169.31.31)
port: 2722
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
12) Scenario 12: After the call is set up, H.323 PhoneB sends H.245 request message
TCS to H.323 PhoneA to start capability exchange procedure, so that H.323
PhoneA can know the receive and transmit capabilities of PhoneB.
request
terminalCapabilitySet
sequenceNumber: 1
multiplexCapability (h2250Capability)
h2250Capability
maximumAudioDelayJitter: 60
receiveMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
4-56

Chapter 4 H.323
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False
centralizedVideo: True
distributedVideo: False
transmitMultipointCapability (MultipointCapability)
receiveAndTransmitMultipointCapability
(MultipointCapability)
mcCapability (H2250Capability-mcCapability)
centralizedConferenceMC: False
decentralizedConferenceMC: False
rtcpVideoControlCapability: False
mediaPacketizationCapability
(MediaPacketizationCapability)
h261aVideoPacketization: False
logicalChannelSwitchingCapability: False
t120DynamicPortCapability: False
capabilityTable (CapabilityTableEntry)
4-57

Chapter 4 H.323
Item 0 (CapabilityTableEntry)
capabilityTableEntryNumber: 1
capability (receiveAudioCapability)
receiveAudioCapability
g7231
capability (receiveVideoCapability)
receiveVideoCapability
h263VideoCapability
qcifMPI: 1
maxBitRate: 5120
unrestrictedVector: False
arithmeticCoding: False
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False
enhancementLayerInfo
(EnhancementLayerInfo)
baseBitRateConstrained: False
g711Ulaw64k: 30
g711Alaw64k: 30
h263VideoCapability
cifMPI: 1
maxBitRate: 5120
4-58

Chapter 4 H.323
pbFrames: False
capabilityDescriptors (CapabilityDescriptor)
Item 0 (CapabilityDescriptor)
capabilityDescriptorNumber: 1
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 1
array: 2
array: 3
array: 4
array: 5
array: 1
13) Scenario 13: H.323 PhoneA receives the TCS message from H.323 PhoneB, and
sends back TCSA message to confirm.
response
terminalCapabilitySetAck
sequenceNumber: 1
14) Scenario 14: H.323 PhoneA sends H.245 request message TCS to H.323 PhoneB
to start capability exchange procedure, so that H.323 PhoneB can know the
receive and transmit capabilities of PhoneA.
4-59

Chapter 4 H.323
request
sequenceNumber: 1
h2250Capability
4-60

Chapter 4 H.323
rtcpVideoControlCapability: False
g7231
h263VideoCapability
qcifMPI: 1
maxBitRate: 5120
pbFrames: False
g711Ulaw64k: 30
4-61

Chapter 4 H.323
g711Alaw64k: 30
h263VideoCapability
cifMPI: 1
maxBitRate: 5120
pbFrames: False
array: 1
array: 2
array: 3
array: 4
array: 5
4-62

Chapter 4 H.323
array: 1
15) Scenario 15: H.323 PhoneB receives the TCS message from H.323 PhoneA, and
sends back TCSA message to confirm. Now, the capability exchange procedure is
over.
response
sequenceNumber: 1
16) Scenario 16: H.323 PhoneB sends MSD message to H.323 PhoneA, to start
master slave determination procedure.
request
masterSlaveDetermination
terminalType: 50
statusDeterminationNumber: 6814
17) Scenario 17: H.323 PhoneA receives the MSD message from H.323 PhoneB, and
it compares the carried terminalType and statusDeterminationNumber with its
corresponding values, to get the result that it is Slave. Then, H.323 PhoneA sends
the result to H.323 PhoneB through MSDA message.
response
masterSlaveDeterminationAck
decision (slave)
slave: slave
18) Scenario 18: H.323 PhoneA sends MSD message to H.323 PhoneB, to start
master slave determination procedure.
request
terminalType: 50
19) Scenario 19: H.323 PhoneB receives the MSD message from H.323 PhoneA, and
it compares the carried terminalType and statusDeterminationNumber with its
corresponding values, to get the result that it is Master. Then, H.323 PhoneB
sends the result to H.323 PhoneA through MSDA message.
response
decision (master)
master: master
4-63

Chapter 4 H.323
20) Scenario 20: H.323 PhoneA sends OLC message to H.323 PhoneB, to start
OpenLogicalChannel procedure. This channel is used to transmit G.723 audio
signals and RTP encapsulated real-time media information (audio). The message
carries the IP address (191.169.150.171) and port number (40000) used by H.323
PhoneA to transmit RTP encapsulated real-time media information (audio signals),
and the IP address (191.169.150.171) and port number (40001) used to transmit
quality parameter message of RTCP encapsulated real-time signal transmission.
request
openLogicalChannel
audioData
g7231
sessionID: 1
unicastAddress
iPAddress
network:
191.169.150.171
(191.169.150.171)
unicastAddress
iPAddress
network:
191.169.150.171
(191.169.150.171)
21) Scenario 21: H.323 PhoneB sends back OLCA message as response. The
message carries the IP address (191.169.31.31) and port number (40000) used
by H.323 PhoneB to transmit RTP encapsulated real-time media information
(audio signals), and the IP address (191.169.31.31) and port number (40001)
used to transmit quality parameter message of RTCP encapsulated real-time
signal transmission.
4-64

Chapter 4 H.323
response
openLogicalChannelAck
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 1
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
flowControlToZero: False
22) Scenario 22: H.323 PhoneA sends OLC message to H.323 PhoneB, to start
OpenLogicalChannel procedure. This channel is used to transmit H.263 video
signals and RTP encapsulated real-time media information (video). The message
PhoneA to transmit RTP encapsulated real-time media information (video signals),
request
openLogicalChannel
dataType (videoData)
videoData
h263VideoCapability
qcifMPI: 1
maxBitRate: 2048
pbFrames: False
4-65

Chapter 4 H.323
enhancementLayerInfo (EnhancementLayerInfo)
sessionID: 2
unicastAddress
iPAddress
network:
191.169.150.171
(191.169.150.171)
unicastAddress
iPAddress
network:
191.169.150.171
(191.169.150.171)
23) Scenario 23: H.323 PhoneB sends back OLCA message as response. The
by H.323 PhoneB to transmit RTP encapsulated real-time media information
(video signals), and the IP address (191.169.31.31) and port number (40003)
response
sessionID: 3
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
4-66

Chapter 4 H.323
24) Scenario 24: H.323 PhoneB sends OLC message to H.323 PhoneA, to start
PhoneA to transmit RTP encapsulated real-time media information (audio signals),
request
openLogicalChannel
audioData
g7231
sessionID: 1
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
25) Scenario 25: H.323 PhoneA sends back OLCA message as response. The
by H.323 PhoneA to transmit RTP encapsulated real-time media information
4-67

Chapter 4 H.323
response
sessionID: 1
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
26) Scenario 26: H.323 PhoneB sends OLC message to H.323 PhoneA, to start
OpenLogicalChannel procedure. This channel is used to transmit H.263 video
signals and RTP encapsulated real-time media information (video). The message
PhoneB to transmit RTP encapsulated real-time media information (video signals),
request
openLogicalChannel
dataType (videoData)
videoData
h263VideoCapability
qcifMPI: 1
maxBitRate: 2048
pbFrames: False
4-68

Chapter 4 H.323
enhancementLayerInfo (EnhancementLayerInfo)
sessionID: 2
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
27) Scenario 27: H.323 PhoneA sends back OLCA message as response. The
by H.323 PhoneA to transmit RTP encapsulated real-time media information
(video signals), and the IP address (191.169.150.171) and port number (40003)
signal transmission. Now, the audio and video logical channels at both ends are
opened, that is the logical channel signaling procedure is over, and both parties
begin converstation.
response
sessionID: 3
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
4-69

Chapter 4 H.323
28) Scenario 28: H.323 PhoneB hooks on, and sends Q.931 Release Complete
message to the GK to close the channel.
Q.931
Message type: RELEASE COMPLETE (0x5a)
User-user
Length: 35
h323_message_body (releaseComplete)
releaseComplete
reason (undefinedReason)
undefinedReason: undefinedReason
29) Scenario 29: H.323 PhoneB sends RAS DRQ message to the GK to tell the GK
that the occupied bandwidth can be released.
disengageRequest
requestSeqNum: 91
disengageReason (normalDrop)
normalDrop: normalDrop
answeredCall: True
30) Scenario 30: The GK sends DCF message to H.323 PhoneB, to confirm that it has
received DRQ message and released corresponding bandwidth.
disengageConfirm
requestSeqNum: 91
4-70

Chapter 4 H.323
31) Scenario 31: The GK sends Q.931 Release Complete message to H.323 PhoneA
to close the channel. Now, the call is released.
Q.931
Cause
Information element: Cause
Length: 2
Location: User (U)
Cause value: Normal unspecified
User-user
Length: 30
releaseComplete
32) Scenario 32: H.323 PhoneA sends RAS DRQ message to the GK to tell the GK
that the occupied bandwidth can be released.
disengageRequest
requestSeqNum: 1931
disengageReason (normalDrop)
normalDrop: normalDrop
answeredCall: False
4-71

Chapter 4 H.323
33) Scenario 33: The GK sends DCF message to H.323 PhoneA, to confirm that it has
received DRQ message and released corresponding bandwidth. Now, whole
release procedure is over.
disengageConfirm
requestSeqNum: 1931
4.5.2 Successful H.323 User Call Procedure (Fast Start)

Figure 4-22 shows H.323 call procedure in fast start mode, in which SoftX3000 serves
as the GK.
H.323 PhoneA
SoftX3000
RAS_ARQ
RAS_ACF
Q931_SETUP
H.323 PhoneB
4Q931_CALLPROCEEDING
5
Q931_SETUP
RAS_ARQ
RAS_ACF
8 Q931_ALERTING
9 Q931_ALERTING
10 Q931_CONNECT
11 Q931_CONNECT
Conversation
12
RAS_DRQ
13
RAS_DCF
14Q931_ReleaseComplete
RAS_DRQ
15
16
RAS_DCF
Figure 4-22 Successful H.323 user call procedure (fast start)

H.323 call procedure in fast start mode is similar to H.323 call procedure in normal start
mode, but there is no H.245 negotiation procedure in fast start mode. It should be noted
that the Setup message carries H.245 channel information in H.323 call procedure in
fast start mode.
4.5.3 Successful H.323 Trunk Call Procedure

Different SoftX3000 equipment uses H.323 to communicate. Figure 4-23 shows a
successful H.323 trunk call procedure.
4-72

Chapter 4 H.323
The following example complies with the conventions below:

z
The IP address of SoftX3000A is 191.169.1.112.
The IP address of SoftX3000B is 191.169.1.110.
The phone number of PhoneA controlled by SoftX3000A is 55500011.
The phone number of PhoneB controlled by SoftX3000B is 66500010.
H.323 PhoneA is the calling party, H.323 PhoneB is the called party, and the
called party first hooks on.
SoftX3000A
1
SoftX3000B
Q931_SETUP
2 Q931_CALLPROCEEDING
3
Q931_ALERTING
Q931_CONNECT
Q931_FACILITY
H245_REQ_TCS
H245_REQ_TCSA
H245_REQ_TCS
H245_REQ_TCSA
10
H245_REQ_MSD
11
H245_REQ_MSDA
12
H245_REQ_MSD
13
H245_REQ_MSDA
14
H245_REQ_OLC
15
H245_REQ_OLCA
16
H245_REQ_OLC
17
H245_REQ_OLCA
Conversation
18
H245_REQ_ESD
20
H245_REQ_ESD
Figure 4-23 Successful H.323 trunk call procedure
Note:
The H.323 trunk call connection can be implemented in fast start mode.
4-73

1)
Chapter 4 H.323
Scenario 1: SoftX3000A sends Setup message to SoftX3000B, to request call

establishment. The message contains call ID, phone number of PhoneA, vendor
identifier, and phone number of PhoneB, used for charging and routing. Besides,
the UUIE field in the message carries the transmission layer address (IP address
plus TCP port number) of destination call signaling channel (IP address is
191.169.1.110, and the port number is 1720), and the transmission layer address
(IP address plus TCP port number) of source call signaling channel (IP address is
191.169.1.112, and the port number is 5122), used in subsequent Q.931 message
for interworking between both ends.
Q.931
Bearer capability
Length: 4
Information transfer rate: Multirate (64 kbit/s base rate)
Rate multiplier: 186
Display
Length: 30
Length: 12
Number: 02055500011
Called party number
Length: 9
Number: 66500010
User-user
Length: 181
4-74
Ltd.

Chapter 4 H.323

setup
Item 0 (e164)
e164: 02055500011
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
Item 0 (e164)
e164: 66500010
ipAddress
ip: 191.169.1.110 (191.169.1.110)
port: 1720
activeMC: False
conferenceID: 908552FC-3018-E030-844A-AC14C86413C4
create: create
ipAddress
ip: 191.169.1.112 (191.169.1.112)
port: 5122
guid: 908552FC-3018-E030-8449-AC14C86413C4
2)
Scenerio 2: SoftX3000B sends back Call Proceeding message, indicating that the
call has been processed. The VendorIdentifier in the UUIE field of the message
4-75

Chapter 4 H.323
indicates the vendor identifier of SoftX3000B. Here, the country code is 28,
extension is 21, vendor identifier is 0. Besides, it is indicated that SoftX3000B is
Huawei NGN SoftX3000 product, whose version is SoftX3000V3.
Q.931
Message type: CALL PROCEEDING (0x02)
User-user
Length: 70
h323_message_body (callProceeding)
callProceeding
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
guid: 908552FC-3018-E030-8449-AC14C86413C4
3)
Scenario 3: SoftX3000B sends Alerting message to SoftX3000A, indicating that

the call has arrived and asking PhoneB resident gateway to play ringing tone. After
SoftX3000A receives the message, it asks PhoneA resident gateway to play
ringback tone.
Q.931
User-user
4-76

Chapter 4 H.323

Length: 129
alerting
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
guid: 908552FC-3018-E030-8449-AC14C86413C4
4)
Scenario 4: H.323 PhoneB sends Connect message to SoftX3000A, to request

H.245 TCP connection.
Q.931
Bearer capability
Length: 3
Information transfer rate: 64 kbit/s
Display
Length: 30
User-user
4-77
Ltd.

Chapter 4 H.323

Length: 86
connect
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
mc: False
guid: 908552FC-3018-E030-8449-AC14C86413C4
5)
Scenario 5: SoftX3000B sends Facility message to SoftX3000A. The UUIE in the

message carries H.245 control channel transmission layer address (IP address
plus TCP port number) of SoftX3000B, where the IP address is 191.169.1.110,
and the port number is 5259. The "Reason is Start H.245. Now, the call is set up.
Q.931
Message type: FACILITY (0x62)
User-user
Length: 38
h323_message_body (facility)
facility
4-78

Chapter 4 H.323
reason (startH245)
startH245: startH245
ipAddress
ip: 191.169.1.110 (191.169.1.110)
port: 5259
6)
Scenario 6: After the call is set up, SoftX3000B sends H.245 request message
TCS to SoftX3000A to start capability exchange procedure, so that SoftX3000A
can know the receive and transmit capabilities of SoftX3000B.

request
sequenceNumber: 2
h2250Capability
centralizedControl: False
centralizedAudio: False
centralizedVideo: False
4-79

Chapter 4 H.323
rtcpVideoControlCapability: True
g711Alaw64k: 20
array: 1
7)
Scenario 7: SoftX3000A receives TCS message from SoftX3000B, and sends

back TCSA message to acknowledge.

response
sequenceNumber: 2
4-80

8)
Chapter 4 H.323
Scenario 8: SoftX3000A sends H.245 request message TCS to SoftX3000B to

start capability exchange procedure, so that SoftX3000B can know the receive
and transmit capabilities of SoftX3000A.

request
sequenceNumber: 1
h2250Capability
4-81

Chapter 4 H.323
rtcpVideoControlCapability: True
g711Alaw64k: 20
array: 1
9)
Scenario 9: SoftX3000B receives TCS message from SoftX3000A, and sends

back TCSA message to acknowledge. Now, the capability exchange procedure is
over.

response
sequenceNumber: 1
10) Scenario 10: SoftX3000A sends MSD message to SoftX3000B, to start master
slave determination procedure.
request
terminalType: 120
4-82

Chapter 4 H.323
11) Scenario 11: SoftX3000B receives the MSD message from SoftX3000A, and it
compares the carried terminalType and statusDeterminationNumber with its
corresponding values, to get the result that it is Slave. Then, SoftX3000B sends
the result to SoftX3000A through MSDA message.
response
decision (master)
master: slave
12) Scenario 12: SoftX3000B sends MSD message to SoftX3000A, to start master
slave determination procedure.
request
terminalType: 120
13) Scenario 13: SoftX3000A receives the MSD message from SoftX3000B, and it
compares the carried terminalType and statusDeterminationNumber with its
corresponding values, to get the result that it is Master. Then, SoftX3000A sends
the result to SoftX3000B through MSDA message.
response
decision (slave)
slave: master
14) Scenario 14: SoftX3000A sends OLC message to SoftX3000B, to start

carries the IP address (191.169.3.38) and port number (30001) used by PhoneA
resident gateway to transmit quality parameter information of RTCP encapsulated
real-time signal transmission.
request
openLogicalChannel
audioData
g711Alaw64k: 20
4-83

Chapter 4 H.323
sessionID: 1
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
15) Scenario 15: SoftX3000B sends back OLCA message as response. The message
carries the IP address (191.169.1.135) and port number (30019) used by PhoneB
resident gateway to transmit RTP encapsulated real-time media information
response
sessionID: 1
unicastAddress
iPAddress
network: 191.169.1.135 (191.169.1.135)
unicastAddress
iPAddress
network: 191.169.1.135 (191.169.1.135)
16) Scenario 16: SoftX3000B sends OLC message to SoftX3000A, to start

carries the IP address (191.169.1.135) and port number (30019) used by PhoneB
resident gateway to transmit quality parameter information of RTCP encapsulated
real-time signal transmission.
request
openLogicalChannel
4-84

Chapter 4 H.323
audioData
g711Alaw64k: 20
sessionID: 1
unicastAddress
iPAddress
network: 191.169.1.135 (191.169.1.135)
17) Scenario 17: SoftX3000A sends back OLCA message as response. The message
carries the IP address (191.169.3.38) and port number (30000) used by PhoneA
resident gateway to transmit RTP encapsulated real-time media information
(audio signals), and the IP address (191.169.3.38) and port number (30001) used
to transmit quality parameter message of RTCP encapsulated real-time signal
transmission. Now, the audio logical channels at both ends are opened, that is the
logical channel signaling procedure is over, and both parties begin converstation.
response
sessionID: 1
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
18) Scenario 18: PhoneB hooks on. SoftX3000B sends ESD message to SoftX3000A
to request converstation end.
4-85

Chapter 4 H.323

command
endSessionCommand
disconnect: disconnect
19) Scenario 19: SoftX3000A sends Q.931 Release Complete message to

SoftX3000B, to close the channel. Now, the call is released. Meanwhile,
SoftX3000A asks PhoneA resident gateway to play busy tone.
Q.931
Cause
Information element: Cause
Length: 2
Location: User (U)
Cause value: Normal unspecified
User-user
Length: 30
releaseComplete
guid: 908552FC-3018-E030-8449-AC14C86413C4
20) Scenario 20: PhoneA hooks on. SoftX3000A sends ESD message to SoftX3000B.
Now, whole call procedure is over.
command
endSessionCommand
disconnect: disconnect
4-86

Chapter 5 SIGTRAN
Chapter 5 SIGTRAN
5.1 Overview
5.1.1 Functions
Signaling Transport (SIGTRAN) protocol stack is defined by the SIGTRAN workgroup
of the Internet Engineering Task Force (IETF) for interworking purposes between the
Signaling System No. 7 (SS7) and the Internet Protocol (IP).This protocol stack
supports transmission of switched circuit network (SCN) signaling across IP network.
This protocol stack supports the inter-layer standard primitive interface defined in SCN
signaling protocol hierarchy model so as to ensure utilization of the existing SCN
signaling application without modification. It also uses the standard IP transport
protocol as the transmission bottom layer, and satisfies the special transmission
requirements of SCN signaling by adding its own functions.
Caution:
z
The SIGTRAN protocol stack only implements SCN signaling adaptation and transmission on IP
network without processing user-layer signaling messages.
The SIGTRAN protocol stack is functionally composed of two classes of protocols as follows:
The first class includes universal signaling transport protocols that achieve the
efficient and reliable transmission of SS7 signaling on IP network. Currently
SoftX3000 uses Stream Control Transmission Protocol (SCTP) specified by the
IETF.
The second class refers to SS7 adaptation protocols including SS7 MTP2-User
Adaptation Layer (M2UA), SS7 MTP3-User Adaptation Layer (M3UA), ISDN
Q.921-User Adaptation Layer (IUA), and V5.2-User Adaptation Layer (V5UA). The
SS7 adaptation protocols are applicable to existing SCN signaling systems and
protocols.
5-1

Chapter 5 SIGTRAN
5.1.2 Terminology
I. Media Gateway (MG)
When media streams are transferred from the SCN to the packet-switching network,
the MG terminates SCN media streams, puts them into data packets (if the media data
is not in form of packets), and then transfers the data packets to the packet-switching
network. When media steams are transmitted from the packet-switching network to the
SCN, reverse processes are performed.
II. Media Gateway Controller (MGC)

MGC processes registration and management of MG resources. SoftX3000 has MGC
functions.
MGC might have the following capabilities:
z
Authorizing resource usage according to the local strategies.
Terminating and initiating SCN signaling protocols, such as SS7-ISUP and Q.931.
(ISUP is the acronym of ISDN User Part.)
III. Signaling Gateway (SG)

SG, a signaling agent, can receive or transmit internal SCN signaling at the edge of IP
network. The SG in the SS7-Internet gateway can relay, translate or terminate SS7
signaling.
The SG functions might also be integrated into the MG functions.

Figure 5-1 illustrates the SIGTRAN protocol model.
M3UA M2UA
IUA
SUA
M2PA V5UA
SCTP
IP
M3UA: MTP3-User Adaptation Layer
IUA: ISDN Q.921-User Adaptation Layer
M2PA: MTP2-User Peer-to-Peer Adaptation Layer
SCTP: Stream Control Transmission Protocol
Figure 5-1 SIGTRAN protocol model
5-2
M2UA: MTP2-User Adaptation Layer

SUA: SCCP-User Adaptation Layer
V5UA: V5.2-User Adaptation Layer
IP: Internet Protocol

Chapter 5 SIGTRAN
Note:
Currently SoftX3000 does not support MTP2-User Peer-to-Peer Adaptation Layer (M2PA) or SCCP-User
Adaptation Layer (SUA).
5.1.4 SIGTRAN Implementation in SoftX3000

The SIGTRAN is used in SoftX3000 connection with an SG, for transmission of
narrowband circuit-switched signaling over IP network, for example, SS7 ISUP and
Intelligent Network Application Part (INAP). The SIGTRAN implemented in the
SoftX3000 is illustrated in Figure 5-2.
Signaling stream
Media stream
SIGTRAN/SS7
SS7
SG
H.248
IP c ore network
PSTN
Circ uit-switc hing network
Sof tX3000
TMG/UMG
Pack et-s witching network
Figure 5-2 SIGTRAN implementation in SoftX3000

The SIGTRAN is implemented on the interface between the SG and the SoftX3000 to
transmit narrowband SCN signaling over IP network. The working principle of the
SIGTRAN is as follows:
SCN signaling is accessed by the SG, and media streams (such as trunk voice channel)
are accessed by the trunk media gateway (TMG).The SG packs the inter-layer
primitives (or narrowband signaling) and transmits them to the SoftX3000. The
SoftX3000 processes the signaling and controls the bearer connection of the MG
through a media gateway control protocol (H.248), thereby achieving the interworking
between the circuit switched network and the packet switched network. In this model,
the SIGTRAN stack is employed between the SG and the SoftX3000.
Depending on the location of the SG, SoftX3000 provides three modes to interwork with
SCN signaling:
z
SG embedded in the SoftX3000
The SoftX3000 provides Time Division Multiplex (TDM) interface to the SCN and uses
MTP, not SIGTRAN, for signaling transmission.
5-3

z
Chapter 5 SIGTRAN
SG embedded in the TMG or universal media gateway (UMG)
The TMG or UMG with an embedded SG converts and adapts SCN signaling,
encapsulates the signaling into IP packets, and transmits the packets to the SoftX3000
across the IP network. The signaling transmission is based on M2UA, IUA, or V5UA of
the SIGTRAN.
z
Independent SG
The SG converts and adapts SCN signaling, encapsulates the signaling into IP packets,
and transmits the packets to the SoftX3000 across the IP network. Signaling
transmission is based on M3UAof the SIGTRAN.
5.2 SCTP
5.2.1 Introduction
Before the SCTP is stipulated, UDP and TCP carry SS7 signaling traffic over IP network.
UDP is a connectionless transport protocol and cannot guarantee the quality of
transmission required by SS7 signaling. TCP is a connection-oriented transport
protocol and guarantees the reliable transmission of signaling. TCP, however, has
some disadvantages such as line header block, poor real-time ability, difficult
multi-homing implementation, and vulnerable to denial of service (DOS) attacks. To
solve those problems, the IETF put forward a connection-oriented, packet-based, and
transmission-reliable protocolSCTP. The SCTP removes those problems existing in
the TCP and thus provides a higher reliability of signaling transmission. The design of
the SCTP includes appropriate congestion avoidance behavior and resistance to
flooding and masquerade attacks. The SCTP has optimized real-time performance and
supports the multi-homing function. Therefore, SCTP is chosen as the transport
protocol in the SIGTRAN protocol stack.
The SCTP is a transport-layer protocol above which SCTP user applications are
operating and below which a packet-based network is lying. In the SIGTRAN
implementation, the upper-layer users of the SCTP are SCN signaling adaptation
modules, for example, M2UA, M3UA, IUA, and V5UA. The underlying layer of the
SCTP is the IP network. The position of the SCTP in the SIGTRAN protocol stack is
5.2.2 Terminology
I. Transport Address
A transport address is defined by the combination of an IP address, a transport-layer
protocol type, and a transport-layer port number. Because the SCTP is transmitted on
5-4

Chapter 5 SIGTRAN
the IP, an SCTP transport address is the combination of an IP address and an SCTP
port number. SCTP port number is used for the identification of the users at the same
address, and it is identical to TCP port number in the concept. For example, the IP
address 10.105.28.92 and SCTP port number 1024 indicate a transport address, while
10.105.28.93 and 1024 mean another transport address. Similarly 10.105.28.92 and
1023 indicate a different transport address.
II. Host and Endpoint

z
Host
A host is configured with one or multiple IP addresses. It is a typical physical entity.
SCTP Endpoint
Endpoint is one of the basic concepts of SCTP. An endpoint is the logical

sender/receiver of SCTP packets. It is a typical logical entity.
A transport address (the combination of an IP address and an SCTP port number)
uniquely identifies an endpoint. An endpoint might be defined by several transport
addresses. For the same destination endpoint, all transport addresses used by the
SCTP endpoint must use the same port number, but can use multiple IP addresses.
Notes:
A host can have more than one endpoint.
III. Association and Stream

z
Association
An association is the logical relationship or said channel, established between two

SCTP endpoints for data transmission, by using the four-way handshake mechanism
prescribed in SCTP.
As prescribed in the SCTP, two SCTP endpoints must not have more than one SCTP
association between them at any given time. Because an association depends on the
transport addresses used by the endpoints in the association, an SCTP association can
be uniquely identified by the combination of four parameters, namely local IP address,
local SCTP port number, peer IP address, and peer SCTP port number. In SoftX3000,
an association might be an M2UA link, an M3UA link, a V5UA link, or an IUA link.
z
Stream
The term Stream used in SCTP refers to a sequence of user messages that are to be
delivered to the upper-layer protocol in order with respect to other messages within the
same stream. Strictly speaking, stream, in an SCTP association, is a uni-directional
5-5

Chapter 5 SIGTRAN
logical channel established from one endpoint to the other associated endpoint. An
association is composed of several uni-directional streams, any of which is
independent of the others. Stream IDs identifies the streams. Each stream transmits
data without influence from other streams.
Note:
z
Multiple streams might be in the same stream. The number of available streams depends on the
negotiation of the endpoints when an association is established between them. A stream cannot
belong to more than one association. The number of outgoing streams might be different from that of
incoming streams.
The data to be delivered in sequence must be conveyed within a single stream.
IV. Path and Primary Path

z
Path
A path is a route taken by the SCTP packets sent by one SCTP endpoint to a
specific destination transport address of its peer SCTP endpoint. Sending to
different destination transport addresses does not necessarily guarantee getting
separate paths.
Primary path
A primary path is the destination and source address that will be put into a packet
outbound to the peer endpoint by default. If there is more than one destination address
to an endpoint, the SCTP endpoint is multi-homed. The definition includes the source
address since an implementation might wish to specify both destination and source
address to better control the return path taken by reply chunks and on which interface
the packet is transmitted when the data sender is multi-homed.
Both SCTP endpoints in an SCTP association can be configured with several IP
addresses, and thus there are several paths between the associated endpoints. This is
the multi-address feature of an SCTP association. This is also the greatest difference of
SCTP from TCP.
An SCTP association might include several paths but has only one primary path. As
shown in Figure 5-3, an endpoint on the MGC (for example, SoftX3000) has two
transport addresses (10.11.23.14:2905 and 10.11.23.15:2905); an endpoint on the SG
also has two transport addresses (10.11.23.16:2904 and 10.11.23.17:2904).
5-6

10.11.23.14
Chapter 5 SIGTRAN
10.11.23.16
Path0
Path2
MGC
10.11.23.15
Path1
Path3
SG
10.11.23.17
Figure 5-3 Multi-homing function of SCTP

The two endpoints determine an association that includes four paths, namely Path 0,
Path 1, Path 2, and Path 3. Selections of the paths depend on your data configurations.
For example, you configure the four paths and set Path 0 as the primary path, as shown
in Figure 5-4.
z
Path 0: The local transport address 1 (10.11.23.14:2905) transmits SCTP packets

to the peer transport address 1 (10.11.23.16:2904).



The SCTP working principles for data transmission from an endpoint are as follows:
By default, an endpoint should always transmit SCTP packets through the primary path
from a local transport address A to the peer endpoint. When the primary path becomes
faulty, the SCTP automatically switches over to one of the backup paths. The SCTP
preferentially switches the transport addresses of the peer endpoint; furthermore, the
SCTP switches the transport addresses of the local endpoint.
The SCTP defines heartbeat messages. When a path is idle, the local SCTP user
requires the SCTP to generate a heartbeat message and sends the message through
that path to the peer endpoint which must immediately return a heartbeat
acknowledgement message. This mechanism serves to precisely measure the
round-trip time (RTT) and helps to monitor the reachability of the association as well as
holding the active state of the SCTP association.
5-7

Chapter 5 SIGTRAN
Figure 5-4 Data configuration for determining path selections

1)
TSN and SSN
TSN
The SCTP uses a transmission sequence number (TSN) mechanism to acknowledge

data transmission. An endpoint in an association assigns a 32-bit sequence number,
which is based on an initial TSN, to each data chunk sent by the local end to permit the
receiving SCTP endpoint to acknowledge its receipt.
TSN is maintained on the basis of association.
Note:
In the TCP, the TSN mechanism helps to achieve acknowledged transmission and sequenced-delivery of
data. When it is found that TSNs are not continuous, the TCP retransmits the data that will not be delivered
to an upper-layer user above the TCP layer until the TSNs are sequential. This mechanism results in the
dissatisfaction of the TCP for low-delay transmission of SS7 signaling traffic.
SSN
The SCTP assigns a 16-bit stream sequence number (SSN) to each data chunk sent in
a stream by the local end, to ensure sequenced transmission in the stream.
5-8

Chapter 5 SIGTRAN
At the establishment of an association, the SSNs in all streams are numbered from 0.
When an SSN reaches 65535, the subsequent SSN is numbered from 0 again.
The assignments of TSN and SSN are independent to each other.
2)
CWND
SCTP is a sliding window protocol. Congestion window (CWND) is maintained on the

basis of each destination address and will be adjusted according to the network
condition. Once the length of the unacknowledged message sent from the destination
address is greater than the CWND value, the endpoint will stop transmitting data to this
address.
3)
RWND
Receiver window (RWND) indicates the size of the receivers inbound buffer in an
association. During the association establishment, both data sender and receiver will
exchange their RWND value with each other. The two RWND values will vary with data
transmission and acknowledgement. This is, in effect, restricting the amount of data it
can transmit. If the RWND is equal to 0, the data sender can always have one packet in
flight to the receiver, which allows the sender to probe for a change in buffer of the data
receiver by means of the acknowledgement message.
4)
TCB
Transmission control block (TCB) is an internal data structure created by an SCTP

endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB
contains all the status and operational information for the endpoint to maintain and
manage the corresponding association.
5.2.3 SCTP Functions

As shown in Figure 5-5, the SCTP has the following functions:
z
Association startup and takedown
Sequenced delivery within streams
User data fragmentation
Acknowledgement and congestion avoidance
Chunk bundling
Packet validation
Path management
5-9

Chapter 5 SIGTRAN

Association
startup
and
takedown

Chunk bundling
Packet validation
Path management
Figure 5-5 SCTP functions

1)
Association startup and takedown
An association is initiated by a request from an SCTP user, for example, M2UA or

M3UA. Compared with a TCP connection, the startup of an SCTP association is
relatively complicated. The startup uses a four-way handshake and employs a cookie
mechanism. Cookie is a data chunk containing the initialization information and
encryption information about the endpoint, which is processed and exchanged
between the communication parties during the startup of the association to enhance
protocol security and provide protection against potential DoS or masquerade attacks.
SCTP provides graceful close (that is, shutdown) for an active association on request
from the SCTP user. SCTP also allows ungraceful close (that is, abort) either on
request from the user or as a result of an error condition detected within the SCTP
layer.
SCTP does not support a half-open state wherein one side might continue sending data
while the other end is closed. When either endpoint performs a shutdown, the
association on each peer will stop accepting request primitives from its user.
2)
SCTP can transport the datagrams in sequence. The datagrams sent in sequence must
be put in one stream, and the stream is the basis for sequenced transmission.
With streams, SCTP provides two mechanisms respectively for data acknowledgement
and sequenced delivery. SCTP uses the TSN mechanism to achieve acknowledged
transmission of data, and uses stream number and SSN to achieve sequenced delivery
of data. When the SSNs that SCTP receives are sequential, SCTP delivers the data to
the SCTP user, without waiting for continuity of TSNs of the data.
5-10

Chapter 5 SIGTRAN
When the stream is blocked, the next expected in-sequence SCTP user message can
be delivered from other streams.
SCTP also provides non in-sequence delivery service. User messages sent using this
mechanism are delivered to the SCTP user as soon as they are received, without
guarantee of in-sequence delivery.
3)
SCTP detects the path maximum transmission unit (PMTU) on the transport path,
based on which SCTP fragments and then packetizes large user data to avoid multiple
fragmentations and reassemblies at the IP layer. The purpose is to reduce the data load
on the IP layer.
z
Before transmission, SCTP fragments user messages to ensure that the SCTP
packet passed to the lower layer conforms to the PMTU.
On receipt, SCTP reassembles the fragments into complete messages before

passing them to the SCTP user.
4)
Acknowledgement and retransmission are measures taken by a protocol to guarantee

transmission reliability. So does SCTP. The acknowledgement mechanism is the basis
for SCTP to guarantee transmission reliability. Congestion avoidance follows the
window mechanism implemented in TCP, used for appropriate flow control.
z
SCTP assigns, in sequence, a TSN to each user data fragment or un-fragmented

message before delivering it to the lower layer.
The TSN is independent of any SSN assigned at the stream level. The TSN serves
to ensure the reliability of the transmission. The SSN is used to guarantee
sequenced delivery of messages within streams.
TSN and SSN functionally separate reliable transmission from sequenced delivery.
The receiver acknowledges all TSNs received, even if there are gaps in the
sequence.
Packet retransmission function is responsible for acknowledgement of TSNs as

well as resistance to congestion.
5)
Chunk bundling
If short-length user data is attached with a large SCTP message header, the
transmission efficiency is very low. Therefore, SCTP bundles several pieces of user
data into the same SCTP packet to improve the utilization ratio of the bandwidth.
z
An SCTP packet consists of a common header followed by one or more chunks.

Each chunk might contain either user data or SCTP control information.
The SCTP user has the option to request bundling of more than one user
messages into a single SCTP packet.
During a congestion or retransmission, an SCTP implementation might still

perform bundling to improve the efficiency even though the user has requested
that SCTP not bundle.
5-11

6)
Chapter 5 SIGTRAN
Packet validation
Packet validation is the basis for SCTP to provide errorless transmission. The common
header of an SCTP packet includes a Verification Tag field and a 32-bit Checksum field.
The Verification Tag value is chosen by each end of the association during association
startup. The receiver discards packets received without the expected Verification Tag
value, as a protection against blind masquerade attacks and against stale SCTP
packets from a previous association.
The sender of each SCTP packet sets the checksum to provide additional protection
against data corruption in the network. The receiver of an SCTP packet with an invalid
checksum discards the packet.
7)
Path management
The sending SCTP user can use a set of transport addresses as destinations for SCTP
packets. The SCTP path management function chooses a destination transport
address for each outgoing SCTP packet based on the SCTP users instructions and the
currently perceived reachability status of the eligible destination set. The path
management function monitors reachability through heartbeats when other packet
traffic is inadequate to provide this information and advises the SCTP user when
reachability of any far-end transport address changes. The path management function
is also responsible for reporting the eligible set of local transport addresses to the far
end during association startup, and for reporting the transport addresses returned from
the far end to the SCTP user.
At association startup, a primary path is defined for each SCTP endpoint, and is used
for normal sending of SCTP packets.
On the receiving end, the path management is responsible for verifying the existence of
a valid SCTP association to which the inbound SCTP packet belongs before passing it
for further processing.
5.2.4 SCTP Primitives

The upper layer protocols (ULP) requests for services by passing primitives to SCTP
and receives notifications from SCTP for various events.
SCTP primitive description uses the following format:
Primitive name: mandatory attributes, [optional attributes]
Returned result: mandatory attributes, [optional attributes]
5-12

Chapter 5 SIGTRAN
I. Request Primitives Sent from SCTP User to SCTP

There are 16 request primitives sent from the SCTP user to SCTP. The meanings of the
request primitives are shown in Table 5-1.
Table 5-1 SCTP request primitives
Primitive
INITIALIZE
Function
This primitive allows SCTP to initialize its internal data structures and allocate
necessary resources for setting up its operation environment. Once SCTP is
initialized, ULP can communication directly with other endpoints without
re-invoking this primitive.
SCTP will return to the ULP an event number (instance) of the SCTP
association to be processed locally.
This primitive allows the upper layer to initiate an association to a specific peer
endpoint. The peer endpoint shall be specified by one of the transport
addresses which defines the endpoint. If the local SCTP instance has not been
initialized, the ASSOCIATE is considered an error.
ASSOCIATE
An association ID, which is a local handle to the SCTP association, will be

returned on successful establishment of the association. If SCTP is not able to
open an SCTP association with the peer endpoint, an error is returned. If an
association is successful, other association parameters might be returned,
including the complete destination transport addresses of the peer as well as
the outbound stream count of the local endpoint. One transport address from
the returned destination addresses will be selected by the local endpoint as
default primary path for sending SCTP packets to this peer. The returned
destination transport address list can be used by the SCTP user to change the
default primary path or to force sending a packet to a specific transport address.
Returned result: Association ID
This primitive is used to gracefully close an association. Any locally queued user
data will be delivered to the peer. The association will be terminated only after
the peer acknowledges all the SCTP packets sent.
SHUTDOWN
Returned result indicates whether the association is successfully closed. A

success code will be returned on successful termination of the association. If
attempting to terminate the association results in a failure, an error code shall be
returned.
This primitive is used to ungracefully close an association. Any locally queued
user data will be discarded and an ABORT chunk is sent to the peer.
ABORT
SEND
Returned result indicates whether the association is successfully closed. A

success code will be returned on successful abortion of the association. If the
action of attempting to abort the association results in a failure, an error code
shall be returned.
This primitive allows the SCTP user to notify SCTP of sending data to a
destination transport address in a specified stream ID.
Returned result indicates whether the data is successfully sent.
5-13

Chapter 5 SIGTRAN
Primitive
Function
This primitive allows the ULP to instruct the local SCTP to use the specified
destination transport address as primary path for sending packets.
SET PRIMARY
Returned result is a result code, indicating whether this operation is successfully

performed. If the specified destination transport address is not present in the
destination transport address list returned earlier in an ASSOCIATE command
or COMMUNICATION UP notification, an error shall be returned.
This primitive is used to read available user message in the SCTP queue into
the buffer specified by the SCTP user.
RECEIVE
The size of the message read, in bytes, will be returned. It might, depending on
the specific implementation, also return other information such as the senders
address, the stream ID on which it is received, and whether there are more
messages available for retrieval. For ordered messages, their SSN might also
be returned.
This primitive is used to return a data block containing the following information:
STATUS
Association connection state
Destination transport address list
Destination transport address reachability states
Current receiver window size
Current congestion window size
Number of unacknowledged DATA chunks
Number of received DATA chunks
Primary path
Most recent SRTT on primary path
RTO on primary path
Returned result is the state of the information that is required to return.

CHANGE
HEARTBEAT
REQUEST
HERATBEAT
GET SRTT
REPORT
This primitive allows the ULP to instruct the local endpoint to enable or disable
heartbeat on a specified destination transport address.
Returned result indicates the performance of this operation. If the destination
transport address is not idle, heartbeat will not take place.
This primitive allows the ULP to instruct the local endpoint to perform a
heartbeat on a specified destination address of a given association.
Returned result indicates whether the transmission of the HEARTBEAT chunk
to the destination address is successful.
This primitive allows the ULP to instruct the local SCTP to report the current
SRTT measurement on a specified destination transport address of a given
association.
Returned result is an integer containing the most recent SRTT in milliseconds.
5-14

Chapter 5 SIGTRAN
Primitive
SET FRAILURE
THRESHOLD
Function
This primitive allows the local SCTP to customize the reachability failure
detection threshold for a specified destination transport address.
Returned result indicates whether the operation is successful.
SET PROTOCOL
PARAMETERS
This primitive allows the local SCTP to customize the protocol parameters.
RECEIVE
UNSENT
MESSAGE
This primitive allows the ULP to instruct the local SCTP to store the received
failure message in the ULP buffer.
RECEIVE
UNACKNOWLED
GED MESSAGE
This primitive allows the ULP to instruct the local SCTP to store the received
unacknowledged failure message in the ULP buffer.
DESTROY
Returned result indicates whether the operation is successful.
Returned result is the number of bytes including the failure message.
Returned result is the number of bytes including the unacknowledged message.

This primitive indicates the SCTP event number (instance) to be destroyed.
(The SCTP event number is generated in the INITIALIZE primitive.)
Returned result indicates whether it is successful.
II. Notification Primitives Sent from SCTP to SCTP User

There are eight notification primitives sent from SCTP to the SCTP user. The meanings
of the notification primitives are shown in Table 5-2.
Table 5-2 SCTP notification primitives
Primitive
Function
When a user message is successfully received and ready for delivery to the
SCTP user, SCTP invokes this primitive to notify the upper-layer user.
DATA ARRIVE
The following information is passed with the notification:

y
Association ID: local handle to the SCTP association.
Stream ID: indicates the stream on which the data is received.
If a message cannot be delivered, SCTP invokes this primitive to notify the

SCTP user.
SEND FAILURE
Data retrieval ID: an identification used to retrieve unsent and

unacknowledged data.
Cause code: indicates the reason of the failure, for example, too long size,
and message lifetime expiration.
5-15

Chapter 5 SIGTRAN
Primitive
Function
When a destination transport address is marked inactive (for example, when
SCTP detects a failure) or marked active (for example, when SCTP detects a
recovery), SCTP invokes this primitive to notify the SCTP user.
NETWORK
STATUS CHANGE

y
Destination transport address: indicates the destination transport address

of the peer endpoint affected by the status change.
New-status: indicates the new status.
When the local SCTP becomes ready to send or receive SCTP packets or when
a lost communication to an endpoint is restored, SCTP invokes this primitive to
notify the SCTP user.
COMMUNCIATION
UP
Status: indicates the type of the event that has occurred.
Destination transport address list: the complete set of transport addresses

of the peer.
Outbound stream count: the maximum number of streams allowed to be

used in this association by the SCTP user.
Inbound stream count: the number of streams that the peer endpoint has
requested with this association. (This might not be the same number as
outbound stream count".)
When SCTP completely loses communication to an endpoint (through

heartbeat) or detects that the endpoint has performed an abort operation, SCTP
invokes this primitive to notify the SCTP user.
COMMUNICATION
LOST
Status: indicates the type of the event that has occurred. The status might
indicate a failure or a normal termination event occurred in response to a
SHUTDOWN or ABORT request.
Data retrieval ID: an identification used to retrieve unsent and

unacknowledged data.
Last acknowledged TSN: the TSN last acknowledged by that peer

endpoint.
Last sent TSN: the TSN last sent to that peer endpoint.
When SCTP receives an ERROR chunk from its peer and decides to notify its
upper-layer user, SCTP invokes this primitive.
COMMUNICATION
ERROR

y
Error info: indicates the type of the error and optionally some additional
information received through the ERROR chunk.
5-16

Chapter 5 SIGTRAN
Primitive
Function
When SCTP detects that the peer has restarted, SCTP invokes this primitive to
notify the SCTP user.
RESTART
The association ID is passed with the notification.

When the local SCTP completes the shutdown procedure, SCTP invokes this
primitive to notify the SCTP user.
SHUTDOWN
COMPLETE
The association ID, local handle to the SCTP association, is passed with the
notification.
5.2.5 SCTP Messages

I. Message Structure
Figure 5-6 shows the structure of an SCTP packet.
16 bits
16 bits
Destination Port Number
Source Port Number
Common
Header
Verification Tag
Checksum
Chunk Type
Chunk Flags
Chunk Length
Chunk #1
Chunk Value
Chunk Type
Chunk Flags
Chunk Length
Chunk #n
Chunk Value
Figure 5-6 Structure of SCTP packet
5-17

Chapter 5 SIGTRAN
An SCTP packet is composed of a common header and several chunks. A chunk

contains either control information or user data. Multiple chunks can be bundled into
one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN
COMPLETE chunks. These chunks must not be bundled with any other chunk in a
packet. If a user message does not fit into one SCTP packet, it can be fragmented into
multiple chunks.
1)
Format of the common header
SCTP common header is composed of a Source Port Number, a Destination Port

Number, a Verification Tag, and a Checksum.
z
Source Port Number: 16 bits
This is the SCTP senders port number. The receiver can use it in combination with the
source IP address, the destination port number, and possibly the destination IP address
to identify the association to which this packet belongs.
z
Destination Port Number (16 bits)
This is the SCTP port number to which this packet is destined. The receiving host will
use this port number to de-multiplex the SCTP packet to the correct receiving endpoint
or application.
z
Verification Tag (32 bits)
When an association is established, the local endpoint generates a random

identification to the association. During association startup, the endpoints exchange
this Tag with each other. On data transmission, the sender must carry the Tag of the
peer in the common header for verification purposes.
z
Checksum (32 bits)
SCTP uses the Adler-32 algorithm to calculate the user data and obtains a 32-bit
checksum which will be carried in the datagram. The receiver performs the same
operation and checks whether the new checksum is equal to the carried one to judge
whether the user data is destroyed.
2)
Format of chunk fields
Each chunk is formatted with a Chunk Type field, a Chunk Flags field, a Chunk Length
field, and a Chunk Value field.
z
Chunk Type (8 bits)
This field identifies the type of information contained in the Chunk Value field. Table 5-3
lists the values of Chunk Types.
Table 5-3 SCTP chunk types
ID
Chunk type
DATA (payload
data)
Description
Transmitted user data.
5-18

ID
Chapter 5 SIGTRAN
Chunk type
Description
INIT
This chunk is used to initiate an SCTP association between two

endpoints.
INIT ACK
This chunk is used to acknowledge the initiation message (INIT) of an

SCTP association.
SACK
This chunk is sent to the peer endpoint to acknowledge received

DATA chunks and to inform the peer endpoint of gaps in the received
subsequences of DATA chunks.
HEARTBEAT
An endpoint sends this chunk to its peer endpoint to probe the

reachability of a particular destination transport address defined in the
present association.
HEARTBEAT
ACK
Response to a HEARTBEAT chunk.
ABORT
This chunk is sent to the peer of an association to close the

association.
SHUTDOWN
An endpoint in an association uses this chunk to initiate a graceful

close of the association with its peer.
SHUTDOWN
ACK
This chunk is used to acknowledge the receipt of the SHUTDOWN

chunk at the completion of the shutdown process.
ERROR
An endpoint sends this chunk to its peer endpoint to notify it of certain

error conditions.
10
COOKIE ECHO
This chunk is used only during the initialization of an association. It is

sent by the initiator of an association to its peer to complete the
initialization process.
11
COOKIE ACK
This chunk is used to acknowledge the receipt of a COOKIE ECHO

chunk.
12
ECNE
Reserved for explicit congestion notification echo
13
CWR
Reserved for congestion window reduced
14
SHUTDOWN
COMPLETE
This chunk is used to acknowledge the receipt of the SHUTDOWN

ACK chunk at the completion of the shutdown process.
15 to 62
63
Reserved by the IETF

IETF-defined Chunk Extensions
64 to
126
127
128 to
190
191
192 to
254
255

5-19

Chapter 5 SIGTRAN
Chunk Types are encoded such that the highest-order two bits specify the action that
must be taken if the processing endpoint does not recognize the Chunk Type. Table 5-4
shows the meanings of the bit combinations.
Table 5-4 Meanings of the highest-order two bits of Chunk Type
Bits (highest-order
two bits)
Meaning
00
Stop processing this SCTP packet and discard it. Do not process any further
chunks within it.
01
chunks within it. Report to the initiating endpoint the unrecognized parameter
either in an ERROR or in the INIT ACK.
10
Skip this chunk and continue processing.
11
Skip this chunk and continue processing. Report to the initiating endpoint the
unrecognized parameter either in an ERROR or in the INIT ACK.
Chunk Flags (8 bits)
The usage of these bits depends on the chunk type as given by the Chunk Type. Unless
otherwise specified, they are set to zero on transmit and are ignored on receipt.
z
Chunk Length (16 bits)
This value represents the size of the chunk including the Chunk Type, Chunk Flags,
Chunk Length, and Chunk Value fields. The length is expressed in a binary number.
z
Chunk Value (variable length)
The Chunk Value field contains the actual information to be transferred in the chunk.
The contents depend on the Chunk Type. The length of the Chunk Value is variable.
Note:
The total length of a chunk (including Type, Length, and Value fields) must be a multiple of four bytes. If the
length of the chunk is not a multiple of four bytes, the sender must pad the chunk with all zero bytes and
this padding is not included in the chunk length field. The sender should never pad with more than three
bytes. The receiver must ignore the padding bytes.
3)
Format of optional and variable-length parameters
Chunk values of SCTP control chunks (except DATA chunk) consist of a

chunk-type-specific header of required fields, followed by zero or more parameters.
The optional and variable-length parameters contained in a chunk are defined in a
Type-Length-Value format as shown in Figure 5-7.
5-20

Chapter 5 SIGTRAN
16 bits
16 bits
Parameter Length
Parameter Type
Parameter Value
Figure 5-7 Format of optional and variable-length parameters

z
Chunk Parameter Type (16 bits)
This field identifies the type of the parameter. It takes a value from 0 to 65534. The
value of 65535 is reserved for IETF-defined extensions.
Chunk Parameter Types are encoded such that the highest-order two bits specify the
action that must be taken if the processing endpoint does not recognize the Parameter
Type. Table 5-5 shows the meanings of the bit combinations.
Table 5-5 Meanings of the highest-order two bits of Chunk Parameter Type
Bits (highest-order
two bits)
Meaning
00
chunks within it.
01
chunks within it. Report the unrecognized parameter either in an ERROR or in
the INIT ACK.
10
Skip this chunk and continue processing.
11
Skip this chunk and continue processing. Report to the initiating endpoint the
unrecognized parameter either in an ERROR or in the INIT ACK.
Chunk Parameter Length (16 bits)
This field contains the size of the parameter, in bytes, including the Parameter Type,
Parameter Length, and Parameter Value fields. Therefore, a parameter with a
zero-length Parameter Value field would have a Length field of 4. The Parameter
Length does not include any padding bytes.
z
Chunk Parameter Value (variable-length)
This field contains the actual information to be transferred in the parameter.
5-21

Chapter 5 SIGTRAN
Note:
The total length of a parameter (including Type, Length, and Value fields) must be a multiple of four bytes.
If the length of the parameter is not a multiple of four bytes, the sender pads the parameter at the end with
all zero bytes. The length of the padding is not included in the parameter length field. A sender should not
pad with more than three bytes. The receiver must ignore the padding bytes.
II. Format of SCTP Chunks

1)
Payload data (DATA)
Figure 5-8 shows the format for the DATA chunk.

0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 0
Reserve
U B E
Length
TSN
SSN
Stream ID
Payload Protocol Identifier
User Data
Figure 5-8 Format of DATA

z
Type
The Type of the chunk is encoded to be 0.

z
Reserved (5 bits)
The Reserved bits are set to all zeros and ignored by the receiver.
z
U bit (1 bit)
The unordered bit, if set to 1, indicates that this is an unordered DATA chunk, and
there is no stream sequence number assigned to this DATA chunk. Therefore, the
receiver must ignore the SSN field.
After re-assembly (if necessary), unordered DATA chunks are dispatched to the SCTP
user by the receiver without any attempt to re-order.
If an unordered user message is fragmented, each fragment of the message must have
its U bit set to 1.
5-22

Chapter 5 SIGTRAN
B bit
The beginning fragment bit, if set, indicates the first fragment of a user message.
E bit
The ending fragment bit, if set, indicates the last fragment of a user message.
An unfragmented user message shall have both the B and E bits set to 1.
Setting both B and E bits to 0 indicates a middle fragment of a multi-fragment user
message. When a user message is fragmented into multiple chunks, the receiver uses
the TSNs to reassemble the message. This means that the TSNs for each fragment of
a fragmented user message must be strictly sequential. Table 5-6 shows the meanings
of the B and E bits.
Table 5-6 Meanings of the B and E bits
B
Meaning
First piece of a fragmented user message
Middle piece of a fragmented user message
Last piece of a fragmented user message
Unfragmented message
Length (16 bits)
This field indicates the length of the DATA chunk in bytes from the beginning of the type
field to the end of the user data field excluding any padding. A DATA chunk with no user
data field will have Length set to 16 (indicating 16 bytes).
z
TSN (32 bits)
This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to
4294967295 (232 - 1). TSN wraps back to 0 after reaching 4294967295.
z
Stream ID
This field identifies the stream to which the following user data belongs.
z
SSN (16 bits)
This value represents the stream sequence number of the following user data within the
stream. The valid range of this field is 0 to 65535. When a user message is fragmented
by SCTP for transport, the same sequence number must be carried in each of the
fragments of the message.
z
Payload Protocol Identifier (32 bits)
This value represents an application (or upper layer) specified protocol identifier. The
upper layer (SCTP user) passes this value to SCTP and sends it to the peer. SCTP
does not use this identifier. Certain network entities and the peer application use this
5-23

Chapter 5 SIGTRAN
identifier to identify the type of information being carried in this DATA chunk. This field
must be sent even in fragmented DATA chunks to make sure it is available for agents in
the middle of the network.
The value 0 indicates no application identifier is specified by the upper layer for this
payload data.
User Data (variable length)
This is the payload user data. This field must be padded to be a multiple of four bytes. A
sender should not pad with more than three bytes. The receiver must ignore the
padding bytes.
2)
Initiation (INIT)
This chunk is used to initiate an SCTP association between two endpoints. Figure 5-9
shows the format of the INIT chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 1
Length
Chunk Flags
Initiate Tag
Advertised Receiver W indow Credit
Number of Outbound Streams
Number of Inbound Streams
Initial TSN
Optional/Variable-Length Parameters
Figure 5-9 Format of INIT

The INIT chunk contains the following parameters. Unless otherwise noted, each
parameter must only be included once in the INIT chunk.
Fixed parameters include Initiate Tag, Advertised Receiver Window Credit, Number of
Outbound Streams, Number of Inbound Streams, and Initial TSN.
Variable parameters include IPv4 Address, IPv6 Address, Cookie Preservative, ECN
Capable, Host Name Address, and Supported Address Type.
z
Chunk Flags
The Chunk Flags field in INIT is reserved and all bits in it should be set to 0. The
sequence of parameters within an INIT can be processed in any order.
z
Initiate Tag (32 bits)
5-24

Chapter 5 SIGTRAN
The receiver of the INIT records the value of the Initiate Tag parameter. This value must
be placed into the Verification Tag field of every SCTP packet that the receiver of the
INIT transmits within this association.
The Initiate Tag is allowed to take any value except 0. If the value of the Initiate Tag in a
received INIT chunk is found to be 0, the receiver must treat it as an error and close the
association by transmitting an ABORT.
z
Advertised Receiver Window Credit (a_rwnd, 32 bits)
This value represents the dedicated buffer space, in number of bytes, the sender of the
INIT has reserved in association with this window. During the life of the association this
buffer space should not be lessened (that is, dedicated buffers taken away from this
association); however, an endpoint might change the value of a_rwnd it sends in SACK
chunks.
z
Number of Outbound Streams (OS)
This field defines the number of outbound streams the sender of this INIT chunk wishes
to create in this association. The value of 0 must not be used. A receiver of an INIT with
the OS value set to 0 will abort the association.
z
Number of Inbound Streams (MIS)
This defines the maximum number of streams the sender of this INIT chunk allows the
peer end to create in this association. The value of 0 must not be used. A receiver of an
INIT with the MIS value of 0 will abort the association.
z
Initial TSN
This field defines the initial TSN that the sender will use. This field might be set to the
value of the Initiate Tag field.
z
IPv4 Address
This field contains an IPv4 address of the sending endpoint. It is binary encoded. An
INIT chunk might contain several IPv4 or IPv6 addresses or a combination of
addresses.
z
IPv6 Address
This field contains an IPv6 address of the sending endpoint. It is binary encoded. An
INIT chunk might contain several IPv4 or IPv6 addresses or a combination of
addresses. A sender must not use an IPv4-mapped IPv6 address; instead, the sender
can use an IPv4 Address Parameter for an IPv4 address.
Combined with the Source Port Number in the SCTP common header, the value
passed in an IPv4 or IPv6 Address parameter indicates a transport address that the
sender of the INIT will support for the association being initiated. That is, during the
lifetime of this association, this IP address can appear in the source address field of an
IP datagram sent from the sender of the INIT, and can be used as a destination address
of an IP datagram sent from the receiver of the INIT. When the INIT sender is
5-25

Chapter 5 SIGTRAN
multi-homed, more than one IP Address parameter can be included in an INIT chunk.
Moreover, a multi-homed endpoint might have access to different types of network, and
thus more than one address type can be present in one INIT chunk. That is, IPv4 and
IPv6 addresses are allowed in the same INIT chunk.
If the INIT contains at least one IP Address parameter, the source address of the IP
datagram containing the INIT chunk and any additional address provided within the
INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not
contain any IP Address parameters, the endpoint receiving the INIT must use the
source address associated with the received IP datagram as its sole destination
address for the association.
z
Cookie Preservative
The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for
a longer life-span of the State Cookie. This parameter should be added to the INIT
chunk by the sender when it re-attempts establishing an association with a peer to
which its previous attempt of establishing the association failed due to a stale cookie
operation error. The receiver might choose to ignore the suggested cookie life-span
increase for its own security reasons.
The Cookie Preservative parameter contains a 32-bit Suggested Cookie Life-span
Increment parameter that indicates to the receiver how much increment in milliseconds
the sender wishes the receiver to add to its default cookie life-span.
z
Host Name Address
The sender of INIT uses this parameter to pass its Host Name (in place of its IP
addresses) to its peer. The peer is responsible for resolving the name. Using this
parameter might make it more likely for the association to work across a network
address translation (NAT) box.
z
Host Name
This variable-length field contains a host name defined according to host name syntax
in RFC1123. The method for resolving the host name is out of scope of SCTP.
At least one null terminator is included in the Host Name string and must be included in
the length.
z
Supported Address Types
The sender of INIT uses this parameter to list all the address types it can support.
z
Address Type
This parameter is filled with the type value of the corresponding address (for example,
IPv4 = 5, IPv6 = 6, Hostname = 11).
3)
Initiation Acknowledgement (INIT ACK)
The INIT ACK chunk is used to acknowledge the initiation of an SCTP association.
5-26

Chapter 5 SIGTRAN
Figure 5-10 shows the format of the INIT ACK chunk. The parameter part of INIT ACK is
formatted similarly to the INIT chunk. It uses two extra variable parameters: State
Cookie and Unrecognized Parameter.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 2
Length
Chunk Flags
Initiate Tag
Advertised Receiver Window Credit
Number of Inbound Streams
Number of Outbound Streams

Initial TSN
Optional/Variable-Length Parameters
Figure 5-10 Format of INIT ACK

z
Initiate Tag (32 bits)
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value
must be placed into the Verification Tag field of every SCTP packet that the receiver of
the INIT ACK transmits within this association.
The Initiate Tag is allowed to take any value except 0. If the value of the Initiate Tag in a
received INIT ACK chunk is found to be 0, the receiver must treat it as an error and
close the association by transmitting an ABORT.
z
Advertised Receiver Window Credit (32 bits)
This value represents the dedicated buffer space, in number of bytes, the sender of the
INIT ACK has reserved in association with this window. During the life of the
association this buffer space should not be lessened.
z
Number of Outbound Streams (OS, 16 bits)
This field defines the number of outbound streams the sender of this INIT ACK chunk
wishes to create in this association. The value of 0 must not be used. A receiver of an
INIT ACK with the OS value set to 0 will destroy the association discarding its TCB.
z
Number of Inbound Streams (MIS, 16 bits)
This defines the maximum number of streams the sender of this INIT ACK chunk allows
the peer end to create in this association. The value of 0 must not be used. A receiver of
an INIT ACK with the MIS value set to 0 will destroy the association discarding its TCB.
z
Initial TSN (32 bits)
5-27

Chapter 5 SIGTRAN
This field defines the initial TSN that the INIT ACK sender will use. This field might be
set to the value of the Initiate Tag field.
z
IPv4 Address and IPv6 Address
Combined with the Source Port Number in the SCTP common header, the value
passed in an IPv4 or IPv6 Address parameter indicates a transport address that the
sender of the INIT ACK will support for the association being initiated. That is, during
the lifetime of this association, this IP address can appear in the source address field of
an IP datagram sent from the sender of the INIT ACK, and can be used as a destination
address of an IP datagram sent from the receiver of the INIT ACK. When the INIT ACK
sender is multi-homed, more than one IP Address parameter can be included in an INIT
chunk. Moreover, a multi-homed endpoint might have access to different types of
network, and thus more than one address type can be present in one INIT chunk. That
is, IPv4 and IPv6 addresses are allowed in the same INIT chunk.
If the INIT ACK contains at least one IP Address parameter, the source address of the
IP datagram containing the INIT ACK chunk and any additional address provided within
the INIT ACK can be used as destinations by the endpoint receiving the INIT ACK. If the
INIT ACK does not contain any IP Address parameters, the endpoint receiving the INIT
ACK must use the source address associated with the received IP datagram as its sole
destination address for the association.
z
State Cookie (variable length)
The parameter length depends on the size of cookie. The parameter value must
contain all the necessary state and parameter information required for the sender of
this INIT ACK to create the association, along with a Message Authentication Code.
z
Unrecognized Parameters (variable length)
This parameter is returned to the originator of the INIT chunk when the INIT contains an
unrecognized parameter which has a value that indicates that it should be reported to
the sender. This parameter value field contains unrecognized parameters copied form
the INIT chunk complete with Parameter Type, Length, and Value fields.
4)
Selective Acknowledgement (SACK)
This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to
inform the peer endpoint of gaps in the received subsequences of DATA chunks as
represented by their TSNs. Gaps refer to the cases in which the TSNs of the received
DATA chunks are not sequential.
Figure 5-11 shows the format of the SACK chunk.
5-28

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 3
Length
Chunk Flags
Cumulative TSN Ack

Advertised Receiver Window Credit (a_rwnd)
Number of Gap Ack Blocks = N
Number of Duplicate TSNs = X
Gap Ack Block #1 Start
Gap Ack Block #1 End
Gap Ack Block #n Start
Gap Ack Block #n End

Duplicate TSN 1
Duplicate TSN X
Figure 5-11 Format of SACK

z
Type
The value is 3.
z
Chunk Flags
This parameter is set to all zeros on transmit and ignored on receipt.

z
Cumulative TSN Ack
This parameter contains the TSN of the last DATA chunk received in sequence before a
gap. The subsequent TSN is not received by the endpoint sending the SACK chunk.
This parameter acknowledges the receipt of all TSNs that are less than or equal to this
value.
z
Advertised Receiver Window Credit (a_rwnd)
This field indicates the updated receive buffer space, in bytes, of the sender of this
SACK.
z
Number of Gap Ack Blocks = N
This field indicates the number of Gap Ack Blocks included in this SACK. Each Gap
Ack Block acknowledges the sequence of TSNs received after an insequential TSN. All
TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative
TSN Ack.
z
Number of Duplicate TSNs = X
5-29

Chapter 5 SIGTRAN
This field contains the number of duplicate TSNs the endpoint has received. Each
duplicate TSN is listed following the Gap Ack Block list.
Gap Ack Blocks
These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up
to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All
DATA chunks with TSNs greater than or equal to the sum of Cumulative TSN Ack plus
Gap Ack Block Start and less than or equal to the sum of Cumulative TSN Ack plus Gap
Ack Block End of each Gap Ack Block are assumed to have been received correctly.
Gap Ack Block Start
This field indicates the Start offset TSN for this Gap Ack Block. To calculate the actual
TSN number, the Cumulative TSN Ack is added to this offset number. This calculated
TSN identifies the first TSN, in this Gap Ack Block, that has been received.
Gap Ack Block End
This field indicates the End offset TSN for this Gap Ack Block. To calculate the actual
TSN number, the Cumulative TSN Ack is added to this offset number. This calculated
TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block.
Duplicate TSN
This field indicates the number of times a TSN was received in duplicate since the last
SACK was sent. Every time a receiver gets a duplicate TSN (before sending the SACK),
it adds this TSN to the list of duplicates. The duplicate count is re-initialized to zero after
sending each SACK.
5)
Heartbeat Request (HEARTBEAT)
An SCTP endpoint sends this chunk to its peer endpoint to probe the reachability of a
particular destination transport address defined in the present association.
Figure 5-12 shows the format of the HEARTBEAT chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 4
Chunk Flags
HEARTBEAT Length
Heartbeat Information TLV (Variable-Length)
Figure 5-12 Format of HEARTBEAT

z
Type (8 bits)
The value is 4.
z
This field is set to zero on transmit and ignored on receipt.
5-30

Chapter 5 SIGTRAN
Heartbeat Length
This field is set to the size of the chunk, in bytes, including the chunk header and the
Heartbeat Information field.
Heartbeat Information TLV
The heartbeat parameter field contains Heartbeat Information (Heartbeat Information

TLV). The Heartbeat Information has a variable-length and untransparent data
structure. It is acceptable that only the sender understands the information. Figure 5-13
shows the format of the Heartbeat Information.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Heartbeat Info Type=1
HB Info Length
Sender-specific Heartbeat Info
Figure 5-13 Format of Heartbeat Information

The Sender-specific Heartbeat Info field normally includes information about the
senders current time when this HEARTBEAT chunk is sent and the destination
transport address to which this HEARTBEAT is sent.
6)
Heartbeat Acknowledgement (HEARTBEAT ACK)
An SCTP endpoint sends this chunk to its peer endpoint as a response to a

HEARTBEAT chunk. A HEARTBEAT ACK is always sent to the source IP address of
the IP datagram containing the HEARTBEAT chunk to which this ACK is responding.
Figure 5-14 shows the format of the HEARTBEAT ACK chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 5
Chunk Flags
Heartbeat Ack Length
Heartbeat Information TLV (Variable-Length)
Figure 5-14 Format of HEARTBEAT ACK

z
Type (8 bits)
The value is 5.
z

z
Heartbeat Ack Length
5-31

Chapter 5 SIGTRAN
This field is set to the size of the chunk, in bytes, including the chunk header and the
Heartbeat Information field.
Heartbeat Information TLV
This variable-length field contains the Heartbeat Information parameter of the

Heartbeat Request to which this Heartbeat Acknowledgement is responding. This
parameter field has a variable-length and untransparent data structure.
7)
Abort Association (ABORT)
An SCTP endpoint sends an Abort chunk to the peer of an association to close the
association. The ABORT chunk might contain Cause Parameters to inform the receiver
the reason of the abort. DATA chunks must not be bundled with ABORT. Control chunks
(except for INIT, INIT ACK, and SHUTDOWN COMPLETE) might be bundled with an
ABORT, but they must be placed before the ABORT in the SCTP packet; otherwise,
they will be ignored by the receiver.
If an endpoint receives an ABORT with a format error or for an association that does not
exist, it must silently discard it. Moreover, under any circumstances, an endpoint that
receives an ABORT must not respond to that ABORT by sending an ABORT of its own.
Figure 5-15 shows the format of the ABORT chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 6
Reserved
Length
zero or more Error Causes
Figure 5-15 Format of ABORT

z
Type (8 bits)
The value is 6.
z
The high-order seven bits are reserved. They are set to zero on transmit and ignored on
receipt. The T bit is set to 0 if the sender had a TCB that it destroyed. The T bit is set to
1 if the sender did not have a TCB.
z
Length (16 bits)
This field is set to the size of the chunk, in bytes, including the chunk header and all the
Error Cause fields present.
z
Zero or more Error Causes
This field contains the information contents of the ABORT chunk.

8)
Shutdown Association (SHUTDOWN)
5-32

Chapter 5 SIGTRAN
An endpoint in an association uses this chunk to initiate a graceful close of the

association with its peer. Figure 5-16 shows the format of the SHUTDOWN chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 7
Chunk Flags
Length=8
Cumulative TSN Ack
Figure 5-16 Format of SHUTDOWN

Type
The value is 7.

Length
This field indicates the length of the SHUTDOWN chunk. It is set to 8.

Cumulative TSN Ack
This field contains the TSN of the last chunk received in sequence before any gaps.
Because the SHUTDOWN message does not contain Gap Ack Blocks, it cannot be
used to acknowledge TSNs received out of order.
9)
Shutdown Acknowledgement (SHUTDOWN ACK)
At the completion of a shutdown process, this chunk must be used to acknowledge the
receipt of the SHUTDOWN chunk. Figure 5-17 shows the format of the SHUTDOWN
ACK chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type = 8
Chunk Flags
Length=4
Figure 5-17 Format of SHUTDOWN ACK

Chunk Flags: This field is set to zero on transmit and ignored on receipt.
The SHUTDOWN ACK does not contain other parameters, so the Length is set to 4.
10) Operation Error (ERROR)
An endpoint sends this chunk to its peer endpoint to notify it of certain error conditions.
This chunk contains one or more error causes. An Operation Error is not considered
fatal. A fatal condition is usually reported in an ABORT chunk. Figure 5-18 shows the
format of the ERROR chunk.
5-33

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type =9
Chunk Flags
Length
one or more Error Causes
Figure 5-18 Format of ERROR

z
Type (8 bits)
The value is 9.
z

z
Length (16 bits)
This field is set to the size of the chunk, in bytes, including the chunk header and all the
Error Cause fields present.
Error causes
An error cause parameter is composed of the Cause Code, Cause Length, and
Cause-specific Information fields. Figure 5-19 shows the format of an error cause.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Cause Code
Cause Length
Cause-specific Information
Figure 5-19 Format of Error Cause

Cause-specific information depends on the cause code. Table 5-7 shows their
correspondence.
5-34

Chapter 5 SIGTRAN
Table 5-7 Correspondence between cause-specific information and cause code

Cause code
value
Cause code and meaning
Invalid Stream Identifier:

1
This error cause indicates that

an endpoint received a DATA
chunk sent to a nonexistent
stream.
Missing Mandatory Parameter:

2

one or more mandatory
parameters are missing in a
received INIT or INIT ACK.
Stale Cookie Error:

3
This error cause indicates the

receipt of a valid State Cookie
that has expired.
Parameters
The Stream Identifier (16 bits) field contains the
stream identifier of the DATA chunk received in
error.
The Reserved (16 bits) field is set to all zeros on
transmit and ignored on receipt.
Cause Length = 8
The Number of Missing Parameters (32 bits) field
indicates the number of parameters that are
missing.
The Missing Parameter Type (16 bits) field contains
the missing mandatory parameter number.
Cause Length = 8 + N x 2
The Measure of Staleness (32 bits) field contains
the difference, in microseconds, between the
current time and the time the State Cookie expired.
The sender of this error cause might choose to
report how long past expiration the State cookie is
by including a non-zero value in the Measure of
Staleness field. If the sender does not wish to
provide this piece of information, it should set the
Measure of Staleness field to the value of zero.
Cause Length = 8
Out of Resource:
4

the sender is out of resource.
This is usually sent in
combination with or within an
ABORT.
Unresolvable Address:

the sender is not able to resolve
the specified address
parameter (for example, type of
address is not supported by the
sender). This is usually sent in
combination with or within an
ABORT.
5-35
Cause Length = 4
The Unresolvable Address (variable length) field

contains the complete type, length, and value of the
address parameter that contains the unresolvable
address or host name.
Cause Length has a variable length.

Cause code
value
Chapter 5 SIGTRAN
Cause code and meaning

Unrecognized Chunk Type:
This error cause is returned to

the originator of the chunk if the
receiver does not understand
the chunk and the upper bits of
the Chunk Type are set to 1.
Parameters
The Unrecognized Chunk (variable length) field
contains the unrecognized chunk from the SCTP
packet complete with the chunk type, the chunk
flags, and the chunk length.
The Cause Length field has a variable length.
Invalid Mandatory Parameter:

7

the originator of an INIT or INIT
ACK chunk when one of the
mandatory parameters is set to
an invalid value.
Unrecognized Parameters:

the originator of the INIT ACK
chunk if the receiver does not
recognize one or more optional
parameters in the INIT ACK
chunk.
Cause Length = 4
The Unrecognized Parameters (variable length)

field contains the unrecognized parameters copied
from the INIT ACK chunk. When the sender of the
COOKIE ECHO chunk wishes to report
unrecognized parameters, this error cause is
normally contained in an ERROR chunk bundled
with the COOKIE ECHO chunk when responding to
the INIT ACK.
The Cause Length field has a variable length.
No User Data:
9

the originator of a DATA chunk if
a received DATA chunk has no
user data.
The TSN Value field contains the TSN of the DATA

chunk received with no user data field.
Cause Length = 8
Cookie Received While

Shutting Down:
10
This error cause is usually

returned when a COOKIE
ECHO is received while the
endpoint is in
SHUTDOWN-ACK-SENT state.
Cause Length = 4
11) Cookie Echo (COOKIE ECHO)

This chunk is used only during the initialization of an association. The initiator of an
association sends this chunk to its peer to complete the initialization process. This
chunk must precede any DATA chunk sent within the association, and can be bundled
with one or more DATA chunks in the same SCTP packet.
Figure 5-20 shows the format of the COOKIE ECHO chunk.
5-36

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type =10
Chunk Flags
Length
COOKIE
Figure 5-20 Format of COOKIE EHCO

Type (8 bits)
The value is 10.

This field is set to all zeros on transmit and ignored on receipt.

Length (16 bits)
This field is set to the size of the chunk, in bytes, including the four bytes of the chunk
header and the size of the Cookie.
COOKIE (variable length)
This field must contain the exact cookie received in the State Cookie parameter from
the previous INIT ACK. An implementation should make the cookie as small as
possible to ensure interoperability.
12) Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to
acknowledge the receipt of a COOKIE ECHO chunk. This chunk must precede any
DATA or SACK chunk sent within the association, and can be bundled with one or more
DATA chunks or SACK chunk in the same SCTP packet.
Figure 5-21 shows the format of the COOKIE ACK chunk.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type =11
Chunk Flags
Length=4
Figure 5-21 Format of COOKIE ACK

This field is set to all zeros on transmit and ignored on receipt.
13) Shutdown Complete (SHUTDOWN COMPLETE)
This chunk is used to acknowledge the receipt of the SHUTDOWN ACK chunk at the
completion of shutdown process.
5-37

Chapter 5 SIGTRAN
Figure 5-22 shows the format of the SHUTDOWN COPLIETE chunk.

0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type =14
Reserved
Length=4
Figure 5-22 Format of SHUTDOWN COMPLETE

Type (8 bits)
The highest-order seven bits of the field are reserved. The reserved bits are set to zero
on transmit and ignored on receipt.
T bit (1 bit)
The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have
a TCB, it should set this bit to 1.
III. SCTP endpoint maintenance parameters and recommended values

1)
Parameters necessary for each SCTP instance
Table 5-8 lists the parameters necessary for each SCTP instance.
Table 5-8 Parameters necessary for each SCTP instance
Parameter
Meaning
Associations
A list of current associations and mappings to the data consumers for each
association.
Secret key
A secret key is used by the endpoint to compute the message authentication

code (MAC). This should be a cryptographic quality random number with a
sufficient length. The RFC1750 provides helpful information on selection of
the key.
Address list
The list of IP addresses that this instance has bound. This piece of information
is passed to the peer in INIT and INIT ACK chunks.
SCTP port
The local SCTP port number that the endpoint is bound to.
2)
Parameters necessary about each association
Table 5-9 lists the parameters necessary about each association.

Table 5-9 Parameters necessary about each association
Parameter
Meaning
Peer verification tag
Value of the Initiate Tag field in the received INIT or INIT ACK chunk.
My verification tag
Value of the Initiate Tag field in the sent INIT or INIT ACK chunk.
5-38

Chapter 5 SIGTRAN
Parameter
Meaning
Peer transport
address type
A list of IP addresses to which the instance is bound. This piece of information

is delivered to the peer endpoint in the INIT or INIT ACK chunk.
Primary path
Local SCTP port bound by the endpoint.
Overall error count
The overall association error count.
Overall error
threshold
This threshold is used to control the association. If the overall error count
reaches this threshold, the association will be closed or aborted.
Peer RWND
Current calculated value of the peers RWND.
Next TSN
The next TSN number to be assigned to a new DATA chunk. This is sent in the
INIT or INIT ACK chunk to the peer and incremented each time a DATA chunk
is assigned a TSN (normally just prior to transmit or during fragmentation).
Last received TSN
This is the last TSN received in sequence. This value is set initially by taking
the peers initial TSN, received in the INIT or INIT ACK chunk, and subtracting
one from it.
Mapping array
An array of bits or bytes, indicating the out-of-order TSNs that have been
received (relative to the last received TSN). If no gaps exist (that is, no
out-of-order packets have been received), this array will be set to all zeros.
ACK state
This flag indicates whether the next received packet is to be responded to with
an SACK. This is initialized to 0.
Inbound streams
An array of structures to track the inbound streams, normally including the

next sequence number expected and possibly the stream number.
Outbound streams
An array of structures to track the outbound streams, normally including the

next sequence number to be sent on the stream.
Reship Queue
A reassembly queue.
Local transport
address list
The list of local IP addresses bound in to this association.
Association PMTU
The smallest Path MTU discovered for all of the peers transport addresses.
Note:
For a given association, the two endpoints use a value of the verification tag that is unnecessarily changed
during the lifetime of the association. Whenever either endpoint clears the association, however, a new
value of the verification tag must be used to re-establish an association to the peer.
3)
Parameters necessary for each transport address
Table 5-10 lists the parameters that need to be maintained by an endpoint for each
destination transport address in the peers address list derived from the INIT or INIT
ACK chunk.
5-39

Chapter 5 SIGTRAN
Table 5-10 Parameters necessary for each transport address

Parameter
Meaning
Error count
The current error count for this destination.
Error threshold
Current error threshold for this destination. If the error count reaches this
value, the association to this destination transport address is marked to be
stopped.
CWND
The current congestion window.
RTO
The current retransmission timeout value.
SRTT
The current smoothed round trip time.
RTTVAR
The current RTT variation.
Partial
bytes
acknowledged
The tracking method for increase of CWND in case of congestion avoidance

mode.
State
The current state of this destination,

ALLOW-HEARTBEAT, or NO-HEARTBEAT.
PMTU
The current known path MTU.
Per destination timer
A timer used by each destination.
Last-time used
The time when a packet is last sent to this destination. This can be used to
determine whether a HEARTBEAT is needed.
4)
General parameters necessary
Out queue: A queue of outbound DATA chunks.
In queue: A queue of inbound DATA chunks.
5)
Suggested SCTP protocol parameter values
RTO.Initial: 3 seconds
RTO.Min: 1 second
RTO.Max: 60 seconds
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retransmissions: 10 attempts
Path.Max.Retransmissions: 5 attempts
Max.Init.Retransmissions: 8 attempts
Heartbeat.interval: 30 seconds
that
is,
DOWN,
UP,
5.2.6 Basic Signaling Procedures

I. Association Establishment and Transmission Procedure
SCTP endpoint A initiates the association establishment procedure and sends a user
message to endpoint B. Endpoint B sends two user messages to endpoint A.(Suppose
5-40

Chapter 5 SIGTRAN
theses messages are not bundled or segmented.) Figure 5-23 illustrates the signaling
procedure.
Endpoint A
Endpoint B
(1) INIT
(2) INIT ACK
(3) COOKIE ECHO
(4) COOKIE ACK
(5) DATA
(6) SACK
(7) DATA
(8) DATA
(9) SACK
Figure 5-23 Message interaction during association establishment

1)
Endpoint A creates a transmission control block (TCB) to describe the association

to be initiated, including the basic information of the association. Endpoint A sends
an INIT chunk to Endpoint B. The INIT chunk contains the following parameters:
Initiate Tag: It is used by the peer end for verification use. It can be set to Tag_A,
for example. Tag_A is a random number in the range of 1 to 4294967295.
OS: It represents the maximum number of outband streams expected by the local
endpoint.
MIS: It represents the maximum number of inbound streams allowed by the local
endpoint.
5-41

Chapter 5 SIGTRAN
Note:
For endpoint A and endpoint B, each performs the related checks on the stream information received from
the peer endpoint. If the maximum number of inbound streams of the peer endpoint is smaller than the
maximum number of outbound streams of the local endpoint, it indicates that the peer endpoint cannot
support the number of outbound streams expected by the local endpoint. In this case, the local endpoint
can either use the maximum number of inbound streams of the peer endpoint as the number of outbound
streams of the local endpoint or abort the association and notify the SCTP user of resource shortage at the
peer endpoint.
After sending the INIT, endpoint A starts the INIT timer and enters the COOKIE-WAIT
state.
Note:
The INIT timer is used to wait for an INIT ACK chunk returned by the peer endpoint. If no INIT ACK chunk
is received when the timer expires, the local endpoint retransmits an INIT chunk until the maximum
number of retransmission reaches.
2)
Upon receipt of the INIT message, endpoint B immediately responds with an INIT
ACK chunk. The INIT ACK chunk must contain the following parameters:
Destination IP Address: It is set to the source IP address of the INIT chunk.
Initiate Tag: It is set to Tag_B.
State Cookie: A temporary TCB is created according to the basic information of the
association. After the TCB is created, the necessary information (including
timestamp and lifespan of a cookie) contained in it and a local secret key are
computed to generate a 32-bit abstract MAC according to the algorithm described
in the RFC2401. This computation is not reversible. The necessary information
and the MAC constitute the State Cookie parameter.
Local transport address
Maximum number of inbound streams
Maximum number of outbound streams
3)
Upon receipt of the INIT ACK, endpoint A stops the INIT timer to quit the
COOKIE-WAIT state, and sends a COOKIE ECHO chunk which echoes the State
Cookie parameter contained in the INIT ACK chunk. Subsequently, endpoint A
starts the COOKIE timer and enters the COOKIE-ECHOED state.
5-42

Chapter 5 SIGTRAN
Caution:
The COOKIE ECHO chunk can be bundled with one or more DATA chunks in the same SCTP packet, but
the COOKIE ECHO must be the first chunk in the packet. The sending endpoint cannot send other packets
to the peer endpoint unless the returned COOKIE ACK chunk is received.
4)
Upon receipt of the COOKIE ECHO chunk, endpoint B performs the following
authentication on the cookie:a) Compute a MAC using the TCB data carried in the
State Cookie and the local secret key according to the MAC algorithm presented in
the RFC2401. b) Compare the computed MAC with the one carried in the State
Cookie.c) If the MACs are not the same, the message is discarded. If the same,
compare the timestamp in the TCB with the current time to check whether the time
expires the lifespan carried in the cookie.d) If so, the message is discarded.
Otherwise, create an association to endpoint A according to the information
carried in the TCB. Endpoint B enters the ESTABLISHED state and sends a
COOKIE ACK chunk. Endpoint B sends a SCOMMUNCIATION UP notification to
the SCTP user.
Caution:
The COOKIE ACK chunk can be bundled with one or more DATA or SACK chunks in the same SCTP
packet, but the COOKIE ACK must be the first chunk in the packet.
Upon receipt of the COOKIE ACK chunk, endpoint A moves from the
COOKIE-ECHOED state to the ESTABLISHED state and stops the COOKIE timer.
Endpoint A notifies the SCTP user of the successful establishment of the association
with a COMMUNICATION UP notification.
Note:
The establishment of an association is a four-way handshake process, which has four message
interactions: INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK.
5)
Endpoint A sends a DATA chunk to endpoint B and starts the T3-RTS timer. The
DATA chunk must contain the following parameters:
TSN: It is the initial TSN of the DATA chunk.

5-43

z
Chapter 5 SIGTRAN
Stream Identifier: It identifies the stream to which the user data belongs. Suppose
the stream identifier is 0.
Stream Sequence Number: It represents the sequence number of the user data
within the stream. The valid range is 0 to 65535.
User Data: This field contains the payload user data.
6)
Upon receipt of the DATA chunk, endpoint B returns an SACK chunk. The SACK
chunk must contain the following parameters:
Cumulative TSN Ack: It is the initial TSN of endpoint A.
Gap Ack Block: Its value is 0.
Upon receipt of the SACK chunk, endpoint A stops the T3-RTX timer.
7)
Endpoint B sends a DATA chunk to endpoint A. The DATA chunk must contain the
following parameters:
TSN: It is the initial TSN of the DATA chunk sent by endpoint B.
within the stream. Suppose the stream sequence number is 0.
8)
Endpoint B sends a second DATA chunk to endpoint A. The DATA chunk must
contain the following parameters:
TSN: It is one plus the initial TSN of the DATA chunk sent by endpoint B.
within the stream. In this case, the stream sequence number is 1.
9)
Upon receipt of the DATA chunk, endpoint A returns an SACK chunk. The SACK
chunk must contain the following parameters:
Cumulative TSN Ack: It is the initial TSN of endpoint B.
Gap Ack Block: Its value is 0.
II. Association Termination Procedure

An endpoint should terminate its association when it exits service. An association can
be terminated by either abort (ungraceful close) or shutdown (graceful close).
Abort (ungraceful close) of an association can be performed at any incompletion time.
Both ends of the association discard data without delivering it to the peer. This method
does not take data security into consideration. The association abort procedure is
simple. The initiating endpoint sends an ABORT chunk to its peer endpoint. The SCTP
packet sent must contain the Verification Tag of the peer, and the ABORT chunk must
not be bundled with any DATA chunk. Upon receipt of the ABORT chunk, the receiving
endpoint performs checks on the tag. If the Verification Tag is the same as the local one,
5-44

Chapter 5 SIGTRAN
the receiving endpoint removes the association from its record and notifies the SCTP
user of the termination of the association.
When either endpoint performs a shutdown procedure, both ends of the association
stop receiving new data from the respective SCTP users. When sending or receiving a
SHUTDOWN chunk, the endpoint delivers the data in the packet to its SCTP user. With
a shutdown of an association, it can be ensured that all data that is not sent or is sent
but not acknowledged will be sent or acknowledged before the termination of the
association.
Endpoint A
Endpoint B
(1) SHUTDOWN
(2) SHUTDOWN ACK
(3) SHUTDOWN COMPLETE
Figure 5-24 Message interaction during association shutdown

The shutdown procedure of an association is demonstrated as follows:
1)
The SCTP user of endpoint A that initiates the shutdown procedure sends the
cause of the requested shutdown to the SCTP. The SCTP association moves from
the ESTABLISHED state to the SHUTDOWN-PENDING state. In this state, the
SCTP does not accept any data sending request from the SCTP user on this
association. Meanwhile, the SCTP waits for endpoint Bs acknowledgement to all
sent but not acknowledged data of endpoint A. After all sent but not acknowledged
data of endpoint A is acknowledged, endpoint A sends a SHUTDOWN chunk to
endpoint B. Endpoint A starts the T2-shutdown timer and enters the
SHUTDOWN-SENT state. The purpose of starting the T2-shutdown timer is to
wait for a SHUTDOWN-ACK chunk returned by endpoint B. If the timer expires,
endpoint A must retransmit the SHUTDOWN chunk.
2)
Upon
receipt
of
the
SHUTDOWN
message,
endpoint
enters
the
SHOUTDOWN-RECEIVED state and no longer accepts new data sent from the
SCTP user. In addition, endpoint B checks the Cumulative TSN Ack field of the
chunk and verifies that all pending DATA chunks have been received by the
SHUTDOWN sender. After endpoint Bs data that is not sent or is sent but not
acknowledged is sent or acknowledged, endpoint B sends a SHUTDOWN ACK
chunk,
starts
the
local
T2-SHUTDOWN
timer,
and
enters
the
SHUTDOWN-ACK-SENT state. If the timer expires, endpoint B retransmits the

SHUTDOWN ACK chunk.
3)
Upon receipt of the SHUTDOWN ACK message, endpoint A stops the

T2-shutdown timer, sends a SHUTDOWN COMPLETE chunk to endpoint B, and
5-45

Chapter 5 SIGTRAN
removes all records about the association. Upon receipt of the SHUTDOWN
COMPLETE
chunk,
endpoint
checks
whether
it
is
in
the
SHUTDOWN-ACK-SENT state. If it is not in this state, the chunk is discarded. If

the endpoint is in the SHUTDOWN-ACK-SENT state, endpoint B stops the
T2-shutdown timer, removes all records about the association, and enters the
CLOSED state.
5.3 M2UA
5.3.1 Introduction
SS7 MTP2-User Adaptation Layer Protocol (M2UA) is a protocol for the transport of
SS7 MTP2 User signaling messages (MTP3 messages) over IP using the Stream
Control Transmission Protocol (SCTP) or any other suitable transport protocol. This
protocol would be used between a Signaling Gateway (SG) and Media Gateway
Controller (MGC). See Figure 5-25.
SS7
SEP
ISUP
MTP3
SIGTRAN
SG
PSTN
IP
MTP2
MTP2
MTP1
MTP1
MGC
ISUP
MTP3
M2UA
M2UA
SCTP
SCTP
IP
IP
Figure 5-25 Location of M2UA in the system

As illustrated above, narrowband signaling of signaling end point (SEP) uses SG to
access MGC. In the SIGTRAN protocol stack, M2UA runs on top of SCTP and is the
SCTP user. The upper layer user of M2UA at the MGC side is MTP3, and is MTP2 at
the SG side.
5.3.2 Terminology:
I. Application Server (AS)
AS is a logical entity, standing for a certain amount of resources and corresponding to a
particular routing context. For M2UA, AS is a group of Interface IDs. Each AS contains
a set of application server processes (ASPs), of which one or more are normally
actively processing traffic.
5-46

Chapter 5 SIGTRAN
II. Application Server Process (ASP)

ASP is a process instance of an AS. Each ASP contains an SCTP endpoint and can
serve a number of ASs. In the M2UA application, ASPs work in the active/standby
mode, and only the active ASP processes traffic.
III. Signaling Gateway Process (SGP)

SGP is a process instance that uses M2UA to communicate to and from a signaling link
terminal (SLT).SGP serves as an active, backup, or load-sharing process of a signaling
gateway.
IV. Backhaul
Backhaul refers to the transport of signaling from the point of interface for the
associated data stream (that is, SG function in the MG) back to the point of call
processing (that is, the MGC), if this is not local.
V. Interface ID
Interface ID is used in the communication between the two ends of M2UA. It can be text
or integer. Each interface ID corresponds to one actual physical link. The interface ID is
a logical ID of the MTP link used between SG and ASP.
VI. Link Key

Link key is a locally unique (between ASP and SG) value that identifies a registration
request for a particular signaling data link and signaling terminal pair. Link key is used in
a dynamic registration.
VII. M2UA Link

M2UA link is a logical connection established between SG and ASP of MGC
(SoftX3000).A M2UA link consists of SG, ASP, and SCTP association between SG and
ASP. Its state corresponds to ASP state and SCTP association state.
Figure 5-26 shows the network architecture of M2UA. After the concept of M2UA LINK
is introduced, this architecture can be simplified as in Figure 5-27.
5-47

Chapter 5 SIGTRAN
MTP2 link 0
MTP2 link 2
AS0
SCTP assoc 1
MTP2link 1
MG/SG0
MTP2 link 3
MGC
ASP0
SCTP assoc 0
ASP1
AS0 includes MTP2 link0 and link 1
SCTP assoc 2
ASP2
AS1
SCTP assoc 3
ASP3
AS1 includes MTP2 link2 and link 3
Figure 5-26 Network architecture of M2UA
MGC
MTP2 link 0
M2UA LINK 0(servered for MTP2 link 0and link1)
MTP2 link 1
MTP2 link 2
MG/SG0
MTP2 link 3
M2UA LINK 1(servered for MTP2 link 2and link3)
AS0
AS1
Figure 5-27 Simplified network architecture of M2UA

M2UA link provides channels for one or more MTP2s to communicate with its user,
MTP3.Each MTP link will be mapped to a particular M2UA link by the M2UA interface ID,
where the correspondence should be configured by executing the related
commands.Thus the data coming from an MTP link can be carried over the M2UA link
transparently.

Figure 5-28 shows the M2UA protocol stack.
M2UA
SCTP
IP
MAC
Figure 5-28 M2UA protocol stack
5.3.4 Implementation of M2UA

In NGN applications, a TMG provides the SG functionality. The networking is illustrated
in Figure 5-29.
5-48

Chapter 5 SIGTRAN
SoftX3000
IP metropolitan
area network
H.248/M2UA
H.248/IUA
TMG/UMG
TMG/UMG
ISUP trunk
ISUP trunk
PSTN
PSTN
Figure 5-29 Implementation of M2UA

M2UA can provide the following services:
z
Support for MTP2/MTP3 interface boundary that enables a seamless, or as

seamless as possible, operation of the MTP2-Users in the PSTN and IP network.
Support for management layer communication between SG and MGC.
Support for management of the SCTP association between SG and MGC.
SG embedded in TMG terminates MTP2 layer messages. SoftX3000 terminates MTP3

and upper layer messages. In other words, SG transports MTP3 messages over the IP
network to SoftX3000 for processing.
M2UA messages are encapsulated in the user data field of an SCTP message,
including a common message header and an M2UA message header.
5.3.5 Protocol Messages

As shown in Figure 5-30, M2UA message structure is composed of a common
message header, an M2UA message header, and several variable-length M2UA
messages.
5-49

Common Header
Chapter 5 SIGTRAN
Version(8)
Spare(8)
Message class(8)
Message type(8)
Message length(8)
M2UA message
Header
Tag(16)
Length(16)
Interface Identifier(32)
Parameter tag(16)
M2UA message 0#
Parameter length(16)
Parametervalue(32)
Parameter tag(16)
M2UA message n#
Parametervalue(32)
Figure 5-30 M2UA message structure
II. Common Message Header

The common message header contains the Version, Spare, Message Class, Message
Type, and Message Length fields.
z
Version
The Version field contains the version of M2UA. Currently, its value is 1 and represents
Release 1.0.
z
Spare
The Spare field is set to all zeros by the sender and ignored by the receiver.
z
Message Class
Table 5-11 Message classes

Value
Meaning
Management (MGMT) messages [IUA/M2UA/M3UA/SUA]
Transfer messages [M3UA]
SS7 signaling network management (SSNM) messages [M3UA]
ASP state maintenance (ASPSM) messages [IUA/M2UA/M3UA/SUA]
ASP traffic maintenance (ASPTM) messages [IUA/M2UA/M3UA/SUA]
Q.921/Q.931 boundary primitives transport (QPTM) messages [IUA]
MTP2 user adaptation (MAUP) messages [M2UA]
Connectionless messages [SUA]
Connection-oriented messages [SUA]
Routing key management (RKM) messages (M3UA)
5-50

Chapter 5 SIGTRAN
Value
10
Meaning
Interface identifier management (IIM) messages (M2UA)
11127
128255
Reserved for IETF-Defined extensions
Message Type
Table 5-12 lists the message types for the valid message classes.
Table 5-12 MTP2 user adaptation (MAUP) messages [M2UA]
Value
Message type
Meaning
Reserved
Data
It contains an SS7 MTP2-User Protocol Data

Unit (PDU).
Establish Request
When the MGC desires the MTP link to be

in-service, it will send the Establish Request
message to the SG.
Establish Confirm
The SG returns the Establish Confirm message

to the MGC.
Release Request
It is used to release a channel.
Release Confirm
It is used to confirm the Release Request

message.
Release Indication
It is used to indicate that the channel has been

released.
State Request
It is sent from an MGC to cause an action on a

particular MTP link supported by the SGP.
State Confirm
It is sent by the SGP in response to a State

Request from the MGC.
State Indication
It is sent from an SGP to an ASP to indicate a

condition on a link.
10
Retrieval Request
It is sent by the MGC during the MTP Level 3

changeover procedure to request the BSN, to
retrieve PDUs from the transmit and retransmit
queues or to flush PDUs from the retransmit
queue.
11
Retrieval Confirm
It is sent by the SG to the related queue.
12
Retrieval Indication
It is sent by the SG with a PDU from the transmit

or retransmit queue.
13
Retrieval Complete Indication
It is exactly the same as the Retrieval Request

message except that it also contains the last
PDU from the transmit or retransmit queue.
5-51

Value
Chapter 5 SIGTRAN
Message type
Meaning
14
Congestion Indication
It is sent from an SGP to an ASP to indicate the

congestion status and discard status of a link.
15
Data Acknowledge
It is used to acknowledge the Data message.
16127
128255
Reserved
extensions
for
IETF-Defined
Table 5-13 Application server process state maintenance (ASPSM) messages

Value
Message type
Meaning
Reserved
ASP Up (UP)
Used to indicate to a remote M2UA peer that the

adaptation layer is ready to receive traffic or
maintenance messages.
ASP Down (DOWN)
It is used to indicate to a remote M2UA peer that

the adaptation layer is not ready to receive traffic
or maintenance messages.
Heartbeat (BEAT)
It is optionally used to ensure that the M2UA

peers are still available to each other.
ASP Up Ack (UP ACK)
Used to acknowledge an ASP Up message

received from a remote M2UA peer.
ASP Down Ack (DOWN ACK)
It is used to acknowledge an ASP Down

message received from a remote M2UA peer.
Heartbeat Ack (BEAT ACK)
It is sent in response to a Heartbeat message.

An M2UA peer must send a Heartbeat Ack in
response to a Heartbeat message. It includes all
the parameters of the received Heartbeat
message, without any change.
7127
128255
Reserved
extensions
for
IETF-Defined
Table 5-14 Application server process traffic maintenance (ASPTM) messages

Value
Message type
Meaning
Reserved
ASP Active (ACTIVE)
It is sent by an ASP to indicate to an SGP that it

is active and ready to be used.
5-52

Value
Chapter 5 SIGTRAN
Message type
Meaning
ASP Inactive (INACTIVE)
It is sent by an ASP to indicate to an SGP that it

is no longer an active ASP to be used from
within a list of ASPs.
ASP Active Ack (ACTIVE ACK)
It is used to acknowledge an ASP Active

ASP Inactive Ack (INACTIVE ACK)
It is used to acknowledge an ASP Inactive

5127
128255
Reserved
extensions
for
IETF-Defined
Table 5-15 Management (MGMT) messages

Value
Message type
Meaning
Error (ERR)
It is used to notify a peer of an error event

associated with an incoming message. For
example, the message type might be
unexpected given the current state, or a
parameter value might be invalid.
Notify (NTFY)
It is used to provide an autonomous indication of

M2UA events to an M2UA peer.
2127
128255
Reserved
extensions
for
IETF-Defined
Table 5-16 Interface identifier management (IIM) messages

Value
0
Message type
Meaning
Reserved
Registration Request (REG REQ)
It is sent by an ASP to indicate to a remote

M2UA peer that it wishes to register one or more
given Link Keys with the remote peer. Typically,
an ASP would send this message to an SGP,
and expect to receive a REG RSP in return with
an associated Interface Identifier value.
Registration Response (REG RSP)
It is used as a response to the REG REQ

message from a remote M2UA peer. The REG
RSP contains indications of success/failure for
registration requests and returns a unique
Interface Identifier value for successful
registration requests.
5-53

Value
Chapter 5 SIGTRAN
Message type
Meaning
Deregistration Request (DEREG

REQ)
It is sent by an ASP to indicate to a remote

M2UA peer that it wishes to de-register a given
Interface Identifier. Typically, an ASP would
send this message to an SGP, and expect to
receive a DEREG RSP in return reflecting the
Interface Identifier and containing a
de-registration status.
Deregistration Response (DEREG

RSP)
It is used as a response to the DEREG REQ

message from a remote M2UA peer.
5127
128255
Reserved
extensions
for
IETF-Defined
Message Length
The Message Length field defines the length of the message in octets, including the
header. The Message Length must include parameter padding bytes, if any. The
Message Length must not be longer than an MTP3 message plus the length of the
common and M2UA message headers.
III. Format for M2UA Message Header

The M2UA message header includes the Tag, Length, and Interface Identifier fields.
z
Tag
The 16-bit Tag field indicates the type of the interface identifier. Table 5-17 shows the
correspondence between the tag values of the M2UA message header and the types of
the interface identifier.
Table 5-17 Correspondence between tag values and interface identifier types
Tag value
Interface identifier type
1 (0x01)
Integer
3 (0x03)
Text
Length
The Parameter Length values of the M2UA message header vary with different types of
interface identifiers.
The Length value is 8 if the type of the interface identifier is integer.
The Length value is variable if the type of the interface identifier is text. The maximum
length does not exceed 255 octets. The Length is equal to the length of the interface
identifier plus four bytes (the tag and length fields).
5-54

z
Chapter 5 SIGTRAN
Interface Identifier
The Interface Identifier identifies the physical interface at the SG for which the signaling
messages are sent/received. The format of the interface identifier parameter can be
text or integer, the values of which are assigned according to network operator policy.
The values used are coordinated between the SG and the ASP.
Caution:
The integer formatted interface identifier must be supported. The text formatted interface identifier may
optionally be supported.
IV. Format for Variable-Length M2UA Message

The common and M2UA message headers are followed by variable-length M2UA
messages. An M2UA message includes the Parameter Tag, Parameter Length, and
Parameter Value fields. Different M2UA messages determine different parameter tags,
parameter lengths, and parameter values.
z
Parameter Tag
The Parameter Tag field is a 16-bit identifier of the type of parameter.

The common parameters used by the adaptation layers are in the range of 0x00 to
0xff.The M2UA specific parameters have tags in the range 0x300 to 0x3ff.Table 5-18
shows the correspondence between values and parameters.
Table 5-18 Correspondence between M2UA message tag values and parameters
Tag value
Parameter name
0 (0x00)
Reserved
1 (0x01)
Interface Identifier (Integer)
2 (0x02)
Unused
3 (0x03)
Interface Identifier (Text)
4 (0x04)
Info String
5 (0x05)
Unused
6 (0x06)
Unused
7 (0x07)
Diagnostic Information
8 (0x08)
Interface Identifier (Integer Range)
9 (0x09)
Heartbeat Data
5-55

Chapter 5 SIGTRAN
Tag value
Parameter name
10 (0x0a)
Unused
11 (0x0b)
Traffic Mode Type
12 (0x0c)
Error Code
13 (0x0d)
Status Type/Information
14 (0x0e)
Unused
15 (0x0f)
Unused
16 (0x10)
Unused
17 (0x11)
ASP identifier
18 (0x12)
Unused
19 (0x13)
Correlation ID
768 (0x0300)
Protocol Data
769 (0x0301)
Protocol Data Response
770 (0x0302)
State Request
771 (0x0303)
State Event
772 (0x0304)
Congestion Status
773 (0x0305)
Discard Status
774 (0x0306)
Action
775 (0x0307)
Sequence Number
776 (0x0308)
Retrieval Result
777 (0x0309)
Link Key
778 (0x030A)
Local-LK-Identifier
789 (0x030B)
Signaling Data Terminal (SDT) Identifier
780 (0x030C)
Signaling Data Link (SDL) Identifier
781 (0x030D)
Registration Result
783 (0x030E)
Registration Status
783 (0x030F)
De-Registration Result
784 (0x0310)
De-Registration Status
Parameter Length
The Parameter Length field must be a multiple of four bytes. If it is not a multiple of four
bytes, the sender pads with all zero bytes after the Parameter Value field. The
Parameter Length must not be padded with all zero bytes. A sender must not pad with
more than three bytes. The receiver must ignore the padding bytes.
5-56

Chapter 5 SIGTRAN
Parameter Value
The Parameter Value field contains the actual M2UA message contents that are sent or
received.
V. MTP2 User Adaptation Messages

1)
Data
As shown in Figure 5-31, the Data message contains the following parameters:
Protocol Data (mandatory): The Protocol Data field contains the MTP2-User
application message in network byte order starting with the Signaling Information
Octet (SIO).
Correlation ID (optional): The Correlation ID parameter permits the new active
ASP to synchronize its processing of the traffic in each ordered stream with other
ASPs in the broadcast group. The Correlation ID parameter is assigned by the
sending M2UA, and uniquely identifies the MSU carried in the Protocol Data within
an AS.
0
15
Parameter tag=0x300
31
Parameter length
Protocol data(32)
Parameter tag=0x13
Parameter length=8
Correlation ID
Figure 5-31 Structure of Data message

2)
Data Acknowledge
As shown in Figure 5-32, the Data Acknowledge message contains the Correlation ID
message.
0
15
Parameter tag=0x301
31
Parameter length=8
Correlation ID
Figure 5-32 Structure of Data Acknowledge message

3)
State Request
As shown in Figure 5-33, the State Request message contains the State parameter.
5-57

Chapter 5 SIGTRAN
15
Parameter tag=0x302
31
Parameter length=8
State
Figure 5-33 Structure of State Request message

Table 5-19 shows the valid values for the State parameter.
Table 5-19 Valid values for State parameter
Value
4)
Definition
Meaning
0x0
STATUS_LPO_SET
Request local processor outage
0x1
STATUS_LPO_CLEAR
Request local processor outage recovered
0x2
STATUS_EMER_SET
Request emergency alignment
0x3
STATUS_EMER_CLEAR
Request normal alignment
0x4
STATUS_FLUSH_BUFFERS
Flush or clear receive, transmit and retransmit queues
0x5
STATUS_CONTINUE
Continue or resume
0x6
STATUS_CLEAR_RTB
Clear the retransmit queue
0x7
STATUS_AUDIT
Audit state of link
0x8
STATUS_CONG_CLEAR
Congestion cleared
0x9
STATUS_CONG_ACCEPT
Congestion accept
0x0a
STATUS_CONG_DISCARD
Congestion discard
State Confirm
As shown in Figure 5-34, the State Confirm message contains the State parameter. The
content of the State parameter in the State Confirm message is the same as that in the
State Request message.
0
15
Parameter tag=0x302
31
Parameter length=8
State
Figure 5-34 Structure of State Confirm message

5)
State Event
As shown in Figure 5-35, the State Event message contains the Event parameter.
5-58

Chapter 5 SIGTRAN
15
Parameter tag=0x303
31
Parameter length=8
Event
Figure 5-35 Structure of State Event message

Table 5-20 shows the valid values for the Event parameter.
Table 5-20 Valid values for Event parameter
Value
6)
Definition
Meaning
0x1
EVENT_RPO_ENTER
Remote entered processor outage
0x2
EVENT_RPO_EXIT
Remote exited processor outage
0x3
EVENT_LPO_ENTER
Link entered processor outage
0x4
EVENT_LPO_EXIT
Link exited processor outage
Congestion Indication
As shown in Figure 5-36, the Congestion Indication message contains the Congestion
Status and Discard Status parameters.
0
15
Parameter tag=0x304
31
Parameter length=8
Congestion status
Parameter tag=0x305
Parameter length=8
Discard status
Figure 5-36 Structure of Congestion Indication message

Table 5-21 shows the valid values for the Congestion Status and Discard Status
parameters.
Table 5-21 Valid values for Congestion Status and Discard Status parameters
Value
Definition
Meaning
0x0
LEVEL_NONE
No congestion
0x1
LEVEL_1
Congestion Level 1
0x2
LEVEL_2
Congestion Level 2
0x3
LEVEL_3
Congestion Level 3
5-59

7)
Chapter 5 SIGTRAN
Retrieval Request
As shown in Figure 5-37, the Retrieval Request message contains the mandatory
Action parameter and optional Sequence Number parameter.
0
15
Parameter tag=0x306
31
Parameter length=8
Action
Parameter tag=0x307
Parameter length=8
Sequence number
Figure 5-37 Structure of Retrieval Request message

z
Action
Table 5-22 shows the valid values for the Action parameter.
Table 5-22 Valid values for Action parameter
Value
Definition
Meaning
0x1
ACTION_RTRV_BSN
Retrieve the backward sequence number (BSN)
0x2
ACTION_RTRV_MSGS
Retrieve the PDUs from the transmit and retransmit

queues
Sequence Number
In the Retrieval Request message, the Sequence Number field is not present if the
Action field is 0x01 (ACTION_RTRV_BSN).The Sequence Number field contains the
forward sequence number (FSN) of the far end if the Action is 0x2.
8)
Retrieval Confirm
As shown in Figure 5-38, the Retrieval Confirm message contains the mandatory
Action parameter, mandatory Result parameter, and optional Sequence Number
parameter.
5-60

Chapter 5 SIGTRAN
15
31
Parameter tag=0x306
Parameter length=8
Action
Parameter tag=0x308
Parameter length=8
Result
Parameter tag=0x307
Parameter length=8
Sequence number
Figure 5-38 Structure of Retrieval Confirm message

z
Action
The meaning of the Action parameter in the Retrieval Confirm message is the same as
that of the Action parameter in the Retrieval Request message.
z
Result
Table 5-23 shows the valid values for the Result parameter.
Table 5-23 Valid values for Result parameter
Value
Definition
Meaning
0x0
RESULT_SUCCESS
Action successful
0x2
RESULT_FAILURE
Action failed
Sequence Number
When the SGP sends a Retrieval Confirm to a Retrieval Request, it echoes the Action
field. If the Action was ACTION_RTRV_BSN and the SGP successfully retrieved the
BSN, the SGP will put the BSN in the Sequence Number field and will set
Result_Success in the Result field.
If the BSN could not be retrieved, the Sequence Number field will not be included and
Result_Failure will be contained in the Result field.
9)
Retrieval Indication
As shown in Figure 5-39, the Retrieval Indication message contains the Protocol Data
parameter.
5-61

Chapter 5 SIGTRAN
15
31
Parameter tag=0x300
Parameter length
Protocol data
Figure 5-39 Structure of Retrieval Indication message
VI. ASP State Maintenance Messages

The ASP state maintenance messages only use the common message header.
1)
ASP Up
As shown in Figure 5-40, the ASP Up message contains the optional ASP Identifier
parameter and optional INFO String parameter.
0
15
31
Parameter tag=0x11
Parameter length=8
ASP identifier
Parameter tag=0x4
Parameter length
INFO string
Figure 5-40 Structure of ASP Up message

z
ASP Identifier
The ASP Identifier must be used where the SGP cannot identify the ASP by
pre-configured address/port number information. For example, an ASP is resident on a
host using dynamic address/port number assignment.
The optional ASP Identifier parameter contains a unique value that is locally significant
among the ASPs that support an AS. The SGP should save the ASP Identifier to be
used, if necessary, with the Notify message.
z
INFO string
The optional INFO String parameter can carry any meaningful UTF-8 [6] character
string along with the message. Length of the INFO String parameter is from 0 to 255
octets. No procedures are presently identified for its use but the INFO String might be
used for debugging purposes.
2)
ASP Up Ack
As shown in Figure 5-41, the ASP Up Ack message contains an optional INFO String
parameter. The format and description of the INFO String in the ASP Up Ack message
are the same as those of the INFO String in the ASP Up message.
5-62

0
Chapter 5 SIGTRAN
15
Parameter tag=0x04
31
Parameter length
INFO string
Figure 5-41 Structure of ASP Up Ack message

3)
ASP Down
As shown in Figure 5-42, the ASP Down message contains an optional INFO String
parameter. The format and description of the INFO String in the ASP Down message
0
15
Parameter tag=0x04
31
Parameter length
INFO string
Figure 5-42 Structure of ASP Down message

4)
ASP Down Ack
As shown in Figure 5-43, the ASP Down Ack message contains an optional INFO String
parameter. The format and description of the INFO String in the ASP Down Ack
message are the same as those of the INFO String in the ASP Up message.
0
15
Parameter tag=0x04
31
Parameter length
INFO string
Figure 5-43 Structure of ASP Down Ack message

5)
Heartbeat
As shown inFigure 5-44, the Heartbeat message contains an optional Heartbeat Data
parameter.
0
15
Parameter tag=0x09
31
Parameter length
Heartbeat data
Figure 5-44 Structure of Heartbeat message

The sending node defines the contents of the Heartbeat Data parameter. It may include
a Heartbeat Sequence Number and/or time stamp, or other implementation specific
details.
5-63

Chapter 5 SIGTRAN
Because the Heartbeat Data parameter is only of significance to the sender, the
receiver of the Heartbeat message does not process this field. The receiver echoes the
contents of the Heartbeat Data in a Heartbeat Ack message.
6)
Heartbeat Ack
As shown in Figure 5-45, the Heartbeat Ack message contains an optional Heartbeat
Data parameter. The format and definition of the Heartbeat Data parameter in the
Heartbeat Ack message are the same as those of the Heartbeat Data parameter in the
Heartbeat message.
0
15
Parameter tag=0x09
31
Parameter length
Heartbeat data
Figure 5-45 Structure of Heartbeat Ack message
VII. ASP Traffic Maintenance Messages

ASP traffic maintenance messages use the common and M2UA message headers.
1)
ASP Active
As shown in Figure 5-46 and Figure 5-47, the ASP Active message contains the
optional Traffic Mode Type, Interface Identifier, Additional Interface Identifier, and INFO
String parameters, according to the text and integer formatted interface identifiers.
5-64

Chapter 5 SIGTRAN
15
Parameter tag=0x0b
31
Parameter length=8
Traffic mode type

Parameter tag=0x01(Integer)
Parameter length
Interface Identifiers
Parameter tag=0x08(Integer range)
Parameter length
Interface Identifier start1

Interface Identifier stop1
Interface Identifier start n

Interface Identifier stop n
Additional Interface Identifier
Parameter tag=0x04
Parameter length
INFO string
Figure 5-46 Structure of ASP Active message (integer formatted interface identifier)
15
Parameter tag=0x0b
31
Parameter length
Traffic mode type

Parameter tag=0x03(String)
Parameter length
Additional Interface Identifiers
Parameter tag=0x04
Parameter length
INFO string
Figure 5-47 Structure of ASP Active message (text formatted interface identifier)
z
Traffic Mode Type
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP
within an AS. Within a particular AS, only one Traffic Mode Type can be used. Table
5-24 shows the three traffic mode types defined.
5-65

Chapter 5 SIGTRAN
Table 5-24 Traffic mode types

Value
Definition
Meaning
0x01
Override
The ASP takes over all traffic in an AS (that is,

primary/backup operation), overriding any currently
active ASPs in the AS.
0x02
Load-share
The ASP shares in the traffic distribution with any

other currently active ASPs.
0x03
Broadcast
All of the active ASPs receive all message traffic in

the AS.
Interface Identifiers (optional)
The optional Interface Identifiers parameter contains a list of Interface Identifier

integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) indexing the Application
Server traffic that the sending ASP is configured/registered to receive. If integer
formatted Interface Identifiers are being used, the ASP can also send ranges of
Interface Identifiers (Type 0x8).Interface Identifier types Integer (0x1) and Integer
Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3)
cannot be used with either Integer (0x1) or Integer Range (0x8) types.
If no Interface Identifiers are included, the message is for all provisioned Interface
Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface
Identifiers for an AS are included, the ASP is noted as Active for all the Interface
Identifiers provisioned for that AS.
Caution:
If the optional Interface Identifier parameter is present, the integer formatted Interface Identifier must be
supported, while the text formatted Interface Identifier may be supported.
INFO String (optional)
The format and description of the INFO String parameter are the same as for the ASP
Up message.
2)
ASP Active Ack
As shown in Figure 5-48 and Figure 5-49, the ASP Active Ack message contains the
optional Traffic Mode Type, Interface Identifier, Additional Interface Identifier, and INFO
String parameters.
5-66

Chapter 5 SIGTRAN
15
Parameter tag=0x0b
31
Parameter length=8
Traffic mode type

Parameter length
Parameter length


Additional Interface Identifier of Tag type 0x1 or type 0x8
Parameter tag=0x04
Parameter length
INFO string
Figure 5-48 Structure of ASP Active Ack message (integer formatted interface identifier)
15
Parameter tag=0x0b
31
Parameter length
Traffic mode type

Parameter length
Parameter tag=0x04
Parameter length
INFO string
Figure 5-49 Structure of ASP Active Ack message (text formatted interface identifier)
The format and description of the optional INFO String parameter are the same as for
the ASP Up message.
The format of the optional Interface Identifiers parameter is the same as for the ASP
Active message.
3)
ASP Inactive
As shown in Figure 5-50 and Figure 5-51, the ASP Inactive message contains the
optional Interface Identifier and INFO String parameters.
5-67

Chapter 5 SIGTRAN
15
31
Parameter length
Parameter length


Parameter tag=0x04
Parameter length
INFO string
Figure 5-50 Structure of ASP Inactive message (integer formatted interface identifier)
15
31
Parameter length
Parameter tag=0x04
Parameter length
INFO string
Figure 5-51 Structure of ASP Inactive message (text formatted interface identifier)
Active message.
the ASP Up message.
4)
ASP Inactive Ack
ASP Inactive Ack message contains the optional Interface Identifier and INFO String
parameters.
Active message.
the ASP Up message.
5-68

Chapter 5 SIGTRAN
VIII. Layer Management Messages

1)
Error
As shown in Figure 5-52, the Error message contains mandatory Error Code, optional
Interface Identifier, and optional Diagnostic Information parameters.
0
15
31
Tag=0x0C
Length=8
Error code
Length
Tag=0x01,0x03,0x08
Length
Tag=0x07
Diagnostic information
Figure 5-52 Structure of Error message

z
Error Code
The Error Code parameter indicates the reason for the Error Message. Table 5-25
lists the defined M2UA error codes.
Table 5-25 Error codes

Value
Definition
Meaning
The "Invalid Version" error would be sent if a message
was received with an invalid or unsupported version.
0x01
The Error message would contain the supported

version in the Common header. The Error message
could optionally provide the supported version in the
Diagnostic Information area.
Invalid Version
The "Invalid Interface Identifier" error would be sent by

an SGP if an ASP sends a message (that is, an ASP
Active message) with an invalid (not configured)
Interface Identifier value.
0x02
Invalid Interface Identifier
0x03
Unsupported Message Class
The "Unsupported Message Class" error would be

sent if a message with an unexpected or unsupported
Message Class is received.
0x04
Unsupported Message Type
The "Unsupported Message Type" error would be sent

if a message with an unexpected or unsupported
Message Type is received.
One of the optional Interface Identifier parameters

(integer-based, text-based, or integer range) must be
used with this error code to identify the invalid
Interface Identifier(s) received.
5-69

Value
0x05
Chapter 5 SIGTRAN
Definition
Meaning
Unsupported Traffic Handling

Mode
The "Unsupported Traffic Handling Mode" error would

be sent by an SGP if an ASP sends an ASP Active with
an unsupported Traffic Handling Mode. An example
would be a case in which the ASP sent an ASP Active
message with load-sharing traffic handling mode, but
the SGP did not support load-sharing.
One of the optional Interface Identifier parameters
(integer-based, text-based, or integer range) may be
used with this error code to identify the Interface
Identifier(s).
0x06
Unexpected Message
The "Unexpected Message" error would be sent by an

ASP if it received an MAUP message from an SGP
while it was in the Inactive state.
0x07
Protocol Error
The "Protocol Error" error would be sent for any

protocol anomaly (that is, a bogus message).
0x08
0x09
Unsupported
Identifier Type
Interface
The "Unsupported Interface Identifier Type" error

would be sent by an SGP if an ASP sends a text
formatted Interface Identifier and the SGP only
supports integer formatted Interface Identifiers.
When the ASP receives this error, it will need to
resend its message with an integer formatted Interface
Identifier.
Invalid Stream Identifier
The "Invalid Stream Identifier" error would be sent if a

message was received on an unexpected SCTP
stream (that is, an MGMT message was received on a
stream other than "0").
Not Used in M2UA
Refused
Blocking
The "Refused Management Blocking" error is sent

when an ASP Up or ASP Active message is received
and the request is refused for management reasons
(for example, management lock-out").
0x0a
0x0b
0x0c
0x0d
0x0e
Management
The "ASP Identifier Required" is sent by an SGP in

response to an ASP Up message which does not
contain an ASP Identifier parameter when the SGP
requires one.
ASP Identifier Required
The ASP should resend the ASP Up message with an

ASP Identifier.
0x0f
The "Invalid ASP Identifier" is sent by an SGP in

response to an ASP Up message with an invalid (that
is, non-unique) ASP Identifier.
Invalid ASP Identifier
5-70

Value
Chapter 5 SIGTRAN
Definition
Meaning
ASP Active for Interface

Identifier(s)
The "ASP Currently Active for Interface Identifier(s)"

error is sent by an SGP when a Deregistration
Request is received from an ASP that is active for
Interface Identifier(s) specified in the Deregistration
Request. One of the optional Interface Identifier
parameters (integer-based, text-based, or integer
range) may be used with this error code to identify the
Interface Identifier(s).
0x11
Invalid Parameter Value
The "Invalid Parameter Value " error is sent if a

message is received with an invalid parameter value
(for example, a State Request with an undefined
State).
0x12
Parameter Field Error
The "Parameter Field Error" would be sent if a

message with a parameter has a wrong length field.
0x13
Unexpected Parameter
The "Unexpected Parameter" error would be sent if a

message contains an invalid parameter.
Not Used in M2UA
Missing Parameter
The "Missing Parameter" error would be sent if a

mandatory parameter was not included in a message.
0x10
0x14
0x15
0x16
The optional Diagnostic information can be any information germane to the error
condition, to assist in the identification of the error condition.
In the case of an Invalid Version Error Code, the Diagnostic information includes the
supported Version parameter. In the other cases, the Diagnostic information should be
the first 40 bytes of the offending message.
2)
Notify
As shown in Figure 5-53and Figure 5-54, the Notify message contains mandatory
Status Type, mandatory Status Information, optional ASP Identifier, optional Interface
Identifiers, and optional INFO String parameters.
5-71

Chapter 5 SIGTRAN
15
31
Parameter tag=0x0d
Parameter length=8
Status type
Status information
Parameter tag=0x11
Parameter length
ASP identifiers
Parameter length
Parameter length


Parameter tag=0x04
Parameter length
INFO string
Figure 5-53 Structure of Notify message (integer formatted interface identifier)
15
31
Parameter tag=0x0d
Parameter length=8
Status type
Status information
Parameter tag=0x11
Parameter length
ASP identifiers
Parameter length
Additional Interface Identifier of Tag type 0x03
Parameter tag=0x04
Parameter length
INFO string
Figure 5-54 Structure of Notify message (text formatted interface identifier)

z
Status Type
The Status Type parameter identifies the type of the Notify message. The following
table lists the defined status types.
5-72

Chapter 5 SIGTRAN
Table 5-26 Status types

Value
Definition
0x01
Application server state change (AS_State_Change)
0x02
Other
The Status Information parameter contains more detailed information for the
notification, based on the value of the Status Type.
If the Status Type is AS_State_Change, the Status Information values shown in Table
5-27 are used: These notifications are sent from an SGP to an ASP upon a change in
status of a particular AS. The value reflects the new state of the AS. The Interface
Identifiers of the AS may be placed in the message if desired.
Table 5-27 Status Information values if Status Type is AS_State_Change
Value
Definition
0x01
Reserved
0x02
Application server inactive (AS_Inactive)
0x03
Application server active (AS_Active)
0x04
Application server pending (AS_Pending)
If the Status Type is Other, the Status Information values shown in Table 5-28 are
defined:
Table 5-28 Status Information values if Status Type is Other
Value
0x01
0x02
Definition
Meaning
Insufficient ASP resources

active in AS
The SGP is indicating to an ASP-Inactive ASP(s) in

the AS that another ASP is required in order to handle
the load of the AS (load-sharing mode).
The formerly Active ASP is informed when an
alternate ASP transitions to the ASP Active state in
override mode.
Alternate ASP active
The ASP Identifier (if available) of the Alternate ASP

must be placed in the message.
0x03
The SGP is indicating to ASP(s) in the AS that one of

the ASPs has transitioned to ASP-DOWN.
ASP failure
The ASP Identifier (if available) of the failed ASP must

be placed in the message.
5-73

z
Chapter 5 SIGTRAN
Interface Identifier s
The format of the Interface Identifiers parameter in the Notify message is the same as
for the ASP Active message.
z
INFO String
The format of the INFO String parameter in the Notify message is the same as for the
ASP Up message.

I. Establishment Procedure of Service Environment
Establishment procedure of the M2UA service environment is illustrated in Figure
5-55.SCTP association must be established between SG and MGC before the
establishment of M2UA service environment.
MGC
SG
ASP UP
ASP UP ACK
ASP ACTIVE
ASP ACTIVE ACK
Figure 5-55 Establishment procedure of M2UA service environment

Here MGC is the client, which will first send the request to establish the environment.
Once the environment is ready, the M2UA data, MGC maintenance messages, and
layer management messages can be transmitted between the peers.
II. Data Transfer Procedure

When the M2UA layer on ASP has an MAUP message to send to SG, it will do the
following:
z
Determine the correct SG
Get the M2UA link number
Find the SCTP association to the chosen SG
Determine the correct stream in the SCTP association based on the SS7 link
Fill in the MAUP message, fill in M2UA Message Header, fill in Common Header,
and generate the M2UA message unit
Send the MAUP message to the remote M2UA peer in SG, over the SCTP
association
5-74

Chapter 5 SIGTRAN
When the M2UA layer on SG has an MAUP message to send to ASP, it will do the
following:
z
Get Interface Identifier
Determine the M2UA link number, which supports that MTP link
Get the SCTP association
Determine the correct stream in the SCTP association based on the SS7 link
Fill in the MAUP message, fill in M2UA Message Header, fill in Common Header,
and generate the M2UA message unit
Send the MAUP message to the remote M2UA peer in ASP, over the SCTP
association
III. Release Procedure

Release procedure of the M2UA service environment is illustrated in Figure 5-56.
MGC
SG
ASP INACTIVE
ASP INACTIVE ACK
ASP DOWN
ASP DOWN ACK
Figure 5-56 Release procedure of M2UA service environment

After SG receives the release primitive from MGC, it begins the release process of
M2UA service environment, and closes SCTP connection.
5.4 M3UA
5.4.1 Introduction
As SS7 MTP3-User adaptation layer, M3UA provides primitive communication service
for MTP3 users over IP network and MTP3 (in an SG) at the edge of a network, so as to
implement interworking between TDM SS7 and IP.
M3UA supports the following functions:
z
SS7 signaling point code representation
Within an SS7 network, an SG might be charged with representing a set of nodes in the
IP domain into the SS7 network for routing purposes. The SG itself, as a physical node
in the SS7 network, must have an SS7 point code.
z
Routing function
5-75

Chapter 5 SIGTRAN
The distribution of SS7 messages between the signaling gateway process (SGP) and
the application servers (ASs) is determined by the routing keys and their associated
routing contexts.
Possible SS7 address/routing information that comprises a routing key entry includes,
for example, the originating point code (OPC), destination point code (DPC), SIO found
in the MTP3 routing label, or MTP3-User specific fields such as the ISUP circuit
identification code (CIC).
z
SS7 and M3UA interworking
In the case of SS7 and M3UA interworking, the M3UA adaptation layer is designed to
provide an extension of the MTP3 defined user primitives.
z
Congestion management
The M3UA layer at an ASP or IP server process (IPSP) indicates local congestion to an
M3UA peer with a signaling connection (SCON) message. When an SG receives a
congestion message (SCON) from an ASP, and the SG determines that a signaling
point management cluster (SPMC) is now encountering congestion, it might trigger
SS7 MTP3 transfer controlled management messages to concerned SS7 destinations
according to congestion procedure of the relevant MTP3 standard.
z
SCTP stream mapping
The M3UA layer at both the SGP and ASP also supports the assignment of signaling
traffic to streams within an SCTP association. Traffic that requires sequencing must be
assigned to the same stream. To accomplish this, MTP3-User traffic can be assigned to
individual streams based on, for example, the signaling link selection (SLS) value in the
MTP3 routing label, subject of course to the maximum number of streams supported by
the underlying SCTP association.
z
Client/Server model
The SGP and ASP are able to support both client and server operation. The peer
endpoints using M3UA should be configured so that one always takes on the role of
client and the other the role of server for initiating SCTP associations. The default
orientation would be for the SGP to take on the role of server while the ASP is the client.
In this case, ASPs should initiate the SCTP association to the SGP.
M3UA is conveyed over SCTP. The user port number registered by SCTP is 2905 for
M3UA.
The following introduces some related terms and their definitions.
z
IP server process (IPSP)
An IPSP is a process instance of an IP-based application. An IPSP is essentially the

same as an ASP, except that it uses M3UA in a point-to-point fashion instead of using
the services of a signaling gateway.
z
Signaling gateway process (SGP)
5-76

Chapter 5 SIGTRAN
An SGP is a processing instance of a signaling gateway. It serves as an active, backup

or load-sharing process of a signaling gateway.
z
Routing key
A routing key describes a set of SS7 parameters and parameter values (such as DPC,
SIO + DPC, SIO + DPC + OPC, and SIO + DPC + OPC + CIC) that uniquely define the
range of signaling traffic to be handled by a particular application server. Parameters
within the routing key cannot extend across a single destination point code.
I. Structure of Protocol Stack

Figure 5-57 shows the architecture of the M3UA protocol.
MTP3-User
M3UA
SCTP
LM
IP
Figure 5-57 Architecture of the M3UA protocol
M3UA is the lower-layer protocol of MTP3-User. It provides a standard MTP3 interface
for MTP3-User. SCTP is the lower-layer protocol of M3UA and provides an association
to serve M3UA. M3UA has also unique layer management (LM) to provide
management services.
II. M3UA Implementations

M3UA provides the following service functions:
z
Support for the transport of MTP3-user messages
Native management functions
Interworking with MTP3 network management functions
Support for the management of SCTP associations between the SGP and ASPs
Support for the management of connections to multiple SGPs
5.4.2 M3UA Messages

I. Messages
1)
SS7 signaling network management (SSNM) messages
All M3UA protocol messages (including SSNM messages) contain a common message
header and zero or more parameters defined by the message type. Table 5-29 lists the
SSNM messages.
5-77

Chapter 5 SIGTRAN
Table 5-29 SSNM messages

Message
Description
Destination unavailable
(DUNA)
The DUNA message is sent from all SGPs in an SG to all concerned

ASPs to indicate that the SG has determined that one or more SS7
destinations are unreachable. It is also sent by an SGP in response to a
message from the ASP to an unreachable SS7 destination. The
MTP3-User at the ASP is expected to stop traffic to the affected
destination in the DUNA message.
Destination available
(DAVA)
The DAVA message is sent from the SGP to all concerned ASPs to
indicate that the SG has determined that one or more SS7 destinations
are now reachable, or in response to a DAUD message (refer to the
following part). The ASP MTP3-User protocol should resume traffic to
the affected destination in the DAVA message.
Destination state audit

(DAUD)
The DAUD message is sent from the ASP to the SGP to audit the
availability/congestion state of SS7 routes to one or more affected
destinations.
SS7 network congestion

(SCON)
The SCON message is sent from the SGP to all concerned ASPs to
indicate congestion in the SS7 network to one or more destinations, or to
an ASP in response to a DATA or DAUD message as appropriate. The
SCON message might also be sent from the M3UA layer of an ASP to an
M3UA peer indicating that the M3UA layer or the ASP is congested.
Destination user part

unavailable (DUPU)
The DUPU message is used by an SGP to inform an ASP that a remote

peer MTP3-User part at an SS7 node is unavailable.
2)
ASP management (ASPM) messages
Table 5-30 lists the ASPM messages.

Table 5-30 ASPM messages
Message
Description
ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that

the adaptation layer is ready to receive any SSNM or ASPM messages
for all routing keys that the ASP is configured to serve.
ASP Up Ack
The ASP Up Ack message is used to acknowledge an ASP Up message

ASP Down
The ASP Down (ASPDN) message is used to indicate to a remote

M3UA peer that the adaptation layer is not ready to receive DATA,
SSNM, RKM or ASPTM messages.
ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down

message received from a remote M3UA peer, or in response to an
ASPM message received by the ASP and locked due to management
reasons.
Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers
are still available to each other. It is recommended for use when the
M3UA runs over a transport layer other than the SCTP. The BEAT
message does not contain any parameter.
5-78

Chapter 5 SIGTRAN
Message
Description
Heartbeat Ack (BEAT Ack)
The BEAT Ack message is sent in response to a received BEAT

message. It includes all the parameters of the received BEAT message.
II. M3UA Routing Key Management (RKM) Messages

1)
Registration request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer that it
wishes to register one or more given routing keys with the remote peer. Typically, an
ASP would send this message to an SGP, and expects to receive a REG RSP message
in return with an associated routing context value. Table 5-31 lists the registration
request messages.
Table 5-31 Registration request messages
Message
Description
Registration response
(REG RSP)
The REG RSP message is used as a response to the REG REQ

message from a remote M3UA peer. It contains indications of
success/failure for registration requests and returns a unique routing
context value for successful registration requests, to be used in
subsequent M3UA traffic management protocol.
De-registration request
(DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote

M3UA peer that it wishes to de-register a given routing key. Typically, an
ASP would send this message to an SGP, and expects to receive a
DEREG RSP message in return with the associated routing context
value.
De-registration response
(DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ

message from a remote M3UA peer.
2)
ASP traffic maintenance (ASPTM) messages
Table 5-32 lists the ASPTM messages.

Table 5-32 ASPTM messages
Message
Description
ASP active (ASPAC)
The ASPAC message is sent by an ASP to indicate to a remote M3UA

peer that it is ready to process signaling traffic for a particular application
server. The ASPAC message affects only the ASP state for the routing
keys identified by the routing contexts, if present.
ASP active ack (ASPAC

Ack)
The ASPAC Ack message is used to acknowledge an ASPAC message

5-79

Chapter 5 SIGTRAN
Message
Description
ASP inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to a remote M3UA

peer that it is no longer an active ASP to be used within a list of ASPs.
The ASPIA message affects only the ASP state for the routing keys
identified by the routing contexts, if present.
ASP inactive ack (ASPIA

Ack)
The ASPIA Ack message is used to acknowledge an ASPIA message

3)
Management (MGMT) messages
Table 5-33 lists the MGMT messages.

Table 5-33 MGMT messages
Message
Description
Error (ERR)
The ERR message is used to notify a peer of an error event associated

with an incoming message. For example, the message type might be
unexpected in the current state, or a parameter value might be invalid.
The ERR message must contain the error code parameter. The error
code parameter indicates the reason for the ERR message. The error
parameter value can be one of the values in Table 5-34.
Notify (NTFY)
The NTFY message is used to provide an autonomous indication of

M3UA events to an M3UA peer.
Table 5-34 Valid values for Error parameter

Value
Description
0x01
Invalid Version. The Invalid Version error is sent if a message was received with an invalid
or unsupported version. The ERR message contains the supported version in the common
header. The ERR message could optionally provide the supported version in the diagnostic
information area.
0x02
Not used in M3UA
0x03
Unsupported Message Class. The Unsupported Message Class error is sent if a message
with an unexpected or unsupported Message Class is received.
0x04
Unsupported Message Type. The Unsupported Message Type error is sent if a message
with an unexpected or unsupported Message Type is received.
0x05
Unsupported Traffic Mode Type. The Unsupported Traffic Mode Type error is sent by an
SGP if an ASP sends an ASP Active message with an unsupported Traffic Mode Type or a
Traffic Mode Type that is inconsistent with the presently configured mode for the AS. An
example would be a case in which the SGP did not support loadsharing.
0x06
Unexpected Message. The Unexpected Message error may be sent if a defined and
recognized message is received that is not expected in the current state (in some cases the
ASP may optionally silently discard the message and not send an ERR message). For
example, silent discard is used by an ASP if it received a DATA message from an SGP while
it was in the ASP-INACTIVE state. If the unexpected message contained Routing
Context(s), the Routing Context(s) should be included in the Error message.
5-80

Chapter 5 SIGTRAN
Value
Description
0x07
Protocol Error. The Protocol Error error is sent for any protocol anomaly, that is, reception
of a parameter that is syntactically correct but unexpected in the current situation.
0x08
Not used in M3UA
0x09
Invalid Stream Identifier. The Invalid Stream Identifier error is sent if a message is received
on an unexpected SCTP stream (for example, a management message was received on a
stream other than 0).
0x0a
Not used in M3UA
0x0b
Not used in M3UA
0x0c
Not used in M3UA
0x0d
Refused Management Blocking. The Refused Management Blocking error is sent

when an ASP Up or ASP Active message is received and the request is refused for
management reasons (for example, management lockout). If this error is in response to an
ASP Active message, the Routing Context(s) in the ASP Active message should be
included in the Error message.
0x0e
ASP Identifier Required. The ASP Identifier Required error is sent by an SGP in response
to an ASP Up message which does not contain an ASP Identifier parameter when the SGP
requires one. The ASP should resend the ASP Up message with an ASP Identifier.
0x0f
Invalid ASP Identifier. The Invalid ASP Identifier error is sent by an SGP in response to an
ASP Up message with an invalid (that is, non-unique) ASP Identifier.
0x10
Not used in M3UA
0x11
Invalid Parameter Value. The Invalid Parameter Value error is sent if a message is
received with an invalid parameter value (for example, a DUPU message was received with
a Mask value other than 0).
0x12
Parameter Field Error. The Parameter Field Error error is sent if a message is received
with a parameter having a wrong length field.
0x13
Unexpected Parameter. The Unexpected Parameter error is sent if a message is received

with an invalid parameter.
0x14
Destination Status Unknown. The Destination Status Unknown error is sent if a DUAD
message is received at an SG enquiring the availability/congestion status of a destination,
and the SG does not wish to provide the status (for example, the sender is not authorized to
know the status). For this error, the invalid or unauthorized Point Code(s) must be included
along with the Network Appearance and/or Routing Context associated with the Point
Code(s).
0x15
Invalid Network Appearance The "Invalid Network Appearance" error is sent by an SGP if an
ASP sends a message with an invalid (unconfigured) Network Appearance value. For this
error, the invalid (unconfigured) Network Appearance must be included in the Network
Appearance parameter.
0x16
Missing Parameter. The Missing Parameter error is sent if a mandatory parameter is not
included in a message.
0x17
Not used in M3UA
0x18
Not used in M3UA
5-81

Chapter 5 SIGTRAN
Value
Description
0x19
Invalid Routing Context. The Invalid Routing Context error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid
Routing Context(s) must be included in the Error message.
0x1a
Not Configured AS for ASP. The Not Configured AS for ASP error is sent if a message is
received from a peer without a Routing Context parameter and it is not known by
configuration data which ASs are referenced.
III. Message format

The general M3UA message format includes a common message header followed by
zero or more parameters as defined by the message type. For forward compatibility, all
message types may have attached parameters.
1)
Common message header
The protocol messages for MTP3-User adaptation require to contain the version,
message type, message length, and message content. See Figure 5-58. The message
header is common for all signaling protocol adaptation layer messages.
0
1
2
3
01234567890123456789012345678901
Version
Reserved
Message class Message type
Message length
Figure 5-58 Common message header

z
M3UA Protocol Version
The Version field contains the version of the M3UA adaptation layer. The supported
version is Release 1.0 protocol with the value 00000001.
z
Message Classes and Types
Table 5-35 lists the message classes defined by M3UA. Table 5-36, Table 5-37, Table
5-38, Table 5-39, Table 5-40, and Table 5-41 respectively list the message types
defined by M3UA.
Table 5-35 M3UA message classes
Message class
Message class code (hexadecimal)
Management (MGMT) messages
00
Transfer messages
01
SS7 signaling network management (SSNM) messages
02
ASP state maintenance (ASPSM) messages
03
5-82

Chapter 5 SIGTRAN
Message class
Message class code (hexadecimal)
ASP traffic maintenance (ASPTM) messages
04
Reserved for other SIGTRAN adaptation layers
05
06
07
08
Routing key management (RKM) messages
09
0A to 7F
Reserved for IETF-defined message class extensions
80 to FF
Table 5-36 M3UA management (MGMT) message types

Message type
Message type code (hexadecimal)
Error (ERR)
00
Notify (NTFY)
01
02 to 7F
Reserved for IETF-defined MGMT extensions
80 to FF
Table 5-37 M3UA transfer message types

Message type
Reserved
00
Data (DATA)
01
02 to 7F
Reserved for IETF-defined transfer extensions
80 to FF
Table 5-38 M3UA signaling network management (SSNM) message types

Message type
Reserved
00
Destination unavailable (DUNA)
01
Destination available (DAVA)
02
Destination state audit (DAUD)
03
SS7 network congestion (SCON)
04
5-83

Chapter 5 SIGTRAN
Message type
Destination user part unavailable (DUPU)
05
Destination restricted (DRST) (not in use temporarily)
06
7 to 7F
Reserved for IETF-defined SSNM extensions
80 to FF
Table 5-39 M3UA state maintenance (ASPSM) message types

Message type
Reserved
00
ASP up (ASPUP)
01
ASP down (ASPDN)
02
Heartbeat (BEAT)
03
ASP up acknowledgement (ASPUP ACK)
04
ASP down acknowledgement (ASPDN ACK)
05
Heartbeat acknowledgement (BEAT ACK)
06
7 to 7F
Reserved for IETF-defined ASPSM extensions
80 to FF
Table 5-40 M3UA traffic maintenance (ASPTM) message types

Message type
Reserved
00
ASP active (ASPAC)
01
ASP inactive (ASPIA)
02
ASP active acknowledgement (ASPAC ACK)
03
ASP inactive acknowledgement (ASPIA ACK)
04
5 to 7F
Reserved for IETF-defined ASPTM extensions
80 to FF
Table 5-41 M3UA routing key management (RKM) message types

Message type
Reserved
00
5-84

Chapter 5 SIGTRAN
Message type
Registration request (REG REQ)
01
Registration response (REG RSP)
02
Deregistration request (DEREG REQ)
03
Deregistration response (DEREG RSP)
04
5 to 7F
Reserved for IETF-defined RKM extensions
80 to FF
Message Length
The message length defines the length of the message in octets, including the common
header. For messages with a final parameter containing padding, the parameter
padding must be included in the message length.
2)
Variable-length parameter format
M3UA messages consist of a common header followed by zero or more variable length
parameters. Figure 5-59 shows the format of all the parameters contained in a
message.
0
1
2
3
01234567890123456789012345678901
Parameter tag
Parameter length
Parameter value
Figure 5-59 Variable-length parameter format

Where more than one parameter is included in a message, the parameters may be in
any order, except where explicitly mandated. A receiver should accept the parameters
in any order.
z
Parameter Tag
The Tag field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534.
Common parameters used by adaptation layers are in the range of 0x00 to 0x3F.
M3UA-specific parameters have tags in the range of 0x0200 to 0x02FF. Table 5-42 lists
the common parameter tags defined.
Table 5-42 Common parameter tags
Parameter
Parameter tag code (hexadecimal)
Reserved
0x0000
5-85

Chapter 5 SIGTRAN
Parameter
Not used in M3UA
0x0001
Not used in M3UA
0x0002
Not used in M3UA
0x0003
INFO string
0x0004
Not used in M3UA
0x0005
Routing context
0x0006
0x0007
Not used in M3UA
0x0008
Heartbeat data
0x0009
Not used in M3UA
0x000a
Traffic mode type
0x000b
Error code
0x000c
Status
0x000d
Not used in M3UA
0x000e
Not used in M3UA
0x000f
Not used in M3UA
0x0010
ASP identifier
0x0011
Affected signaling point code
0x0012
Correlation ID
0x0013
Table 5-43 lists the M3UA specific parameters.

Table 5-43 M3UA specific parameters
Parameter
Network appearance
0x0200
Reserved
0x0201
Reserved
0x0202
Reserved
0x0203
User/cause
0x0204
Congestion indications
0x0205
Concerned destination
0x0206
Routing key
0x0207
5-86

Chapter 5 SIGTRAN
Parameter
Registration result
0x0208
Deregistration result
0x0209
local_routing key identifier
0x020a
Destination point code
0x020b
Service indicators
0x020c
Reserved
0x020d
Originating point code list
0x020e
Circuit range
0x020f
Protocol data
0x0210
Reserved
0x0211
Registration status
0x0212
Deregistration status
0x0213
0x0214-0xffff
Parameter Length
The Parameter Length is 16 bits. The Parameter Length field contains the size of the
parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. The parameter length does not include any padding bytes.
z
Parameter Value
The Parameter Value is variable-length. The Parameter Value field contains the actual
information to be transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length, and Value fields)
must be a multiple of four bytes. If the length of the parameter is not a multiple of four
bytes, the sender pads the parameter at the end with all zero bytes. The length of the
padding is not included in the Parameter Length field. A sender should not pad with
IV. Transfer Messages

1)
Data (DATA)
A DATA message contains a common message header and zero or more parameters
defined by the message type.
The DATA message contains the SS7 MTP3-User protocol data, including the complete
MTP3 routing label. The DATA message contains the optional Network Appearance
(not in use temporarily), optional Routing Context, mandatory Protocol data, and
optional Correlation ID parameters.
5-87

Chapter 5 SIGTRAN
Figure 5-60 shows the parameter format of the DATA message.

0
1
2
3
01234567890123456789012345678901
Tag (0x0200)
Length =8
Network appearance
Length =8
Tag (0x0006)
Routing context
Tag (0x00210)
Length =8
Protocol data
Tag (0x0013)
Length =8
Correlation Id
Figure 5-60 DATA message parameter format

z
Network Appearance
It is a parameter in the message to supplement the network indicator (NI).

In a DATA message, the Network Appearance implicitly defines the SS7 point code
format used, the SS7 network indicator value, and the MTP3/MTP3-User protocol
type/variant/version.
For example, two areas belong to the same NI (national network), but their signaling
point formats are different. One area employs the 24-bit signaling point encoding
scheme, and the other employs the 14-bit signaling point encoding scheme. In such a
case, the network appearance parameter in the message is required.
The Network Appearance parameter value is of local significance only, coordinated
between the SGP and ASP. Therefore, in the case where an ASP is connected to more
than one SGP, the same SS7 network context may be identified by different Network
Appearance values depending on which SGP a message is being transmitted or
received.
Where the Network Appearance parameter is present, it must be the first parameter in
the message as it defines the format of the protocol data field.
The network appearance parameter is not used in the M3UA protocol specification
temporarily.
z
Routing Context
The routing context is a 32-bit value. In a message, it represents the routing key.
The Routing Context parameter contains the Routing Context value associated with the
DATA message. Where a Routing Key has not been coordinated between the SGP and
ASP, sending of Routing Context is not required. Where multiple Routing Keys and
Routing Contexts are used across a common association, the Routing Context must be
sent to identify the traffic flow, assisting in the internal distribution of Data messages.
5-88

Chapter 5 SIGTRAN
Protocol Data
The Protocol Data parameter contains the original SS7 MTP3 message, including the
service information octet and routing label.
The Protocol Data Parameter contains the Service Indicator (SI), Network Indicator (NI),
Destination Point Code (DPC), Originating Point Code (OPC), and Signaling Link
Selection Code (SLS) fields.
User Protocol Data includes MTP-User protocol elements (for example, ISUP, SCCP,
or TUP parameters).
Figure 5-61 shows the format of the protocol data parameter.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Reserved
OPC
Reserved
DPC
SI
Reserved
NI
Reserved
SLS
User Protocol Data
Figure 5-61 Format of protocol data parameter

z
Originating Point Code
The Originating Point Code field contains a 32-bit value.

z
Destination Point Code
The Destination Point Code field contains a 32-bit value. The Originating and
Destination Point Code fields contain the OPC and DPC from the routing label of the
original SS7 message in network byte order, justified to the least significant bit. Unused
bits are coded 0.
z
Service Indicator
The 8-bit Service Indicator field contains the SI field from the original SS7 message
justified to the least significant bit. Unused bits are coded 0.
z
Network Indicator
The 8-bit Network Indicator contains the NI field from the original SS7 message justified
to the least significant bit. Unused bits are coded 0.
z
Signaling Link Selection
5-89

Chapter 5 SIGTRAN
The 8-bit Signaling Link Selection field contains the SLS bits from the routing label of
the original SS7 message justified to the least significant bit and in Network Byte Order.
Unused bits are coded 0.
z
User Protocol Data
The User Protocol Data field contains a byte string of MTP-User information from the
original SS7 message starting with the first byte of the original SS7 message following
the Routing Label.
z
Correlation ID
The Correlation ID parameter uniquely identifies the MSU carried in the Protocol Data
within an AS. This Correlation ID parameter is assigned by the sending M3UA.
V. SS7 Signaling Network Management (SSNM) Messages

1)
Destination Unavailable (DUNA)
The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate
that the SG has determined that one or more SS7 destinations are unreachable. It is
also sent by an SGP in response to a message from the ASP to an unreachable SS7
destination. As an implementation option the SG may suppress the sending of
subsequent "response" DUNA messages regarding a certain unreachable SS7
destination for a certain period to give the remote side time to react. If there is no
alternate route through another SG, the MTP3-User at the ASP is expected to stop
traffic to the affected destination through the SG in accordance with the defined
MTP3-User procedures.
The DUNA message contains the optional Network Appearance, optional Routing
Context, mandatory Affected Point Code, and optional INFO String parameters.
Figure 5-62 shows the structure of the DUNA message.
5-90

0
Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0200
Length = 8
Network Appearance
Tag = 0x0006
Length
Routing Context
Tag = 0x0012
Mask
Length
Affected PC 1
...
Mask
Affected PC n
Tag = 0x0004
Length
INFO String
Figure 5-62 Structure of DUNA message

z
Network Appearance
Refer to the description of the Network Appearance field in the DATA message.
z
Routing Context
The optional Routing Context parameter contains the Routing Context values
associated with the DUNA message. Where a Routing Key has not been coordinated
between the SGP and ASP, sending of Routing Context is not required. Where multiple
Routing Keys and Routing Contexts are used across a common association, the
Routing Context(s) must be sent to identify the concerned traffic flows for which the
DUNA message applies, assisting in outgoing traffic management and internal
distribution of MTP-PAUSE indications to MTP3-Users at the receiver.
z
Affected Point Code
The Affected Point Code parameter contains a list of Affected Destination Point Code
fields, each three-octet parameter to allow for 14-, 16- and 24-bit binary formatted SS7
Point Codes. Affected Point Codes that are less than 24 bits are padded on the left to
the 24-bit boundary.
z
INFO String
5-91

Chapter 5 SIGTRAN
The optional INFO String parameter can carry any meaningful UTF-8 [10] character
string along with the message. Length of the INFO String parameter is from 0 to 255
octets. No procedures are presently identified for its use but the INFO String may be
used for debugging purposes.
2)
Destination Available (DAVA)
The DAVA message is sent from an SGP to all concerned ASPs to indicate that the SG
has determined that one or more SS7 destinations are now reachable (and not
restricted), or in response to a DAUD message if appropriate. If the ASP M3UA layer
previously had no routes to the affected destinations the ASP MTP3-User protocol is
informed and may now resume traffic to the affected destination. The ASP M3UA layer
now routes the MTP3-user traffic through the SG initiating the DAVA message.
The DAVA message contains the optional Network Appearance, optional Routing
z
Network Appearance
The format and description of the Network Appearance are the same as for the DUNA
message.
z
Routing Context
The format and description of the Routing Context are the same as for the DUNA
message.
z
Affected Point Code
The format and description of the Affected Point Code are the same as for the DUNA
message.
z
INFO String
The format and description of the INFO String are the same as for the DUNA message.
3)
Destination State Audit (DAUD)
The DAUD message may be sent from the ASP to the SGP to audit the
availability/congestion state of SS7 routes from the SG to one or more affected
destinations.
The DAUD message contains the optional Network Appearance, optional Routing
z
Network Appearance
message.
z
Routing Context
message.
z
Affected Point Code
5-92

Chapter 5 SIGTRAN
message.
z
INFO String
4)
Signaling Congestion (SCON)
The SCON message can be sent from an SGP to all concerned ASPs to indicate that
an SG has determined that there is congestion in the SS7 network to one or more
destinations, or to an ASP in response to a DATA or DAUD message as appropriate.
For some MTP protocol variants (for example, ANSI MTP) the SCON message may be
sent when the SS7 congestion level changes. The SCON message may also be sent
from the M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer or the
ASP is congested.
The SCON message contains the optional Network Appearance, optional Routing
Context, mandatory Affected Point Code, optional Concerned Destination, optional
Congestion Indications, and optional INFO String parameters.
Figure 5-63 shows the structure of the SCON message.
5-93

0
Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0200
Length = 8
Network Appearance
Tag = 0x0006
Length
Routing Context
Tag = 0x0012
Length
Mask
Affected PC 1
...
Mask
Affected PC n
Tag = 0x0206
Length = 8
Reserved
Concerned DPC
Tag = 0x0205
Length = 8
Reserved
Cong. Level
Tag = 0x0004
Length
INFO String
Figure 5-63 Structure of SCON message

z
Network Appearance
message.
z
Routing Context
message.
z
Affected Point Code
message.
5-94

Chapter 5 SIGTRAN
The Affected Point Code parameter can be used to indicate congestion of multiple
destinations or ranges of destinations.
Concerned Destination
The optional 32-bit Concerned Destination parameter is only used if the SCON
message is sent from an ASP to the SGP. It contains the point code of the originator of
the message that triggered the SCON message. The Concerned Destination
parameter contains one Concerned Destination Point Code field, a three-octet
parameter to allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. A
Concerned Point Code that is less than 24 bits is padded on the left to the 24-bit
boundary.
Congestion Indications
The optional 32-bit Congestion Indications parameter contains a Congestion Level field.
This optional parameter is used to communicate congestion levels in national MTP
networks with multiple congestion thresholds, such as in ANSI MTP3. For MTP
congestion methods without multiple congestion levels (for example, the ITU
international method) the parameter is not included.
Congestion Level
The 8-bit Congestion Level field, associated with all of the Affected DPC(s) in the
Affected Destinations parameter, contains one of the values as shown in Table 5-44.
Table 5-44 Congestion level values
Value
Meaning
No congestion or undefined
Congestion level 1
Congestion level 2
Congestion level 3
The congestion levels are defined in the congestion method in the appropriate national
MTP recommendations [7,8].
z
INFO String
5)
Destination User Part Unavailable (DUPU)
The DUPU message is used by an SGP to inform concerned ASPs that a remote peer
MTP3-User Part (for example, ISUP or SCCP) at an SS7 node is unavailable.
The DUPU message contains the optional Network Appearance, optional Routing
Context, mandatory Affected Point Code, mandatory User/Cause, and optional INFO
String parameters.
5-95

Chapter 5 SIGTRAN
Figure 5-64 shows the structure of the DUPU message.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0200
Length = 8
Network Appearance
Tag = 0x0006
Length
Routing Context
Tag = 0x0012
Length = 8
Mask = 0
Affected PC
Tag = 0x0204
Length = 8
Cause
User
Tag = 0x0004
Length
INFO String
Figure 5-64 Structure of DUPU message

z
Network Appearance
message.
z
Routing Context
message.
z
Affected Point Code
The format and description of the Affected Point Code parameter are the same as for
the DUNA message except that the Mask field is not used and only a single Affected
DPC is included. Ranges and lists of Affected DPCs cannot be signaled in a DUPU
message, but this is consistent with UPU operation in the SS7 network. The Affected
Destinations parameter in an MTP3 User Part Unavailable message (UPU) received by
an SGP from the SS7 network contains only one destination.
z
User/Cause
5-96

Chapter 5 SIGTRAN
The Unavailability Cause and MTP3-User Identity fields, associated with the Affected
PC in the Affected Point Code parameter, are encoded as follows.
Unavailability Cause field
The 16-bit Unavailability Cause parameter provides the reason for the unavailability of
the MTP3-User. The valid values for the Unavailability Cause parameter are shown in
Table 5-45.
Table 5-45 Unavailability cause values
Value
Meaning
Unknown
Unequipped remote user
Inaccessible remote user
The values agree with those provided in the SS7 MTP3 User Part Unavailable
message. Depending on the MTP3 protocol used in the Network Appearance,
additional values may be usedthe specification of the relevant MTP3 protocol
variant/version recommendation is definitive.
MTP3-User Identity field
The 16-bit MTP3-User Identity describes the specific MTP3-User that is unavailable
(for example, ISUP and SCCP). Some of the valid values for the MTP3-User Identity
are shown in Table 5-46.
Table 5-46 MTP3-User identity values
Value
Meaning
0 to 2
Reserved
SCCP
TUP
ISUP
6 to 8
Reserved
Broadband ISUP
10
Satellite ISUP
11
Reserved
12
AAL type 2 signaling
13
Bearer Independent Call Control (BICC)
14
Gateway control protocol
15
Reserved
5-97

Chapter 5 SIGTRAN
The values align with those provided in the SS7 MTP3 User Part Unavailable message
and Service Indicator. Depending on the MTP3 protocol variant/version used in the
network appearance, additional values may be used. The relevant MTP3 protocol
variant/version recommendation is definitive.
z
INFO String
6)
Destination Restricted (DRST)
The DRST message is optionally sent from the SGP to all concerned ASPs to indicate
that the SG has determined that one or more SS7 destinations are now restricted from
the point of view of the SG, or in response to a DAUD message if appropriate. The
M3UA layer at the ASP is expected to send traffic to the affected destination through an
alternate SG with route(s) of equal priority, but only if such an alternate route exists and
is available. If the affected destination is currently considered unavailable by the ASP,
The MTP3-User should be informed that traffic to the affected destination can be
resumed. In this case, the M3UA layer should route the traffic through the SG initiating
the DRST message.
The DRST message contains the optional Network Appearance, optional Routing
z
Network Appearance
message.
z
Routing Context
message.
z
Affected Point Code
message.
z
INFO String
VI. ASP State Maintenance Messages

1)
ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation
layer is ready to receive any ASPSM/ASPTM messages for all Routing Keys that the
ASP is configured to serve.
The ASP Up message contains the optional ASP Identifier and optional INFO String
parameters.
5-98

Chapter 5 SIGTRAN
Figure 5-65 shows the structure of the ASP Up message.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0011
Length = 8
ASP Identifier
Tag = 0x0004
Length
INFO String

ASP Identifier
The 32-bit ASP Identifier parameter contains a unique value that is locally significant
among the ASPs that support an AS. The SGP should save the ASP Identifier to be
used, if necessary, with the Notify message.
INFO String
the DUNA message.
2)
ASP Up Acknowledgement (ASP Up Ack)
The ASP UP Ack message is used to acknowledge an ASP Up message received from
a remote M3UA peer.
The ASP Up Ack message contains the optional INFO String parameter.
Figure 5-66 shows the structure of the ASP Up Ack message.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length
Tag = 0x0004
INFO String

z
INFO String
5-99

Chapter 5 SIGTRAN
the DUNA message.
The INFO String in an ASP Up Ack message is independent from the INFO String in the
ASP Up message (that is, it does not have to echo back the INFO String received).
3)
ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that the adaptation
layer is NOT ready to receive DATA, SSNM, RKM or ASPTM messages.
The ASP Down message contains the optional INFO String parameter.
Figure 5-67 shows the structure of the ASP Down message.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length
Tag = 0x0004
INFO String

INFO String
the DUNA message.
4)
ASP Down Acknowledgement (ASP Down Ack)
The ASP Down Ack message is used to acknowledge an ASP Down message received
from a remote M3UA peer.
The ASP Down Ack message contains the optional INFO String parameter.
Figure 5-68 shows the structure of the ASP Down Ack message.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length
Tag = 0x0004
INFO String
Figure 5-68 Structure of ASP Down Ack message
5-100

Chapter 5 SIGTRAN
INFO String
the DUNA message.
The INFO String in an ASP Down Ack message is independent from the INFO String in
the ASP Down message (that is, it does not have to echo back the INFO String
received).
5)
Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers are still available
to each other. It is recommended for use when the M3UA runs over a transport layer
other than the SCTP, which has its own heartbeat.
The BEAT message contains the optional Heartbeat Data parameter.
Figure 5-69 shows the structure of the BEAT message.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0009
Length
Heartbeat Data
Figure 5-69 Structure of BEAT message

z
Heartbeat Data
The Heartbeat Data parameter contents are defined by the sending node. The
Heartbeat Data could include, for example, a Heartbeat Sequence Number and/or
Timestamp. The receiver of a BEAT message does not process this field as it is only of
significance to the sender. The receiver must respond with a BEAT Ack message.
6)
Heartbeat Acknowledgement (BEAT Ack)
The BEAT Ack message is sent in response to a received BEAT message. It includes
all the parameters of the received BEAT message, without any change.
VII. Routing Key Management Messages

1)
Registration Request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer that it
wishes to register one or more given Routing Keys with the remote peer. Typically, an
ASP would send this message to an SGP, and expects to receive a REG RSP message
in return with an associated Routing Context value.
5-101

Chapter 5 SIGTRAN
The REG REQ message contains one or more mandatory Routing Key parameter.
Figure 5-70 shows the structure of the REG REQ message.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0207
Length
Routing Key 1
Tag = 0x0207
Length
Routing Key n
Figure 5-70 Structure of REG REQ message

z
Routing Key
The mandatory Routing Key parameter is a variable-length value. The sender of this
message expects that the receiver of this message will create a Routing Key entry and
assign a unique Routing Context value to it, if the Routing Key entry does not already
exist.
The Routing Key parameter may be present multiple times in the same message. This
is used to allow the registration of multiple Routing Keys in a single message.
Figure 5-71 shows the format of the Routing Key parameter.
5-102

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Local-RK-Identifier
Traffic Mode Type (optional)
Network Appearance (optional)
Service Indicators (optional)
Originating Point Code List (optional)
Circuit Range List (optional)

Service Indicators (optional)
Originating Point Code List (optional)
Circuit Range List (optional)
Figure 5-71 Format of Routing Key parameter

The Destination Point Code, Service Indicators, Originating Point Code List, and Circuit
Range List parameters may be repeated as a grouping within the Routing Key
parameter, in the structure shown above.
Local-RK-Identifier
The 32-bit Local-RK-Identifier field is used to uniquely identify the registration request.
The Identifier value is assigned by the ASP, and is used to correlate the response in an
REG RSP message with the original registration request. The Identifier value must
remain unique until the REG RSP message is received.
Figure 5-72 shows the format of the Local-RK-Identifier field.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length = 8
Tag = 0x020a
Local-RK-Identifier value
Figure 5-72 Format of Local-RK-Identifier field
5-103

Chapter 5 SIGTRAN
Traffic Mode Type
The 32-bit Traffic Mode Type parameter identifies the traffic mode of operation of the
ASP(s) within an AS.
Figure 5-73 shows the format of the Traffic Mode Type Identifier.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x000b
Length = 8
Traffic Mode Type
Figure 5-73 Format of Traffic Mode Type Identifier

Table 5-47 lists the valid values for Traffic Mode Type.
Table 5-47 Valid values for Traffic Mode Type
Value
Traffic mode type
Override
Loadshare
Broadcast
The Destination Point Code parameter is mandatory, and identifies the Destination
Point Code of incoming SS7 traffic for which the ASP is registering. The format is the
same as described for the Affected Destination parameter in the DUNA message.
Figure 5-74 shows the format of the Destination Point Code.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x020b
Mask = 0
Length = 8
Figure 5-74 Format of Destination Point Code

z
Network Appearance
The optional Network Appearance parameter field identifies the SS7 network context
for the Routing Key, and has the same format as in the DATA message. The absence of
5-104

Chapter 5 SIGTRAN
the Network Appearance parameter in the Routing Key indicates the use of any
Network Appearance value.
Figure 5-75 shows the format of the Network Appearance.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length = 8
Tag = 0x0200
Network Appearance
Figure 5-75 Format of Network Appearance parameter

Service Indicators
The optional SI field contains one or more Service Indicators from the values as
described in the MTP3-User Identity field of the DUPU message. The absence of the SI
parameter in the Routing Key indicates the use of any SI value, excluding of course
MTP management. Where an SI parameter does not contain a multiple of four SIs, the
parameter is padded out to 32-byte alignment.
Figure 5-76 shows the format of the Service Indicators parameter.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x020c
SI #1
Length
SI #2
SI #3
SI #4
SI #n
0 Padding, if necessary
Figure 5-76 Format of Service Indicators parameter

z
Originating Point Code List
The Originating Point Code List parameter contains one or more SS7 OPC entries, and
its format is the same as the Destination Point Code parameter. The absence of the
OPC List parameter in the Routing Key indicates the use of any OPC value.
Figure 5-77 shows the format of the Originating Point Code List.
5-105

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x020e
Length
Mask = 0
Origination Point Code #1
Mask = 0
Mask = 0
Origination Point Code #n
Figure 5-77 Format of the Originating Point Code List

Circuit Range
An ISUP controlled circuit is uniquely identified by the SS7 OPC, DPC, and CIC value.
For the purposes of identifying Circuit Ranges in an M3UA Routing Key, the optional
Circuit Range parameter includes one or more circuit ranges, each identified by an
OPC and Upper/Lower CIC value. The DPC is implicit as it is mandatory and already
included in the DPC parameter of the Routing Key. The absence of the Circuit Range
parameter in the Routing Key indicates the use of any Circuit Range values, in the case
of ISUP/TUP traffic. The Origination Point Code is encoded the same as the
Destination Point Code parameter, while the CIC values are 16-bit integers.
Figure 5-78 shows the format of the Circuit Range.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x020f
Mask = 0
Length
Lower CIC Value #1

Mask = 0
Upper CIC Value #1

Lower CIC Value #2
Upper CIC Value #2
Mask = 0
Origination Point Code #n
Lower CIC Value #n
Upper CIC Value #n
Figure 5-78 Format of Circuit Range
5-106

2)
Chapter 5 SIGTRAN
Registration Response (REG RSP)
The REG RSP message is used as a response to the REG REQ message from a
remote M3UA peer. It contains indications of success/failure for registration requests
and returns a unique Routing Context value for successful registration requests, to be
used in subsequent M3UA Traffic Management protocol.
The REG RSP message contains one or more mandatory Registration Result
parameters.
Figure 5-79 shows the structure of the REG RSP message.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0208
Length
Registration Result 1
Tag = 0x0208
Length
Registration Result n
Figure 5-79 Structure of REG RSP message

z
Registration Result
The Registration Result parameter contains the registration result for a single Routing
Key in an REG REQ message. The number of results in a single REG RSP message
must be anywhere from one to the total number of Routing Key parameters found in the
corresponding REG REQ message. Where multiple REG RSP messages are used in
reply to REG REQ message, a specific result should be in only one REG RSP
message.
Figure 5-80 shows the format of each Registration Result.
5-107

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x020a
Length = 8
Local-RK-Identifier value
Tag = 0x0212
Length = 8
Registration Status
Tag = 0x0006
Length = 8
Routing Context
Figure 5-80 Format of Registration Result

Local-RK-Identifier
The 32-bit Local-RK-Identifier contains the same value as found in the matching
Routing Key parameter found in the REG REQ message.
Registration Status
The 32-bit Registration Result Status field indicates the success or the reason for
failure of a registration request.
Table 5-48 lists the values for the Registration Status.
Table 5-48 Values for Registration Status
Value
Meaning
Successfully Registered
Error - Unknown
Error - Invalid DPC
Error - Invalid Network Appearance
Error - Invalid Routing Key
Error - Permission Denied
Error - Cannot Support Unique Routing
Error - Routing Key not Currently Provisioned
Error - Insufficient Resources
Error - Unsupported RK parameter Field
10
Error - Unsupported/Invalid Traffic Handling Mode
5-108

Chapter 5 SIGTRAN
Routing Context
The 32-bit Routing Context field contains the Routing Context value for the associated
Routing Key if the registration was successful. It is set to "0" if the registration was not
successful.
3)
Deregistration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA peer that it
wishes to deregister a given Routing Key. Typically, an ASP would send this message
to an SGP, and expects to receive a DEREG RSP message in return with the
associated Routing Context value.
The DEREG REQ message contains the mandatory Routing Context parameter.
Figure 5-81 shows the structure of the DEREG REQ message.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length
Tag = 0x0006
Routing Context
Figure 5-81 Structure of DEREG REQ message

z
Routing Context
The Routing Context parameter contains (a list of) integers indexing the AS traffic that
the sending ASP is currently registered to receive from the SGP but now wishes to
deregister.
4)
Deregistration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message from a
remote M3UA peer.
The DEREG RSP message contains one or more mandatory Deregistration Result
parameters.
Figure 5-82 shows the structure of the DEREG RSP message.
5-109

0
Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0209
Length
Deregistration Result 1
Tag = 0x0209
Length
Deregistration Result n
Figure 5-82 Structure of DEREG RSP message

Deregistration Result
The Deregistration Result parameter contains the deregistration status for a single
Routing Context in a DEREG REQ message. The number of results in a single DEREG
RSP message may be anywhere from one to the total number of Routing Context
values found in the corresponding DEREG REQ message.
Where multiple DEREG RSP messages are used in reply to DEREG REQ message, a
specific result should be in only one DEREG RSP message. Figure 5-83 shows the
format of each Deregistration Result parameter.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length = 8
Tag = 0x0006
Routing Context
Tag = 0x0213
Length = 8
Deregistration Status
Figure 5-83 Format of Deregistration Result parameter

z
Routing Context
The 32-bit Routing Context field contains the Routing Context value of the matching
Routing Key to deregister, as found in the DEREG REQ message.
z
Deregistration Status
5-110

Chapter 5 SIGTRAN
The 32-bit Deregistration Result Status field indicates the success or the reason for
failure of the deregistration.
Table 5-49 lists the values for the Deregistration Status.
Table 5-49 Values for Deregistration Status
Value
Meaning
Successfully Deregistered
Error - Unknown
Error - Invalid Routing Context
Error - Permission Denied
Error - Not Registered
Error - ASP Currently Active for Routing Context
VIII. ASP Traffic Maintenance Messages

1)
ASP Active
The ASP Active message is sent by an ASP to indicate to a remote M3UA peer that it is
ready to process signaling traffic for a particular AS. The ASP Active message affects
only the ASP state for the Routing Keys identified by the Routing Contexts, if present.
The ASP Active message contains the optional Traffic Mode Type, optional Routing
Context, and optional INFO String parameters.
Figure 5-84 shows the structure of the ASP Active message.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length = 8
Tag = 0x000b
Traffic Mode Type

Tag = 0x0006
Length
Routing Context
Tag = 0x0004
Length
INFO String
Figure 5-84 Structure of ASP Active message
5-111

Chapter 5 SIGTRAN
Traffic Mode Type
The 32-bit Traffic Mode Type parameter identifies the traffic mode of operation of the
ASP within an AS.
Table 5-50 lists he valid values for Traffic Mode Type.
Table 5-50 Valid values for Traffic Mode Type
Value
Traffic mode type
Override
Loadshare
Broadcast
Within a particular Routing Context, Override, Loadshare and Broadcast should not be
mixed. The Override value indicates that the ASP is operating in Override mode, and
the ASP takes over all traffic in an AS (that is, primary/backup operation), overriding
any currently active ASPs in the AS. In Loadshare mode, the ASP will share in the
traffic distribution with any other currently active ASPs. In Broadcast mode, the ASP will
receive the same messages as any other currently active ASP.
z
Routing Context
The optional Routing Context parameter contains (a list of) integers indexing the AS
traffic that the sending ASP is configured/registered to receive.
There is one-to-one relationship between an index entry and an SGP Routing Key or
AS Name. Because an AS can only appear in one Network Appearance, the Network
Appearance parameter is not required in the ASP Active message.
An ASP may be configured to process traffic for more than one logical AS. From the
perspective of an ASP, a Routing Context defines a range of signaling traffic that the
ASP is currently configured to receive from the SGP. For example, an ASP could be
configured to support call processing for multiple ranges of PSTN trunks and therefore
receive related signaling traffic, identified by separate SS7 DPC/OPC/CIC ranges.
z
INFO String
the DUNA message.
2)
ASP Active Acknowledgement (ASP Active Ack)
The ASP Active Ack message is used to acknowledge an ASP Active message
The ASP Active Ack message contains the optional Traffic Mode Type, optional
Routing Context, and optional INFO String parameters.
5-112

Chapter 5 SIGTRAN
Figure 5-85 shows the structure of the ASP Active Ack message.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x000b
Length = 8
Traffic Mode Type

Tag = 0x0006
Length
Routing Context
Tag = 0x0004
Length
INFO String
Figure 5-85 Structure of ASP Active Ack message

z
Traffic Mode Type
The format of the Traffic Mode Type is the same as for the ASP Active message.
z
Routing Context
The format of the Routing Context is the same as for the ASP Active message.
z
INFO String
the DUNA message.
The INFO String in an ASP Active Ack message is independent from the INFO String in
the ASP Active message (that is, it does not have to echo back the INFO String
received).
3)
ASP Inactive
The ASP Inactive message is sent by an ASP to indicate to a remote M3UA peer that it
is no longer an active ASP to be used within a list of ASPs. The ASP Inactive message
affects only the ASP state in the Routing Keys identified by the Routing Contexts, if
present.
The ASP Inactive message contains the optional Routing Context and optional INFO
String parameters.
Figure 5-86 shows the structure of the ASP Inactive message.
5-113

0
Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0006
Length
Routing Context
Tag = 0x0004
Length
INFO String
Figure 5-86 Structure of ASP Inactive message

Routing Context
The format and description of the optional Routing Context are the same as for the ASP
Active message.
INFO String
The format and description of the optional INFO String are the same as for the ASP
Active message.
4)
ASP Inactive Acknowledgement (ASP Inactive Ack)
The ASP Inactive Ack message is used to acknowledge an ASP Inactive message
The ASP Inactive Ack message contains the optional Routing Context and optional
INFO String parameters.
Figure 5-87 shows the structure of the ASP Inactive Ack message.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x0006
Length
Routing Context
Tag = 0x0004
Length
INFO String
Figure 5-87 Structure of ASP Inactive Ack message

z
Routing Context
5-114

Chapter 5 SIGTRAN
The format of the Routing Context parameter is the same as for the ASP Inactive
message.
z
INFO String
the DUNA message.
The INFO String in an ASP Inactive Ack message is independent from the INFO String
in the ASP Inactive message (that is, it does not have to echo back the INFO String
received).
IX. Management Messages

1)
Error
The Error message is used to notify a peer of an error event associated with an
incoming message. For example, the message type might be unexpected in the current
state, or a parameter value might be invalid.
The Error message contains the mandatory Error Code, mandatory Routing Context,
mandatory Network Appearance, mandatory Affected Point Code, and optional
Diagnostic Information parameters.
Notes:
The Routing Context, Network Appearance, and Affected Point Code parameters are only mandatory for
specific Error Codes.
Figure 5-88 shows the structure of the Error message.
5-115

Chapter 5 SIGTRAN
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x000c
Length = 8
Error Code
Tag = 0x0006
Length
Routing Context
Tag = 0x0012
Length
Mask
Affected Point Code 1
Mask
Affected Point Code n
Tag = 0x0200
Length = 8
Netw ork Appearance
Tag = 0x0007
Length

z
Error Code
The 32-bit Error Code parameter indicates the reason for the Error message.
shows the Error parameter values.
z
Values for Error parameter Diagnostic Information
When included, the variable-length Diagnostic Information can be any information

germane to the error condition, to assist in identification of the error condition.
2)
Notify
The Notify message is used to provide an autonomous indication of M3UA events to an

M3UA peer.
The Notify message contains the mandatory Status, optional ASP Identifier, optional
Routing Context, and optional INFO String parameters.
5-116

Chapter 5 SIGTRAN
Figure 5-89 shows the structure of the Notify message.

0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tag = 0x000d
Length = 8
Status Type
Status Information
Tag = 0x0011
Length = 8
ASP Identifier
Tag = 0x0006
Length
Routing Context
Tag = 0x0004
Length
INFO String
Figure 5-89 Structure of Notify message

Status Type
The 16-bit Status Type parameter identifies the type of the Notify message. Table 5-51
lists the valid values for the Status Type.
Table 5-51 Valid values for Status Type
Value
Meaning
Application Server State Change (AS-State_Change)
Other
Status Information
The 16-bit Status Information parameter contains more detailed information for the
If the Status Type is AS-State_Change, the Status Information values are shown in
Table 5-52.
5-117

Chapter 5 SIGTRAN
Table 5-52 Values for Status Information if Status Type is AS-State_Change

Value
Definition
Reserved
Application Server Inactive (AS-INACTIVE)
Application Server Active (AS-ACTIVE)
Application Server Pending (AS-PENDING)
These notifications are sent from an SGP to an ASP upon a change in status of a
particular AS. The value reflects the new state of the AS.
If the Status Type is Other, the Status Information values are defined in Table 5-53.
Table 5-53 Values for Status Information if Status Type is Other
Value
Definition
Meaning
Insufficient ASP Resources

Active in AS
In the Insufficient ASP Resources case, the SGP is

indicating to an ASP_INACTIVE ASP in the AS that another
ASP is required to handle the load of the AS (Loadsharing
or Broadcast mode).
Alternate ASP Active
For the Alternate ASP Active case, an ASP is informed

when an alternate ASP transitions to the ASP-ACTIVE state
in Override mode. The ASP Identifier (if available) of the
Alternate ASP must be placed in the message.
ASP Failure
For the ASP Failure case, the SGP is indicating to ASP(s) in

the AS that one of the ASPs has transitioned to
ASP-DOWN. The ASP Identifier (if available) of the failed
ASP must be placed in the message.
These notifications are not based on the SGP reporting the state change of an ASP or
AS.
z
ASP Identifier
The format and description of the optional ASP Identifier are the same as for the ASP
Up message.
z
Routing Context
The format and description of the Routing Context parameter are the same as for the
ASP Active message.
z
INFO String
The format and description of the INFO String parameter are the same as for the ASP
Active message.
5-118

Chapter 5 SIGTRAN

The following examples show M3UA message flows for the establishment of traffic
between an SGP and an ASP. It is assumed that the SCTP association is already set
up.
I. Establishment of Association and Traffic Between SGPs and ASPs

1)
Single ASP in an application server
This scenario shows the example M3UA message flows for the establishment of traffic
between an SGP and an ASP, where only one ASP is configured within an AS (no
backup).
z
Single ASP in an application server (1+0 sparing), no registration
In such conditions, the sending of M3UA messages is shown in Figure 5-90.

SGP/IPSP
ASP1/IPSP1
ASP Up
ASP Up Ack
ASP active (RCn)
RC: Routing Context

(optional)
ASP active Ack (RCn)
Figure 5-90 Procedure to set up an M3UA message (example 1)

z
Single ASP in an application server (1+0 sparing), dynamic registration
This scenario is the same as the former one but with the optional exchange of
registration information. In this case the registration is accepted by the SGP. In such
conditions, the sending of M3UA messages is shown in Figure 5-91.
SGP
ASP1
ASP Up
ASP Up Ack
REG REQ (LRCn,RKn)
LRC: Local Routing Context

RK: Routing Key
RC: Routing Context
REGRSP (LRCn,RKn)
ASP active (RCn)
5-119

z
Chapter 5 SIGTRAN
Single ASP in multiple application servers (each with 1+0 sparing), dynamic
registration
In such conditions, the sending of M3UA messages is shown in Figure 5-92.

SGP
ASP1
ASP Up
ASP Up Ack
REG REQ( LRC1,RK1 )
REG RSP(LRC1,RC1 )
LRC: Local Routing Context

RK: Routing Key
RC: Routing Context
ASP active (RC1)

ASP active Ack (RC1)
REG REQ (LRCn,RKn)

REG RSP (LRCn,RCn)
ASP active (RCn)
II. ASP traffic fail-over examples

1)
1+1 sparing, withdrawal of ASP, back-up over-ride
Referring to Figure 5-93, ASP1 withdraws from service as shown in Figure 5-93.
SGP
ASP1
ASP2
ASP inactive
ASP inactive Ack
NTFY (AS-Pending)
ASP active
ASP active Ack
Figure 5-93 ASP traffic fail-over (example 1)

Note: If the SGP M3UA layer detects the loss of the M3UA peer (M3UA heartbeat loss
or detection of SCTP failure), the initial ASP inactive message exchange (that is, SGP
to ASP1) would not occur.
5-120

2)
Chapter 5 SIGTRAN
1+1 sparing, back-up over-ride
Following on from the example in Figure 5-94, and ASP2 wishes to over-ride ASP1 and
take over the traffic. See Figure 5-94.
SG
ASP1
ASP2
ASP active
ASP active Ack
NTFY (alternate ASP-active)
Figure 5-94 ASP traffic fail-over (example 2)
III. Normal Withdrawal of an ASP from an Application Server and Teardown of

an Association
An ASP which is now confirmed in the state ASP-INACTIVE (that is, the ASP has
received an ASP inactive Ack message) may now proceed to the ASP-DOWN state, if it
is to be removed from service.
See Figure 5-95.
SGP
ASP inactive (RCn)
ASP1
ASP inactive Ack (RCn)
RC: Routing Context
DEREG REQ (RCn)

DEREG RSP (LRCn,RCn)
ASP Down
ASP Down Ack
Figure 5-95 Example of normal withdrawal of an ASP from an application server and teardown of an
association
5.5 IUA
5.5.1 Introduction
This section describes the need for ISDN Q.921-User Adaptation (IUA) layer protocol
as well as how this protocol shall be implemented. Defined by RFC 3057, IUA defines a
5-121

Chapter 5 SIGTRAN
protocol for backhauling of ISDN Q.921 User messages over IP using the Stream
Control Transmission Protocol (SCTP).IUA supports both ISDN Primary Rate Access
(PRA) as well as Basic Rate Access (BRA) including the support for both point-to-point
(P2P) and point-to-multipoint (M2MP) modes of communication. Figure 5-96 shows the
details.
DSS1
IUA
SG
ISDN EP
Q.931
Q.921
PSTN
MGC
IP
(NIF)
Q.921
Q.931
IUA
IUA
SCTP
SCTP
IP
IP
Figure 5-96 Location of IUA in the system
5.5.2 Terminology
I. Interface
An interface supports the relevant ISDN signaling channel. This signaling channel MAY
be a 16 kbit/s D channel for an ISDN BRA as well as 64 kbit/s primary or backup D
channel for an ISDN PRA.
II. Application Server (AS)

An AS is a logical entity serving a specific application instance. An example of an
Application Server is a MGC handling the Q.931 and call processing for D channels
terminated by the Signaling Gateways.
III. Application Server Process (ASP)

A process instance of an Application Server. Examples of Application Server
Processes are primary or backup MGC instances.
IV. Layer Management

Layer management is a nodal function that handles the inputs and outputs between the
IUA layer and a local management entity.
5-122

Chapter 5 SIGTRAN
5.5.3 Services Provided by the IUA Layer

I. Support for Transport of Q.921/Q.931 Boundary Primitives
In DSS1, all Q.921/Q.931 boundary primitives are standard. IUA layer needs to support
all of the primitives of this boundary to successfully backhaul Q.931.The primitives are
DL-ESTABLISH, DL-RELEASE, DL-DATA, and DL-UNIT DATA.
II. Support for Communication Between Layer Management Modules on SG

and MGC
The IUA layer needs to provide some services that will facilitate communication
between Layer Management modules on the SG and MGC. The primitives are M-TEI
STATUS and M-ERROR.
III. Support for Management of Active Associations Between SG and MGC

The IUA layer can be instructed by the layer management to establish an SCTP
association to a peer IUA node. This procedure can be achieved using the M-SCTP
ESTABLISH primitive. Nine primitives between the IUA layer and the layer
management are defined below to help the layer management manage the SCTP
association(s) between the SG and MGC:
z
M-SCTP ESTABLISH
M-SCTP RELEASE
M-SCTP STATUS
M-ASP STATUS
M-ASP-UP
M-ASP-DOWN
M-ASP-ACTIVE
M-ASP-INACTIVE
M-AS STATUS
5.5.4 Functions Implemented by the IUA Layer

I. Mapping
The IUA layer MUST maintain a map of the interface identifier to a physical interface on
the SG.A physical interface would be a E1 interface or a timeslot on the interface. In
addition, for a given interface the SG MUST be able to identify the associated signaling
channel. IUA layers on both SG and MGC MAY maintain the status of TEIs and SAPIs.
The SG maps an interface identifier to an SCTP association/stream only when an ASP
sends an ASP Active message for a particular interface identifier. It MUST be noted,
however, that this mapping is dynamic and could change at any time due to a change of
5-123

Chapter 5 SIGTRAN
ASP state. Therefore, the SG MUST maintain the states of AS/ASP and reference them
during the routing of a message to an AS/ASP.
II. Status of ASPs

The IUA layer on the SG MUST maintain the state of the ASPs it is supporting. The
state of an ASP changes because of reception of peer-to-peer messages (such as
ASPM messages) or reception of indications from the local SCTP association. At a SG,
an application server list MAY contain active and inactive ASPs to support ASP
load-sharing and fail-over procedures. When, for example, both a primary and a
back-up ASP are available, IUA peer protocol is required to control which ASP is
currently active. The ordered list of ASPs within a logical application server is kept
updated in the SG to reflect the active application server process(es).
Also the IUA layer MAY need to inform the local management of the change in status of
an ASP or AS. This can be achieved using the M-ASP STATUS or M-AS STATUS
primitives.
III. SCTP Stream Management

SCTP allows a user specified number of streams to be opened during the initialization.
It is the responsibility of the IUA layer to ensure proper management of these streams.
Because of the unidirectional nature of streams, an IUA layer is not aware of the stream
number to interface identifier mapping of its peer IUA layer. Instead, the interface
identifier is in the IUA message header. The use of SCTP streams within IUA is
recommended in order to minimize transmission and buffering delay, therefore
improving the overall performance and reliability of the signaling elements.
It is
recommended that a separate SCTP stream is used for each D channel.
IV. Seamless Network Management Interworking

The IUA layer on the SG SHOULD pass an indication of unavailability of the IUA-User
(Q.931) to the local layer management, if the currently active ASP moves from the
ACTIVE state. The layer management could instruct Q.921 to take some action, if it
deems appropriate. Likewise, if an SCTP association fails, the IUA layer on both the SG
and ASP sides MAY generate Release primitives to take the data links out-of-service.
V. Congestion Management
If the IUA layer becomes congested (implementation dependent), it MAY stop reading
from the SCTP association to flow control from the peer IUA.
5.5.5 Structure of IUA Protocol Stack

Figure 5-97 shows the IUA protocol stack.
5-124

Chapter 5 SIGTRAN
Q.931
IUA
LM
SCTP
IP
Figure 5-97 Structure of IUA protocol stack
5.5.6 Definition of IUA Boundaries

I. Definition of IUA/Q.921 Boundary
Four primitives are defined for communication between IUA and Q.921:
z
DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA
II. Definition of IUA/Q0.931 Boundary

Four primitives are also defined between IUA and Q.931:
z
DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA
III. Definition of IUA/SCTP Boundary

For the primitives defined between IUA and SCTP, refer to 5.2.6 Basic Signaling
Procedures.
IV. Definition of IUA/Layer-Management Boundary

Table 5-54 lists the primitives defined between IUA and the layer management of IUA
endpoint.
Table 5-54 Boundaries between IUA and layer management (LM)
Boundary
M-SCTP ESTABLISH request
Direction
LM -> IUA
5-125
Purpose
LM requests ASP to establish an SCTP
association with an SG.

Boundary
Chapter 5 SIGTRAN
Direction
Purpose
M-STCP ESTABLISH confirm
IUA -> LM
ASP confirms to LM that it has established an

SCTP association with an SG.
M-SCTP ESTABLISH indication
IUA -> LM
SG informs LM that an ASP has established an

SCTP association.
M-SCTP RELEASE request
LM -> IUA
LM requests ASP to release an SCTP

association with SG.
M-SCTP RELEASE confirm
IUA -> LM
ASP confirms to LM that it has released SCTP

association with SG.
M-SCTP RELEASE indication
IUA -> LM
SG informs LM that ASP has released an SCTP

association.
M-SCTP_RESTART indication
IUA -> LM
IUA informs LM that an instruction to restart

SCTP has been received.
M-SCTP STATUS request
LM -> IUA
LM requests IUA to report status of SCTP

association.
M-SCTP STATUS confirm
IUA -> LM
IUA reports status of SCTP association.
M-ASP STATUS request
LM -> IUA
LM requests SG to report status of remote ASP.
M-ASP STATUS confirm
IUA -> LM
SG reports status of remote ASP.
M-AS STATUS request
LM -> IUA
LM requests SG to report status of AS.
M-AS_STATUS indication
IUA -> LM
SG reports status of remote AS.
M-NOTIFY indication
IUA -> LM
ASP reports that it has received a NOTIFY

message from its peer.
M-ERROR indication
IUA -> LM
ASP or SG reports that it has received an

ERROR message from its peer.
M-ASP_UP request
LM -> IUA
LM requests ASP to start its operation and send

an ASP UP message to the SG.
M-ASP_UP confirm
IUA -> LM
ASP reports that it has received an ASP UP

Acknowledgement message from the SG.
M-ASP_DOWN request
LM -> IUA
LM requests ASP to stop its operation and send

an ASP DOWN message to the SG.
M-ASP_DOWN confirm
IUA -> LM
ASP reports that it has received an ASP DOWN

Acknowledgement message from the SG.
M-ASP_ACTIVE request
LM -> IUA
LM requests ASP to send an ASP ACTIVE

message to the SG.
M-ASP_ACTIVE confirm
IUA -> LM
ASP reports that it has received an ASP

ACTIVE Acknowledgement message from the
SG.
M-ASP_INACTIVE request
LM -> IUA
LM requests ASP to send an ASP INACTIVE

message to the SG.
5-126

Chapter 5 SIGTRAN
Boundary
Direction
M-ASP_INACTIVE confirm
IUA -> LM
Purpose
ASP reports that it has received an ASP
INACTIVE Acknowledgement message from
the SG.
5.5.7 Implementation of IUA

Figure 5-98 shows a typical implementation of IUA in an NGN solution.
SoftX3000
IUA
RSP subscriber frame
UMG8900
BRA
PRA
PBX
ISDN terminal
ISDN terminal
Figure 5-98 Typical implementation of IUA
The UMG8900 interoperates with the PBX through PRA and accesses the ISDN
terminals through the BRA interfaces provided by the RSP subscriber frame. The
UMG8900 transparently transmits the Q.931 messages in BRA and PRA to the
SoftX3000 through IUA. The SoftX3000 processes the Q.931 call control messages.
5.5.8 IUA Protocol Messages

I. Message structure
As shown in Figure 5-99, the IUA message structure is composed of a common
message header, an IUA message header, and several variable-length IUA messages.
5-127

Common Header
Chapter 5 SIGTRAN
Version(8)
Spare(8)
Message class(8)
Message type(8)
Message length(8)
IUA message
Header
Tag(16)
Length(16)
Parameter tag(16)
IUA message 0#
Parametervalue(32)
Parameter tag(16)
IUA message n#
Parametervalue(32)
Figure 5-99 IUA message structure

The common message header contains the Version, Spare, Message Class, Message
Type, and Message Length fields. The message header part applies to all signaling
protocol adaptation layer messages.
Version
The version field contains the version of the IUA adaptation layer. The currently
supported version number is 0000 0001, which means version 1.0.
Spare
The length of the spare field is eight bits. This field SHOULD be set to all '0's and
ignored by the receiver.
Message Class
Table 5-55 Message class codes

Value
Meaning
00
Management (MGMT) messages [IUA/M2UA/M3UA/V5UA]
01
02
SS7 signaling network management (SSNM) messages [M3UA/SUA]
03
04
05
06
07
08

5-128

Chapter 5 SIGTRAN
Value
Meaning
09
0A
0B-7F
80-FF
Message Type
The message types as listed in Table 5-55, Table 5-56, Table 5-57 and Table 5-58 are
defined according to different message classes.
Table 5-56 Q.921/Q.931 boundary primitives transport (QPTM) messages
Value
Message type
Meaning
00
Reserved
01
Data Request
A Data Request contains an ISDN Q.921 user protocol data

unit (PDU). A PDU corresponds to a confirmed information
transmission service.
02
Data Indication
A Data Indication message indicates that the peer IUA has

successfully processed a received Data Request message.
03
Unit Data Request
A Unit Data Request message contains an ISDN Q.921 user

PDU. A PDU corresponds to a unconfirmed information
transmission service.
04
Unit Data Indication
A Unit Data Indication message indicates that the peer IUA

has successfully processed a received Unit Data Request
message.
05
Establish Request
An Establish Request message establishes a data link on a

signaling channel or confirms that a data link has been
established on a signaling channel. MGC controls the status
of channel D. When MGC expects channel D to be in the
service operation state, it sends an Establish Request
message.
06
Establish Confirm
SG sends an Establish Confirm message to confirm an

Establish Request message.
07
Establish Indication
SG sends an Establish Indication message to indicate that a

data link has been established in a signaling channel.
08
Release Request
MGC sends a Release Request to release a data link on a

signaling channel.
09
Release Confirm
SG sends a Release Confirm message to respond to a

Release Request message
0A
Release Indication
SG sends a Release Indication message to indicate that a

data link has been released on a signaling channel.
0B-7F
5-129

Value
80-FF
Chapter 5 SIGTRAN
Message type
Reserved
IETF-defined
extensions
for
QPTM
Meaning
-
Table 5-57 IUA application server process state maintenance (ASPSM) messages
Value
Message type
Meaning
00
Reserved
01
ASP Up (UP)
ASP sends an ASP Up (UP) message to SG to indicate that

ASP is ready to receive traffic or maintenance messages.
02
ASP Down (DOWN)
ASP sends an ASP Down (DOWN) message to SG to

indicate that ASP is not ready to receive traffic or
maintenance messages.
03
Heartbeat (BEAT)
It is optionally used to ensure that the IUA peers are still

available to each other.
04
ASP Up Ack (UP ACK)
It is used to acknowledge an ASP Up message received

from a remote IUA peer.
05
ASP Down Ack (DOWN

ACK)
It is used to acknowledge an ASP Down message received

from a remote IUA peer.
06
Heartbeat Ack (BEAT

ACK)
It is sent in response to a Heartbeat message. An IUA peer

must send a Heartbeat Ack message in response to a
Heartbeat message. The Heartbeat Ack message includes
all the parameters of the received Heartbeat message,
without any change.
07-7F07-7F
80-FF
Reserved
IETF-defined
extensions
for
ASPSM
Table 5-58 IUA application server process traffic maintenance (ASPTM) messages
Value
Message type
Meaning
00
Reserved
01
ASP Active (ACTIVE)
It is sent by an ASP to indicate to an SGP that it is active and

ready to be used.
02
ASP Inactive (INACTIVE)
It is sent by an ASP to indicate to an SG that it is no longer an

active ASP.
03
ASP Active Ack (ACTIVE

ACK)
It is used to respond to an ASP Active message received

from a remote IUA.
5-130

Value
Chapter 5 SIGTRAN
Message type
Meaning
04
ASP
Inactive
(INACTIVE ACK)
Ack
It is used to respond to an ASP Inactive message received

from a remote IUA.
05-7F
80-FF
Reserved
IETF-defined
extensions
for
ASPTM
Table 5-59 IUA management (MGMT) messages

Value
Message type
Meaning
00
ERROR
It is used to notify a peer of an error event associated with an

incoming message. For example, the message type might be
unexpected given the current state, or a parameter value
might be invalid.
01
Notify (NTFY)
It is used to provide the automatic indication of an IUA event

to the IUA peer.
02
TEI Status Request
It is interchanged between peers of IUA layer to request the

status of a specific TEI.
03
TEI Status Confirm
It is interchanged between peers of IUA layer to confirm the

04
TEI Status Indication
It is interchanged between peers of IUA layer to indicate the

05-7F
80-FF
Reserved
IETF-defined
extensions
1)
for
MGMT
Message Length
The message length field defines the length of the message in octets, including the
header.
III. Variable-Length Parameter Format

IUA messages consist of a common header followed by zero or more variable-length
parameters, as defined by the message type. The variable-length parameters
contained in a message are defined in a tag-length-value format.
A variable-length parameter consists of the [Parameter Tag], [Parameter Length], and
[Parameter Value] fields.
z
Parameter Tag
The [Parameter Tag] field is a 16-bit identifier of the type of parameter.

5-131

Chapter 5 SIGTRAN
Parameter Length
The [Parameter Length] field must be a multiple of four bytes. If it is not a multiple of
four bytes, the sender pads with all zero bytes after the Parameter Value field. The
[Parameter Length] must not be padded with all zero bytes. A sender must not pad with
Parameter Value
The [Parameter Value] has a variable length. It contains the actual information to be
transferred in the parameter.
IV. Format of IUA Message Header

In addition to the common message header, there will be a specific message header for
QPTM and the TEI Status MGMT messages. The IUA message header will
immediately follow the common header in these messages.
As shown in Figure 5-100, this message header consists of the tag, length, interface
identifier, and data link connection identifier (DLCI).
0
15
Parameter tag=0x01
31
Parameter length

Parameter tag=0x05
Parameter length=8
Spare
DLCI
Figure 5-100 IUA message header

z
Tag
The 16-bit [Tag] field indicates the type of the interface identifier. Table 5-60 shows the
correspondence between the tag values of the IUA message header and the types of
the interface identifier.
Table 5-60 Correspondence between tag values and interface identifier types
Tag value
Interface identifier type
0x0001
Integer
0x0003
Text
5-132

Chapter 5 SIGTRAN
Note:
The integer formatted interface identifier MUST be supported. The text formatted Interface Identifier MAY
optionally be supported. The interface identifier of the character string type is not supported at present.
Length
The [Parameter Length] values of the IUA message header vary with different types of
interface identifiers.
The [Length] value is 8 if the type of the interface identifier is integer.
The [Length] value is variable if the type of the interface identifier is text. The maximum
length does not exceed 255 octets. The length is equal to the length of the interface
identifier plus four bytes (the tag and length fields).
z
The interface identifier identifies the physical interface at the SG for which the signaling
messages are sent/received. The format of the [Interface Identifier] parameter can be
text or integer. The interface identifiers are assigned according to network operator
policy. The integer values used are of local significance only, coordinated between the
SG and ASP.
V. Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages

1)
Data Request message
The Data Request message contains the common message header followed by IUA
message header. As shown in Figure 5-101, the Data message contains a mandatory
protocol data. The protocol data contains the upper layer Q.931 message.
0
15
Parameter tag=0x00e
31
Parameter length
Protocol data(32)
Figure 5-101 Structure of Data message
2)
Unit Data Request message
The Data Request message contains the common message header followed by IUA
message header. As shown in Figure 5-102 the Unit Data Request message contains a
mandatory protocol data. The protocol data contains the upper layer Q.931 message.
5-133

Chapter 5 SIGTRAN
15
Parameter tag=0x00e
31
Parameter length
Protocol data(32)
Figure 5-102 Structure of Data Acknowledge message
3)
Establish messages (Request, Confirm, Indication)
The Establish messages contain the common message header followed by IUA
message header. It does not contain any additional parameters.
4)
Release messages (Request, Indication, Confirmation)
The Release messages contain the common message header followed by IUA
message header. The Release Confirm message does not contain any additional
parameters. The Release Request and Indication messages contain the parameters as
shown in Figure 5-103:
0
15
Parameter tag=0x00f
31
Parameter length
Reason
Figure 5-103 Structure of Release Request and Release Indication messages
Table 5-61 shows the valid values for the [Reason] parameter.
Table 5-61 Valid values for the [Reason] parameter
Value
Define
Description
0x00
RELEASE_MGMT
Management layer generated release.
0x01
RELEASE_PHYS
Physical layer alarm generated release.
0x02
RELEASE_DM
Specific to a request. Indicates Layer 2 SHOULD

release and deny all requests from far end to
establish a data link on the signaling channel (that
is, if SABME is received, send a DM)
0x03
RELEASE_OTHER
Other reasons
Caution:
Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid reason codes for a Release
Request message.
5-134

Chapter 5 SIGTRAN
VI. IUA application server process state maintenance (ASPSM) messages

The IUA ASPSM messages will only use the common message header.
The ASP state maintenance messages only use the common message header.
1)
ASP Up
As shown in Figure 5-104, the ASP Up message contains an optional [INFO String]
parameter.
0
15
31
Parameter tag=0x4
Parameter length
INFO string
The optional [INFO String] parameter can carry any meaningful 8-bit ASCII character
string along with the message. Length of the [INFO String] parameter is from 0 to 255
characters. No procedures are presently identified for its use but the INFO String MAY
be used for debugging purposes.
2)
ASP Up Ack
As shown in Figure 5-105, the ASP Up Ack message contains an optional [INFO String]
parameter. The format and description of the INFO String in the ASP Up Ack message
0
15
31
Parameter tag=0x04
Parameter length
INFO string
3)
ASP Down
As shown in Figure 5-106, the ASP Down message contains the mandatory [Reason]
parameter and the optional [INFO string] parameter.
0
15
31
Parameter tag=0x0a
Parameter length
Reason
Parameter tag=0x4
Parameter length
INFO string
5-135

z
Chapter 5 SIGTRAN
Reason
The [Reason] parameter indicates the reason that the remote IUA adaptation layer is
unavailable. The value of this parameter is fixed set to 0x01, indicating that ASP is
under management inhibition. If an ASP is removed from Management Inhibit, the ASP
will send an ASP Up message.
z
INFO string
The format and description of the [INFO String] parameter are the same as for the ASP
Up message.
4)
ASP Down Ack
The ASP Down Ack message contains the mandatory [Reason] parameter and the
optional [INFO String] parameter. The format and description of the [Reason] and
[INFO String] parameters are the same as for the ASP Down message.
5)
Heartbeat
As shown in Figure 5-107, the Heartbeat message contains an optional [Heartbeat

Data] parameter.
0
15
Parameter tag=0x09
31
Parameter length
Heartbeat data
Figure 5-107 Structure of Heartbeat message
The [Heartbeat Data] parameter contents are defined by the sending node. The
Heartbeat Data could include, for example, a Heartbeat Sequence Number and, or
Timestamp. The receiver of a Heartbeat message does not process this field as it is
only of significance to the sender. The receiver MUST respond with a Heartbeat Ack
message.
6)
Heartbeat Ack
The Heartbeat Ack message contains an optional [Heartbeat Data] parameter. The
format and description of the [Heartbeat Data] parameter in the Heartbeat Ack
message are the same as for the Heartbeat message.
VII. IUA application server process traffic maintenance (ASPTM) messages

ASP traffic maintenance messages use the common and IUA message headers.
1)
ASP Active (ASPAC)
As shown in Figure 5-108 and Figure 5-109, the ASP Active message contains the
mandatory [Traffic Mode Type], optional [Interface Identifier], and optional [INFO String]
parameters, according to the text and integer formatted interface identifiers.
5-136

Chapter 5 SIGTRAN
15
Parameter tag=0x0b
31
Parameter length=8
Traffic mode type

Parameter length
Parameter length


Additional Interface Identifier
Parameter tag=0x04
Parameter length
INFO string
Figure 5-108 Structure of ASP Active message (integer formatted interface identifier)
15
Parameter tag=0x0b
31
Parameter length
Traffic mode type

Parameter length
Parameter tag=0x04
Parameter length
INFO string
Figure 5-109 Structure of ASP Active message (text formatted interface identifier)
z
Traffic Mode Type
The [Traffic Mode Type] parameter identifies the traffic mode of operation of the ASP
within an AS. The valid values for the parameter are shown in Table 5-62:
5-137

Chapter 5 SIGTRAN
Table 5-62 Traffic mode types

Value
Definition
Description
0x010x01
Override
The ASP takes over all traffic in an AS (that is,

primary/backup operation), overriding any currently
active ASPs in the AS.
0x02
Load-share
The ASP will share in the traffic distribution with any

other currently active ASPs.
Interface Identifiers (optional)
The optional [Interface Identifiers] parameter contains a list of Interface Identifier

integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) indexing the Application
Server traffic that the sending ASP is configured/registered to receive. If integer
formatted Interface Identifiers are being used, the ASP can also send ranges of
Interface Identifiers (Type 0x8).Interface Identifier types Integer (0x1) and Integer
Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3)
cannot be used with either Integer (0x1) or Integer Range (0x8) types.
If no Interface Identifiers are included, the message is for all provisioned Interface
Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface
Identifiers for an AS are included, the ASP is noted as Active for all the Interface
Identifiers provisioned for that AS.
Caution:
If the optional [Interface Identifier] parameter is present, the integer formatted Interface Identifier must be
supported, while the text formatted Interface Identifier may be supported.
INFO String (optional)
The format and description of the [INFO String] parameter are the same as for the ASP
Up message.
2)
ASP Active Ack (ASPAC ACK)
The ASP Active Ack message contains the mandatory [Traffic Mode Type], optional
[Interface Identifier], and optional [INFO String] parameters.
The format and description of the [Traffic Mode Type] and [Interface Identifier]
parameters are the same as for the ASP Active (ASPAC) message.
The format and description of the optional [INFO String] parameter are the same as for
the ASP Up message.
5-138

3)
Chapter 5 SIGTRAN
ASP Inactive (ASPIA)
The ASPIA message contains the mandatory [Traffic Mode Type], optional [Interface
Identifier], and optional [INFO String] parameters.
The format and description of the [Traffic Mode Type] and [Interface Identifier]
parameters are the same as for the ASP Active (ASPAC) message.
the ASP Up message.
4)
ASP Inactive Ack
The ASP Inactive Ack message contains the optional [Interface Identifier] and [INFO
String] parameters.
The format of the optional [Interface Identifier] parameter is the same as for the ASP
Active message.
the ASP Up message.
VIII. Layer Management (MGMT) Messages

1)
Error
The Error message will only have the common message header. The Error message
contains the mandatory [Error Code] and optional [Diagnostic Information] parameters.
Figure 5-110 shows the structure of the Error message.
0
15
31
Length=8
Tag=0x0C
Error code
Tag=0x07
Length

z
Error Code
The [Error Code] parameter indicates the reason for the Error Message. Table 5-63 lists
the defined IUA error codes.
5-139

Chapter 5 SIGTRAN
Table 5-63 Error codes

Value
Definition
Description
The "Invalid Version" error would be sent if a message was
received with an invalid or unsupported version.
0x010x01
Invalid Version
0x02
Invalid
Identifier
0x03
Unsupported
Message Class
The "Unsupported Message Class" error would be sent if a

message with an unexpected or unsupported Message Class is
received.
0x04
Unsupported
Message Type
The "Unsupported Message Type" error would be sent if a

message with an unexpected or unsupported Message Type is
received.
0x05
Unsupported Traffic
Handling Mode
The "Unsupported Traffic Handling Mode" error would be sent by

a SG if an ASP sends an ASP Active with an unsupported Traffic
Handling Mode. An example would be a case in which the SG did
not support load-sharing.
Interface
0x06
Unexpected
Message
0x07
Protocol Error
0x08
The Error message would contain the supported version in the

common header. The Error message could optionally provide the
supported version in the Diagnostic Information area.
The "Invalid Interface Identifier" error would be sent by a SG if an
ASP sends a message with an invalid (unconfigured) [Interface
Identifier] value.
The "Unexpected Message" error would be sent by an ASP if it

received a QPTM message from an SG while it was in the
Inactive state (the ASP could optionally drop the message and
not send an Error).
It would also be sent by an ASP if it received a defined and
recognized message that the SG is not expected to send (for
example, if the MGC receives an IUA Establish Request
message).
The "Protocol Error" error would be sent for any protocol
anomaly (that is, a bogus message).
Unsupported
Interface
Identifier
Type
Stream
The "Unsupported Interface Identifier Type" error would be sent

by an SG if an ASP sends a text formatted Interface Identifier and
the SG only supports integer formatted Interface Identifiers.
When the ASP receives this error, it will need to resend its
message with an integer formatted Interface Identifier.
The "Invalid Stream Identifier" error would be sent if a message
was received on an unexpected SCTP stream. For example, an
MGMT message was received on a stream other than "0".
0x09
Invalid
Identifier
0x0a
Unassigned TEI
The "Unassigned TEI" error may be used when the SG receives

an IUA message that includes a TEI which has not been
assigned or recognized for use on the indicated ISDN D-channel.
0x0b
Unrecognized SAPI
The "Unrecognized SAPI" error would handle the case of using a

SAPI that is not recognized by the SG.
5-140

Value
0x0c
Chapter 5 SIGTRAN
Definition
Invalid TEI,
combination
Description
SAPI
The "Invalid TEI, SAPI combination" error identifies errors where

the TEI is assigned and the SAPI is recognized, but the
combination is not valid for the interface (for example, on a BRI
the MGC tries to send Q.921 Management messages through
IUA when Layer Management at the SG SHOULD be performing
this function).
The optional Diagnostic information can be any information germane to the error
condition, to assist in the identification of the error condition.
To enhance debugging, the Diagnostic information could contain the first 40 bytes of
the offending message.
2)
Notify (NTFY)
As shown in Figure 5-111 and Figure 5-112, the Notify message contains the
mandatory [Status Type], mandatory [Status Information], optional [ASP Identifier],
optional [Interface Identifiers], and optional [INFO String] parameters.
0
15
31
Parameter tag=0x0d
Parameter length=8
Status type
Status information
Parameter length
Parameter length


Parameter tag=0x04
Parameter length
INFO string
Figure 5-111 Structure of Notify message (with integer-formatted interface identifiers)
5-141

Chapter 5 SIGTRAN
15
31
Parameter tag=0x0d
Parameter length=8
Status type
Status information
Parameter length
Additional Interface Identifier of Tag type 0x03
Parameter tag=0x04
Parameter length
INFO string
Figure 5-112 Structure of Notify message (with text-formatted interface identifiers)

z
Status Type
The [Status Type] parameter identifies the type of the Notify message. Table 5-64 lists
the defined status types.
Table 5-64 Status types
Value
Definition
0x010x01
Application server state change (AS_State_Change)
0x020x02
Other
Status Information
The [Status Information] parameter contains more detailed information for the
If the Status Type is AS_State_Change, the Status Information values shown in Table
5-65 are used: These notifications are sent from an SG to an ASP upon a change in
status of a particular Application Server. The value reflects the new state of the AS.
Table 5-65 Status information whose Status Type is AS_State_Change
Value
Definition
0x010x01
Application Server Down (AS-Down)
0x02
Application Server Inactive (AS_Inactive)
0x03
Application Server Active (AS_Active)
0x04
Application Server Pending (AS_Pending)
5-142

Chapter 5 SIGTRAN
If the Status Type is Other, the Status Information values shown in Table 5-66 are
defined. These notifications are not based on the SG reporting the state change of an
ASP or AS.
Table 5-66 Status information whose Status Type is Other
Value
Definition
Description
0x01
Insufficient ASP
resources active in
AS
In the Insufficient ASP Resources case, the SG is indicating to an

"Inactive" ASP(s) in the AS that another ASP is required in order to
handle the load of the AS (Load-sharing mode).
0x02
Alternate
Active
For the Alternate ASP Active case, an ASP is informed when an

alternate ASP transitions to the ASP-Active state in Over-ride mode.
ASP
The format of the [Interface Identifiers] parameter in the Notify message is the same as
for the ASP Active message.
INFO String
The format of the [INFO String] parameter in the Notify message is the same as for the
ASP Up message.
3)
TEI Status Messages (Request, Confirm and Indication)
The TEI Status messages contain the common message header followed by IUA
message header. The TEI Status Request message does not contain any additional
parameters. As shown in Figure 5-113, the TEI Status Indication, and Confirm
messages contain the mandatory [Status] parameter.
0
15
Parameter tag=0x10
31
Parameter length
Status
Figure 5-113 Structure of TEI Confirm and TEI Indication messages
The valid values for Status are shown in Table 5-67.

Table 5-67 Status in TEI Confirm and TEI Indication messages
Value
Definition
Description
0x00
ASSIGNED
TEI is considered assigned by Q.921.
0x01
UNASSIGNED
TEI is considered unassigned by Q.921.
5-143

Chapter 5 SIGTRAN

I. Establishment of Association and Traffic between SGs and ASPs
z
Single ASP in an Application Server (1+0 sparing)
Figure 5-114shows the example IUA message flows for the establishment of traffic
between an SG and an ASP, where only one ASP is configured within an AS (no
backup). It is assumed that the SCTP association is already set up.
SG
ASP
ASP Up
ASP Up Ack
ASP Active
ASP Active ACK
Figure 5-114 Establishment of traffic when there is a single ASP in an AS

z
Two ASPs in Application Server (1+1 sparing)
between an SG and two ASPs in the same Application Server, where ASP1 is
configured to be Active and ASP2 a standby in the event of communication failure or
the withdrawal from service of ASP1. ASP2 MAY act as a hot, warm, or cold standby
depending on the extent to which ASP1 and ASP2 share call state or can communicate
call state under failure/withdrawal events.
SG
ASP1
ASP2
ASP Up
ASPUP ACK
ASP Up
ASPUP ACK
ASP Acitve
ASP Acitve ACK
Figure 5-115 Establishment of traffic when there are two ASPs in the same AS
z
Two ASPs in an Application Server (1+1 sparing, load-sharing case)
The two ASPs are brought to active and load-share the traffic load. In this case, one
ASP is sufficient to handle the total traffic load. See Figure 5-116.
5-144

SG
Chapter 5 SIGTRAN
ASP1
ASP Up
ASP2
ASPUP ACK
ASP Up
ASPUP ACK
ASP Active (Load-sharing)
ASP Active ACK
ASP Active ACK
Figure 5-116 Establishment of traffic when there are two ASPs in the same AS (in the load-sharing case)
z
Three ASPs in an Application Server (n+k sparing, load-sharing case)
between an SG and three ASPs in the same Application Server, where two of the ASPs
are brought to active and share the load. In this case, a minimum of two ASPs are
required to handle the total traffic load (2+1 sparing).
SG
ASP Up
ASP1
ASP2
ASP3
ASPUP ACK
ASP Up
ASPUP ACK
ASP Up
ASPUP ACK

ASP Active ACK
ASP Active ACK
Figure 5-117 Establishment of traffic when there is are three ASPs in the same AS
II. ASP Traffic Fail-over Examples

z
(1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
Figure 5-118shows a case in which an ASP withdraws from service.
5-145

SG
ASP Up
Chapter 5 SIGTRAN
ASP1
ASP2
ASPUP ACK
Notify (AS Pending)
ASP Active
ASP Active ACK
Figure 5-118 Withdrawal of ASP from service
In this case, the SG notifies ASP2 that the AS has moved to the Down state. The SG
could have also (optionally) sent a Notify message when the AS moved to the Pending
state.
Caution:
If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the initial SG-ASP1
ASP Inactive message exchange would not occur.
(1+1 Sparing, Back-up Over-ride)
Figure 5-119shows a case in which ASP2 wishes to over-ride ASP1 and take over the
traffic. In this case, the SG notifies ASP1 that an alternative ASP has overridden it.
ASP1
SG
ASP Active
ASP2
ASPUP Active ACK

Notify (Alt ASP-ACT))
Figure 5-119 Overriding an active ASP by a backup ASP

z
(n+k Sparing, Load-sharing case, withdrawal of ASP)
between an SG and three ASPs in the same Application Server in the n+k backup and
load-sharing mode. ASP1 withdraws from service. In this case, the SG has knowledge
of the minimum ASP resources required (implementation dependent),for example, if
the SG knows that n+k = 2+1 for a load-share AS and n currently equals 1.
5-146

SG
ASP Inactive
Chapter 5 SIGTRAN
ASP1
ASP3
ASP2
ASP Inactive ACK

NTFY(Ins. ASPs)
ASP Act (Ldshr)
ASP Act (Ack)
Figure 5-120 Withdrawal of service by ASP in the load-sharing mode
Caution:
If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the initial SG-ASP1
ASP Inactive message exchange would not occur.
III. Q.921/Q.931 Primitives Backhaul Examples

Table 5-68 shows the two procedures of sending a QPTM message in two directions.
Table 5-68 Procedures of sending a QPTM message
Direction
Procedure
Step 1: Determine the correct SG.
Step 2: Find the SCTP association to the chosen SG.
ASP->SG
Step 3: Determine the correct stream in the SCTP association

based on the D channel.
Step 4: Fill in the QPTM message, IUA message header, and
common header.
Step 5: Send the QPTM message to the remote IUA peer in the SG,
over the SCTP association.
Step 1: Determine the AS for the Interface Identifier.
Step 2: Determine the Active ASP (SCTP association) within the
AS.
SG->ASP
Step 3: Determine the correct stream in the SCTP association

based on the D channel.
Step 4: Fill in the QPTM message, IUA message header, and
common header.
Step 5: Send the QPTM message to the remote IUA peer in the
ASP, over the SCTP association.
5-147

Chapter 5 SIGTRAN
An example of the message flows for establishing a data link on a signaling channel,
passing PDUs, and releasing a data link on a signaling channel is shown in Figure
5-122. An active association between ASP and SG is established prior to the message
flows.
SG
ASP
Establish Request
Establish Confirm
Data Request
Data Indication
Data Request
Data Indication
Data Request
Data Request
Data Indication
Release Request(Release_MGMT)
Release Confirm
Figure 5-121 Establishing and releasing a data link.
Figure 5-122shows an example of the message flows for a failed attempt to establish a
data link on the signaling channel. In this case, the gateway has a problem with its
physical connection, so it cannot establish a data link on the signaling channel.
SG
Establish Request( Establish START)
ASP
Establish Indication (RELEASE_PHYS)
Figure 5-122 Failure of establishing a data link
IV. Layer Management Communication Examples

An example of the message flows for communication between Layer Management
modules between SG and ASP is shown in Figure 5-123. An active association
between ASP and SG is established prior to the message flows.
5-148

SG
Chapter 5 SIGTRAN
ASP
DATA Request
Error Indication (INVALID_TEI)
TEI Status Request
TEI Status Confirm (Unassigned TEI)
Figure 5-123 Communication between Layer Management modules
5.6 V5UA
5.6.1 Introduction
V5UA is defined by IETF Draft V5.2-User Adaptation Layer (V5UA). It is a mechanism
for backhauling of V5.2 messages over IP using SCTP or other applicable transmission
protocols. See Figure 5-124.
AN
V5.2
LAPV5
V5.2
V5UA
SG
(NIF)
LAPV5
MGC
V5UA
V5UA
M2UA
SCTP
SCTP
IP
IP
Figure 5-124 Location of V5UA in the system
5.6.2 Terminology
I. Bearer Channel Connection (BCC) Protocol
It refers to a protocol which allows the local exchange (LE) to instruct the access
network (AN) to allocate bearer channels, either singly or in multiples, on demand.
II. Communication Channel (C-Channel)

It refers to a 64 kbit/s time slot on a V5.2 interface provisioned to carry communication
channels.
5-149

Chapter 5 SIGTRAN
III. Communication Path (C-Path)

It refers to any one of the following information types:
z
The layer 2 data link carrying the control protocol
The layer 2 data link carrying the link control protocol
The layer 2 data link carrying the PSTN signaling
Each of the layer 2 data links carrying the protection protocol
The layer 2 data link carrying the BCC protocol
All the ISDN Ds-type data from one or more user ports
All the PSTN P-type data from one or more user ports
All the ISDN T-type data from one or more user ports
IV. Envelope Function Address (EFA)

It refers to a 13-bit number, ranging from 0 to 8191 (decimal).An EFA uniquely identifies
one of the five V5.2 protocols, or an ISDN agent attached to an AN. Table 5-69 contains
the possible values for an EFA.
Table 5-69 Corresponding relations between EFA values and protocols
Value
Protocol
08175
ISDN_PROTOCOL
8176
PSTN_PROTOCOL
8177
CONTROL_PROTOCOL
8178
BCC_PROTOCOL
8179
PROT_PROTOCOL
8180
LINK_CONTROL_PROTOCOL
81818191
RESERVED
V. Logical Communication Channel (Logical C-Channel)

It refers to a group of one or more C-paths, all of different types, but excluding the
C-path for the protection protocol.
VI. Multi-Link
It refers to a collection of more than one 2048 kbit/s link which together make up a V5.2
interface.
5-150

Chapter 5 SIGTRAN
VII. Multi-Slot
It refers to a group of more than one 64 kbit/s channels providing 8 kHz and time slot
sequence integrity, generally used together within an ISDN Primary Rate Access
(ISDN-PRA) user port, in order to supply a higher bit-rate service.
VIII. Physical Communication Channel (Physical C-Channel)

It refers to a 64 kbit/s time slot on a V5.2 interface which has been assigned for carrying
logical C-channels. A physical C-channel may not be used for carrying bearer
channels.
IX. Primary Link

It refers to a 2048 kbit/s (E1) link in a multi-link V5.2 interface whose physical
C-channel in time slot 16 carries a C-path for the protection protocol and, on V5.2
initialization, also the C-path for the control protocol, link control protocol, and the BCC
protocol. Other C-paths may also be carried in the time slot 16.
X. Secondary Link
It refers to a 2048 kbit/s (E1) link in a multi-link V5.2 interface whose time slot 16 carries
a C-path for the protection protocol, and, on V5.2 initialization, acts as the standby
C-channel for the control protocol, link control protocol, and BCC protocol and any
other C-paths initially carried in time slot 16 of the primary link.
XI. Layer 1 Functional State Machine (L1 FSM)

It refers to the Functional State Machine in V5 System Management that tracks and
controls the states of the physical E1 links on the interface. The L1 FSM is located on
the SG.
5.6.3 V5UA Functions

I. Client/Server Model
An SG and MGC communicating through V5UA adopts the client/server peer mode.
When the MGC is set to server, the SG is mandatorily set to client. When the MGC is
set to client, the SG is mandatorily set to server. Normally, the MGC (SoftX3000) is set
to client.
The SCTP registered User Port Number Assignment for V5UA is 5675.
5-151

Chapter 5 SIGTRAN
II. SCTP Stream Management

It is recommended that one SCTP stream be used for BCC, Link Control, Control and
PSTN protocol on a specific C-channel. It is recommended to use a separate SCTP
stream for Protection protocol on a specific C-channel. It is also recommended to use
one SCTP stream for all ISDN user ports on a specific C-channel. One single stream
should not be used to carry data of more than one C-channel. In addition, it is
recommended that one separate SCTP stream be used for all MPH (link related)
messages.
5.6.4 Structure of V5UA Protocol Stack

Figure 5-125 shows the V5UA protocol stack.
V5.2
V5UA
LM
SCTP
IP
Figure 5-125 Structure of V5UA protocol stack
5.6.5 Definition of V5UA Boundaries

Table 5-70 lists the boundary primitives defined by V5UA.
Table 5-70 V5UA boundary primitives
Boundary primitive
Description
MDL ESTABLISH Request
It is used to request the outcome of the procedures for establishing

multiple frame operation.
MDL ESTABLISH confirm
It is used to confirm the outcome of the procedures for establishing

MDL ESTABLISH indication
It is used to indicate the outcome of the procedures for establishing

MDL RELEASE request
It is used to request the outcome of the procedures for terminating

MDL RELEASE confirm
It is used to confirm the outcome of the procedures for terminating

MDL RELEASE indication
It is used to indicate the outcome of the procedures for terminating

5-152

Chapter 5 SIGTRAN
Boundary primitive
MPH-LINK
Reporting
MPH-LINK
Reporting
Status
Status
Description
Start
Stop
It is used by V5 system management to request to take the link in

service for use on a V5 interface. On reception of this message L1
FSM on the SG shall also start reporting the status of the V5 link to
the GWC. The use of this primitive is similar to that of the
MPH-Processed primitive defined by V5.2. However, this primitive
has more extended meanings than the MPH-Processed primitive.
It is used by V5 system management to request to take the link out of
service for use on a V5 interface. On reception of this message L1
FSM on the SG shall also stop reporting the status of the V5 link to
the GWC. The use of this primitive is similar to that of the MPH-Stop
primitive defined by V5.2. However, this primitive has more extended
meanings than the MPH-Stop primitive.
MPH-LINK Status Indication
It is used by L1 FSM on the Signaling Gateway to report the status

(operational/non-operational) of a V5 link to V5 system management.
This primitive equals the MPH-AI and MPH-DI primitives in V5.2.
MPH-SA-BIT SET
It is used by system management to request that the L1 FSM in the

SG sets or resets the value of a specified Sa bit on the requested link,
or to report the successful setting or resetting of this bit back to
system management. For V5 this message will be used for the Link
Identification procedure to set/reset the value of the Sa7 bit.
MPH-SA-BIT Status
They are used between system management in the MGC and L1

FSM in the SG to request reporting of the status of a specified Sa bit
on the requested link, or to report (indicate) the status of this bit back
to system management. For V5 these messages will be used for the
Link identification procedure to request or report the status of the Sa7
bit.
MDL-ERROR Indication
It is used to indicate an error condition to V5 System Management.

The only valid reason for this primitive is 'Overload', indicating an
overload condition of the C-channel on the SG.
5.6.6 Implementation of V5UA

Figure 5-126 shows a typical implementation of V5UA in an NGN solution.
5-153

Chapter 5 SIGTRAN
SoftX3000
H.248/V5UA
IP MAN
UMG8900
V5
ONU
POTS
ISDN
Figure 5-126 Typical implementation of V5UA
The UMG8900 is connected to an access network through V5, and transparently

transmits V5.2 message flows to the SoftX3000 through V5UA for processing.
5.6.7 V5UA Protocol Messages

As shown in Figure 5-127, the V5UA message structure is composed of a common
header, a V5UA message header, and several variable-length V5UA messages.
Common Header
Version(8)
Spare(8)
Message class(8)
Message type(8)
Message length(8)
V5UA message
Header
Tag(16)
Length(16)
Parameter tag(16)
V5UA message 0#
Parametervalue(32)
Parameter tag(16)
V5UA message n#
Parametervalue(32)
Figure 5-127 V5UA message structure
5-154

Chapter 5 SIGTRAN

The common message header contains the [Version], [Spare], [Message Class],
[Message Type], and [Message Length] fields. The message header part applies to all
signaling protocol adaptation layer messages.
Version
The version field contains the version of the V5UA adaptation layer. The currently
supported version number is 0000 0001, which means version 1.0.
Spare
The length of the spare field is eight bits. This field SHOULD be set to all '0's and
Message Class
Table 5-71 Message class codes

Value
Description
00
Management (MGMT) messages [IUA/M2UA/M3UA/V5UA]
01
02
SS7 signaling network management (SSNM) messages [M3UA/SUA]
03
04
05
06
07
08
09
0A
0B-7F
80-FF
Message Type
The message types as listed in Table 5-72, Table 5-73, Table 5-74 and Table 5-75 are
defined according to different message classes.
Table 5-72 V5 boundary primitives transport messages (V5PTM)
Value
00
Message type
Reserved
Description
-
5-155

Value
Chapter 5 SIGTRAN
Message type
Description
01
Data Request
It is sent by the MGC and contains an ISDN Q.921 user

protocol data unit (PDU). An PDU corresponds to a confirmed
information transmission service.
02
Data Indication
It is sent by the SG to indicate that the peer IUA has

successfully processed a received Data Request message.
03
Unit Data Request
It is sent by the MGC and contains an ISDN Q.921 user

protocol data unit (PDU). An PDU corresponds to an
unconfirmed information transmission service.
04
Unit Data Indication
It is sent by the SG to indicate that the peer IUA has

successfully processed a received Unit Data Request
message.
05
Establish Request
It is sent by the MGC to establish a data link on a signaling

channel or confirms that a data link has been established on a
signaling channel. MGC controls the status of channel D.
When MGC expects channel D to be in the service operation
state, it sends an Establish Request message.
06
Establish Confirm
SG sends an Establish Confirm message to confirm an

Establish Request message.
07
Establish Indication
SG sends an Establish Indication message to indicate that a

data link has been established in a signaling channel.
08
Release Request
MGC sends a Release Request message to release the data

link on the signaling channel.
09
Release Confirm
SG sends a Release Confirm message to respond to a

Release Request message
0A
Release Indication
SG sends a Release Indication message to indicate that a

data link has been released on a signaling channel.
0B
Link Status Start

Reporting
MGC sends a Link Status Start Reporting message, which is

used between V5 System Management on the MGC and the
L1 FSM on the SG to track the status of a particular E1 link.
This is required regardless of whether or not the E1 link
carries C-channels.
0C
Link Status Stop

Reporting
MGC sends a Link Status Stop Reporting message, which is

used between V5 System Management on the MGC and the
L1 FSM on the SG to stop tracking the status of a particular
E1 link.
0D
Link Status Indication
SG sends a Link Status Indication message, which is used

between V5 System Management on the MGC and the L1
FSM on the SG.
0E
Sa-Bit Set Request
SGC sends a Sa-Bit Set Request message, which is used

between V5 System Management in the MGC and the L1
FSM in the SG to set the status of Sa bits on the E1 links.
0F
Sa-Bit Set Confirm
SG sends a Sa-Bit Set Confirm message to return the status

of Sa bits on the E1 links.
5-156

Value
Chapter 5 SIGTRAN
Message type
Description
10
Sa-Bit Status Request
SGC sends a Sa-Bit Status Request message, which is used

between V5 System Management in the MGC and the L1
FSM in the SG to obtain and read the status of Sa bits on
theE1 links.
11
Sa-Bit Status Indication
SG sends a Sa-Bit Status Indication message to return the

status of Sa bits on the E1 links.
12
Error Indication
SG sends an Error Indication message, which is used

between the V5 stack on the SG and the V5 System
Management in the MGC to indicate an error condition of the
SG.
0B-7F
80-FF
Reserved
IETF-defined
extensions
for
V5PTM
Table 5-73 V5UA application server process state maintenance (ASPSM) messages
Value
Message type
Description
00
Reserved
01
ASP Up (UP)
ASP sends an ASP Up (UP) message to SG to indicate that

ASP is ready to receive services or maintain messages.
02
ASP Down (DOWN)
ASP sends an ASP Down (DOWN) message to SG to indicate

that ASP is not ready to receive services or maintain
messages.
03
Heartbeat (BEAT)
It is optionally used to ensure that the V5UA peers are still

available to each other.
04
ASP Up Ack (UP ACK)
It is used to acknowledge an ASP Up message received from

a remote V5UA peer.
05
ASP Down Ack (DOWN

ACK)
It is used to acknowledge an ASP Down message received

from a remote V5UA peer.
06
Heartbeat Ack (BEAT

ACK)
It is sent in response to a Heartbeat message. An V5UA peer

must send a Heartbeat Ack message in response to a
Heartbeat message. The Heartbeat Ack message includes all
the parameters of the received Heartbeat message, without
any change.
07-7F
80-FF
Reserved
IETF-defined
extensions
for
ASPSM
5-157

Chapter 5 SIGTRAN
Table 5-74 V5UA application server process traffic maintenance (ASPTM) messages
Value
Message type
Description
00
Reserved
01
ASP Active (ACTIVE)
It is sent by an ASP to indicate to an SGP that it is active and

ready to be used.
02
ASP
(INACTIVE)
Inactive
It is sent by an ASP to indicate to an SG that it is no longer an

active ASP.
03
ASP
Active
(ACTIVE ACK)
Ack
It is used to respond to an ASP Active message received from

a remote V5UA.
04
ASP
Inactive
(INACTIVE ACK)
Ack
It is used to acknowledge an ASP Inactive message received

from a remote V5UA peer.
05-7F
80-FF
Reserved
IETF-defined
extensions
for
ASPTM
Table 5-75 V5UA management (MGMT) messages

Value
Message type
Description
00
ERROR
It is used to notify a peer of an error event associated with an

incoming message. For example, the message type might be
unexpected given the current state, or a parameter value
might be invalid.
01
Notify (NTFY)
It is used to provide the automatic indication of an V5UA event

to the IUA peer.
02
TEI Status Request
It is interchanged between peers of V5UA layer to request the

03
TEI Status Confirm
It is interchanged between peers of V5UA layer to confirm the

04
TEI Status Indication
It is interchanged between peers of V5UA layer to indicate the

05-7F
80-FF
Reserved
IETF-defined
extensions
1)
for
MGMT
Message Length
The message length field defines the length of the message in octets, including the
header.
5-158

Chapter 5 SIGTRAN
III. Format of Variable-Length Parameter

V5UA messages consist of a common header followed by zero or more variable-length
parameters, as defined by the message type. The variable-length parameters
contained in a message are defined in a tag-length-value format.
A variable-length parameter consists of the [Parameter Tag], [Parameter Length], and
[Parameter Value] fields.
Parameter Tag
The [Parameter Tag] field is a 16-bit identifier of the type of parameter.

Parameter Length
The [Parameter Length] field must be a multiple of four bytes. If it is not a multiple of
four bytes, the sender pads with all zero bytes after the [Parameter Value] field. The
[Parameter Length] must not be padded with all zero bytes. A sender must not pad with
Parameter Value
The [Parameter Value] has a variable length. It contains the actual information to be
transferred in the parameter.
IV. Format of V5UA Message Header

In addition to the common message header, there will be a specific message header for
V5UA messages. The V5UA message header will immediately follow the common
header in these messages. However, it is used only in QPTM, Error Indication, and all
MGMT messages containing Sa.
As shown in Figure 5-128, for the V5 extension of the IUA Message Header, the
[Envelope Function Address (EFA)] field is included in the [Spare] field in addition to the
integer-formatted interface identifier and DLCI.
0
15
Parameter tag=0x01
31
Parameter length

Parameter tag=0x05
Parameter length=8
EFA
DLCI
Figure 5-128 V5UA message header

z
DLCI
For details of DLCI, refer to 5.5.8 IV Format of IUA Message Header".

z
EFA
5-159

Chapter 5 SIGTRAN
EFA is defined in the V5 standard. The EFA identifies a C-path, which is a 13-bit number,
ranging from 0 to 8191 (decimal). As shown in Table 5-68, an EFA uniquely identifies
one of the five V5.2 protocols, or an ISDN agent attached to an AN.
Caution:
For MPH messages for which DLCI and EFA are not used, SAPI, TEI and EFA shall be set to ZERO and
shall be ignored by the receiver. For all other messages, the DLCI shall be set as defined in the V5.2
standard.
Figure 5-129 shows the integer-formatted interface identifier.

0
15
Parameter tag=0x01
31
Parameter length
Channel ID
Link Identifier
Figure 5-129 Interface Identifier (Integer)

Field
Description
Link Identifier
It refers to the identifier for an E1 link on the SG (27 bits).It must be unique
on the SG. This Link Identifier MUST match the Link Identifier used in the
Link Management Messages defined in this document.
Channel ID
It refers to Channel Identifier (5 bits).This is equal to the time slot number of

the addressed time slot. Possible values are 15, 16 and 31 representing
the possible time slots for C-channels on a V5 interface. For Link
Management messages, the Channel ID must be set to 0.
The text formatted interface identifier shall be coded as the hex representation of the
integer formatted interface identifier, written as a variable length string.
V. Link Status Messages (Start Reporting, Stop Reporting, Indication)

All Link Status Messages contain the V5UA Message Header. The Link Identifier
portion of the Interface Identifier identifies the physical link on the SG addressed by the
message. For all link status messages, the Channel ID shall be set to '0' and shall be
The integer value used for the Link Identifier is of local significance only, coordinated
between the SG and MGC. It has to be unique for every V5 link on the SG.
5-160

Chapter 5 SIGTRAN
The Link Status Indication Message contains the common message header followed by
the V5UA message header. In addition it contains the parameter as shown in Figure
5-130.
0
15
Parameter tag=0x11
31
Parameter length
Link Status
Figure 5-130 Parameter of Link Status Indication message
The valid values for Link Status are shown in the Table 5-76.
Table 5-76 Valid values of Link Status
Value
Definition
Description
0x0000
Operational
Link is in operation.
0x0001
Non-Operational
Link is not in operation.
VI. Sa-Bit Messages (Set Request, Set Confirm, Status Request, Status
Indication)
All Sa-Bit Messages contain the V5UA message header and the additional parameters
of [BIT ID] and [BIT Value] as shown in Figure 5-131.
0
15
Parameter tag=0x12
31
Parameter length
BIT Value
BIT ID
Figure 5-131 Additional parameters of Sa-Bit message

z
BIT ID
Table 5-77 shows the value of BIT ID.

Table 5-77 Value of BIT ID
Value
0x07
Definition
Description
Sa7
Addresses the Sa7 bit
BIT Value
Table 5-78 shows the values of BIT Value.
5-161

Chapter 5 SIGTRAN
Table 5-78 Values of BIT Value

Value
Definition
Description
0x00
Bit is set to ZERO.
0x01
Bit is set to ONE.
Note:
For the Sa-Bit Status Request and Set Confirm messages, the BIT Value should be set to '0' by the sender
and should be ignored by the receiver.
VII. Error Indication Message

The Error Indication message contains the V5UA message header. Its additional
parameter is shown in Figure 5-132.
0
15
Parameter tag=0x13
31
Parameter length
ERROR Reason
Figure 5-132 Additional parameter of Error Indication message
[Error Reason] has only one value, that is, 0x01, whose definition is Overload. It means
that a C-channel is not able to process all Layer 3 messages on this C-channel in a
timely manner (overload condition of the C-channel).
5.6.8 Basic Signaling Procedures of V5UA

I. Link Identification Procedure Initiated by the MGC Through V5UA
Figure 5-133 shows a link identification procedure initiated by the MGC through V5UA.
An active association between ASP and SG is established prior to the following
message flow, and the V5 interface is already activated.
5-162

Chapter 5 SIGTRAN
SG
ASP
Data Request (LnkCtrl:FE-IDReq)
Data Indication (LnkCtrl ACK:FE-IDReq)
Data Indication(LnkCtrl:FE-IDAck)
Data Request (LnkCtrl ACK:FE-IDAck)
Sa_BIT Status Request (Sa7)
Sa_BIT Status Indication(Sa7,ZERO)
Data Request (LnkCtrl:FE-IDRel)
Data Indication (LnkCtrl ACK:FE-IDRel)
Figure 5-133 Link identification procedure initiated by the MGC through V5UA
II. Link Identification Procedure Initiated by the AN Through V5UA

Figure 5-134 shows a link identification procedure initiated by the AN through V5UA.
An active association between ASP and SG is established prior to the following
messages flow, and the V5 interface is already activated.
SG
ASP
Data Indication (LnkCtrl: FE-IDReq)
Data Request (LnkCtrl Ack: FE-IDReq)
Sa-Bit Set Req ( Sa7, ZERO )

Sa-Bit Set Conf (Sa7)
Data Request (LnkCtrl: FE-IDAck)
Data Request (LnkCtrl Ack: FE-IDRel)
Sa-Bit Set Req ( Sa7, ONE )
Sa-Bit Set Conf (Sa 7)
Figure 5-134 Link identification procedure initiated by the AN through V5UA
5-163

Chapter 6 SS7
Chapter 6 SS7
6.1 Overview
Signaling system No.7 (SS7) is made by International Telephone and Telegraph
Consultative Committee (CCITT). SS7 is an international standard common channel
signaling, which features high-speed transmission, potentiality of providing a great
number of signals, powerful functions, flexibility and reliability. It can meet the signaling
requirements of public switched telephone network (PSTN), global system for mobile
communications (GSM), and intelligent network (IN).
Functional structure of the SS7 in the NGN is shown in Figure 6-1.
T
U
P
I
S
U
P
INAP
User part
TCAP
SCCP
Message transfer part
MTP3
MTP2
M3UA
M2UA
MTP1
SCTP
IP
MAC
Figure 6-1 Functional structure of the SS7 in the NGN application

From the above figure, it can be seen that SS7 is divided into two parts: user part (UP)
and message transfer part (MTP).
z
Common MTP: It is to transfer signaling messages between various user functions

reliably. The SS7 can be transmitted through TDM or IP network (The protocol is
M2UA/M3UA).
Independent user part applicable to different users: It is a functional entity which

makes use of the transmission capability of the MTP, including ISDN user part
(ISUP) and IN application part (INAP).
6-1

Chapter 6 SS7
6.2 MTP
MTP is used to transmit signaling messages of various UPs (such as TUP, DUP, and
ISUP) in SS7 system. Its design complies with the ITU-TQ.701-710 recommendations.
The MTP provides reliable signaling message transmission. It takes measures to avoid
message loss, repetition, and out-of-sequence in case of the signaling network failure.
The MTP includes the functional levels of signaling data link (MTP1), signaling link
(MTP2) and signaling network (MTP3).
I. MTP1
The signaling data link function is the Level 1 function (MTP1) of MTP. MTP1 defines
the physical, electrical and functional features of a signaling data link and the means to
access the data link. It is equivalent to the physical layer of open system
interconnection (OSI)s seven-layer model, which is to generate and receive signals
over physical channels.
One signaling data link is composed of two data channels operating at the same data
transmission rate and in two opposite directions. The bit rate of digital message carrier
is 64 kbit/s. It is applicable to transmission links of both lower rate (such as 4.8 kbit/s)
and higher rate (such as 2048 kbit/s).
II. MTP2
The signaling link function is the Level 2 function (MTP2) of MTP. It provides reliable
signaling links for transmitting signaling messages to signaling data links between two
directly connected SPs together with Level 1.
Signaling link function can be divided into eight parts:
z
Demarcation of signal units;
Location of signal units;
Error detection;
Error correction;
Initial alignment;
Processor faults;
Flow control in Level 2;
Monitoring of signaling link error rate.
III. MTP3
The network layer is the Level 3 (MTP3) of MTP. It transmits management messages
between two SPs to ensure the reliable transmission of various signaling messages in
case of the failure of signaling links or STPs. It is equivalent to the third layer (network
layer) of the OSI model.
6-2

Chapter 6 SS7
IV. Signaling Network Function

The signaling network function provided by the MTP3 must ensure the reliable
transmission of signaling messages between SPs in case of the failure of signaling
links or STPs. Therefore, this function includes functions and procedures required in
notifying the remote end of fault results and the configuration function and procedure
required in message routing in the signaling network.
The signaling network function is divided into signaling message processing and
signaling network management, as shown in Figure 6-2.
Level 4
Level 3 message transfer part
Level 2
Signaling network function

Outgoing
Signaling message processing

Message
distribution
Incoming
Message
discrimination
Message
routing
Signaling network management
Signaling traffic
management
Signaling route
management
Signaling link
management
Test and maintenance

----
Signaling message stream

Indication and control
Figure 6-2 Signaling network function

1)
Signaling message processing
The signaling message processing function is to ensure the signaling messages

initiated by a specific UP of a signaling point (SP) to be transmitted to the same UP of
the DSP designated by this UP.
The signaling message processing function is divided into three parts.
z
Message routing function determines the outgoing signaling links through which
messages are transmitted to destinations from every SP.
Message discrimination function is used to identify whether the DSP that receives
a message is the local SP. If the local SP is not the DSP and is capable of
transferring, the message routing function will be enabled to transfer the message.
Message distribution function distributes received signaling messages to

corresponding UPs by every SP.
2)
Signaling network management function
6-3

Chapter 6 SS7
When a signaling link or SP is faulty, signaling network management function provides

the reconfiguration capability of the network. When congestion occurs, it can control
signaling traffic. The reconfiguration capability is to change the routing, bypass faulty
links or faulty SPs of the signaling service through proper procedures. In some cases,
you must activate and align new signaling links to restore signaling traffic required
between two SPs. When faulty links or SPs are restored, the opposite activities and
procedures are used to rebuild the normal configuration of the signaling network.
The signaling network management consists of signaling traffic management, signaling
link management and signaling route management.
When the status of a signaling link, route or SP is changed, the above three
management functions can be activated under proper situations. The following
describes specific contents.
Signaling traffic management: It is to transmit signaling traffic from one link or
route to multiple links or routes. It can restart MTP of an SP or slow down signaling
traffic temporarily in case of congestion.
Signaling link management: It is to restore faulty signaling links, to activate those
links that are not arranged, and to deactivate arranged signaling links.
Signaling route management: It distributes the status information of the signaling
network to block or unblock signaling routes.
6.2.2 Singnaling Message

I. Message Type
Table 6-1 Signaling network management message
Acronym of message
Full name
CHM
Changeover and changeback messages
COO
Changeover-order signal
COA
Changeover-acknowledgement signal
CBD
Changeback-declaration signal
CBA
Changeback-acknowledgement signal
ECM
Emergency-changeover message
ECO
Emergency-changeover-order signal
ECA
Emergency-changeover-acknowledgement signal
FCM
Signaling-traffic-flow-control messages
RCT
Signaling-route-set-congestion-test signal
TFC
Transfer-controlled signal
TFP
Transfer-prohibited signal
6-4

Chapter 6 SS7
Acronym of message
Full name
TFR
Transfer-restricted signal (national option)
TFA
Transfer-allowed signal
RSM
Signaling-route-set-test message
RST
Signaling-route-set-test signal for prohibited destination
RSR
Signaling-route-set-test signal for restricted destination (national option)
MIM
Management inhibit messages
LIN
Link inhibit signal
LUN
Link uninhibited signal
LIA
Link inhibit acknowledgement signal
LUA
Link uninhibited acknowledgement signal
LID
Link inhibit denied signal
LFU
Link forced uninhibited signal
LLT
Link local inhibit test signal
LRT
Link remote inhibit test signal
TRM
Traffic-restart-allowed message
TRA
Traffic-restart-allowed signal
DLM
Signaling-data-link-connection-order message
DLC
Signaling-data-link-connection-order signal
CSS
Connection-successful signal
CNS
Connection-not-successful signal
CNP
Connection-not-possible signal
UFC
User part flow control messages
UPU
User part unavailable signal
II. Message Structure

To meet the requirements of signaling message transmission through the MTP, three
basic signaling unit formats are stipulated: message signaling unit (MSU), link status
signaling unit (LSSU) and fill-in signaling unit (FISU).
z
MSU is to transmit messges of various UPs, management messages, and test and
maintenance messges.
LSSU is to provide link status information so as to connect and restore signaling

links.
6-5

Chapter 6 SS7
FISU is to maintain the normal running of signaling links and play a fill-in part when
no message signaling or link status signaling unit is transmitted.

Message unit structure is shown in Figure 6-3.
MSU
CK
SIF
SIO
16
8N(N 2)
LI
FIB
FSN
BIB
BSN
F
8 Bit sent firstly
Format of message signaling unit
LSS U
CK
SF
16
8 or 16
LI
FIB
FSN
BIB
BSN
Bit sent firstly
Format of link status signaling unit

FISU
CK
16
LI
FIB
FSN
BIB
BSN
Bit sent firstly
Format of fill-in signaling unit
Figure 6-3 Message unit format

Structurally, signaling unit is divided into two parts. One is the mantatory part of MTP
part processing occupied by various signaling units, which consists of eight fixed-length
fields. The other is the signaling message part of user part processing.
1)
Mantatory Part of MTP Processing
This part includes flag (F), forward sequence number (FSN), forward indicator bit (FIB),
backward sequence number (BSN), backward indicator bit (BIB), length indicator (LI),
check bit (CK), status field (SF) and service information octet (SIO).
z
Flag
Flag is also called delimiter. There is a flag at both the start and the end of every
signaling unit. During the transimission of signaling units, every flag indicates the end of
the last signaling unit and the start of the next one. Therefore, in the delimitation
identification of signaling units, a signaling unit is identified by two flags of the start and
the end in the information flow.
The pattern for a flag is 8-bit binary code 01111110.
In addition to the delimitation function, some flags can be inserted between signaling
units in case of overload of signaling links to reduce load.
z
FSN
FSN indicates the sequence number of the transmitted MSU and consists of 7 bits. At
the transmitting end, every transmitted MSU is allocated with a FSN. FSNs are
numbered in a cyclic sequence ranging from 0 to 127 At the receiving end, the FSNs in
6-6

Chapter 6 SS7
the received MSUs are used to check the sequence of the MSUs, which is a part of the
confirmation function. When retransmission is necessary, it is also used to identify the
signal units to be retransmitted. The FSN of FISU or LSSU uses the FSN of the MSU
transmitted last time, instead of being assigned with new sequence numbers.
z
FIB
It occupies one bit. FIB is used in the retransmission process of MSUs. In the normal
operation, FIB has the same state with that of the received BIB. Retransmission is
requested if the received BIB changes its value. Upon retransmitting MSUs, the
signaling terminal will also change the value of FIB (from "1" to "0" or from "0" to "1" ), so
that it is consistent with BIB again until BIB changes its value again when there is
another retransmission request.
z
BSN
The BSN is the sequence number of the confirmed (that is, received correctly) MSUs
being sent back to the transmitting end by the receiving end.
If retransmission is requested, BSN indicates the sequence number of the unit to be
retransmitted.
In the operation of a signaling network, the transmitting end and receiving end set their
FSN independently.
For transmitted and unconfirmed signaling units, the limit value of FSN and BSN is 127.
z
BIB
BIB is used to initiate a retransmission request for a wrong signaling unit received. If an
MSU received is correct, its BIB value remains unchanged when a new signaling unit is
sent. If a wrong MSU is received, the bit will be reversed (that is, from "0" to "1" or from
"1" to "0") and sent, requesting the opposite end to send a correct MSU.
z
LI
LI is used to indicate the number of octets following the length indicator octet and
preceding the check bit (CK) so as to distinguish three types of signaling units.
LI is a number in binary code in the range 063 (decimal numeral). The field of LI is 6
bits.
The LIs of the three types of signaling units are as follows:
Length indicator LI=0
Fill-in signaling unit
Length indicator LI=1 or 2
Link status signaling unit
Length indicator LI> 2:
Message signaling unit
In a signaling network, if the signaling information field of an MSU is more than 62

octets, the length indicator is set to 63. However, if the LI is 63, the maximum length
indicated must not exceed 272 octets.
Note that the numbers of bits and octets between two flags of a signaling unit have to
be calculated frequently in the receiving and processing of signaling units. The CCITT
6-7

Chapter 6 SS7
regulates that the number of bits between two flags of a signaling unit must be an
integral number of octets. The number of octets can be "0" (if only the flag is transmitted)
or 5 (for FISU). The number can also be less than or equal to m+7 octets (m is equal to
272). If the number is beyond the range, it is regarded that there is a signaling unit error.
CK
The field is used for error detection of signaling units. It consists of 16 bits.
The seven fields above mentioned are available in all the three kinds of signaling units.
(Eight fields including end F have been discussed). They are mandatory for every
signaling unit.
SF
Status field is unique to each LSSU, which indicates the statuses of signaling links.
The length of SF can be an octect (8-bit) or two octects (16-bit).
When it is an octect, the lower 3 bits indicates link statuses. The meanings are shown in
Table 6-2.
Table 6-2 Meanings of SF status indication
CBA
Identifier
Indication
Meaning
000
SIO
Status indication O
Out of location
001
SIN
Status indication N
Normal location
010
SIE
Status indication E
Emergency location
011
SIOS
Status indication OS
Out of service
100
SIOP
Status indication OP
Processor outage
101
ISB
Status indication EB
Busy
SIO
The field of SIO is unique to MSUs. It consists of SI and SSF, as shown in Figure 6-4.
The field has 8 bits. SI and SSF occupy 4 bits respectively.
6-8

F CK SIF
Chapter 6 SS7
SIO
SSF
DCBA
Meaning
0000
0100
International message
1000
1100
National message
Reserved (international)
Reserved (national)
SI
DCBA
0000
0001
0010
0011
0100
0101
0110
Meaning
Signaling network management message
Signaling network test and maintenance message
Reserved
Signaling connection control part
Telephone subscriber part
ISUP
Digital user part
0111
1000
Reserved
1111
Figure 6-4 Format and codes of SIO
2)
SI
SI indicates to which user part the transmitted message belongs. In the MTP of a
signaling network, the message processing function distributes a message to the user
part indicated by SI.
SI is coded as Figure 6-4. The capacity of SI allows it to represent messages of16 kinds
of UPs. This diagram only lists those that are frequently used.
3)
SSF
ISSF consists of 4 bits, of which the higher two bits act as the network indicator, and the
lower two bits, coded 00, are reserved presently.
The network indicator serves to distinguish the network attribute of the transmitted
message, that is, to distinguish between an international signaling network message
and a national signaling network message. Figure 6-4 illustrates the codes and network
allocation of SSF.
According to CCITT stipulations, the use of the reserved codes in SSF is determined by
the domestic signaling network conditions in different countries.
4)
Signaling Information Part Processed by User Part
Signaling information part processed by user parts is the SIF in the format of MSU. SIF
is unique to MSUs. It consists of message addressing tag, user signaling information
heading and user signaling information.
6-9

z
Chapter 6 SS7
Tag
Tag includes the information required in sending messages to the destination. Standard
routing tag has 32 bits, which is at the beginning of SIF. The tag includes destination
point code (DPC), originating point code (OPC) and SLS.
Signaling point code is a digital address, which identifies every signaling point in the
No.7 singnaling network uniquely. When the DPC in a message represents the
receiving sigaling point, the message is distributed to the correponding user part (such
as ISUP or SCCP) in the SIO as indicated by the service indicator.
The SLS ensures the sequencing of messages. Any two messages sent with the same
SLS always arrive at the destination in the same sequence as that in which they are
sent. Equal traffic load can be shared among all available links. If a user part regulary
sends messages and distributes the SLS value cyclically, all the service levels to the
destination should be equal. There are four types of tag structures, as shown in Figure
6-5.
Type A
MTP management message
Type B
TUP message
Type C
ISUP message
Type D
SCCP message
Since TCAP messages must be sent through SCCP, TCAP messages belong to the
type of SCCP messages, that is, type D.
F
CK
SIO
SIF
SLC
Management message
CIC
Signaling message
Signaling message
SCCP user data
SLS
CIC
SLC
SLS
LI
FIB FSN BIB
BSN F
OPC
DPC
Type A: MTP management message
OPC
DPC
Type B: TUP message
OPC
DPC
Type C: ISUP message
OPC
DPC
Type D: SCCP message
Figure 6-5 Four types of tag structures

z
Label
It is the field immediately following the tag field. It is composed of H1 and H0, occupies 4
bits respectively, and indicates the group and type of messages. For example, H0=
0001 and H1=0001 in a telephone user part (TUP) message mean that the transmitted
message is an initial address message (IAM); H0=0001 and H1=0100 mean that the
6-10

Chapter 6 SS7
transmitted message is an address complete message (ACM). For signaling network

management messages, if both H0=0001 and H1=0001, it means that the transmitted
message is changeover order signaling (COO); if H0=0001 and H1=0100, it mean that it
is a transmission forbidden message. Since both H1 and H0 occupy 4 bits, a certain
user message can accommodate 256 messages.
z
Signaling message
Signaling message part is also called service message part. This part can be further
divided into several sub-fields. These sub-fields may be mandatory or optional, and
meanwhile they may be of fixed length or variable length so as to meet the needs of
various functions and expansion. Thus the SMU is adaptable to different user
messages with different features, so that these various user messages can be
transmitted through common channels.
For specific format and codes of SIF, refer to the descriptions of codes and format of
user messages.
z
MTP
The fields F, BSN, BIB, FSN, FIB, LI and CK in a signaling unit are mainly used for the
sending and receiving sequence, error detection and correction of signaling message
units. These fields are analyzed and processed in the second function level of a
signaling network, that is, signaling link level. FISU is mainly composed of those fields
with transmission control function. It has the function to "fill-in" in the signaling link, and
therefore the signaling unit of this type is generated and processed by the second
function level.
LSSU is used to transmit the status indication information of a signaling link. It is also
generated and processed on the second function level. The second function level may
generate and transmit corresponding status signaling units according to instructions
from the third level or its judgement, or receive and process the signaling link status
indication sent by the opposite end. If necessary, it reports such statuses as congestion
and processor error to the third level.
The MSUs transmitted in a signaling network fall into three types according to their
roles in the network: MSU used for signaling network management (MSU-SNM), MSU
used for signaling network test and maintenance (MSN-SNT), and MSU generated by
the user part (MSU-UP). The first two types are of type A structure, which are
transmitted between MTPs. They are generated and processed by Level 3. The third
type consists of messages of type B, C and D structures. These messages are
transmitted through the MTP to a specific UP. Level 3 analyzes its message tag, and
determines the message destination; while the generation and processing of its service
message part (SIF) are performed in Level 4, that is, the user part.
The most important message in the MTP layer is the signaling network management
message. The following introduces the general format of the signaling network
management message.
6-11

Chapter 6 SS7
In the signaling network, the signaling network management message is identified by

the SI bit S1=10000 of the SIO in the signaling unit.
As one kind of message signaling unit, the signaling information of the signaling
network management message is transferred by the SIF. The Figure 6-6 shows the
structure of the signaling management message.
Management
H1
information
8n
(n0)
H0
4
SLC
4
OPC
DPC
24/14
24/14
Bit sent firstly
Figure 6-6 General format of the signaling network management message

z
Tag
The tag comprises three parts: DPC, OPC, and SLC.

The DPC and OPC are the same as those described above.
The SLC refers to the signaling link code that connects the DSP and the originating
signaling point (OSP). If transferred messages are not related to the signaling link or
another special code is not specified, the SLC is 0000. Currently a four-bit code is
used. The standby four-bit code is 0000.
z
Heading code
The heading code comprises two four-code bits: H0 and H1.

H0 identifies a management message group, and H1_determines the messages in a
message group. Since H0 and H1 both have four codes, the total message capacity is
up to 256 types. That is, there can be 16 message groups, and each group has 16
types of messages. At present only some of the message types are used. Refer to
Table 6-3.
6-12

Chapter 6 SS7
Table 6-3 Distribution of the heading code of the management message of the signaling network
Message
Group
H1
H0
0000
0001
0010
0011
0100
0101
0110
CBD
CBA
TFA
LID
LFU
0111
1000
LLT
LRT
0000
CHM
0001
COO
COA
ECM
0010
ECO
ECA
FCM
0011
RCT
TFC
TFM
0100
TFP
RSM
0101
RST
RSR
MIM
0110
LIN
LUN
LIA
LUA
TRM
0111
TRA
DLM
1000
DLC
CSS
CNS
CNP
TFR
1001
UFC
1010
UPU
1011
1100
1101
1110
1111
6-1
1001
1010
1011
1100
1101
1110
1111

Chapter 6 SS7
Example
The following is the format of the TFA message:
DCBA 0100
Destination
H1
H0
Flag
24
56
Bit sent firstly
The heading code H1 contains a signaling code, as shown beblow:

D
TFA
III. Signaling Procedure

1)
Message routing
The message routing function is based on the information contained in the routing tag,
that is, the information on DPC and SLC field.
Each signaling point has routing information which determines the signaling link.
Messages are sent in the siganaling link according to the DPC and SLS field.
Typically, the DPC is associated with more than one signaling links which are used to
bear messages. A specific signaling link is selected through the SLS field, thus realizing
load sharing.
Two basic exmples of load sharing:
z
Load sharing among links in the same link group.
Load sharing among links not in the same link group.
Any SLC can be allocated to messages unrelated to the signaling link so that the
messages can be load-shared. The other way is to allocate the default SLC, such as
0000 to these messages. The messages route according to the normal routing
function. In this function, the SLC is used as the SLS to realize load sharing.
2)
Switchover
The switchover program ensures that the signaling services borne on unavailable links
are switched over to alternative signaling links as soon as possible. It also avoids
message loss, repetition and sequencing errors.
To implement this function, buffer updating and recovery are included in the switchover
process. The process is started before the signaling link starts switching over the
service. Buffer updating includes identifying all the messages in the retransmission
buffer of the available signaling link. These message are not received by the remote
end. Recovery includes forwarding relevant messages to the transfer buffer of the
alternative link.
6-1

Chapter 6 SS7
When one signaling link is unavailable, switchover is implemented in the signaling point.
Then the following is conducted:
z
Terminating the sending and receiving of MSUs on relevant signaling links.
Sending LSSUs or FLSUs.
Determining the alternative signaling link.
Running the content updating process of the re-buffer of the unavailable signaling
link.
Transferring signaling services to the alternative signaling link.
3)
Changback
The changback program ensures that the signaling services are transferred from
alternative signaling links to available signaling links as soon as possible. It also avoids
message loss, repetition and sequencing errors. Changback includes the basic
program that uses opposite activities for switchover.
When a signaling link becomes available due to reconnection, recovery or unlocking,
changback is implemented at the signaling point. Then the following is conducted:
z
Determining the alternative signaling link that forwarded normals servies in the
past.
Stopping the transmitting of related services on the alternative signaling link, and
storing the services in the changback buffer.
Sending a changback notification through a related alternative signaling link to the

remote signaling point of the signaling link that becomes available. This message
indicates that the message service on the alternative signaling link can be sent
through the available signaling link.
When receiving the changback confirmation sent by the remote signaling point of
the available signaling link, the relevant signaling point will restart the forwarded
service on the available signaling link.
4)
Activating the signaling link.
When it is decided to activate an inactive signaling link, initial alignment starts:

z
If initial alignment succeeds, the signaling link becomes activated and the
signaling link test starts.
If the signaling link test succeeds, the link prepares to transmit signaling services.
If initinal alignment fails, a new initial alignment process starts on the same
signaling link after time-out for the timer.
If the signaling link test fails, start link recovery until the signaling link is activated
or conduct manual operations.
5)
Recovering the signaling link.
When a signaling link fault is detected, signaling link initial alignment will occur.
z
If initial alignment succeeds, the signaling link test starts.
If the signaling link test succeeds, the link is recovered and can be used for
signaling transmission.
6-2

z
Chapter 6 SS7
If initial alignment fails, a new initial alignment process may be started on the same
signaling link.
If the signaling link test fails, repeat the recovery process until the link is recovered,
or intervene manually.
6)
Deactivating the signaling link.
If not bearing signaling services, an active signaling link can turn inactive through the
deactivating process. If a signaling link is deactivated, the signaling terminals of the
signaling link exit services.
7)
Signaling route management process
The purpose of signaling route management is to ensure that information is reliably

exchanged between signaling points; that is, to ensure the signaling route is available.
The unavailability, restriction, and availabitity of the signaling route are implemented by
the transfer-prohibited, transfer-restricted, and transfer-allowed procedures.
8)
Transfer-prohibited procedure
To facilitate description, three letters are used to represent three kinds of signaling
points: Y for OSP, X for DSP, and Z for signaling transfer point (STP).
z
When Y selects the signaling route from Z to X, Z is unavailable for Y. In this case,
the TFP transfer-prohibited message is sent to Z.
When Z confirms that X is difficult to reach, the transfer-prohibited message is sent

to all reachable adjacent signaling points (by broadcasting).
When Z receives a message sent to X and Z cannot forward the message, the
transfer-prohibited message is sent to an adjacent signaling point and relevant
messages are received at this point.
6.3 ISUP
6.3.1 Overview
I. Basic Concepts
ISUP is one kind of UPs of the No.7 public channel signaling system. It provides the
signaling function required for supporting voice and non-vocie basic bearer services
and supplementary services in the integrated services digital network (ISDN).
ISUP is applied to the hybrid digital/analog network, telephony network, and dedicated
circuit-switched data network. ISUP meets the requirements of CCITT for international
semi-automatic and automatic telephony services and circuit-switched data services.
II. Protocol stack architecture

The ISUP uses services provided by the MTP to transfer information between ISUPs.
Figure 6-7 shows the protocol stack of the ISUP. ISUP information is carried to the MTP
or from MTP to ISUP by primitives in the form of parameters.
6-3

Chapter 6 SS7
ISUP
User part
Message transfer part
M3UA
MTP3
M2UA
MTP2
SCTP
IP
MTP1
MAC
Figure 6-7 ISUP protocol stack

Primitives used between MTP and ISUP include the transfer primitive, recovery
primitive, suspension primitive, and status primitive.
The MTP transfer primitive receives and sends ISUP singaling messages by
encapsulating the messages.
When MTP sends the MTP suspension primitive, it means MTP cannot send messages
to a specific destination as parameters.
When MTP sends the MTP recovery primitive, it means MTP can be recovered to
parameters and can send messages to a specific destination in an unrestricted manner.
When MTP sends the MTP status primitive, it means that the signaling route to a
specific destination is congested or that there is no ISUP on the destination. This may
be because ISUP is not installed or ISUP cannot be accessed. Other unkown factors
may cause this problem too.
III. Application in NGN

ISUP has three application modes in NGN solutions, as shown in Figure 6-8, Figure 6-9
and Figure 6-10.
1)
Application of ISUP in NGN (MTP-MTP)
6-4

Chapter 6 SS7
MTP link
SS7 network
STP(B)
STP(A)
SoftX3000
ISUP
PSTN switch
SS7 trunk circuit
IP MAN
TMG8010 / UMG8900
Figure 6-8 Application of ISUP in NGN (MTP-MTP)

A MTP link goes directly from the SoftX3000 to connect a STP, thus realizing the
interoperation of SS7 with a PSTN switch through an SS7 network. In the voice channel,
the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN.
2)
Application of ISUP in NGN (M2UA-MTP)
SoftX3000
M2UA
ISUP
IP MAN
PSTN switch
TMG8010 / UMG8900
Figure 6-9 Application of ISUP in NGN (M2UA-MTP)

The SoftX3000 provides an M2UA link to connect with the TMG8010, and exchanges
SS7 with a PSTN switch through the TMG8010, which has the function of an
embedded signaling gateway. In the voice channel, the SoftX3000 controls the
TMG8010 to implement the interconnection with the PSTN.
3)
Application of ISUP in NGN (M3UA-MTP)
SoftX3000
SS7 network
SG7000
STP
M3UA link
MTP link
SS7 trunk circuit
IP MAN
TMG8010 / UMG8900
Figure 6-10 Application of ISUP in NGN (M3UA-MTP)

6-5
PSTN switch

Chapter 6 SS7
The SoftX3000 provides an M3UA link to connect with the SG7000, and exchanges
SS7 with a PSTN switch through the SG7000. In the voice channel, the SoftX3000
controls the TMG8010 to implement the interconnection with the PSTN.

ISUP messages are transferred on the signaling link through the MSU. The messages
are encapsulated in the SIF of the MSU. An ISUP message consists of six parts: routing
tag, circuit identification code (CIC), message type code, mandatory fixed part,
mandatory variable part, and optional part, as shown in Figure 6-11.
For details of the routing tag and CIC, refer to 6.2.2 Singnaling Message. The following
introduces other parts of the ISUP message.
F
SIF
CK
Signaling message
SIO
CIC
LI
OPC
SLC
FIB
FSN
BIB
BSN
DPC
MSU
ISUP message
Message type
Mandatory parameter A with fixed length
Mandatory parameter with fixed length
Mandatory parameter F with fixed length

Point to parameter M
Point to parameter P
Point to star t bit of optional parameter
Mandatory parameter with variable length
Length of parameter M
Parameter M
Length of parameter P
Parameter P
Code of parameter X
Length of parameter X
Parameter X
Optional parameter
Code of parameter Z
Length of parameter Z
Parameter Z
End tag of variable parameter
Figure 6-11 Structure of the ISUP message
I. Message Type Code

A message type code is an SIO field, which is required for all messages. The message
type code defines the function and format of each kind of ISUP message. See Table
6-4.
6-6

Chapter 6 SS7
Table 6-4 ISUP message code

Code
Abbreviation
Meaning
00000001
IAM
Initial address message: A message sent in the forward direction to

initiate occupancy of an outgoing circuit and to transmit number and
other information relating to the routing and handling of a call.
00000010
SAM
Subsequent address message: A message that may be sent in the

forward direction following an initial address message, to convey
additional called number information.
00000011
INR
Information request: A message sent by a switch to request

information in association with a call.
00000100
INF
Information: A message sent to convey information in association

with a call, which may have been requested in an information
request message.
00000101
COT
Continuity message: A message indicating whether or not there is

continuity on the preceding circuit as well as of the selected circuit
to the following switch, including verification of the communication
path across the switch with the specified degree of reliability.
00000110
ACM
Address complete message: A message indicating that all the

address signals required for routing the call to the called party have
been received.
00000111
CON
Connect message: A message indicating that all the address

signals required for routing the call to the called party have been
received and that the call has been answered.
FOT
Forward transfer message: A message sent in the forward direction

on semi-automatic calls when the outgoing international switch
operator wants the help of an operator at the incoming international
switch. The message will normally serve to bring an assistance
operator into the circuit if the call is automatically set up at the
switch. When the call is completed through an operator at the
incoming international switch, the message should preferably
cause this operator to be recalled.
ANM
Answer message: it indicates that the call has been answered. In

semi-automatic working, this message has a supervisory function.
In automatic working, this message is used in conjunction with
charging information.
00001100
REL
Release message: A message sent in either direction to indicate

that the circuit is being released due to the cause supplied and is
ready to be put into the idle state on receipt of the release complete
message. When the call is redirected, the redirection message will
also carry the redirection number.
00001110
RES
Resume message: A message sent in either direction indicating

that the calling or called party, after having been suspended, is
reconnected.
RLC
Release complete message: A message sent in either direction in

response to the receipt of a release message, or if appropriate to a
reset circuit message, when the circuit concerned has been brought
into the idle condition.
00001000
00001001
00010000
6-7

Code
Chapter 6 SS7
Abbreviation
Meaning
00010001
CCR
Continuity check request message: A message sent by a switch for

a circuit on which a continuity check is to be performed, to the
switch at the other end of the circuit, requesting continuity checking
equipment to be attached.
00010010
RSC
Reset circuit message: A message sent to release a circuit, due to

memory broken or other causes.
0010011
BLO
Blocking: A message sent only for maintenance purposes to the

switch at the other end of a circuit, to cause an engaged condition of
that circuit for subsequent calls outgoing from that switch. When a
circuit is used in the dual-circuit mode of operation, a switch
receiving the blocking message must be capable of accepting
incoming calls on the concerned circuit unless it has also sent a
blocking message. Under certain conditions, a blocking message is
also a proper response to a reset circuit message.
00010101
BLA
Blocking acknowledgement: A message sent in response to a

blocking message, indicating that the circuit has been blocked.
00010111
GRS
Circuit group reset: A message sent to release an identified group

of circuits.
00011000
CGB
Circuit group blocking message: A message sent to the switch at

the other end, indicating the specified circuit group has been
blocked.
00011001
CGU
Circuit group unblocking: A message sent to the switch at the other

end of an identified group of circuits to cause cancellation in that
group of circuits of an engaged condition activated earlier by a
blocking or circuit group blocking message.
00011010
CGBA
Circuit group blocking acknowledgement: A message sent in

response to a circuit group blocking message to indicate that the
requested group of circuits has been blocked.
00011011
CGUA
Circuit group unblocking acknowledgement: A message sent in

response to a circuit group unblocking message to indicate that the
requested group of circuits has been unblocked.
00011111
FAR
Facility request: A message sent from a switch to another switch to

request activation of a facility.
00100000
FAA
Facility accepted: A message sent in response to a facility request

message, indicating that the requested facility has been activated.
00100001
FRJ
Facility rejected: A message sent in response to a facility request

message to indicate that the facility request has been rejected.
00100100
LPA
Loop-back acknowledgement message: A message sent in the

backward direction in response to a continuity check request
message indicating that a loop (or transceiver in the case of a
2-wire circuit) has been connected.
00101000
PAM
Pass-along message
6-8

Code
Chapter 6 SS7
Abbreviation
Meaning
00101001
GRA
Circuit group reset acknowledgement: A message sent in response

to a circuit group reset message and indicating that the requested
group of circuits has been reset. The message also indicates the
maintenance blocking state of each circuit.
00101010
CQM
Circuit group query message: A message sent on a routine or

demand basis to request the far-end switch to give the states of all
circuits in a particular range.
00101011
CQR
Circuit group query response: A message sent in response to a

circuit group query message to indicate the states of all circuits in a
particular range.
CPG
Call progress: A message sent in either direction during the set-up

or active phase of the call, indicating that an event, which is of
significance, and should be relayed to the originating or terminating
access, has occurred.
CFN
Confusion message: A message sent in response to any message

(other than a confusion message) if the switch does not recognize
the message or detects a part of the message as being
unrecognized.
00110000
OLM
Overload message: A message sent in the backward direction, on

non-priority calls in response to an IAM, to invoke temporary trunk
blocking of the circuit concerned when the switch generating the
message is subject to load control.
00110001
CRG
Charging information: Information sent in either direction for

accounting and/or call charging purposes.
00110010
NRM
Network resource management message: A message sent in order

to modify network resources associated with a certain call. The
message is sent along an established path in any phase of the call.
00110011
FAC
Facility: A message sent in either direction at any phase of the call

to request an action at another switch. The message is also used to
carry the results, error or rejection of a previously requested action.
00110110
IDR
Identification request
00110111
IDS
Identification response
00111000
SGM
Segmentation message: A message that may be sent in either

direction to convey an additional message segement of an
extremely long message.
00101100
00101111
00011101
00011100
00011110
Reserved.
00100111
6-9

Chapter 6 SS7
Each kind of message is composed of a message type code and several parameters.
Each parameter has a name that is coded by a single octet. The length of a parameter
can be fixed or variable, and each parameter has an LI, the length of which is one octet.
II. Mandatory Fixed Part

For a specified message type, those mandatory parameters with fixed lengths are
contained in the mandatory fixed part. The locations, lengths and order of them are
defined by the message type. In this case, the message does not include the name and
LI of its parameter.
III. Mandatory Variable Part

Those mandatory parameters with variable lengths are contained in the mandatory
variable part. A pointer is used to indicate the start of each parameter, and it is coded
based on a single octet. The parameter name and pointer transmitting order are implicit
in the message type, and the numbers of parameters and pointers are defined by the
message type.
A pointer also can be used to indicate the start of an optional part. If a message type
specifies that the optional part is not allowed, this pointer does not exist. If a message
type specifies that there may be optional part, but this specific message does not
include optional part, the pointer field is all 0.
All pointers are transmitted consecutively at the start of mandatory variable part. Each
parameter includes parameter LI and contents.
IV. Optional Part

Optional part is composed of parameters, which may appear or not appear in any
specific message type. Parameters may be of fixed or variable lengths, and optional
parameters can be transmitted in any order. Each optional parameter should contain a
parameter name (one octet), a LI (one octet) and the parameter content.
"Optional parameter end" octet: If there are optional parameters, the "optional
parameter end" octet will be transmitted after all optional parameters are sent out, and
the octet is all 0.
6.3.3 Basic Signaling Flow

Figure 6-12 shows the call setup and release flow originated by an IP trunk media
gateway. When an IP trunk media gateway originates a call, the media gateway is
connected with subscribers through the circuit trunk of a circuit-switched network, and
call signaling enters the SoftX3000 through an SS7 gateway.
This flow example is based on the following conventions:
z
The caller is controlled by MG1 and SG1.
The callee is controlled by MG2 and SG2.
6-10

Chapter 6 SS7
ISUP is taken as an example of SS7.
MG1 and MG2 are controlled by the same SoftX3000.

SG1
(1)
MG1
SoftX3000
MG2
SG2
IAM
(2)
Add
Replay
Add
(3)
Replay
IAM
IAM
(4)
ACM
(5)
Modify
Reply
(6)
ACM
ANM
(8)
Modify
(7)
Reply
(9)
ANM
REL
(10)
REL
RLC
RLC
Subtract
Subtract
(11)
Reply
Reply
Figure 6-12 ISUP call setup and release flow originated by a trunk media gateway
1)
After the caller dials the number of the callee, an IAM is sent to the SoftX3000
through SG1.
2)
A context is created in MG1. TDM termination and RTP termination are added in
the context. [Mode] is set to SendReceive. The jitter buffer and voice
compression algorithm are also set. MG1 returns its RTP port number and voice
compression algorithm through the Reply command.
3)
6-11

4)
Chapter 6 SS7
The SoftX3000 sends an IAM to the circuit-switched network through SG2. The
circuit-switched network returns an ACM. The phone set of the callee rings.
5)
The SoftX3000 sends the Modify command to MG1 and reports the remote RTP
port number.
6)
The SoftX3000 sends an ACM to SG1.
7)
The callee hooks off. SG2 sends an ANM to the SoftX3000.
8)
The SoftX3000 sends an ANM to SG1.
9)
The callee hooks off. SG2 sends an REL to the SoftX3000. The SoftX3000 sends
an REL to SG1.
10) The SoftX3000 sends the Subtract command to MG1 and MG2.
6.4 SCCP
Signaling connection control part is abbreviated as SCCP. In the layered architecture of
SS7, SCCP is one of the UPs. It belongs to the fourth functional group, providing
additional functions for MTP at the same time so that circuit related information,
non-circuit related information and other information can be transmitted between the
switches and special centers of telecommunication network through SS7 network.
Thus, connectionless or connection-oriented services can be created, and the third
layer (network layer) of OSI layered model can be constructed.
I. Function
The purpose of SCCP is to provide the methods by which data information is
transmitted in the following cases:
z
Connecting logic signaling in the common channel signaling network.
Transferring signaling data units with logic signaling connection established or not
established.
With SCCP function, the circuit related and non circuit related signaling information of
ISUP can be transmitted when peer-to-peer signaling connection is established or not
established.
II. Basic Services

SCCP provides the following 4 classes of services:
z
Class 0: basic connectionless service
Class 1: ordered connectionless service
Class 2: basic connection-oriented service
Class 3: flow control connection-oriented service
Classes 0 and 1 services are connectionless, and classes 2 and 3 services are
connection-oriented.
6-12

Chapter 6 SS7
The connectionless services mean that the user can transfer signaling information
through signaling network without setting up signaling connections in advance. The
connectionless services of SCCP are equivalent to the data service of data network.
Class 0 service do not ensure that messages can be transferred in sequence, while
class 1 service can ensure that messages can be transferred to their destination in
sequence by using SLS.
The connection-oriented services mean that users exchange control information
between SCCPs to reach a protocol before transmitting data. The protocol contains the
route through which data are transferred, the class of transferred services (whether it is
basic connection-oriented class or flow control connection-oriented one), even possibly
the amount of the data transferred, and so on.
The connection-oriented services of signaling can be divided into temporary signaling
connection and permanent signaling connection.
Service users control the establishment of temporary signaling connection, which is
similar to dialing telephone connection.
Permanent signaling connection is established and controlled by local (or remote) O&M
function or by the node management function, which can provide the users with
semi-permanent connection, which is similar to a leased telephone line. The
connection-oriented connection described here refers to temporary signaling
connection.
III. Application in SoftX3000

The SoftX3000 can interwork with SCP through IANP. As IANP needs SCCP and TCAP
to transmit signaling, SCCP exists in SoftX3000 to serve as the intermediate layer for
transferring messages.
SCCP messages are processed by the FCCU/FCSU in SoftX3000.

The SCCP message is a MSU of SS7. Its message contents lie in the SIF of MSU. An
MSU is identified to be an SCCP message by the SI being 0011 in the SIO of the MSU,
as shown in Figure 6-13.
The route tag in Figure 6-13 has been described in MTP section. The message type
employs 8-bit coding. One code determines one SCCP message. The parameters of
certain special message type that are described as mandatory and have fixed lengths
must be put in the mandatory fixed part. The parameters that are mandatory but have
variable lengths must be put in the mandatory variable part. Any individual message
may include optional parameters. The optional parameters may be of fixed or variable
lengths. If a parameter is mandatory with variable length, it is necessary to point out its
position through the pointer. For optional parameters, it is necessary not only to point
out their start bits but also to give their respective codes and lengths.
6-13

7 6
1 0
Chapter 6 SS7
bit
DPC
0 0 0 0 0 0 0 0
OPC
BIB
BSN
FIB
F SN
SLS
Message type
LI
Sub-service field
SI
Mandatory parameter A
with fixed length
Mandatory parameter B
with fixed length
Mandatory parameter B with fixed length
Point to parameter M
Point to parameter P
Point to start bit of
optional parameter
SIF
Length of parameter M
Parameter M
Length of parameter P
Parameter P
Code of parameter X
ck
Length of parameter X
Parameter X
0 1 1 1 1 1 1 0
Code of parameter Z
Length of parameter Z
Parameter Z
0 0 0 0 0 0 0 0
Figure 6-13 SCCP message format
I. SCCP Message Type

SCCP functions and programs, such as transmitting data signaling units with logic
signaling connections established or not established, must be implemented by
transmitting various kinds of SCCP messages. The SCCP messages are classified into
connectionless service messages and connection-oriented service messages. Table
6-5 lists SCCP messages and their corresponding protocol classes and codes.
Table 6-5 SCCP messages
Protocol class
Message type
Connection request (CR)
2
X
6-14
3
X
Code
00000001

Chapter 6 SS7
Protocol class
Message type
Code
Connection confirm (CC)
00000010
Connection refusal
(CREF)
00000011
Connection released
(RLSD)
00000100
Release completed (RLC)
00000101
Data type 1 (DT1)
00000110
Data type 2 (DT1)
00000111
Data acknowledgement
(AK)
00001000
Unit data (UDT)
00001001
Unit data service (UDTS)
00001010
Expedited data (ED)
00001011
Expedited data
acknowledgement (EA)
00001100
Reset request (RSR)
00001101
Reset confirmation (RSC)
00001110
Protocol data unit error

(ERR)
00001111
Inactivity test (IT)
00010000
: means this message can be used in the corresponding protocol class.
The main message types are explained as follows:

z
CR and CC are used to establish signaling connection.
During signaling connection establishment, a CREF message should be sent to

the originating node when the intermediate SCCP or the destination point SCCP
has no enough resource to establish signaling connection.
DT1, DT2 and ED are three kinds of messages used to transfer data after
signaling connection is established successfully. Among them, DT1 is used for
protocol class 2, while DT2 and ED are used for protocol class 3. In addition, DT2
and ED must be acknowledged by AK and EA.
RLSD and RLC are used to release the signaling connection after data transfer.
RSR and RSC are in protocol class 3 to re-initialize the data sending sequence
numbers in the data transmitting stage.
6-15

z
Chapter 6 SS7
ERR is sent when any protocol error is detected, and IF is used to check whether
both ends of the signaling connection work.
UDT, XUDT, UDTS, and XUDTS are connectionless service messages. UDT and
XUDT are used to transfer connectionless service data. When UDT and XUDT
can not reach their destinations, UDTS and XUDTS must be sent to the originating
point to show the causes if it is specified in UDT and XUDT.
II. Parameters of SCCP Message

To implement respective functions, SCCP messages must have parameters to provide
all kinds of information. For example, the CR message must have the parameter
[Called Address] to access the called subscriber and implement signaling connection.
The ERR message must have the parameter [Error Cause] to show the causes of error.
If a parameter is indispensable in a message, it is called mandatory (M) parameter for
the message, and such messages include the mandatory parameter with fixed length
(F) and the mandatory parameter with variable length (V). If a parameter is optional in a
message, it is called an optional parameter (O). A parameter is mandatory in one
message but may be optional in another message. Therefore, whether a parameter is
mandatory or optional depends on the individual message.
Table 6-6 lists the parameters of SCCP message.
Table 6-6 Parameters of SCCP message
Parameter name
Code
Optional parameters end
00000000
Destination local reference
00000001
Origin local reference
00000010
Called address
00000011
Caller address
00000100
Protocol class
00000101
Segmentation/re-assembly
00000110
Receiving No. P (R)
00000111
Sorting/segmentation
00001000
Credit
00001001
Release cause
00001010
Return cause
00001011
Reset cause
00001100
Error cause
00001101
Refusal cause
00001110
6-16

Chapter 6 SS7
Parameter name
Code
Data
00001111
The meanings of the parameters in Table 6-6 are as follows:

z
[Destination local reference] and [origin local reference] specify one signaling
connection uniquely.
[Called address] and [caller address] are used to identify originating/destination

signaling point and/or SCCP service access point.
[Protocol class] defines the four kinds of protocols of connectionless services and
connection-oriented services.
If the length of network service data unit (NSDU) is longer than the maximum
length of message for data transmitting, the NSDU must be divided into several
segments to be transferred and then reassembled when they reach the
destination. The parameter [segmentation/reassemble] aims to implement this
function. This parameter is only used for DT1.
[Receiving No.] P(R) shows the expected next sequence number, which is used in
DT2 and AK messages of protocol class 3 to confirm that the remote point has
received all the messages prior to that numbered P (R) 1.
[Sorting/segmentation]
is
an
integrated
parameter,
including
[Segmentation/re-assembly], [Sending No.] P (S) and [Receiving No.] P (R). Here

P(S) should be in the range of window value prescribed in the protocol in order to
implement the flow control of protocol class 3.
z
[Credit] appears in CR or CC messages, determining the number of messages

contained in the signaling connection transmission part. It is the window of the
signaling connection, implementing flow control in protocol class 3. During the
data transmission stage, the [credit] in an AK message can modify this window.
[Release cause], [Reset cause] and [Refusal cause] are used respectively to show
the causes for releasing, resetting and refusing the signaling connection. [Error
cause] is used to show the causes of error in ERR message. [Return cause] is
used in UDTS or XUDTS message of connectionless services to point out why
UDT or XUDT is unable to reach the destination.
[Data] is the network service data (NSD) that the user would send to the
destination.
III. Examples of Parameter Format Coding

1)
Subscriber address: called address/caller address
Subscriber address is a parameter with variable length. Its structure is illustrated in

Figure 6-14.
6-17

Chapter 6 SS7
Address indication
Address
Figure 6-14 Subscriber address structure

Address indication
Address indication indicates the type of the address contained, as shown in Figure
6-15.
7
Reserved Addressing
indication
Global title indication
bit
Subsystem Signaling
indication point
indication
Figure 6-15 Address indication

Table 6-7 lists the meaning of the bits of the address indication.
Table 6-7 Meanings of the bits of the address indication
Bit
Bits
52
Value
The address doe not contain the signaling point code.
The address contains the signaling point code.
The address does not contain the subsystem number.
The address contains the subsystem number.
0000
The global tile is not included.
0001
The global title (GT) includes only the nature of address indication.
0010
The GT includes only the translation type, coding plan, and coding design.
0100
The GT includes the translation type, number design, coding design, and
nature of address indication.
Route selection should be based on the GT in the address.
Route selection should be based on the DPC in the MTP route tag and the
sub-system number (SSN) in the called address (DPC+SSN).
Meaning
National reserved.
Address
The order for various units appearing in the address is DPC, SSN, and GT, as shown in
Figure 6-16.
6-18

Chapter 6 SS7
DPC
SSN
GT
Figure 6-16 Order of address units

DPC: Refer to the DPC in the MTP section.
SSN: It is used to identify the SCCP user functions. It is an 8-bit code, as shown below:
Bits: 76543210
00000000 Subsystem unknown
00000001 SCCP management
00000010 Reserved
00000011 ISUP
00000100 Operations, maintenance & administration part (OMAP)
00000101 Mobile application part (MAP)
00000110 Home location register (HLR)
00000111 Visitor location register (VLR)
00001000 Mobile switching center (MSC)
00001001
~
Idle
11111110
11111111 Reserved for expansion
GT: The format of GT has a variable length, including four possibilities:
GT indicator = 0001
When GT indicator is 0001, GT format is illustrated in Figure 6-17.
O/E
Address feature
indication
Address information
Figure 6-17 GT format when GT indicator is 0001

When GT indication is 0001, bits 60 of the first octet in GT are address nature
indications, as shown below:
6-19

Chapter 6 SS7
Bits 60:
0000000 Idle
0000001 User number
0000010 National reserved
0000011 National valid number
0000100 International number
00000101
~
Idle
11111111
Bit 7 is odd/even indication, which is encoded as follows:
0: even number of addresses
1: odd number of addresses
If the GT indication is 0001, the information after the second octet of the GT bits 7, 4, 3,
0 indicates the address signaling. See Figure 6-18.
Second address
instruction
Second address
instruction
Fill in 0
(if necessary)
Nth address
instruction
Figure 6-18 Address information

Address signaling codes are as follows:
0000 Number 0
0001 Number 1
0010 Number 2
0011 Number 3
0100 Number 4
0101 Number 5
0110 Number 6
0111 Number 7
1000 Number 8
1001 Number 9
1010 Idle
1011 Code 11
6-20

Chapter 6 SS7
1100 Code 12
1101 Idle
1110 Idle
1111 ST
If the address comprises an odd number of address signaling, the filling code 0000
should be added at the end of address signaling.
2)
Protocol class and return selection
The protocol class is used to define SCCP service classes. The [Protocol class] field
should be used at the stage of signaling connection establishment, and the protocol
class should be negotiated by both ends of SCCP.
The protocol class is a 4-bit code.
Bits 3210
0000 Protocol class 0
When bits 03 codes indicate that a protocol class is the connection-oriented class
(protocol classes 2 and 3), bits 47 are idle.
When bits 03 codes indicate that a protocol class is the connectionless class (protocol
classes 0 and 1), bits 47 are encoded as follows:
Bits: 7654
0000 Not specified
0001 to
0111 are idle.

1000 Error returned
1001 to
1111 are idle.
IV. Format and Composition of SCCP Message

Each SCCP message is made up of different parameters, including mandatory part and
optional part (if any). Table 6-8 shows the corresponding parameters making up each
message.
6-21

Chapter 6 SS7
Table 6-8 SCCP messages and their corresponding parameters

Message parameter
CR
Destination local
reference
CC
M
Called address
Caller address
Protocol class
CREF
M
RLSD
RLC
DT1
M
DT2
M
AK
M
ED
M
EA
M
RSR
RSC
ERR
M
M
M
Sorting/segmentation
Credit
M
M
Release cause
Return cause
Reset cause
Error cause
M
0
6-1
UDTS
Receiving sequence No.
UDT
Segmentation/re-assem
bly
User data
IT

Chapter 6 SS7
The composition of the messages is illustrated below:

1)
CR message
A CR message comprises:
z
Route tag
Message type code
Two pointers
For parameters of the CR message, see Table 6-9.

Table 6-9 Parameters of CR message
Parameter
Type (F, V and O)
Length (octet)
Protocol class
Called address
3 (minimum)
Credit
Caller address
4 (minimum)
Data
3130
Optional parameters end
2)
UDT message
A UDT message comprises:

z
Route tag
Message type code
Three pointers
For parameters of the UDT message, see Table 6-10.

Table 6-10 Parameters of UDT message
Parameter
Type (F, V and O)
Protocol class
Called address
3 (minimum)
Caller address
2 (minimum)
Data
2X
X: (To be determined)
3)
UDTS message
A UDTS message comprises:

z
Length (octet)
Route tag
6-1

z
Message type code
Three pointers
Chapter 6 SS7
For parameters of the UDTS message, see Table 6-11.

Table 6-11 Parameters of UDTS message
Parameter
Type (F, V and O)
Length (octet)
Return cause
Called address
3 (minimum)
Caller address
2 (minimum)
Data
2X
4)
XUDT message
A XUDT message comprises:

z
Route tag
Message type code
Four pointers
For parameters of the XUDT message, see Table 6-12.

Table 6-12 Parameters of XUDT message
Parameter
Type (F, V and O)
Length (octet)
Protocol class
Called address
3 (minimum)
Caller address
2 (minimum)
Data
2X
Optional
5)
XUDTS message
A XUDTS message comprises:

z
Route tag
Message type code
Four pointers
For parameters of the XUDTS message, see Table 6-13.
6-2

Chapter 6 SS7
Table 6-13 Parameters of XUDTS message

Parameter
Type (F, V and O)
Length (octet)
Return cause
Called address
3 (minimum)
Caller address
2 (minimum)
Data
2X
Optional
6.5 TCAP
Transaction capability (TC) is a series of communication capability provided between
various applications and network services. It provides functions and regulations
independent of the specific applications for switches and special service centers
scattered in the communication network in a large number. TCAP adopts the
addressing mode supported by SCCP, and is based on the connection-oriented and
connectionless services of SCCP. The TCAP process is divided into the component
sub-layer process and the transaction sub-layer process, as shown in Figure 6-19.
TC user
Component sub-layer
Transaction sub-layer
SCCP
Figure 6-19 TC structure
I. Transaction Sub-layer
As the transaction control, the transaction sub-layer transmits components in the
transaction sub-layer message through the end-to-end connection between TC users.
Transactions correspond to the dialogue handling of the component sub-layer on a
one-to-one basis.
6-3

Chapter 6 SS7
Each transaction ID is uniquely specified by the component sub-layer dialogue and

user sub-system.
II. Component Sub-layer

The component sub-layer comprises two parts: component and dialogue.
1)
Component
The component refers to the mode in which the request or response to perform an
operation is transmitted. The operation refers to an action that a specific application of
a TC user requires the remote peer entity to perform. An operation is identified by
invocation ID. There are four classes of operations (INVOKE):
z
Class 1: Both success and failure are reported.
Class 2: Only failure is reported.
Class 3: Only success is reported.
Class 4: Neither success nor failure is reported.
The operation class is decided by TC user and can be discriminated by TCAP. Each
operation has only one response, which may be:
z
RESULT: returned upon operation success.
ERROR: returned upon operation failure.
REJECT: indicating that the operation can not be performed.
CANCEL: indicating that operation invocation is time-out, which is meaningful only

locally.
The component part performs component processing between TC users, including

temporary components. It manages components state machines according to different
operation classes carried by the components.
2)
Dialogue
The consecutive exchange of components between TC users makes up a dialogue.

The components are carried to the corresponding remote TC user part through
dialogue. The component sub-layer provides the dialogue function, allowing several
dialogues to go simultaneously between two given TC users. Dialogues are divided into
structured dialogue and unstructured dialogue. The unstructured dialogue (TC_UNI)
carries components not expecting any response. The structured dialogue comprises
the start process, continuing process and end process. Each dialogue is uniquely
identified by its dialogue ID.
The basic process of a dialogue is as follows:
z
The dialogue begins (TC_BEGIN).
The dialogue is acknowledged (TC_CONFIRM): The first backward continuity

indicates that the dialogue is established and can be continued.
The dialogue continues (TC_CONTINUE): The TC user continues an established

dialogue, and components carried can be exchanged in the full-duplex mode.
6-4

Chapter 6 SS7
The dialogue ends: The transmitting end neither transmits nor receives
components. There are four types of dialogue ending, as shown in Table 6-14.
Table 6-14 Types of dialogue ending
Type of dialogue ending
Meaning
Prearranged end (TC_END)
TC users at both terminals know the ending time beforehand.

The ending is only of local significance, and will not be sent to the
remote terminal.
Basic end (TC_END)
The local TC user terminates the local dialogue, transmits

pending components to the remote terminal, and informs the
remote TC user to end the dialogue.
Abortion (TC_ABORT)
The dialogue is ended immediately, all pending operations are

aborted, and reasons for the abortion should be indicated.
Abortion (TC_NOTICE)

A TCAP message, as SCCP user data, is composed of information elements. Each
element has the same structure, consisting of three fields: tag, length, and contents.
I. Tag
Tag is responsible for class distinguishing and content explanation. A tag comprises
class, format and tag code. Its length is one or more octets. See Table 6-15.
Table 6-15 Composition of a tag
Class
Format
Tag code
Class code: See Table 6-16.
Table 6-16 Meanings of class codes

Value
Meaning
00
Universal
01
Application-wind
10
Context-specific
11
Private use
Element format: 0 stands for primitive and 1 for constructor.
Tag code: Its range is from 00000 to 11110. Code 11111 indicates extension. If
the most significant bit (MSB) of the octet that follows is 1, it indicates that the
6-5

Chapter 6 SS7
extension goes on; if it is 0, it indicates that the tag stops here. The combined tag
is composed of bits 0 through 6 of each extension octet. Bit 6 of the first extension
octet is the MSB, and bit 0 of the last extension octet is the least significant bit
(LSB).
II. Length
It refers to length of the content. The length falls into three formats: short, long, and
indefinite. In the indefinite format, a specific primitive (ECO = 0, length = 0, and
contents = default) is used to indicate the contents end. See Table 6-17, Table 6-18,
and Table 6-19.
Table 6-17 Short format
MSB
Length of contents
0
LSB
Table 6-18 Long format
MSB
The length field is N-1 in length.
0
LSB
MSB
1
2
Length of contents
LSB
Table 6-19 Indefinite format
Information
element
.....
Information
element
6-6

Chapter 6 SS7
ECO tag = 00000000

ECO length = 00000000
III. Contents
IV. The contents can be a value, and makes up a primitive together with the tag
and length. It can also be one or multiple information elements, and
combined with tag and length to form a constructor. The contents are
interpreted based on the tag value.
V. TCAP Message Structure
Figure 6-20 shows the TCAP information element structure.
Message type flag
Message total length
Transaction portion message unit
Dialog portion message unit
Component portion flag
Component portion length
Component type flag
Component length
Component portion message unit
Component
Figure 6-20 TCAP information element structure

1)
Composition of the transaction portion
Table 6-20 shows the composition of the transaction portion.

Table 6-20 Composition of the transaction portion
Message
Parameter
Unidirectio
nal
Originating transaction ID
Begin
Destination transaction ID
Continue
Abort
M
M
Cause for abortion
End
M
O
6-7

Message
Chapter 6 SS7
Parameter
Unidirectio
nal
Dialogue portion
Component portion
Begin
Continue
End
Abort
M means mandatory item, and O means optional item.
2)
Composition of the dialogue portion
Table 6-21 shows the composition of the dialogue portion.

Table 6-21 Composition of the dialogue portion
Class
Unstructured
dialogue
Structured
dialogue
3)
Operation
Contents
Object identifier (M), protocol version (M), application context name

(M), and user information (O).
Dialogue
request
Protocol version (O), application context name (M), and user

information (O).
Dialogue
response
Protocol version (O), application context name (M), result (M), result
source diagnosis (M), and user information (O).
Dialogue
abort
Abortion source (M), and user information (O).
Composition of the component portion
Table 6-22 shows the composition of the component portion.

Table 6-22 Composition of the component portion
Operation
Contents
Invoke
Invocation ID (M), link ID (O), operation code (M), and parameter (O).
Result returned (final

and non-final)
Invocation ID (M), sequence tag (O), operation code (O), and parameter (O).
Returned error
Invocation ID (M), error code (M), and parameter (O).
Refusal
Invocation ID (M), and problem code (M).
6.6 INAP
Generally, the intelligent network consists of the service switching point (SSP), service
control point (SCP), intelligent peripheral (IP), service management system (SMS), and
service creation environment (SCE). See Figure 6-21.
6-8

Chapter 6 SS7
Service control point

SCE
SMS
Functional
peripheral
SCP
Database
No.7
No.7
IP
STP
No.7
No.7
Signaling transfer point
No.7
SSP
Exchange
PABX
User terminal
Figure 6-21 Intelligent network architecture
I. SSP
SSP is the junction point connecting the existing mobile network and intelligent network.
It provides the functions to access the function set of the intelligent network. SSP can
detect the requests for intelligent services, and communicates with SCP. It responds to
SCP requests and allows the service logics in SCP to affect call processing. As far as
functions are concerned, one SSP should contain the call control function (CCF) and
service switching function (SSF). In the case that no independent intelligent peripheral
(IP) is constructed, SSP should also contain the specialized resource function (SRF).
The service processing functions are used to accept client calls, completing such basic
connection functions as call establishement and call hold. The service switching
functions are used to receive and identify intelligent network (IN) service calls, report to
the SCP, and accept the control commands from the SCP.
The SoftX3000 has the SSP functions.
II. SCP
SCP is the core component of the intelligent network. It stores user data and service
logics. The major functions of SCP are to receive the query information from SSP,
query the database, and implement translation. Meanwhile, SCP can start different
service logics according to the call events reported by SSP. It sends call control
instructions to corresponding SSP based on the service logics, thus realizing various IN
calls.
6-9

Chapter 6 SS7
III. IP
IP is the special resource to assist in the implementation of IN services. It usually
possesses voice functions, such as voice synthesis, recorded announcement playing,
dual-tone multifrequency dialed number receiving, voice identification, and so on. IP
can be a separate physical device or serve as part of SSP. It is controlled by SCP, and
executes the operations designated by SCP service logics. If IP is centralized in the
network, with its functions shared by other switches, it can save investment and bring
conveniences to managing voice resources, thus facilitating deployment of those
services whose playing contents change frequently.
IV. SMS
SMS is responsible for managing service data and user data. Generally, it has five
functions: service logic management, service data management, user data
management, service monitoring, and traffic management.
V. SCE
SCE generates new service logics according to the requirements of customers, and it
provides a friendly graphic editing interface for service designers. After confirming
service requirements, you can use SCE to define the data related to the requirements,
adopt various standard graphic elements to design the IN service logics, and then load
them to SCP for system invocation.
The intelligent network is a distributed system. The functional entities (such as SCF,
SSF, and SRF) in the intelligent network nodes transmit messages to one another to
mutually complete IN services. ITU-T uses a kind of higher layer communication
protocol, that is, the standard interface protocol for intelligent network: intelligent
network application protocol (INAP), to define the information streams between the
functional entities of the intelligent network. This interface protocol is put forward in
ITU-T Q.12XY (Q.1208, A.1218 and Q.1228) recommendations, in which the
information streams among SSF, SCF, SRF, SDF and call unrelated service function
(CUSF, only in Q.1228) are described in detail. Meanwhile, the operation procedures
that all functional entities should comply with after they receive information streams are
also prescribed.
VI. Application in SoftX3000

SoftX3000 supports intelligent network application. In the intelligent network
architecture, SoftX3000 serves as SSP, which communicates with SCP through IANP.
INAP is one of SS7 UPs, and it is closely related with TCAP. INAP transmits standard
information streams of the intelligent network by means of invoking TCAP primitives.
The INAP messages can be transported over narrowband TDM link through MTP, and
also can be transported over IP network through SIGTRAN.
INAP messages are processed by the FCCU/FCSU of SoftX3000.
6-10

Chapter 6 SS7

I. INAP Message Structure
INAP is a kind of remote operation service element (ROSE) user procedure, which is
contained in the TCAP component sub-layer for transmission. The application protocol
data unit (APDU) of ROSE serves as unit data (UDT), which are transmitted in SS7,
and class 0 service (basic connectionless service) of SCCP is adopted.
INAP is described by Abstract Syntax Notation-1 (ASN.1) of ITU-T Q.681, Q.682, and
Q.690 recommendations.
For the INAP message structure, see the SCCP message structure.
II. INAP Operations and Classes

There are four classes of INAP operations:
z
Class 1:
Both success and failure are reported.
Class 2:
Only failure is reported.
Class 3:
Only success is reported.
Class 4:
Neither success nor failure is reported.
In the INAP procedure, 36 kinds of operations are adopted in CS-1 phase according to
the requirement of services. Table 6-23 lists the operations in CS-1 phase and their
corresponding information streams.
Table 6-23 INAP operations and classes
Information stream
Operation
Class
Activate Service Filtering
Same
Activity Test
Same
Activity Test Response
Return Result from Activity

Test
Apply Charging
Same
Apply Charging Report
Same
Assist Request Instruction
Same
Call Gap
Same
Call Information Report
Same
Call Information Request
Same
Cancel Status Report Request
Same
Connect Information
Same
Connect
Same
Connect to Resource
Same
6-11

Chapter 6 SS7
Information stream
Operation
Class
Continue
Same
Disconnect Forward Connection
Same
Establish Temporary Connection
Same
Event Notification Charging
Same
Event Report BCSM
Same
Furnish Charging Information
Same
Initiate DP
Same
Initiate Call Attempt
Same
Release Call
Same
Request Charging Event Notification
Same
Request Report BCSM Event
Same
Request Current Status

Request First Status Match
Report
Request Status Report
Request Every Status Change

Report
Reset Timer
Same
Select Facility
Same
Send Charging Information
Same
Service Filtering Response
Same
Status Report
Same
Assist Request Instruction from SRF
Assist Request Instruction
Cancel Announcement
Cancel
Collected User Information
Return Result from Prompt and

Collect User Information
Play Announcement
Same
Prompt and Collect User Information
Same
Specialized Resource Report
Same
Note:
In the "Operation" column, "same" indicates that the operation name is the same as the information stream
name.
6-12

Chapter 6 SS7
In the CS-2 phase, the number of operations extends to 145, among which are 47
operations between SCF and SSF:
1)
10 operations of class 1
Activate service filtering, manage triggering data, request current status, combine call
segment, move LEG, generate call segment association, cut off LEG, request status
change, move call segment, and detach LEG.
2)
Request charging, request charging report, assist request instruction, terminal

authentication, request/cancel call information, cancel status report request, collect
information, connect, connect to resource, continue with parameter, disconnect forward
connection, disconnection forward connection with parameter, establish temporary
connection, request the first status matching report, provide charging information,
initiate DP, initiate call attempt, reconnect, request BCSM event report, request UTSI
report, reset timer, select facility, send charging information, and send STUI.
3)
1 operation of class 3
Activity test
4)
Call gap, call information report, continue, charging event notification, BCSM event
report, release call, service filtering response, status report, specialized resource report,
release entity, and UTSI report.
There are eight operations between SCF and SRF:
5)
Prompt and collect user information, and prompt and accept information.
6)
Close script, script information, run script, play announcement, and assist request
instruction.
7)
Operations of class 3
None.
8)
Script event, and specialized resource report.
6.6.3 Basic Signaling Flow

SoftX3000 supports multiple IN services and generates other services as required. The
INAP message process between SoftX3000 (SSP) and SCP is related to specific
services.
6-13

Chapter 6 SS7
I. 800 Service Process

The 800 service is a freephone service. As the number 800 serves as the
access code of this service, this service is usually called 800 service. An 800 number is
allocated to each subscriber who applies for this service, and the caller who dials the
number needs not to pay. Figure 6-22 shows the process of making an 800 call by an
ordinary subscriber.
Database
SCP
No.7
0755-6540808
IP
(3)
(2)
No.7
(1)
SSP
(4)
Ringing
8008101234
0755-6540808
Figure 6-22 800 service diagram

1)
The caller dials the 800 service number.
2)
SSP collects the 800 number and reports it to SCP.
3)
SCP queries the code translation table, translates the number into an ordinary
phone number (real called number), and sends connection instruction (to connect
with the real called number) and charging instruction (to charge the callee) to SSP.
SSP is responsible for notifying the callee to ring, and completing connection
between the caller and the callee as well as charging.
II. Flow in Which User MG Originates IN Call

The 800 service is taken to illustrate the flow.
z
The user MG originates a call. That is, the MG directly connects the user, and the
user originates a corresponding call.
z
z
The caller is connected with MG1, and the caller dials the 800 service number.
The callee corresponding to the translated 800 service number is conncected with
MG2.
The callee hooks on first.
Figure 6-23 shows the flow.
6-14

MG1
(1)
(2)
(3)
(4)
(7)
(9)
Chapter 6 SS7
SoftX3000
MODIFY
MG2
RELPLY
NOTIFY
RELPLY
MODIFY
RELPLY
NOTIFY
RELPLY
(5) IDP
(6)
ADD
RELPLY
ADD
RELPLY
MODIFY
RELPLY
AC,CON
IDP
AC,CON
(8)
NOTIFY
RELPLY
MODIFY
RELPLY
SUBSTRACT
(14)
SCF
MODIFY
RELPLY
RELPLY
MODIFY
(12)
SGF
NOTIFY
RELPLY
(10)
(11)
(13)
SUBSTRACT
RELPLY
RELPLY
(15) ACR
ACR
Figure 6-23 Flow in which the user MG originates an IN call

1)
SoftX3000 sends the Modify command to MG1 and MG2; that is, it sets up a
termination in the null context. After that, SoftX3000 waits for the off-hook event.
2)
The caller hooks off. MG1 sends the Notify command to SoftX3000 to report the
off-hook event.
3)
SoftX3000 sends the Modify command to MG1 and waits for the user to enter the
called number. The caller listens to the dialing tone.
4)
MG1 sends the Notify command and the called number to SoftX3000.
5)
SoftX3000 sends an INAP/IP operation IDP to SGF to report the triggering of the
800 service. SGF sends the INAP/IP operation IDP to SCF to report triggering of
the 800 service.
6)
SCF sends INAP/TC operations AC and CONNECT to SGF and asks SoftX3000
to charge and connect the call. SGF converts the two operations into an INAP/IP
operation and sends it to SoftX3000.
7)
the context. [Mode] is set to ReceiveOnly. The jitter buffer and voice
6-15

8)
Chapter 6 SS7
9)
SoftX3000 sends the Modify command to MG1 and notifies the remote address.
10) The callee hooks off. MG2 sends the Notify command to SoftX3000.
11) SoftX3000 sends the Modify command to MG2 and cuts off the ringing tone.
12) SoftX3000 sends the Modify command to MG1 and cuts off the ringback tone.
The mode is SendReceive.
13) The callee hooks on. MG2 sends the Notify command to SoftX3000.
14) The SoftX3000 sends the Subtract command to MG1 and MG2.
15) SoftX3000 sends an INAP operation ACR to SGF. SGF sends the INAP operation
ACR and report the charging resut to SCF.
III. Flow in Which Trunk Gateway Originates IN Call

When a trunk media gateway originates a call, the media gateway is connected with the
user through the trunk of a circuit-switched network, and call signaling interworks with
the SoftX3000 through a SS7 gateway.
z
The caller is controlled by MG1 and SG1.
The callee is controlled by MG2 and SG2.
ISUP is taken as an example of SS7.
Figure 6-24 shows the flow.
6-16

SG1
Chapter 6 SS7
SoftX3000
MG1
MG2
(1) IAM
SG2
(1) IDP
(4)
REPLY
ADD
REPLY
AC,CON
(5)
IAM
(6)
ACM
(7) ACM
MODIFY
(8)
REPLY
(10) ANM
ANM
(9)
MODIFY
(11)
REPLY
(12) REL
(13) REL
(14)
ACR
ACR
RLC
RLC
(15)
SCF
IDP
(3) AC,CON
ADD
SGF
SUBSTRACT
REPLY
SUBSTRACT
REPLY
Figure 6-24 Flow in which an IP trunk gateway originates an IN call

1)
After the caller dials the number of the callee, an IAM is sent to the SoftX3000
through SG1.
2)
SoftX3000 sends an INAP/IP operation IDP to SGF to report the triggering of the
800 service. SGF sends the INAP/IP operation IDP to SCF to report triggering of
the 800 service.
3)
SCF sends INAP/TC operations AC and CONNECT to SGF and asks SoftX3000
to charge and connect the call. SGF converts the two operations into an INAP/IP
operation and sends it to SoftX3000.
4)
the context. [Mode] is set to ReceiveOnly. The jitter buffer and voice
5)
6)
The SoftX3000 sends an IAM to the circuit-switched network through SG2. The
circuit-switched network returns an ACM. The phone set of the callee rings.
7)
SoftX3000 sends an ACM to SG1.
6-17

8)
Chapter 6 SS7
SoftX3000 sends the Modify command to MG1, tells the remote RTP port number,
and notifies MG1 to send the ringback tone.
9)
The callee hooks off. SG2 sends an ANM to the SoftX3000.
10) SoftX3000 sends an ANM to SG1.

11) SoftX3000 sends the Modify command to MG1 and cuts off the ringback tone.
The mode is SendReceive.
12) The callee hooks on. SG2 sends an REL to the SoftX3000.
13) SoftX3000 sends an REL to SG1.
14) SoftX3000 sends an INAP operation ACR to SGF. SGF sends the INAP operation
ACR and report the charging result to SCF.
15) SoftX3000 sends the Subtract command to MG1 and MG2.
6-18

Chapter 7 R2 Signaling
7.1 Basic Concepts
As the telecom network is very large in scale, it is hard to replace channel associated
signaling completely with SS7 signaling in a short time span. By far, the channel
associated signaling system is still widely used in the international telecom network
and telecom networks of various countries. No. 1 signaling is a subset of R2 signaling.
R2 signaling consists of line signaling and register signaling. Of these two kinds of
signaling, the definition varies from country to country.
Line signaling is transmitted between line devices (repeaters). It is composed of line
monitoring signals. It is used for monitoring the status of connection of trunks and
controlling the connection. A line device cannot be shared among trunks. Instead,
each trunk must have a line device. Therefore, line signaling is relatively simple to
reduce costs, and the types of line signaling are few.
Register signaling is transmitted between registers. It is composed of selection
signals and service signals. It is used for selecting route and callee and managing the
telephone network. A register is a shared device. Few registers are needed in a
signaling network. Therefore, a register can be a complex device for matching more
kinds of signaling.
7.1.1 Line Signaling

There are three forms of line signaling: DC line signaling, line signaling with in-band
single frequency pulse and digital line signaling.
I. DC line signaling
DC line signaling is used for the real line trunks of electromechanical switches. In
China, local call networks are all stored program-controlled; therefore DC line
signaling actually is not used. DC line signaling will not be introduced in this
document.
II. Line signaling with in-band single frequency pulse

In a toll automatic telephone network, if the inter-office transmission system uses
carrier, microwave or satellite circuits of frequency-division multiplexing, the
inter-office line signaling usually uses the audio signal, namely, the in-band single
frequency pulse signal.
The single frequency used by line signaling is 2600 Hz. It consists of the short signal
unit, long signal unit and continuous signal unit. The short signal unit is a short pulse
7-1

signal with the nominal value of 150 milliseconds. The long signal unit is a long pulse
signal with the nominal value of 600 milliseconds. The nominal interval of sending two
signals is 300 milliseconds. Table 7-1 lists the nominal values of pulse signals and
intervals.
Table 7-1 Nominal values of the in-band single frequency pulses and their intervals
Signal length
(ms)
Interval (ms)
Sending time
deviation at
transmitting end
(ms)
Short signal unit
150
150
30
80 20
Sending interval
300
60
Long signal unit
600
600
120
375 75
Nominal values of pulse signal or interval

Pulse
Recognition time
range at
receiving end
(ms)
There are two kinds of line signaling: forward signaling and backward signaling.
Forward signaling is sent from the originating office to the terminating office.
Backward signaling is sent from the terminating office to the originating office. The
structure of signaling signals is described in Table 7-2.
Table 7-2 Signal structure of line signaling with in-band single frequency pulse
Seria
l No.
Sending
direction
Connection status
(signaling name)
Forwa
rd
Signaling signal structure (ms)
Backw
ard
Occupation signal
Single pulse 150
Disconnection signal
Single pulse 600
Repeated
disconnection signal
150
300
Used
between toll
offices and
between
toll/local
offices
600
600
600
Answer signal
Single pulse 150
Clear signal
Single pulse 600
Release guard signal
Single pulse 600
Blocking signal
Continuous
7-2
Remarks
600
Used
between local
offices

Seria
l No.
Sending
direction
Connection status
(signaling name)
Forwa
rd
Re-ringing or
forced
disconnectio
n signal
Oper
ator
sign
al
Ringback
signal
Signaling signal structure (ms)
Backw
ard
150 150 150 150 150
At least three
pulses
150 150 150 150 150
At least three
pulses
Single pulse 600
Equivalent to
clear signal
Single pulse 600
Equivalent to
release guard
signal
Forced release signal

B
Remarks
The connection states in Table 7-2 are described as follows:

z
Occupation signal is a forward signaling. When the outgoing trunk of the

originating office sends an occupation signal, an incoming trunk of the peer office
will change its state from idle to occupied.
Disconnection signal is a forward signaling sent by the outgoing trunk to the

incoming trunk of the peer office. It means that the switch can release the call in
abnormal call disconnection in addition to normal disconnection. The
disconnection signal is sent in any of the following cases:
The caller hangs up in call control recovery mode
The operator of original toll office in toll semi-automatic connection
The original office receives a backward register signaling such as connection busy.
Callee not pickup after alerting timeout, or caller not hang up for more than 90 seconds
after callee hangs up
The repeated disconnection signal is sent by the outgoing trunk of the original
office when it does not receive the release control signal 3 to 5 seconds after its
sending the disconnection signal. If the release control signal is still not received
after sending the repeated disconnection signal, an alarm will be generated.
The answer signal indicates that the callee picks up the phone. It is a backward
signaling sent by the incoming trunk.
The clear signal indicates that the callee hangs up. It is a backward signaling
sent by the incoming trunk from the terminal office to the original office in relay.
7-3

z
The release control signal is a backward confirmation signal of the disconnection

signal. It indicates that the caller of the originating office releases.
The blocking signal is a backward signaling sent by the incoming trunk of the
incoming office, indicating that the trunk has been blocked.
The re-ringing signal is a forward operator signaling. After the toll office operator
establish call connection with the callee and the callee answers, if the callee
hangs up and the operator need to call the callee, the operator can send the
re-ringing signal.
The forced disconnection signal is also a forward operator signal. When the toll
office operator tries to connect the call, and finds that the callee is engaged in a
local call, the operator will send the signal after receiving confirmation from the
callee.
The ringback signal is a backward operator signaling. It is sent by the operator

back to the caller.
The forced release signal is used in the following case. In a bi-directional trunk
circuit, sometimes it is occupied in both direction due to disturbances. If no
register signaling is received in 15 seconds, one end will send a forward forced
release signal (acting as a release signal), and the other end will send a
backward forced release signal (acting as a release control signal), and the trunk
circuit is released.
III. Digital line signaling

The line signaling monitors the occupation, release, and blocking state of the trunk
lines. To support transmission of 30 voice channel line signaling in the PCM system, a
multiframe concept is introduces. A multiframe consists of 16 individual frames, each
of which is 125 s and contains 32 timeslots. A multiframe has 16 TS16. In the TS16
of the frame 0, the first four bits are used for synchronization in the multiframe, the last
four bits are used for loss-of-synchronization report, and the TS16 of the other 15
frames are used to transmit the line signaling of the 30 voice channels. Table 7-3
describes the usage of TS16 in a PCM multiframe.
Table 7-3 Use of TS16 in a PCM multiframe
Frame 0
Frame 1
abcd
00 00 XY XX
Voice channel
1
abcd
Voice channel
16
Frame 2
abcd
Voice
channel 2
...
abcd
Voice channel
17
TS16 of frame 0
X: Spare bit, and is set to 1.

Y: Loss-of-synchronization report bit. 0 means normal, and 1 means loss of
synchronization.
7-4

TS16 of other frames
A 30-voice-channel PCM system sends the line signaling by sampling and

transmitting the TS16 in a multiframe. There are four bita, b, c, and davailable in
both transmission directions for each voice channel. Only the first three bits are used
for both the forward signaling and the backward signaling.
The bit af, bf, and cf are for the forward signaling, and the ab, bb, and cb are for the
backward signaling. Table 7-4 lists the meaning of the signaling.
Table 7-4 Meaning of forward signaling in digital lines
Bit
Meaning
af=0
Caller picks up (occupied)
af=1
Caller hangs up (released)
bf=0
Not faulty
bf=1
Faulty
cf=0
Operator re-rings or forced releases
cf=1
Operator does not re-ring or forced release
Table 7-5 Meaning of backward signaling in digital lines

Bit
Meaning
ab=0
Callee picks up
ab=1
Caller hangs up (backward released)
bb=0
Idle
bb=1
Occupied or blocked
cb=0
Operator rings back
cb=1
Operator does not ring back
Obviously, no operator intervention is needed in the connection between local offices,

and the automatic connection between a local office and a toll office. Therefore, Cf
and Cb are not needed. Table 7-6 shows the differences between different digital line
signaling in the three bits.
Table 7-6 Signaling bits in the automatic and semi-automatic connection of a toll office
Connection state
Forward signaling
Backward signaling
af
bf
cf
ab
bb
Idle
Occupied
7-5

Forward signaling
Connection state
Backward signaling
af
bf
cf
ab
bb
Occupation confirmed
Answer
Hang up
Re-ring (forced release)
Release
Release control
Ring back
Blocked
Refer to the previous paragraphs on the definition of connection states.
7.1.2 Register Signaling

I. Definition of Register Signaling
The R2 register signaling is in multiple frequency control (MFC) mode. It is divided
into two typesforward signaling and backward signaling. In the register signaling,
the forward signaling and backward signaling are both consistent. The forward
signaling transmits addresses and controls indications, while the backward signaling
confirms and controls a call. When sending a digit, the sending party will not stop
sending the forwarding signaling until having received a backward confirmation.
Similarly, the receiving end will not stop sending backward signaling until having
detected that the peer end stops sending forwarding signaling. As shown in Figure 7-1,
the transmission of R2 register signaling is done in four beats.
Orginating office
SND
Send the first bit of

forward signaling
(Beat 1)
Terminating office
RCV
SND
RCV
t1
Stop sending the first bit t2

of forward signaling
(Beat 3)
t3
Send the second bit of

forwarding signaling
t4
Figure 7-1 The transmission process of R2 register siganling
7-6
Send the first bit of

backward signaling
(Beat 2)
Stop sending the first bit

of backward signaling
(Beat 3)

Beat
Operations
The originating office sends the first bit of forwarding signaling.
The terminating office (receiving end) receives and identifies the forwarding signaling, and
returns the first bit of backward confirmation signaling. The terminating office thus replies
that it has received the forwarding signaling, and informs what specific forwarding
signaling the originating office shall next send.
The originating office receives and identifies the backward confirmation signaling, and
stops sending the forward signaling.
The terminating office detects that the peer end stops sending the forward signaling, and
stops sending the backward confirmation signaling. When the originating office detects
that the peer end stops sending the backward confirmation signaling, it starts the second
control period by sending the next bit of forwarding signaling.
II. Coding Mode of MFC Register Signaling

There are 15 types of forward signaling of MFC register signaling. Fifteen
combinations of two from the six high frequencies1380 Hz, 1500 Hz, 1620 Hz, 1740
Hz, 1860Hz, and 1980Hz. There are six backward signaling of MFC register signaling.
Six combinations of two from four low frequencies1140 Hz, 1020 Hz, 900 Hz, and
780 Hz. Table 7-7 and Table 7-8 details the combination of frequencies.
Table 7-7 Forward signaling
Code
F0 (1380)
F1 (1500)
Frq (Hz)
10
11
12
13
15
F7 (1860)
14
F4 (1740)
F2 (1620)
F11 (1980)
Table 7-8 Backward signaling

Code
F0 (1140)
F1 (1020)
Frq (Hz)
F2 (900)
7-7

Code
Frq (Hz)
F4 (780)
III. Types and meanings MFC register signaling

As described in the above, the MFC register signaling falls into two types: forward and
backward. Both forward signaling and backward signaling have two sub-types: group
I and group II for the forward signaling, and group A and group B for the backward
signaling. Group A is the acknowledgement of group I, and group B the
acknowledgement of group II. Table 7-9 lists the meanings of the four groups of
signaling.
Table 7-9 Meanings of the four groups of signaling
Forward signal
Group
Name
Meaning
KA
Caller type
KC
Toll connection type
KE
KD
Capacity
Group
Name
Meaning
capacity
Back control
acknowledgement of
the number receiving
status and connection
status
Callee status
10/15
5
Toll/local office and urban

connection type
Digit 10
10
Digital
signal
II
Backward signal
Originating call service

type
A
Signal
B
signal
Note: For a local office using the step-by-step system, there are 10 user types; for a stored program control (SPC) local office using the
crossbar system, there are 15 user types.
Forward group I signaling
Forward group I signaling consists of connection control signaling and digital signaling.
For details, refer to Table 7-10 and Table 7-12.
Table 7-10 Forward group I signaling
Type
Meaning
KA
It refers to the caller type signaling sent from the originating local office to the
originating toll office or originating international switching center in the forward
direction. The purpose of this signaling is to provide the charging type (periodical,
immediate, free) and user level (ordinary, high priority) information.
The combination of these two kinds of information is indicated with a KA code, as
shown in Table 7-11. The high priority user in the table refers to those whose calls
take precedence over others in the case of network blocking or overload.
7-8

Type
Meaning
KC
It refers to the connection control signaling sent between toll offices in the forward
direction. This signaling has the functions of ensuring the communication quality of
high-priority users, completing specified calls, and connecting other specified calls
(for example, test calls).
KE
It refers to the connection control signaling sent from the terminating toll office to
the terminating local office and between local offices in the forward direction.
There are two types of KE signaling, as shown in Table 7-11.
Digital signaling
It is a selection signaling. The ten digits, 1, 2, 3, , 0, are used to indicate the

calling number, called area code and called number; 15 is used to separate the
calling number and called number, indicating the end of the calling number.
Backward group A signaling
Backward group A signaling is the MFC signaling of forward group I signaling. It

controls and acknowledges forward group I signaling. For details, refer to Table 7-10
and Table 7-11.
Table 7-11 Backward group A signaling
Type
Meaning
A1, A2, A6
These three kinds of signaling together are called code-sending sequence control
signaling. They control the code-sending sequence of forward digital signaling.
A3
A3 is a conversion control signaling for differentiating forward group I from forward

group II, and backward group A from backward group B. In the toll incoming
register at the local office end in the connection from the terminating toll office to
the local office, or in the multiple frequency incoming register of the local call
connection, A3 signaling is the control signaling. In other cases, A3 signaling is a
pulse (15030 ms) signaling.
A4, A5
They are the cause analysis signaling when connection to the callee fails. A4
indicates busy, and A5 an unallocated number.
7-9

Table 7-12 Forward group I signaling and backward group A signaling

Forward group I signaling
Backward group A signaling
Contents of KA signaling (including KOA)

KA
co
de
1
2
3
Step-by-step local
office
O
rd
in
ar
y
SPC local office using crossbar system

(also including PAM office)
KA
KA
Periodical
Periodical
User
table,
immediate
Printer,
immediate
Ordi
nary
User table,
immediate
Printer,
immediate
KC
code
Contents of
KC signaling
KA
Ordi
nary
KE
code
Contents of KE
signaling
Digit
al
sign
aling
Contents of A signaling
Periodical
A1: send next bit
User table,
immediate
A2: send starting from the

first bit
Printer,
immediate
A3: shift to B signal
Standby
Standby
Standby
A4: telephone key blocking
Ordinary, free
Ordinary, free
Ordinary, free
A5: unallocated number
Standby
Standby
Standby
A6: send KA and calling

number
Standby
Standby
Standby
Standby
High priority,
periodical
High priority,
periodical
(Have right for

suburban automatic
call; have right for toll
automatic call
Standby
Standby
10
(Have no right for

toll/suburban
automatic call)
High priority, free
High priority, free
7-10

11
Standby
11*
Voice mailbox notifies

the user to leave a
message
12
Z indicates a
specified
number call
12
Standby
Test call
13
T indicates a
test
connection
call
13
T indicates a test call
Standby
14
High priority
14
Standby
15
Control the
number
of
satellite circuit
segments
15
Voice mailbox cancels

notifying the user to
leave a message
11
Standby
12
13
14
15
Note: Those types with brackets are not sent to the originating toll office; * indicates that the signal is needed for cooperating with old equipment.
7-11

Forward group II
Forward group II signaling is also called KD signaling. It indicates the originating call
service type. It is used, based on KD, to judge whether the attendant can break in or
forcefully release a local call. Table 7-14 describes the role of this signaling.
Backward group B signaling
Backward group B signaling is also called KB signaling. It indicates the status of the
callee. It is sent after the reception of KD signaling to acknowledge the control and
connection of KD signaling.
Refer to Table 7-13 for the contents of backward group B signaling.
Table 7-13 Forward group II signaling and backward group B signaling
Forward group II signaling (KD)
Backward group B signaling (KB)

Contents of KB signaling
KD
code
KB
code
Contents of KD signaling
Semi-automatic call of a toll

attendant
Automatic toll call,
Urban call
Fax or user data

communication of the urban
user; high priority user
5
6
Used
for toll
call
conne
ction
During toll call

connection or test
call connection
(when KD=1, 2 or
6)
During local call connection

(when KD=3 or 4)
Callee idle, first party release

recovered
Callee idle
Callee local busy
Callee toll busy
Telephone key
blocked
Callee busy or telephone key

blocked
Automatically checking calling number
Called number is an
unallocated number
Called number is an unallocated

number
Test call
Standby
Callee idle, calling party release

recovered
Used
for
urban
call
conne
ction
Standby
Table 7-14 Contents and role of KD signaling

Role of KD signaling
KD code

type
Whether attendant can

break in local call
Yes
Semi-automatic breaking in
of toll attendant
7-1
Whether toll attendant

can break in
No
Yes
No

Role of KD signaling
type
KD code
Whether attendant can

break in local call
Yes
Whether toll attendant

can break in
No
Automatic toll call
Urban call
Urban fax or data
Automatically checking
calling number
Test call
Yes
No
7.2 Application of R2 Signaling

Figure 7-2 illustrates the typical application of R2 signaling in NGN.
SoftX3000
IP MAN
H.248/IUA
H.248/IUA
UMG8900
UMG8900
R2
R2
PBX
Exchange
POTS
POTS
POTS
POTS
Figure 7-2 Typical application of R2 signaling in NGN

The UMG8900 provides the interconnection between R2 trunks and the exchange
and PBX. It packages the R2 message in the H.248 message and sends the R2
7-2

message to the Soft3000, thus implementing the interworking between NGN and the
exchange and PBX in PSTN.
7.3 Basic Signaling Flow

Figure 7-3 takes the connection process of a local call as an example to introduce the
basic flow of R2 signaling.
Transit
office
Originating
office
Terminating
office
Occupy
Occupation acknowledge
P
A1
Q
A1
R
A1
A
A1
B
A1
C
A1
D
Occupy
Occupation acknowledge
P
A1
Q
A1
R
A1
A
A1
B
A1
C
A1
D
A3
A3
KD=3
KD=3
KB=1
KB=1
Answer
Answer
Talk
Caller hooks on
Callee hooks on
Idle
Caller hooks on
Callee hooks on
Idle
Figure 7-3 Signaling process of a local call

In Figure 7-3, the called number is PQRABCD, in which PRQ is the office directional
number, and ABCD is the user number. The figure shows that line signaling and
register signaling are sent segment by segment. After the transit office receives PQR
7-3

completely, it starts routing to send register signaling of the originating office. After
sending the full number, the originating office waits for the terminating office to send
the A3 signal, and then completes the signaling flow. This connection mode takes a
long time. Therefore, it is used when the transmission line is of a poor quality.
7-4

Chapter 8 DSS1 Signaling and V5 Protocol

8.1 DSS1 Signaling
8.1.1 Overview of DSS1 Signaling
ISDN features multiple capabilities, including circuit switching, packet switching,
non-switching connection, and common channel signaling. Normally, a network only
provides functions of lower layersphysical layer, data link layer, and network layer - of
the open systems interconnection (OSI) model. Intra-network higher layer (layers 4 to 7
of model OSI) functions required by some supplementary services can be implemented
inside ISDN or provided by an independent service center.
The basic structure of ISDN is shown in Figure 8-1. The terminal equipment (TE) of
ISDN is connected through the standard user-to-network interface.
Circuit
switching
capacity
TE
User-network
interface
Packet
switching
capacity
ISDN
switch
ISDN
switch
User-network
interface
TE
Non-switching
capacity
Common
channel
signaling
capacity
Figure 8-1 Structure of ISDN

I. Reference Points and Functional Group
The reference configuration (reference model) of the ISDN user-to-network interface is
shown in Figure 8-2. The model is an abstract arrangement of the user-to-network
interface standardized by CCITT (ITU) regulations. It offers reference points to be
standardized and functional groups related to the reference points.
8-1


S
NT2
TE1
NT1
Transmission line
R
TE2
S
TA
Reference point
Functional group
Figure 8-2 Reference configuration for ISDN user-to-network interfaces

Reference point
In Figure 8-2, crosses stands for reference points. A cross is a conceptual reference
point for dividing functional groups. In the user accessing, crosses stand for physical
interfaces between device units. For the implementation of multiple functional groups
combined in one device, reference points between functional groups exist only
conceptually. The physical interfaces cannot be observed.
There are three types of reference points: the U reference point, S/T reference point
and R reference point.
z
U reference point
The U reference point, also called the U interface, is the line interface between the
network and the user. According to the regulations of ITU, the U interface is the line
interface between the network and the ISDN basic rate access (BRA) user, but not the
line interface between the network and the primary rate access (PRA) user. Comparing
the reference model to the actual application, we regard that the E1 line in the PRA
application as the U interface in Figure 8-2.
The BRA U interface determines the transmission line code. The U interface uses the
original analog subscriber line (ASL). To transmit digital signals through twisted pairs,
you need to reduce transmission attenuation. One way for reducing transmission
attenuation is to reduce the line transmission rate, that is, to transmit a 2-bit binary code
with one level. The transmission line code adopted by the U interface in China is 2B1Q.
This code indicates that the line transmission uses four levels, each level being a
combination of two bits. Correlation between binary codes and line levels:
Binary code
Line level
00
3V
01
1V
10
+3V
11
+1V
8-2

In this way, the line rate is reduced by half compared with the binary code rate, thus
reducing the transmission attenuation.
When the 2B1Q line code is used, the line element rate (baud rate) is 80 kbit/s, and the
corresponding bandwidth is 160 kbit/s. The bandwidth allocation is described in Table
8-1.
Table 8-1 Bandwidth allocation in the 2B1Q line code mode
Channel
Rate (bit/s)
Function
2B channel
128 k
Traffic channel
D channel
16 k
Signaling channel
M channel
40 k
Transmitting the maintenance information

between the network and the terminal
Used for U interface

synchronization
12 k
Transmitting clock information
S reference point and T reference point
The S reference point, also called S interface, is the line interface between the ISDN
terminal (terminal equipment type 1 (TE1) or terminal adaptor (TA)) and the network
terminal (NT). The T reference point, also called T interface, is the line interface
between network terminal type 1 (NT1) and network terminal type 2 (NT2). In the ITU
regulation, the specifications of the S interface is the same as that of the T interface.
If the NT2 device does not exist, S and T together form S/T reference point, also called
S/T interface.
The S/T interface uses a four-line transmission mode, two lines for sending and two
lines for receiving. The line code is a pseudo-AMI (alternate mark inversion) code. In
AMI code, binary bit 1 is converted to positive pulse or negative pulse, which alternate
forward and backward; binary bit 0 is converted to level 0. Figure 8-3 illustrates the
correlation between a binary code and an AMI code.
Binary code
AMI code
Sending direction
Figure 8-3 Correlation between a binary code and an AMI code

z
R reference point
8-3

The R reference point, also called R interface, is a non-standard ISDN terminal

interface, for example, RS-232 interface, IEEE-488 interface, and analog telephone
interface.
Functional group
In Figure 8-2, blocks stand for functional groups. A functional group is the combination
and arrangement of functions required on ISDN user interfaces. In application, a
number of functional groups may be implemented in one device.
z
NT1
NT1 provides U interfaces and S/T interfaces for connecting ISDN terminals and
devices of the ISDN exchange. The function of NT1 is the code conversion between the
U interface and S/T interface, for example, the 2B1Q/AMI code conversion in the
Chinese standard.
NT1 is purely a physical layer device without software intelligence,but it has the line
maintenance
and
performance
monitoring
functions.
It
ensures
the
clock
synchronization of the ISDN terminal and network.
Note:
If the NT1 includes the function of the TA, it is called NT1+.
NT2
NT2 is an intelligent terminal device. A common NT2 device can be a terminal control
device such as a private automatic branch exchange (PABX) that has the functions of
ISDN, and a LAN router.
z
TE1
The TE1 is a standard ISDN terminal, with standard S interfaces. It can be connected
directly with the NT1 or NT2 through S interfaces. Common TE1 devices include ISDN
digital telephone sets, G4 fax machines, and video phones.
z
Terminal equipment type 2 (TE2)
TE2 is a non-standard ISDN terminal without S interfaces. It cannot be directly

connected with the NT1 or NT2. An S interface can be connected to the TE2 through a
terminal adapter (TA). Common TE2 devices include PCs, ordinary telephone sets, X
25 packet terminals and G3 fax machines.
z
TA
There is an S or U interface on one end of the TA, and an interface for connecting a
non-standard ISDN terminal on the other end. The role of the TA is for rate adaptation
and protocol conversion. The non-standard ISDN terminal (TE2) does not have the
8-4

function of the common channel signaling (D channel). It can be connected with the S
or U interface only after the rate adaptation and protocol conversion with the TA.
Some TAs contain the built-in AT command set. The AT command set is a general
command format for operating on the Modem on a computer. It supports call originating
and answering on a computer. In other words, the AT command is converted to D
channel signaling. With a TA, the user can make calls and transmit data simultaneously
through a computer.
The B channel protocol of the TA is V.110. It converts the low-speed serial port data to
the data with the speed of 64 kbit/s to enter the B channel. It enables the non-standard
ISDN terminal to communicate with the network through a standard ISDN interface.
II. ISDN Channel

The ISDN channel type refers to the channel path type of the user-to-network interface.
It includes bearer channel (B channel), demand channel (D channel) and H channel.
B channel
The B channel is used for transmitting user information (including voice, data and
images) at the rate of 64 kbit/s. It can implement circuit switching, packet switching and
semi-permanent connection (SPC).
D channel
The D channel transmits signaling messages and packet messages for circuit switching.
According to the number of B channels supported by D channels, D channels are
divided into 2B+D and 30B+D.
Table 8-2 Bandwidth allocation in the 2B1Q line code mode
Channel
Rate (bit/s)
Function
D16
16k
D channel in 2B+D
D64
64k
D channel in 30B+D
H channel
The H channel is for transmitting user information (including stereo programs, images
and data) at a rate over 384 kbit/s.
III. ISDN Interface

The ISDN interface falls into three types: BRA (2B+D), PRA (30B+D) and ISUP.
z
BRA interface
BRA is short for the basic rate interface/access (BRI/BRA). It is specified when the
ordinary subscriber line in PSTN is used as the ISDN subscriber line. It has a rate of
144 kbit/s. It supports two 64 kbit/s user channels (B channel) and one 16 kbit/s
signaling channel (D channel).
8-5

The BRA interface is provided by the digital subscriber line board (DSL) of the optical
network unit (ONU) or remote subscriber processor (RSP) under the UMG8900. Each
DSL can provide eight BRA interfaces. One BRA interface can be connected with eight
ISDN terminals at most. It allows two telephones (each occupying a B channel) and a
packet terminal (occupying the D channel) to communicate with the network
simultaneously. When the ISDN-PC communicates with the network, it can occupy two
B channels at the maximum rate of 128 kbit/s.
As shown in Figure 1-6, the eight ISDN terminals attached to the 2B+D interface can
call another terminal in the subscriber number + sub-address mode. Two subscriber
numbers must be allocated to a BRA interface on the network side and set on the
terminal. Each subscriber number can have four sub-addresses (14 digits) at most.
On the network side, sub-address numbers need not be set. Only the authorities for
sub-address numbers need to be registered. Sub-addresses are set on terminals.
SUB1=1
SUB1=2
N1=6600000
SUB1=3
S/T
2B+D subscriber line
SUB1=4
NT1
N1=6600000
N2=6600001
SUB1=1
SUB1=2
SUB1=3
N2=6600001
SUB1=4
Figure 8-4 ISDN subscriber number and sub-address

z
PRA interface
According to different gaping (E1=32TS, T1=24TS) divided by the PCM system, the
primary rate interfaces/accesses (PRI/PRA) are classified into the 30B+D interfaces
(China and Europe) and the 23B+D interfaces (North America and Japan).
The 30B+D interface is the PRA interface in China with a rate of 2048 kbit/s. It supports
thirty 64 kbit/s user channels (B channels) and a 64 kbit/s signaling channel (D
channel).
The physical channel of the PRA interface is provided by the digital trunk module (DTM).
The board type must be set to PRA during hardware data configuration. Each PRA
board provides two 30B+D PRA interfaces. The subscriber line is a coaxial cable that
can meet the requirement of users with heavy traffic. The PRA interface can be
connected to the PABX that has the functions of ISDN, a LAN, or Internet interim
inter-switch signalling protocol (ISP) system. It can also provide channels for video
conference users to transmit high quality pictures.
z
ISUP interface
8-6

The ISDN user part (ISUP) interface is needed for enabling the ISUP circuit between
two exchanges.
8.1.3 Application of DSS1

Figure 8-5 is a typical application of DSS1 signaling in NGN.
SoftX3000
IP MAN
H.248/IUA
H.248/IUA
UMG8900
UMG8900
PRI
PBX
RSP
BRI
ISDN
PRI
NAS
BRI
POTS
ISDN
POTS
PBX and NAS

devices
ISDN 2B+D access
Figure 8-5 Typical application of DSS1 in NGN

The UMG8900 provides the BRIs and PRIs specified in ISDN User to Network Interface
Specifications, for processing Q.921 messages. It transparently transmits Q.931
signaling to the SoftX3000 through ISDN Q.921-User Adaptation Layer (IUA) to
implement the following ISDN services:
z
Providing BRIs for the accessing of ordinary ISDN users (2B+D);
Providing PRIs for accessing PABXs and network access servers (NAS).
For the DSS1 signaling system, this document introduces only the PRI. For the BRI,
refer to relevant standards.
8-7

8.1.4 Protocol Structure of DSS1

DSS1 signaling has three layers: physical layer, data link layer and call control layer.
Figure 8-6 illustrates the correlation between DSS1 signaling and the OSI reference
model.
Layers 4-7
Call control layer
Layer 3
Data link layer
Layer 2
Physical layer
Layer 1
DSS1 signaling
OSI reference model
Figure 8-6 Correlation between DSS1 signaling and the OSI reference model
I. Physical Layer
The physical layer specifies the procedure and electrical and functional features of the
ISDN user-to-network interface. It provides the technical basis for the interconnection,
operation and maintenance, equipment design, network planning and acceptance test
of the user-to-network interface. For example, the reference configuration of the PRI is
R
TE1
R
TE2
U
NT1
NT2
Transmission media
S
TA
TE1: Standard ISDN terminal

Reference point TE2: Non-standard ISDN terminal
NT1: Network terminal type 1
NT2: Network terminal type 2 (For example, PBX, LAN, Router)
Functional group
TA: Terminal adaptor
Figure 8-7 Reference configuration of ISDN user-to-network interfaces

The meanings of the B channel and D channel supported by the PRI:
B channel: bearer channel of the user information with the rate of 64 kbit/s, used for
carrying voice and data for circuit switching, packet switching and SPC.
D channel: bearer channel of the signaling information with the rate of 64 kbit/s, used to
transmit the signaling information and packet data information of circuit switching. The
PRI physical channel is in the PCM structure. It has the same rate as the PCM primary
8-8

rate, namely, 2048 kbit/s. The PRI can use twisted pairs as the transmission media. In
the 30/32 channels of PCM, each frame is divided into 32 basic time slots. TS0 is used
for frame synchronization and error control, and TS16 for signaling transmission.
II. Data Link Layer

The data link layer specifies the specification attributes of the data link layer of the ISDN
user-to-network interface (PRI). These specification attributes include the concept and
terms of the data link layer protocol, and the frame structure, procedure, procedure
element and field format of the data link layer protocol under normal operation.
On the ISDN user-to-network interface, the data link layer protocol accesses the LAPD
protocol through the link on the D channel. The LAPD protocol defines rules for the
layer 2 entity on the user-to-network interface to exchange information through the D
channel. The layer 2 entity may exchange information between the TE and the NT2
(such as PABX, LAN and a router), between the NT2 and an exchange, or between the
TE and an exchange.
Therefore, LAPD is to provide means of information transmission between
combinations of data link connection ends. Functions of LAPD are as follows:
Providing data link connections on one or more D channels; Discrimination of data link
connections depending on the data link connection identifier (DLCI) contained in each
frame;
Delimitation, location and transparent transmission of frames, hence allowing
recognizing a string of bits sent on the D channel in the form of a frame;
Sequence control for keeping the sequence of frames connected through data links;
Checking of the transmission and format of and operation onto data link connections;
Error recovery after the transmission, format and operation check;
Notifying the management entity of unrecoverable errors;
Performing flow control;
Management of the activation of the physical layer.
For details, refer to ISDN User to Network Interface Specifications Part 2: Technical
Specifications on Data Link Layer (YDN 034.3-1997).
III. Call Control Layer

The call control layer specifies the procedure for establishing, keeping and removing
network connections on the ISDN user-to-network interface. It also specifies the
process of message exchange on the D channel.
With the functions and services provided by the data link layer, the call control layer
provides functions for establishing and operating on network connections to users.
These functions support the basic call control program and the call control program
related to supplementary features provided by the network. These functions include:
8-9

Processing the primitive used for the communication with the data link layer;
Generating and translating layer-3 messages for intra-layer communication;
Managing the timer and logical entity used in the call control program;
Managing accessing resources, including the B channel, and the logical path of the
packet layer (for example, X.25 recommendations);
Ensuring the consistency between the provided services and the services required by
the user (for example, the bearer capacity, address, and the compatibility between the
lower layers and the higher layers);
Routing and trunks;
Network connection control;
Transmitting information between the network and the user;
Multiplexing of network connections;
Error checking;
Error recovery;
Sequencing;
Blocking control and user data stream control;
Restart.
For details, refer to ISDN User to Network Interface Specifications Part 3: Technical
Specifications on Basic Call Control of Layer 3 YDN 034.3-1997.
8.1.5 Call Control Message

The Layer 3 (call control layer) entity of the user side needs to communicate with the
Layer 3 entity of the network side for call control. The communication is realized by
exchanging messages on the D channel. The call control layer message is composed
of data blocks of different lengths. It is produced and processed by the call control layer,
and carried and transmitted by the data link layer.
The format of the call control layer message specified by the recommendations of
ITU-T Q.931/Q.932 is illustrated in Figure 8-8. The call control layer message consists
of a number (an integer) of bytes. Each message has a common part, and optional or
mandatory information elements.
8-10

8

4
1
1 byte
Common
part
Length of call
reference value
2 bytes at
most
FLAG Call reference value

0
Optional or
mandatory
information
elements
1 byte
Message type
1 byte
Other information elements
Figure 8-8 Format of ITU-T Q.931 messages

The common part consists of three sub-parts with the format identical with that of all
messages.
I. Protocol Discriminator
The protocol discriminator separates the call control message from other messages on
the user-to-network interface. The length of the protocol discriminator is one byte. The
value of the Q.931 call control layer message fixedly is 00001000.
II. Call Reference Value

The
reference
identifies
calls
involved
by
messages
or
facility
registration/un-registration requests on the local user-to-network interface. Call

reference value does not have the meaning of overriding ISDN from end to end.
The call reference value is allocated by the call originating interface. Inside the layer-2
logical link connection of a specific D channel, call reference values are unique on the
originating side. They are allocated at the start of calls and kept till the end of these calls
(except in the cases of call suspension). After the end or successful suspension of a
call, the call reference value can be re-allocated to a new call. On layer 2 logical links of
a same D channel, two calls of different directions can have the same call reference
value.
The eighth byte of the second eight-byte set is the call reference flag. The value of the
flag is 0 or 1. The call reference flag identifies the end of the layer 2 logical link to send
the call reference value. The call reference flag on the originating side is always set to 0,
and that on the terminating side is always set to 1. The sole purpose of the call
reference flag is to solve the problem of two ends attempting to allocate the same call
reference value at the same time. The call reference flag is also applied when using the
global call reference (for example, to restart a program).
8-11

III. Message Type

Message types identifies messages that are being sent. They include different
information elements. The message part is the third part of a message, and its length is
one byte. Bit 8 is reserved for future expansion.
Call control layer messages of Q.931 are classified into four types: messages for call
setup, messages used at the call information stage, messages for call clearing, and
other messages. The coding of different types of messages is described in Table 8-3.
Table 8-3 Types of call control layer messages of Q.931
Message code
Message type
0000 0001
ALERTING
0000 0010
CALL PROCEEDING
0000 0111
CONNECT
0000 1111
Messages for call setup
CONNECT ACKNOWLEDGE
0000 0011
PROGRESS
0000 0101
SETUP
0000 1101
SETUP ACKNOWLEDGE
0010 0110
RESUME
0010 1110
RESUME ACKNOWLEDGE
0010 0010
0010 0101
Messages used at the call

information stage
RESUME REJECT
SUSPEND
0010 1101
SUSPEND ACKNOWLEDGE
0010 0001
SUSPEND REJECT
0100 0101
DISCONNECT
0100 1101
RELEASE
0101 1010
Messages for call clearing
RELEASE COMPLETE
0100 0110
RESTART
0100 1110
RESTART ACKNOWLEDGE
0111 1011
INFORMATION
0110 1110
0111 1101
NOTIFY
Other messages
STATUS
0111 0101
STATUS ENQUIRY
8-12

8.1.6 Basic Signaling Process

The following takes the process of the simplest call control with circuit switching as an
example to describe the basic signaling process of DSS1. Suppose both the calling end
and the called end use ISDN terminal devices. If ISUP is used as the signaling protocol
between the originating and terminating offices, the process of a typical call is
illustrated in Figure 8-9.
Calling terminal
Originating ISUP
office
Terminating
office
TEx
Called terminal
TEy
SETUP
SETUP ACK
INFO
INFO
IAM
SETUP
CALL PROC
ALERT
ALERT
ACM
ALERT
CONN
ANM
CONN
CONN ACK
CONN ACK
REL
REL COMP
Conversation or data
Caller
hooks
on first
DISC(cause value=16)
REL
REL COMP
REL
RLC
REL
REL COMP
REL
REL
REL
RLC
REL COMP
Caller
hooks on
first
REL COMP
Figure 8-9 Basic signaling process of DSS1 (circuit switching)
I. Call Setup Process

A call request is sent in the form of the SETUP message. The message is transmitted
on an established data link.
When the SETUP message reaches the network side of the originating office, the
network entity of layer 3 checks whether the called address is complete. If it is complete,
the originating office returns the CALL PROCEEDING message to hold the caller
8-13

waiting. If the called address is incomplete, the originating office returns the SETUP
ACK message to request subsequent information. The caller sends the INFORMATION
message to provide the remaining information.
When the originating office network side receives the complete address information, it
notifies the exchange for routing and resource allocation. In this example, the call must
go through another exchange before being connected to the callee. Therefore, the
originating office exchange must send a message containing the call-related
information to the terminating office exchange through SS7 signaling (ISUP). When the
terminating office receives this message, it sends the SETUP message to the callee.
The SETUP message contains all the information sent by the originating office,
including the bearer service capacity, terminal lower layer and higher layer attributes,
and end-to-end information. It also contains the subscriber information channel
selected by the terminating office.
On the basic interface of the callee, the SETUP message is transmitted on the
broadcast data link (TEI = 127). Therefore, all the terminals connected to the passive
bus receive the SETUP message. These terminals will check whether they meet the
content requirements of the SETUP message. For example, whether they have the
same bearer service features as the message, whether the lower layer and higher layer
protocols are consistent, whether their terminal types match that of the calling terminal,
and whether the sub-address (if there is one) is conformant. The following case is
possible. For a call, there are several terminals having the information compatible with
the SETUP message. Then, these terminals simultaneously return the ALERTING
message to the network and send the ringing tone to the callee. The terminating office
sends the first ALARTING message to the originating office. When the ALARTING
message finally arrives at the calling terminal, the calling terminal sends the ringback
tone (or displays the ALARTING information) to the caller. When a called terminal
responds to the call, it immediately sends the CONNECT message to the network. The
exchange of the terminating office transfers the CONNECT message to the caller side,
and at the same time sends the CONNECT ACK message to the responding called
terminal. Then, the B channels selected by both exchanges are connected. The circuit
connection is set up between the caller and the callee and the circuit is ready for
transmitting subscriber information.
II. Call Release Process

The call release process with the caller hooking on first is as follows.
The caller sends the DISCONNECT message (cause value = 16) to the originating
office. After the originating office receives the message, it sends the REL message to
the terminating office to disconnect the inter-office circuit. The terminating office returns
the RLC message, indicating the completion of call release.
When the originating office sends the REL message to the terminating office, it also
responds to the calling terminal with the RELEASE message to disconnect the
8-14

inter-office circuit. The calling terminal returns the RELEASE COMPETE message,
indicating the completion of disconnection.
After the terminating office receives the REL message from the originating office, it
sends the DISCONNECT message (cause value =16) to the called terminal. The called
terminal responds with the RELEASE message to disconnect the circuit between the
caller and the terminating office. The terminating office returns the RELEASE
COMPLETE message to the callee, indicating the completion of disconnection. Now,
the call is completely released.
For the call release process with the callee hooking on first, DSS1 call control
messages on the user-to-network interface are the same as the above. Refer to Figure
8-9 for an analysis.
8.2 V5 Protocol
The V5 interface comes into being with the development of the access network. It is
used for connecting the local exchange (LE) and the access network (AN). In the 1990s,
Bell Labs changed the analog interface connection between an exchange and devices
to the standard digital interface connection (TR303 interface). This is to solve the
problems of poor transmission performance, high equipment cost and the development
need of digital services that were characteristic of analog connection. In 1993,
European Telecommunications Standards Institute (ETSI) issued V5 interface
standards to perfect the interface and make it widely applicable.
In view of the importance of the V5 interface and the development urgency of the
access network, ITU-T adopted V5 interface specifications by using an expedited
program. These specifications include V5.1 (G.964) and V5.2 (G.965). In China, the V5
interface standards have been reviewed and revised for times. Now, the following two
documents are implemented:
z
Technical Specifications on V5.1 Interface between Local Digital Exchange and

Access Network (YDN 020-1996);
Technical Specifications on V5.2 Interface between Local Digital Exchange and

Access Network (YDN 021-1996);

I. Basic Contents of V5 Interface
The V5 interface is one between the access network and an exchange. It is a service
node interface (SNI), including V5.1 and V5.2.
V5.1 consists of a 2048 kbit/s link. It supports analog telephone accessing and 64
kbit/sbased ISDN basic accessing. These types of access have the assigned bearer
channel allocation capacity. User ports correspond to bearer channels one by one; that
is, the correlation between user ports and bearer channels is fixed. Therefore, there is
8-15

no line concentration capacity within the AN. V5.1 uses one time slot (TS16) to transmit
signaling, leaving the other time slots (except TS0) to transmit the voice signal.
V5.2 consists of one to sixteen 2048 kbit/s links. It can support ISDN PRA besides
those access types supported by V5.1. The access types supported by V5.2 have the
flexible and call-based dynamic bearer channel allocation capacity. In other words, user
ports correspond to bearer channels dynamically. Therefore, line concentration
capacity exists within the AN and on the V5.2 interface.
Table 8-4 lists the differences between V5.1 and V5.2.
Table 8-4 Differences between V5.1 and V5.2
V5.1 interface
V5.2 interface
Only one E1 link
One to sixteen E1 links available
No Bearer Connection Control (BCC) and user

line concentration. E1 time slots directly
correspond to user terminals.
Having BCC and user line concentration.

Connections between E1 bearer channels and
user terminals are dynamically allocated.
Not supporting ISDN-PRA
Supporting ISDN-PRA
No protection protocol, no fault link switching

protection
Having protection protocol, and fault link

switching protection
No link control protocol; managing only a single

link
Having link control protocol; managing multiple

links
Due to its limitation, V5.1 is rarely used now. Instead, V5.2 is widely used between the
access network and the exchange. The following is an introduction to V5.2.
II. Common Terms

Bearer channel: used to provide the bi-directional transmission capability for allocated
B channels from ISDN-BRA user ports, ISDN-PRA user ports, or PCM encoded 64
kbit/s channels from PSTN user ports. They may be used in multiples of 64 kbit/s
channels in order to facilitate certain ISDN services.
Pre-connection bearer channel: any bearer channel or multiples thereof, set up using
the BCC protocol in order to provide switched services within the AN over bandwidth
reserved on the V5.2 interface reserved for it.
BCC protocol: a protocol which allows the LE to instruct the AN to allocate bearer
channels, either singly or in multiples, on demand.
ISDN D channel information: ISDN D channel information is defined as the D channel
information from basic or primary rate access user ports (including Ds-, p- and f-type
data).
Communication path (C path): any one of the following information types:
z
The layer 2 data link carrying the control protocol;
The layer 2 data link carrying the link control protocol;

8-16

The layer 2 data link carrying the PSTN signaling;
The layer 2 data link carrying the protection protocol;
The layer 2 data link carrying the BCC protocol;
All the ISDN D channel signaling data (Ds-type) from one or more user ports;
All the ISDN packet data (p-type) from one or more user ports;
All the ISDN frame relay data (f-type) from one or more user ports.
It should be noted that this definition includes the possibility that there is more than one
C path of the same information type, each allocated to a different logical C channel.
Communication channel (C channel): a 64 kbit/s time slot on a V5.2 interface
provisioned to carry communication paths.
Logical communications path (logical C channel): a group of one or more C paths, all of
different types, but excluding the C path for the protection protocol.
Physical communications channel (physical C channel): a 64 kbit/s time slot on a V5.2
interface which has been assigned for carrying logical C channels. A physical C
channel may not be used for carrying bearer channels. Time slots 16 of the primary and
secondary links (only on a V5.2 interface with more than one 2048 kbit/s link) are
always physical C channels.
Multi-link: a collection of more than one 2048 kbit/s link which together make up a V5.2
interface.
Multi-slot: a group of more than one 64 kbit/s channels providing 8 kHz and time slot
sequence integrity, generally used together within an ISDN-PRA user port, in order to
supply a higher bit-rate service.
Primary link: the 2048 kbit/s link on a multi-link V5.2 interface whose physical C
channel in time slot 16 carries a C path for the protection protocol and, on V5.2
initialization, also the C path for the control protocol, link control protocol, and the BCC
protocol. Other C paths can also be carried in TS16.
Secondary link: the 2048 kbit/s link on a multi-link V5.2 interface whose time slot 16
carries a C path for the protection protocol and, on V5.2 initialization, acts as the
standby C channel for the control protocol, link control protocol, and BCC protocol and
any other C paths initially carried in TS16 of the primary link.
Active C channel: a physical C channel which is currently carrying a logical C channel.
An active C channel becomes a standby C channel when it is not carrying a logical C
channel.
Standby C channel: a physical C channel which is not carrying a logical C channel, but
is used for the protection of logical C channels. Once it is used to carry a logical C
channel, a standby C channel becomes an active C channel.
Protection group: a group of (N + K) physical C channels, where K is the number of
physical C channels which act as standby C channels for the N logical C channels.
8-17

III. Functions of V5.2 Interface

Figure 8-10 illustrates the functions of the V5.2 interface.
Bearer channel
ISDN D-channel information
PSTN signaling information
Control information
AN
Link control information
LE
Protection information
BCC information
Timing
Figure 8-10 Functions of the V5 interface

Functional requirements of the V5 interface:
Bearer channel: used to provide the bi-directional transmission capability for allocated
B channels from ISDN-BRA and ISDN-PRA user ports, or PCM encoded 64 kbit/s
channels from PSTN user ports.
ISDN D channel information: providing the bi-directional transmission capability for the
D channel information (including Ds-, p- and f-type data) of the ISDN-BRA and
ISDN-PRA use ports.
PSTN signaling information: providing the bi-directional transmission capability for the
signaling information of PSTN user ports.
User port control: providing the bi-directional transmission capability for the status and
control information of each user port.
Control of the 2048 kbit/s link: managing the framing, multi-frame locating, alarm
indication and cyclic redundancy check (CRC) information of the 2048 kbit/s link.
Control of layer 2 links: providing the bi-directional transmission capability for control
and PSTN information.
Control for supporting common functions: providing the capability of the synchronous
application and restart of assigned data.
Timing: providing timing information necessary for bit transmission, byte identification
and frame synchronization. This timing information can also be used to synchronize the
LE and AN in the work state.
BCC protocol: used to allocate bearer channels under the LE control.
Service-required multi-slot connection: provided on a 2048 kbit/s link in the V5.2
interface, always with 8 kHz and time slot sequence integrity.
Link control protocol: defining the management function that supports 2048 kbit/s links
on the V5.2 interface.
8-18

Protection protocol: defining logical C channels that support switching between

applicable physical C channels.
8.2.2 Application of V5 Protocol

Figure 8-11 illustrates the typical application of the V5 protocol in NGN.
SoftX3000
IP MAN
H.248/V5UA
UMG8900
V5
ONU
BRI
POTS
ISDN
V5 access network
Figure 8-11 Typical application of the V5 protocol in NGN

The UMG8900 processes Q.921 messages, provides the V5 interface for accessing
the standard V5 access network, and transparently transmits Q.931 messages to the
SoftX3000 through V5UA.
8.2.3 Protocol Structure of V5.2 Interface

Figure 8-12 illustrates the protocol structure of the V5.2 interface.
8-19

AN
LE
PSTN Protection Link Control BCC

protocol
protocol protocol control
Network Q.931
layer
LAPV5-DL
PSTN ProtectionLink
Q.931
BCC
Control
protocolprotocol control
protocol
LAPV5-DL
Q.921
(Note)
Data
link
layer
p- and
f-type date
L2
Map function
Q.921
Physical D16/64
layer
Map function
PSTN
ET/L2
AN frame relay
LAPV5-EF
LAPV5-EF
TE
LC
D16/64
C64
C64
Note: excluding the function of the AN

terminating at AN_FR
Figure 8-12 Protocol structure of the V5.2 interface
I. Physical Layer
The physical layer of the V5.2 interface can provide bi-directional bearer channels for
transmitting all kinds of service information and control information, thus implementing
the physical connection between the AN and LE. The V5.2 interface is composed of
one to sixteen 2048 kbit/s links. The electrical and physical attributes of all 2048 kbit/s
links must conform to relevant regulations of G.703 recommendations. For example:
z
Bit rate: 2048 kbit/s 50 ppm;
Code: HDB3 code;
Impedance: 75-ohm coaxial (out of balance) or 120-ohm twisted pair (balanced);
Synchronization: pull-in range of the AN clock 1 ppm; in the work mode,

maximum offset against the nominal frequency 1 ppm. In the free work mode,
frequency offset of the AN 50 ppm.
II. Data Link Layer

The data link layer (layer 2) of the V5.2 interface is mentioned in terms of the logical C
channel. The specifications and procedure of the layer 2 protocol of the V5.2 interface
(LAPV5) is based on that of the Link Access Procedure on the D channel (LAPD)
protocol specified in Q.921 recommendations. The functions of LAPV5 are as follows.
LAPV5 allows flexible multiplexing of different information streams to C channels to
support different service types.
z
Delimitation, location and transparent transmission of a frame;
Sequence control for keeping the sequence of frames connected through data
links;
8-20

z
Checking of the transmission and format of and operation onto data link
connections;
Error recovery after the transmission, format and operation check;
Notifying the network layer of unrecoverable errors;
Congestion control, such as end-to-end flow control, and the congestion control on
the V5.2 interface.
LAPV5 is used for the transmission of information between the AN and LE. It has three
sub-layers: encapsulation function sub-layer (LAPV5-EF), used to identify the protocol
type of data frames; data link sub-layer (LAPV5-DL), used to describe the protocol
information of data frames; and frame relay sub-layer (AN-FR), used to support the
ISDN D channel information. The communication between sub-layers is achieved
through the mapping function.
III. Network Layer

The network layer (layer 3) of the V5.2 interface is application-oriented. It can
implement different protocol functions with the services provided by layer 2. These
protocols include:
PSTN protocol
The PSTN protocol is an excitation protocol. It does not control the call flow of the AN.
Instead, it transmits relating analog line information between AN user ports and
national protocol entities of the LE. Call control is still a role of the LE. The LE provides
services, while the AN transparently transfers the address signals of analog user ports
and most line signals, and translates part of the analog status signals to be reported to
the LE through the V5 interface.
Control protocol (common control and user port control)
There are two types of control protocol: common control protocols and user port
controls. The common control protocol defines the implementation of the V5 interface
re-assignment and restart, and fulfills the functions such as the verification of variables
and interface IDs and the unblocking of user ports. The user port control protocol
defines the status indication and control (blocking control and activation control) of user
ports, including the control of ISDN-BRA user ports, ISDN-PRA user ports and PSTN
user ports.
Link control protocol
Because the V5.2 interface is composed of multiple links, there must be link
identification and link blocking functions. These functions are realized through the link
control protocol. The functions include:
z
The status indication of the first 2048 kbit/s link and the identification of related
links;
Managing the blocking of layer-1 links and assisting in link unblocking;
8-21

z
Allow the requesting side, by using the link identification program, to check
whether the two ends of a link are matched (consistent);
Coordination among link control functions;
The link control for the communication between the AN and LE during the
coordination of functions on both sides.
BCC protocol
The BCC protocol of the V5.2 interface is used to assign the bearer channels on certain
links to user ports, thus realizing the dynamic connection between V5.2 interface
bearer channels and user ports. In other words, it helps realize line concentration. This
process is specified by the LE and executed by the AN.
The BCC protocol also has an auditing function for checking the allocation and
connection of bearer channels within the AN. In addition, the BCC protocol is capable of
reporting inside-AN faults. If there is a fault affecting the bearer channel connection
inside the AN, the protocol notifies the LE.
The V5.1 interface does not support the BCC protocol. Therefore, it has no line
concentration function.
Protection protocol
A V5.2 interface can have sixteen 2048 kbit/s links at most. According to the structure
of the V5.2 protocol, one communication path can transmit information related to
multiple 2048 kbit/s links. Therefore, if a communication path is faulty, it can affect the
service of a large number of subscribers. For the BCC protocol, control protocol and
link control protocol, when the communication path concerned is faulty, all user ports
are affected. The V5.2 interface provides a protection program to enhance the reliability.
If one communication path is faulty, the program switches to another. When a
communication path is found faulty during fault detection or after link blocking, the
system management of the LE or AN triggers the protection program. The program can
also be triggered by the operator through the management interface.
The protection protocol is used only when the V5.2 interface is composed of multiple
2048 kbit/s links. Each V5.2 interface, consisting of more than one 2048 kbit/s link,
must have protection group 1 and, if provisioned, protection group 2. The system
management requires that protection group 1 be switched through the protection
started by the management interface.
8.2.4 Layer 3 Protocol Message

Layer 3 protocols are message-oriented protocols, each message having the following
information elements:
z
Protocol discriminator (one byte);
Layer 3 address (two bytes);
Message type (one byte);
8-22

Other information elements determined by requirements (the length to be
determined by information elements);

Of the above information elements, the first three are the common part, appearing in
every message; the last one is to be determined by message type, as shown in Figure
8-13.
8 7 6 5 4 3 2 1
Layer 3 address (high level)
Layer 3 address (low level)
Message type
Figure 8-13 Format of layer 3 messages of the V5 interface
I. Protocol Discriminator Information Element

The protocol discriminator is used to discriminate those other protocol messages that
share the same data link connection with V5 protocol messages. In other words,
different protocol discriminators can be used to support different protocols. The
protocol discriminator used by the V5 protocol fixedly is 0x48. The protocol
discriminator information element is the first part of a message. It takes one byte.
The purpose of defining a protocol discriminator is to discriminate it from other
protocols that may be transmitted on a same V5 data link. These protocols are not
defined, but they may be used in the future.
II. Layer 3 Address Information Element

The layer 3 address information element is used to identify layer 3 entities within the
V5.2 interface, to which the transmitted or received message applies. The layer 3
address information element is the second part of a message. It always takes two bytes.
Its structure is protocol-dependent.
For the PSTN protocol, the layer 3 address is used to identify PSTN user ports. The
format of layer 3 address is illustrated in Figure 8-14. The layer 3 address ranges from
0 to 32767.
Layer 3 address (high bit)
Layer 3 address (low bit)
Figure 8-14 Layer 3 address information element identifying the PSTN port
For the control protocol, the layer 3 address information element is used to identify
ISDN or PSTN user ports or to indicate the V5 common control function. Figure 8-14
illustrates the format of layer 3 address information element when it identifies the PSTN
8-23

port. Figure 8-15 illustrates its format when it identifies the ISDN port or common
control (8177) function. The figure shows that the layer 3 address of the ISDN port
ranges from 0 to 8175.
Layer 3 address (high bit) 0
Figure 8-15 Layer 3 address information element identifying the ISDN port or common control function
For the link control protocol, this information element retains the name layer 3 address
although it is used to refer to 2048 kbit/s links. Its format is shown in Figure 8-16. The
figure shows that the layer 3 address ranges from 0 to 255 when it identifies a link.
0
Figure 8-16 Layer 3 address information element identifying a 2048 kbit/s link
For the BCC protocol, this information element has been named the BCC reference
number information element. Its format is shown in Figure 8-17. The source ID in the
figure is a one-bit field used to indicate the entity (LE or AN) that builds the BCC
reference number. For a process created by the LE, this field is coded 0; for a process
created by the AN, the field is coded 1. The figure shows that the value of the BCC
reference number ranges from 0 to 8191.
Source ID BCC
reference number value (high bit)
0 BCC reference number value (low bit)
Figure 8-17 BCC reference number information element

For the protection protocol, this information element has been named the logical C
channel identification information element. Its format is shown in Figure 8-18. The
figure shows that the value of the logical C channel identification ranges from 0 to
65535. In the RESET SN COM and RESET SN ACK messages, the value of the logical
C channel identification must be 0.
Logical C-channel ID (high bit)
Logical C-channel ID (low bit)
Figure 8-18 Logical C-channel identification information element

Table 8-5 lists the usages of the layer 3 address.
8-24

Table 8-5 Usages of the layer 3 address

Protocol type
Name
PSTN protocol
Control protocol
Usage
Digital value
L3 address
Identifying PSTN user ports
032767
08175
L3 address
Identifying ISDN user ports and

PSTN user ports; and used for
common control
032767
8177
BCC protocol
BCC reference number
BCC protocol process
08191
Control protocol
Logical C channel ID
Identifying logical C channels of

the V5.2 interface
065535
Link
protocol
2048 kbit/s link ID
Identifying V5.2 interface links
0255
control
III. Message Type Information Element

This information element is used to identify the protocol a message belongs to and the
function for sending the message. The message type information element is the third
part of a message. It takes one byte fixedly. Table 8-6 is the allocation table of message
type codes.
Table 8-6 Allocation table of message type codes
Protocol type
Scope of message type codes
PSTN protocol
015
Control protocol
1623
BCC protocol
2431
Protection protocol
3247
Link control protocol
4855
Table 8-7 lists the codes of the message type field.

Table 8-7 Structure of V5 protocol message type codes
Bit
8
Hexade
cimal
Protocol message type
This bit is 0 fixedly
PSTN protocol message type
0x00
ESTABLISH
0x01
ESTABLISH ACK
0x02
SIGNAL
0x03
SIGNAL ACK
8-25

Bit
8
Hexade
cimal
This bit is 0 fixedly
0x08
DISCONNECT
0x09
DISCONNECT COMPLETE
0x0C
STATUS ENQUIRY
0x0D
STATUS
0x0E
PROTOCOL PARAMETER
0x10
PORT CONTROL
0x11
PORT CONTROL ACK
0x12
COMMON CONTROL
0x13
COMMON CONTROL ACK
0x18
SWITCH-OVER REQUEST
0x19
SWITCH-OVER COMMAND
0x1A
OS SWITCH-OVER COMMAND
0x1B
SWITCH-OVER ACK
0x1C
SWITCH-OVER REJECT
0x1D
PROTOCOL ERROR
0x1E
RESET SN COMMAND
0x1F
RESET SN ACK
0x20
ALLOCATION
0x21
ALLOCATION COMPLETE
0x22
ALLOCATION REJECT
0x23
DE-ALLOCATION
0x24
DE-ALLOCATION COMPLETE
0x25
DE-ALLOCATION REJECT
0x26
AUDIT
Control protocol message type
Protection protocol message type
BCC protocol message type
8-26

Bit
8
Hexade
cimal
0x27
AUDIT COMPLETE
0x28
AN FAULT
0x29
AN FAULT ACK
0x2A
PROTOCOL ERROR
0x30
LINK CONTROL
0x31
LINK CONTROL ACK
Link control protocol message type
All other values are reserved. The symbol - indicates 0 or 1.
IV. Other Information Elements

These information elements can appear in different messages. According to the
grammatical meaning of this message and its application in the protocol, these
information elements are optional or mandatory. They are specific to different protocols.
For the coding structure of these information elements, refer to Technical Specifications
on V5.2 Interface between Local Digital Exchange and Access Network (YDN
021-1996).
8.2.5 Call Control Flow of V5.2 Interface

I. Call Flow for the PSTN User
Calls of the PSTN user through the V5.2 interface requires the coordination between
the BCC protocol, PSTN protocol and national call entity. The following takes a PSTN
call as an example to describe the flow of the message interaction between the BCC
protocol, PSTN protocol and national protocol.
PSTN call flow started by the AN side user
Suppose the PSTN user on the AN side is in the pulse dialing mode. If the user uses
the DTMF dialing mode, there is no SIGNAL message sent in the signal flow; the DTMF
signal is received by a dual tone number receiver on the LE side through the bearer
channel. After the completion of the call, the caller hooks on first.
The call flow is illustrated in Figure 8-19. In the figure, the SIGNAL ACK message
returned by the peer end is omitted.
8-27

PSTN user port
AN side
FE user occupation
Hook off
(Hook off)
LE side
ESTABLISH
FE establishment
Ss=hook-off
ESTABLISH ACK
ALLOCATION
NAT
(Hook off)
FE establishment acknowledgement
FE allocation request
Ring
ALLOCATION COMP
FE allocation complete
DT
Dialing tone
Digit 1
Digit n
FE line signal
SIGNAL
(Line status signal)

FE line signal
SIGNAL
(Line status signal)
FE line signal
Stop DT
Ds=digit
FE line signal
Ds=digit
Ring back tone (from terminal office)
Start establishing
the call
Talk
User answers
Hook on
FE line signal
(Hook on)
SIGNAL
Ds=hook on
DISCONNECT
FE line signal
(Hook on)
FE disconnection request
Ss=normal polarity
DEALLOCATION
DISCONNECT COMP
Idle
DEALLOCATION COMP
FE deallocation request
FE disconnection complete
FE deallocation complete
Figure 8-19 PSTN call flow started by the AN side user

The PSTN call establishment flow started on the network side
If the network side originates a call, the on the AN side is the callee. In this case, the call
flow is similar to that when the AN side user is the caller. But the signal sequence and
information elements in this call flow established at the call initiation differ from that in
the call flow with the AN side user as the caller. Figure 8-20 illustrates the signal flow at
the call establishment stage for a call originated on the network side.
8-28

PSTN user port
AN side
LE side
ALLOCATION
Idle
ALLOCATION COMP
Ring
FE establishment
Ss=keep on ringing
(Keep on ringing)
ESTABLISH ACK
FE line signal
SIGNAL
(Hoof off)
Hook off
FE allocation complete
ESTABLISH
FE line signal
NAT
Keep on ringing
FE establishment
acknowledgement
FE line signal indication
Ss=hook off
Ring back
tone
Hook off
Talk
Figure 8-20 PSTN call establishment flow started on the network side
II. Call Flow for the ISDN User

PSTN call flow started by the AN side user
Figure 8-21 illustrates the ISDN call flow started by the AN side user. During the
establishment of an ISDN call, the protocol-required synchronization procedure is: The
allocation of the bearer channel must be completed before sending the SETUP ACK
message (a DSS1 message). If the allocation of the bearer channel fails, the RELEASE
COMP message replaces the SETUP ACK message to cancel the establishment of this
call.
ISDN user port
AN side
LE side
NAT
SETUP(B)
ALLOCATION(TS1_B1)
ALLOCATION COMP
FE establishment
complete
SETUP-ACK or other messages (B1)

CONNECT
Hook on
User answers
DICONNECT
Disconnect
the call
RELEASE
DEALLOCATION
FE deallocation request
DEALLOCATION COMP
FE deallocation complete
Figure 8-21 ISDN call and release started by the AN side user
8-29

Figure 8-21 shows that protocol synchronization is not required for the ISDN call
release and the de-allocation of the bearer channel. Therefore, the sending of the
DEALLOCATION COMP message is independent of the order of receiving the
RELEASE message.
ISDN call setup flows simultaneously started
Figure 8-22 illustrates two ISDN call setup flows simultaneously started at one ISDN
user port. The figure shows the message interaction between the BCC protocol and the
DSS1 protocol.
ISDN user port
AN side
LE side
NAT
SETUP(CR1)
ALLOCATION(TS1_B1)
ALLOCATION(TS2_B2)
SETUP(CR2)
ALLOCATION COMP(TS1)
FE establishment complete
SETUP-ACK or other messages (CR1-B1)

ALLOCATION COMP(TS2)
FE establishment complete
SETUP-ACK or other messages (CR2-B2)
Figure 8-22 Two ISDN call setup flows simultaneously started at one ISDN user port
8-30

SoftX3000 Technical Manual-Signaling&amp;Protocols

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SoftX3000 Technical Manual-Signaling&amp;Protocols

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 1 MGCP ..............................................................................................

1.1 Overview ................................................................................................

2.1 Overview ................................................................................................

Chapter 3 SIP ...................................................................................................

3.1 Overview ................................................................................................

3.3.2 Successful SIP User Call Procedure .............................................

4.1 Overview of H.323 ..................................................................................

Chapter 5 SIGTRAN .........................................................................................

5.1 Overview ................................................................................................

5.2.5 SCTP Messages ............................................................................

Chapter 6 SS7 ..................................................................................................

6.1 Overview ................................................................................................

6.3.3 Basic Signaling Flow ......................................................................

Chapter 7 R2 Signaling ...................................................................................

7.1 Basic Concepts ......................................................................................

Chapter 8 DSS1 Signaling and V5 Protocol ..................................................

8.1 DSS1 Signaling ......................................................................................

U-SYS SoftX3000 SoftSwitch System

U-SYS SoftX3000 SoftSwitch System

Signaling & Protocols

Huawei Technologies Co., Ltd.

Copyright 2005 Huawei Technologies Co., Ltd.

All Rights Reserved

, HUAWEI, C&C08, EAST8000, HONET,

, ViewPoint, INtess, ETS, DMC,

TELLIN, InfoLink, Netkey, Quidway, SYNLOCK, Radium,

About This Manual

U-SYS SoftX3000 SoftSwitch System

It provides an overall introduction to SoftX3000, including

U-SYS SoftX3000 SoftSwitch System

It details on the hardware architecture, component

U-SYS SoftX3000 SoftSwitch

It serves as an referential guidance on the usage of

U-SYS SoftX3000 SoftSwitch System

It guides maintenance personnel to perform daily

U-SYS SoftX3000 SoftSwitch System

It details the installation procedure of SoftX3000 hardware

U-SYS SoftX3000 SoftSwitch System

It covers the detailed procedure of installing SoftX3000

U-SYS SoftX3000 SoftSwitch System

It guides the engineers how to perform traffic measurement

U-SYS SoftX3000 SoftSwitch System

It guides the engineers how to configure various data in

U-SYS SoftX3000 SoftSwitch System

It guides the engineers how to configure various data in

U-SYS SoftX3000 SoftSwitch System

It covers the voice services, IP Centrex services,

U-SYS iGateway Bill User Manual

It elaborates on the functioning principle of the iGateway

Chapter 1 MGCP profiles the architecture, message specifications and call

Chapter 2 H.248 details the architecture, message specifications and call

Chapter 3 SIP presents the architecture, message specifications and call

Chapter 4 H.323 details the architecture, message specifications and call

Chapter 5 SIGTRAN provides the architecture, message specifications and call

Chapter 6 SS7 gives a detailed description of the architecture, message

Chapter 7 R2 Signaling elaborates the architecture, message specifications and

Chapter 8 DSS1 and V5 focuses on the architecture, message specifications and

NGN network planning experts

NGN network administrators

NGN system engineers

Normal paragraphs are in Arial.

Warnings, Cautions, Notes and Tips are in Arial Narrow.

Headings are in Boldface.

Terminal Display is in Courier New.

SoftX3000 Technical Manual-Signaling&Protocols

SoftX3000 Technical Manual-Signaling&Protocols