You are on page 1of 487

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.1.3 Structure of Protocol Stack ............................................................
2.1.4 Implementation in SoftX3000 .........................................................
2.2 Protocol Messages .................................................................................
2.2.1 Message Types..............................................................................
2.2.2 Message Structure .........................................................................
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.1.3 Structure of Protocol Stack ............................................................
3.1.4 Implementation in SoftX3000 .........................................................
3.2 Protocol Messages .................................................................................
3.2.1 Message Types..............................................................................
3.2.2 Message Structure .........................................................................
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.3.6 Basic Procedures ...........................................................................
4.4 Recommendation H.245 .........................................................................
4.4.1 Overview of H.245 .........................................................................
4.4.2 H.245 Messages ............................................................................
4.4.3 Basic Procedures ...........................................................................
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.3 Structure of Protocol Stack ............................................................
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.3 Structure of Protocol Stack ............................................................
5.3.4 Implementation of M2UA ...............................................................
5.3.5 Protocol Messages ........................................................................
5.3.6 Basic Signaling Procedures ...........................................................
5.4 M3UA .....................................................................................................
5.4.1 Introduction ....................................................................................
5.4.2 M3UA Messages ............................................................................
5.4.3 Basic Signaling Procedures ...........................................................
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.5.9 Basic Signaling Procedures ...........................................................
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.3.2 Singnaling Message .......................................................................

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.4.2 Singnaling Message .......................................................................
6.5 TCAP ......................................................................................................
6.5.1 Basic Concepts ..............................................................................
6.5.2 Singnaling Message .......................................................................
6.6 INAP .......................................................................................................
6.6.1 Basic Concepts ..............................................................................
6.6.2 Singnaling Message .......................................................................
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

U-SYS SoftX3000 SoftSwitch System


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

U-SYS SoftX3000 SoftSwitch System


Technical Manual-System Description

It provides an overall introduction to SoftX3000, including


product features, applications and technical specifications.

U-SYS SoftX3000 SoftSwitch System


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.

U-SYS SoftX3000 SoftSwitch System


Maintenance Manual- Routine
Maintenance

It guides maintenance personnel to perform daily


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

U-SYS SoftX3000 SoftSwitch System


Hardware Installation Manual

It details the installation procedure of SoftX3000 hardware


components, and matters needing attention during the
installation process.

U-SYS SoftX3000 SoftSwitch System


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.

U-SYS SoftX3000 SoftSwitch System


Operation Manual-Traffic
Measurement

It guides the engineers how to perform traffic measurement


operations and how to analyze traffic measurement results.

U-SYS SoftX3000 SoftSwitch System


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.

U-SYS SoftX3000 SoftSwitch System


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

U-SYS SoftX3000 SoftSwitch System


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.

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.1.3 Structure of Protocol Stack ..................................................................................... 2-6
2.1.4 Implementation in SoftX3000 .................................................................................. 2-7
2.2 Protocol Messages ............................................................................................................ 2-8
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.1.3 Structure of Protocol Stack ..................................................................................... 3-6
3.1.4 Implementation in SoftX3000 .................................................................................. 3-6
3.2 Protocol Messages ............................................................................................................ 3-7
3.2.1 Message Types ....................................................................................................... 3-7
3.2.2 Message Structure ................................................................................................ 3-10
i

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.3.6 Basic Procedures .................................................................................................. 4-27
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.4.3 Basic Procedures .................................................................................................. 4-42
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.3 Structure of Protocol Stack ..................................................................................... 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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.2 Singnaling Message................................................................................................ 6-6
6.3.3 Basic Signaling Flow ............................................................................................. 6-10
6.4 SCCP ............................................................................................................................... 6-12
6.4.1 Basic Concepts ..................................................................................................... 6-12

iii

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Table of Contents

6.4.2 Singnaling Message.............................................................................................. 6-13


6.5 TCAP ................................................................................................................................. 6-3
6.5.1 Basic Concepts ....................................................................................................... 6-3
6.5.2 Singnaling Message................................................................................................ 6-5
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

...

Parameter name: parameter value

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

EndpointConfiguration

EPCF (EndpointId, BearerInformation)


z

NotificationRequest

1-18

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Response code

Chapter 1 MGCP

Transaction ID

Commentary (optional)

Response line

Parameter name: parameter value


Parameter line

...

Parameter name: parameter value

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

EndpointConfiguration

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 1 MGCP

The 4th line: The signal is null, indicating the MGC requires the MG to stop any signal
being sent currently.
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

200 indicates the successful receipt of the command. 32008010 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 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

RQNT 59663957 aaln/1@zd0068.com MGCP 1.0


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

200 indicates the successful receipt of the command. 59663957 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; 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

NTFY 32008011 aaln/1@zd0068.com MGCP 1.0


X:65000102
O:66500008

1-27

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

200 indicates the successful receipt of the command. 32008011 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 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

CRCX 59688530 aaln/1@zd0068.com MGCP 1.0


C:4965
L:a:PCMA,P:20
M:inactive
X:65000106
R: G/ld(N)
S:

The 1st line: The CreateConnection command. The transaction identifier is 59688530,
used to correlate this command with the responses that it triggers. It means to create a
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.
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.

1-28

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 1 MGCP

The 5th line: The encapsulated NotificationRequest in this CreateConnection command.


The request identifier is 65000106, used to correlate this request with the notifications
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.)
The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal
being sent currently.
z

CRCX_RSP encoding

200 59688530 CRCX OK


I:2008012

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. 59688530 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 2008012.
The 3rd line: Null, indicating what is preceded is an SDP session description.
The 4th line: The SDP protocol version is 0. Here, what is returned is the session
description of the local endpoint (Endpoint1).
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 connection.
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
corresponds to the media encoding format PCMA. 0 corresponds to the media
encoding format PCM.

1-29

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 1 MGCP

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

CRCX 59696722 aaln/2@zd0068.com MGCP 1.0


C:4a65
L:a:PCMA,P:20
M:inactive
X:65000008
R:
S:

The 1st line: The CreateConnection command. The transaction identifier is 59696722,
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 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.
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 65000008, used to correlate this request with the notifications
that it triggers.
The 6th line: SoftX3000 requests the MG to detect a specific event that will happen in
the endpoint.
The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal
being sent currently.
z

CRCX_RSP encoding
1-30

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 1 MGCP

200 59696722 CRCX OK


I:2008013

v=0
c=IN IP4 191.169.4.165
m=audio 5004 RTP/AVP 8 0
a=ptime:20

The 1st line: 200 indicates the successful receipt of the command. 59696722 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 2008013.
The 3rd line: Null, indicating what is preceded is an SDP session description.
The 4th line: The SDP protocol version is 0. Here, what is returned is the session
description of the local endpoint (Endpoint2).
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 connection.
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.) 5004 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
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.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 1 MGCP

RQNT 59704917 aaln/2@zd0068.com MGCP 1.0


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

RQNT 59713109 aaln/1@zd0068.com MGCP 1.0


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 3rd line: The MG is requested to detect events that will happen in the Endpoint1.
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

NTFY 32008014 aaln/2@zd0068.com MGCP 1.0


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 8th line: The signal is null, indicating the MGC requires the MG to stop any signal
being sent currently.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
indicates the type of connection address is IP4. 191.169.4.165 represents the
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
m:audio 5004 RTP/AVP 8
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
description of the local endpoint (Endpoint2).
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

MDCX 59729491 aaln/1@zd0068.com MGCP 1.0


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
m:audio 5004 RTP/AVP 8

1-34

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
m:audio 5012 RTP/AVP 8
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

NTFY 32008015 aaln/2@zd0068.com MGCP 1.0


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

MDCX 59754067 aaln/2@zd0068.com MGCP 1.0


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

1-35

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
m:audio 5004 RTP/AVP 8
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.
The 3rd line: The MG is requested to detect events that will happen in the Endpoint2.
The 4th line: The signal is null, indicating the MGC requires the MG to stop any signal
being sent currently.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

NTFY 32008016 aaln/2@zd0068.com MGCP 1.0


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
m:audio 30000 RTP/AVP 8

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
m:audio 30000 RTP/AVP 8
z

MDCX_RSP encoding

200 269207107 MDCX OK


v:0
c:IN IP4 191.169.1.25
m:audio 5004 RTP/AVP 8

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 1 MGCP

R:
S:

v:0
c:IN IP4 191.169.1.25
m:audio 5004 RTP/AVP 8
z

MDCX_RSP encoding

200 269215299 MDCX OK


v:0
c:IN IP4 191.169.3.38
m:audio 30000 RTP/AVP 8

1-41

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

Chapter 2 H.248
2.1 Overview
2.1.1 Basic Concepts
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

2.1.3 Structure of Protocol Stack


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

2.1.4 Implementation in SoftX3000


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 Protocol Messages


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

2.2.2 Message Structure


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,EventBufferDescriptor][,SignalsDescriptor][,DigitMapDescriptor][,AuditDescriptor])
z

Subtract

SUB (TerminationID[,AuditDescriptor])
z

Move

MOV
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,EventBufferDescriptor][,SignalsDescriptor][,DigitMapDescriptor][,AuditDescriptor])
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBuffer
Descriptor][,StatisticsDescriptor][,PackagesDescriptor])
z

Modify

MOD
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBuffer
Descriptor][,StatisticsDescriptor][,PackagesDescriptor])
z

Subtract

SUB
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript

2-23

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

or][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBuffer
Descriptor][,StatisticsDescriptor][,PackagesDescriptor])
z

Move

MOV
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBuffer
Descriptor][,StatisticsDescriptor][,PackagesDescriptor])
z

AuditValue

AuditValue
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
or][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBuffer
Descriptor][,StatisticsDescriptor][,PackagesDescriptor])
z

AuditCapabilities

AuditCapabilities
(TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

MEGACO/1 [191.169.150.170]:2944
P=3{C= - {SC=ROOT{SV{}}}}

The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent
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}}}}

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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}}}

The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent
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 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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent
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 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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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}}}}

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

NTFY_REQ text description

MEGACO/1 [191.169.150.122]:2944
T=884{C= - {
N=A0{
OE=369109251{

2-30

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

NTFY_REPLY text description

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 7th line: The Signals descriptor. Here the signal is null, indicating the MGC requires
the MG to stop any signal played currently.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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{
M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},
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.

ADD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=369363688{
C=${
A=A1{
M{O{MO=SR,RV=OFF,RG=OFF}},

2-33

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

E=369108998{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}}}}}

For details of the parameters, refer to Event 4, earlier in this section.


z

ADD_REPLY text description

MEGACO/1 [191.169.150.122]:2944
P=369363688{C=287{
A=A1,A=A100000035{
M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},
L{v=0 c=IN IP4 191.169.150.122 m=audio 18296 RTP/AVP 8}}}}}

For details of the parameters, refer to Event 4, earlier in this section.


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.

MOD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=372771561{C=287{
MF=A1{
E=369108999{al/*},
SG{al/ri}}}}
z

MOD_REPLY text description

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.

MOD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=372771562{C=286{
MF=A0{
E=369109256{al/*},
SG{cg/rt}}}}
z

MOD_REPLY text description

MEGACO/1 [191.169.150.122]:2944
P=372771562{C=286{MF=A0}}

2-34

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

NTFY_REQ text description

MEGACO/1 [191.169.150.122]:2944
T=885{C=287{
N=A1{
OE=369108999{al/of}}}}
z

NTFY_REPLY text description

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.

MOD_REQ text description

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 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 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 5th line: The Signals descriptor. Here the signal is null, indicating the MGC requires
the MG to stop any signal played currently.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

MOD_REPLY text description

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
description of the RTP Termination A100000035 associated with the Termination
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

MOD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=370281196{C=286{
MF=A0{M{O{MO=SR,RV=OFF,RG=OFF,tdmc/ec=ON}},
E=369109258{al/*},
SG{}},
MF=A100000034{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 18296 RTP/AVP 8}}}}}

For details of the parameters, refer to Event 9, earlier in this section.


z

MOD_REPLY text description

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

NTFY_REQ text description

MEGACO/1 [191.169.150.122]:2944
T=886{C=286{

2-36

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

N=A0{OE=369109258{al/on}}}}
z

NTFY_REPLY text description

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

MOD_REQ text description

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

MOD_REPLY text description

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
z

Chapter 2 H.248

MOD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=372771569{C=287{
MF=A1{E=369109004{al/*},SG{cg/bt}}}}
z

MOD_REPLY text description

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

MOD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=372771570{C= - {
MF=A0{E=369109261{al/*},SG{}}}}
z

MOD_REPLY text description

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

NTFY_REQ text description

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

NTFY_REPLY text description

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

SUB_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=372509427{C=287{O-S=*}}
z

SUB_REPLY text description

MEGACO/1 [191.169.150.122]:2944

2-38

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

MOD_REQ text description

MEGACO/1 [191.169.200.61]:2944
T=372771572{C= - {
MF=A1{E=369109006{al/*},SG{}}}}
z

MOD_REPLY text description

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

ADD_REQ text description

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},
L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 4}}}}}
z

ADD_REPLY text description

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

ADD_REQ text description

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},
L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 4}}}}}
z

ADD_REPLY text description

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},
L{v=0 c=IN IP4 191.169.150.172 m=audio 18300 RTP/AVP 4}}}}}

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.

MOD_REQ text description

MEGACO/1 [191.169.150.170]:2944
T=372787554{C=218{
MF=A0{E=369099790{al/*},SG{al/ri}}}}
z

MOD_REPLY text description

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

MOD_REQ text description

MEGACO/1 [191.169.150.170]:2944
T=371870051{C=15

2-41

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 2 H.248

{MF=A29{SG{SL=0{cg/rt{NC={TO,OR}}}}}}}
z

ADD_REPLY text description

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.

NTFY_REQ text description

MEGACO/1 [191.169.150.172]:2944
T=2470{C=218{
N=A0{OE=369099790{al/of}}}}
z

NTFY_REPLY text description

MEGACO/1 [191.169.150.170]:2944
P=2470{C=218{N=A0}}

6)

Event 6: Through an MOD_REQ command, the MGC sends the connection


description of the RTP Termination A2147489806 associated with the Termination
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.

MOD_REQ text description

MEGACO/1 [191.169.150.170]:2944
T=370297190{C=218{
MF=A0{M{O{MO=SR,RV=OFF,RG=OFF,tdmc/ec=ON}},
E=369099791{al/*},SG{}},
MF=A100000379{M{O{MO=SR,RV=OFF,RG=OFF},
L{v=0 c=IN IP4 m=audio RTP/AVP 4},
R{v=0 c=IN IP4 191.169.150.10 m=audio 13388 RTP/AVP 4}}}}}
z

MOD_REPLY text description

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)

Event 7: Through an MOD_REQ command, the MGC sends the connection


description of the RTP Termination A100000379 associated with the Termination
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
z

Chapter 2 H.248

MOD_REQ text description

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

MOD_REPLY text description

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.

NTFY_REQ text description

MEGACO/1 [191.169.150.172]:2944
T=2471{C=218{
N=A0{OE=369099791{al/on}}}}
z

NTFY_REPLY text description

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.

MOD_REQ text description

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

MOD_REPLY text description

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

SUB_REQ text description

MEGACO/1 [191.169.150.170]:2944
T=372525424{C=218{O-S=*}}

2-43

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
z

Chapter 2 H.248

SUB_REPLY text description

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

SUB_REQ text description

MEGACO/1 [191.169.150.170]:2944
T=372525425{C=15{O-S=A29, O-S=A2147489806}}
z

SUB_REPLY text description

MEGACO/1 [191.169.150.010]:2944
P=372525425{C=15{
S=A29,S=A2147489806}}

2-44

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 3 SIP

Chapter 3 SIP
3.1 Overview
3.1.1 Basic Concepts
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 3 SIP

3.1.3 Structure of Protocol Stack


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.

3.1.4 Implementation in SoftX3000


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 Protocol Messages


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

3.2.2 Message Structure


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Content-Type: application/sdp

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.
In the following example, it is assumed that
z

The IP address of SoftX3000 is 191.169.150.30;

The IP address of SIP Phone is 191.169.150.251;

3-25

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Supported: sip-cc, sip-cc-01, timer
User-Agent: Pingtel/1.2.7 (VxWorks)
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 3 SIP

In the following example, it is assumed that


z

The IP address of SoftX3000 is 191.169.200.61;

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-Type: application/sdp
Content-Length: 203
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE

3-29

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 3 SIP

Supported: sip-cc, sip-cc-01, timer


User-Agent: Pingtel/1.2.7 (VxWorks)
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
User-Agent: Pingtel/1.2.7 (VxWorks)
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-Type: application/sdp
Content-Length: 203
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
Supported: sip-cc, sip-cc-01, timer
User-Agent: Pingtel/1.2.7 (VxWorks)
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:0 pcmu/8000/1
a=rtpmap:96 telephone-event/8000/1
a=rtpmap:8 pcma/8000/1

3-31

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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>
Supported: 100rel,100rel
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,
MESSAGE,REFER
Content-Length: 183
Content-Type: application/sdp

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
m=audio 8766 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 3 SIP

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0


Contact: sip:1001@191.169.150.100
User-Agent: Pingtel/1.0.0 (VxWorks)
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
Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000
Cseq: 1 INVITE
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0
Contact: sip:1001@191.169.150.100
User-Agent: Pingtel/1.0.0 (VxWorks)
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
Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000
Cseq: 1 INVITE
Content-Type: application/sdp
Content-Length: 164
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0
Session-Expires: 36000
Contact: sip:1001@191.169.150.100
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY
User-Agent: Pingtel/1.0.0 (VxWorks)

3-33

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
m=audio 8766 RTP/AVP 0 8
a=rtpmap:0 pcmu/8000/1
a=rtpmap:8 pcma/8000/1

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
Contact: <sip:1001@191.169.200.61:5061;transport=udp>
Content-Length: 183
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 1073741834 1073741834 IN IP4 191.169.200.61
s=Sip Call
c=IN IP4 191.169.150.100
t=0 0
m=audio 8766 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

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
User-Agent: Pingtel/1.2.7 (VxWorks)
Via: SIP/2.0/UDP 191.169.150.101
Content-Length: 0

3-34

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000
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
Supported: sip-cc, sip-cc-01, timer
User-Agent: Pingtel/1.2.7 (VxWorks)
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
Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd
Max-Forwards: 70
Content-Length: 0

3-35

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000
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
User-Agent: Pingtel/1.0.0 (VxWorks)
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.
In the following example, it is assumed that
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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>
Supported: 100rel,100rel
Max-Forwards: 70
Allow:
INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,
MESSAGE,REFER
Content-Length: 184
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.200.61
s=Sip Call
c=IN IP4 191.169.200.101
t=0 0
m=audio 30014 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000

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
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627
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
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

3-37

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 3 SIP

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627


Contact: <sip:5550045@191.169.100.50:5061;transport=udp>
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
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627
Contact: <sip:5550045@191.169.100.50:5061;transport=udp>
Content-Length: 159
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 1073741826 1073741826 IN IP4 191.169.100.50
s=Sip Call
c=IN IP4 191.169.100.71
t=0 0
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

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
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
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
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

3-38

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
Type of number: Unknown
Numbering plan: E.164 ISDN/telephony numbering
Number: 7670001
User-user
Information element: User-user
Length: 126
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (setup)
setup
protocolIdentifier: 0.0.8.2250.0.3
sourceAddress (AliasAddress)
Item 0 (e164)
e164: 7670000
Item 1 (h323_ID)
h323_ID: 7670000
sourceInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 82
t35Extension: 0
manufacturerCode: 2290
productId: CnS H.323v2
versionId: 2.0
terminal (TerminalInfo)
mc: False
undefinedNode: False
destinationAddress (AliasAddress)
Item 0 (e164)
e164: 7670001
activeMC: False
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
conferenceGoal (create)

4-25

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
endpointIdentifier: 22-2
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.

4.3.6 Basic Procedures


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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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 descriptor

Capability
descriptors

Capability descriptor

Simultaneous capability

Alternative capability

Alternative capability

Simultaneous capability

Alternative capability

Capability table entry number

Capability table entry number

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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:
ITU-T Recommendation H.245
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)
tsapIdentifier: 40001
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.

4.4.3 Basic Procedures


I. Capability Exchange
Endpoint A

Timeout

Endpoint B

TCSReq

TCSAck

TCSRej

TCSRel

Figure 4-16 Capability exchange procedure

4-42

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.
ITU-T Recommendation H.225.0
admissionRequest
requestSeqNum: 1930
callType (pointToPoint)
pointToPoint: pointToPoint
callModel (gatekeeperRouted)
gatekeeperRouted: gatekeeperRouted
endpointIdentifier: 22-2
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
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
activeMC: False
answerCall: False
canMapAlias: False
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
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.

ITU-T Recommendation H.225.0


admissionConfirm
requestSeqNum: 1930
bandWidth: 5120
callModel (gatekeeperRouted)
gatekeeperRouted: gatekeeperRouted

4-46

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

destCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.150.170 (191.169.150.170)
port: 1720
irrFrequency: 60
destinationInfo (AliasAddress)
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
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-47

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
Type of number: Unknown
Numbering plan: E.164 ISDN/telephony numbering
Number: 7670001
User-user
Information element: User-user
Length: 126
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (setup)
setup
protocolIdentifier: 0.0.8.2250.0.3
sourceAddress (AliasAddress)
Item 0 (e164)
e164: 7670000
Item 1 (h323_ID)
h323_ID: 7670000
sourceInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 82
t35Extension: 0
manufacturerCode: 2290
productId: CnS H.323v2
versionId: 2.0
terminal (TerminalInfo)
mc: False
undefinedNode: False
destinationAddress (AliasAddress)
Item 0 (e164)
e164: 7670001
activeMC: False
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
conferenceGoal (create)

4-48

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
endpointIdentifier: 22-2
h245Tunneling: False

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: EFD1
Message type: CALL PROCEEDING (0x02)
User-user
Information element: User-user
Length: 70
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (callProceeding)
callProceeding
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)

4-49

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: 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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 0004
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 4
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Circuit mode
Information transfer rate: Multirate (64 kbit/s base rate)
Rate multiplier: 186
User information layer 1 protocol: Recommendation H.221 and H.242
Display
Information element: Display
Length: 30
Display information: Huawei Technologies Co.,

Ltd.

Called party number


Information element: Called party number
Length: 8
Type of number: National number
Numbering plan: E.164 ISDN/telephony numbering
Number: 7670001
User-user
Information element: User-user
Length: 113
Protocol discriminator: X.208 and X.209 coded user information

4-50

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

ITU-T Recommendation H.225.0


h323_uu_pdu (H323-UU-PDU)
h323_message_body (setup)
setup
protocolIdentifier: 0.0.8.2250.0.2
sourceInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
destinationAddress (AliasAddress)
Item 0 (e164)
e164: 7670001
destCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.31.31 (191.169.31.31)
port: 1720
activeMC: False
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
conferenceGoal (create)
create: create
callType (pointToPoint)
pointToPoint: pointToPoint
sourceCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.150.170 (191.169.150.170)
port: 5011
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
mediaWaitForConnect: False
canOverlapSend: False
h245Tunneling: False

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.

ITU-T Recommendation H.225.0

4-51

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

admissionRequest
requestSeqNum: 90
callType (pointToPoint)
pointToPoint: pointToPoint
callModel (gatekeeperRouted)
gatekeeperRouted: gatekeeperRouted
endpointIdentifier: 22-3
destinationInfo (AliasAddress)
Item 0 (h323_ID)
h323_ID: 7670001
Item 1 (e164)
e164: 7670001
srcInfo (AliasAddress)
<empty>
bandWidth: 5120
callReferenceValue: 32772
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
activeMC: False
answerCall: True
canMapAlias: False
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
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..

ITU-T Recommendation H.225.0


admissionConfirm
requestSeqNum: 90
bandWidth: 5120
callModel (gatekeeperRouted)
gatekeeperRouted: gatekeeperRouted
destCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.150.170 (191.169.150.170)
port: 1720
irrFrequency: 60
destinationInfo (AliasAddress)
Item 0 (h323_ID)
h323_ID: 7670001
willRespondToIRR: False
uuiesRequested (UUIEsRequested)

4-52

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8004
Message type: ALERTING (0x01)
User-user
Information element: User-user
Length: 36
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (alerting)
alerting
protocolIdentifier: 0.0.8.2250.0.3
destinationInfo (EndpointType)
terminal (TerminalInfo)
mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: 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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: EFD1
Message type: ALERTING (0x01)
User-user
Information element: User-user
Length: 70

4-53

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

Protocol discriminator: X.208 and X.209 coded user information


ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (alerting)
alerting
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: 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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8004
Message type: CONNECT (0x07)
User-user
Information element: User-user
Length: 81
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (connect)
connect
protocolIdentifier: 0.0.8.2250.0.3
h245Address (ipAddress)
ipAddress

4-54

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
ip: 191.169.31.31 (191.169.31.31)
port: 2722

destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 82
t35Extension: 0
manufacturerCode: 2290
productId: CnS H.323v2
versionId: 2.0
terminal (TerminalInfo)
mc: False
undefinedNode: False
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: 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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: EFD1
Message type: CONNECT (0x07)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Circuit mode
Information transfer rate: 64 kbit/s
User information layer 1 protocol: Recommendation H.221 and H.242
Display
Information element: Display
Length: 30
Display information: Huawei Technologies Co.,
User-user
Information element: User-user
Length: 93

4-55

Ltd.

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

Protocol discriminator: X.208 and X.209 coded user information


ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (connect)
connect
protocolIdentifier: 0.0.8.2250.0.2
h245Address (ipAddress)
ipAddress
ip: 191.169.31.31 (191.169.31.31)
port: 2722
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: 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.
ITU-T Recommendation H.245
request
terminalCapabilitySet
sequenceNumber: 1
protocolIdentifier: 0.0.8.245.0.3
multiplexCapability (h2250Capability)
h2250Capability
maximumAudioDelayJitter: 60
receiveMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)

4-56

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False
centralizedVideo: True
distributedVideo: False

transmitMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False
centralizedVideo: True
distributedVideo: False
receiveAndTransmitMultipointCapability
(MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False
centralizedVideo: True
distributedVideo: False
mcCapability (H2250Capability-mcCapability)
centralizedConferenceMC: False
decentralizedConferenceMC: False
rtcpVideoControlCapability: False
mediaPacketizationCapability
(MediaPacketizationCapability)
h261aVideoPacketization: False
logicalChannelSwitchingCapability: False
t120DynamicPortCapability: False
capabilityTable (CapabilityTableEntry)

4-57

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

Item 0 (CapabilityTableEntry)
capabilityTableEntryNumber: 1
capability (receiveAudioCapability)
receiveAudioCapability
g7231
maxAl_sduAudioFrames: 1
silenceSuppression: False
Item 1 (CapabilityTableEntry)
capabilityTableEntryNumber: 2
capability (receiveVideoCapability)
receiveVideoCapability
h263VideoCapability
qcifMPI: 1
maxBitRate: 5120
unrestrictedVector: False
arithmeticCoding: False
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False
enhancementLayerInfo
(EnhancementLayerInfo)
baseBitRateConstrained: False
Item 2 (CapabilityTableEntry)
capabilityTableEntryNumber: 3
capability (receiveAudioCapability)
receiveAudioCapability
g711Ulaw64k: 30
Item 3 (CapabilityTableEntry)
capabilityTableEntryNumber: 4
capability (receiveAudioCapability)
receiveAudioCapability
g711Alaw64k: 30
Item 4 (CapabilityTableEntry)
capabilityTableEntryNumber: 5
capability (receiveVideoCapability)
receiveVideoCapability
h263VideoCapability
cifMPI: 1
maxBitRate: 5120
unrestrictedVector: False
arithmeticCoding: False

4-58

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False
enhancementLayerInfo

(EnhancementLayerInfo)
baseBitRateConstrained: False
capabilityDescriptors (CapabilityDescriptor)
Item 0 (CapabilityDescriptor)
capabilityDescriptorNumber: 1
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 1
Item 1 (AlternativeCapabilitySet)
array: 2
Item 1 (CapabilityDescriptor)
capabilityDescriptorNumber: 2
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 3
Item 2 (CapabilityDescriptor)
capabilityDescriptorNumber: 3
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 4
Item 3 (CapabilityDescriptor)
capabilityDescriptorNumber: 4
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 5
Item 1 (AlternativeCapabilitySet)
array: 1

13) Scenario 13: H.323 PhoneA receives the TCS message from H.323 PhoneB, and
sends back TCSA message to confirm.
ITU-T Recommendation H.245
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.
ITU-T Recommendation H.245

4-59

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

request
terminalCapabilitySet
sequenceNumber: 1
protocolIdentifier: 0.0.8.245.0.3
multiplexCapability (h2250Capability)
h2250Capability
maximumAudioDelayJitter: 60
receiveMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False
centralizedVideo: True
distributedVideo: False
transmitMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False
centralizedVideo: True
distributedVideo: False
receiveAndTransmitMultipointCapability
(MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: True
distributedControl: False
centralizedAudio: True
distributedAudio: False

4-60

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
centralizedVideo: True
distributedVideo: False

mcCapability (H2250Capability-mcCapability)
centralizedConferenceMC: False
decentralizedConferenceMC: False
rtcpVideoControlCapability: False
mediaPacketizationCapability
(MediaPacketizationCapability)
h261aVideoPacketization: False
logicalChannelSwitchingCapability: False
t120DynamicPortCapability: False
capabilityTable (CapabilityTableEntry)
Item 0 (CapabilityTableEntry)
capabilityTableEntryNumber: 1
capability (receiveAudioCapability)
receiveAudioCapability
g7231
maxAl_sduAudioFrames: 1
silenceSuppression: False
Item 1 (CapabilityTableEntry)
capabilityTableEntryNumber: 2
capability (receiveVideoCapability)
receiveVideoCapability
h263VideoCapability
qcifMPI: 1
maxBitRate: 5120
unrestrictedVector: False
arithmeticCoding: False
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False
enhancementLayerInfo
(EnhancementLayerInfo)
baseBitRateConstrained: False
Item 2 (CapabilityTableEntry)
capabilityTableEntryNumber: 3
capability (receiveAudioCapability)
receiveAudioCapability
g711Ulaw64k: 30
Item 3 (CapabilityTableEntry)
capabilityTableEntryNumber: 4

4-61

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

capability (receiveAudioCapability)
receiveAudioCapability
g711Alaw64k: 30
Item 4 (CapabilityTableEntry)
capabilityTableEntryNumber: 5
capability (receiveVideoCapability)
receiveVideoCapability
h263VideoCapability
cifMPI: 1
maxBitRate: 5120
unrestrictedVector: False
arithmeticCoding: False
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False
enhancementLayerInfo
(EnhancementLayerInfo)
baseBitRateConstrained: False
capabilityDescriptors (CapabilityDescriptor)
Item 0 (CapabilityDescriptor)
capabilityDescriptorNumber: 1
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 1
Item 1 (AlternativeCapabilitySet)
array: 2
Item 1 (CapabilityDescriptor)
capabilityDescriptorNumber: 2
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 3
Item 2 (CapabilityDescriptor)
capabilityDescriptorNumber: 3
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 4
Item 3 (CapabilityDescriptor)
capabilityDescriptorNumber: 4
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 5

4-62

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
Item 1 (AlternativeCapabilitySet)
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.
ITU-T Recommendation H.245
response
terminalCapabilitySetAck
sequenceNumber: 1

16) Scenario 16: H.323 PhoneB sends MSD message to H.323 PhoneA, to start
master slave determination procedure.
ITU-T Recommendation H.245
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.
ITU-T Recommendation H.245
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.
ITU-T Recommendation H.245
request
masterSlaveDetermination
terminalType: 50
statusDeterminationNumber: 4947

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.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (master)
master: master

4-63

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.
ITU-T Recommendation H.245
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)
tsapIdentifier: 40001
mediaControlGuaranteedDelivery: False

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.
ITU-T Recommendation H.245

4-64

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

response
openLogicalChannelAck
forwardLogicalChannelNumber: 1
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 1
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40000
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40001
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
carries the IP address (191.169.150.171) and port number (40002) used 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) used to transmit
quality parameter message of RTCP encapsulated real-time signal transmission.
ITU-T Recommendation H.245
request
openLogicalChannel
forwardLogicalChannelNumber: 2
forwardLogicalChannelParameters
(OpenLogicalChannel-forwardLogicalChannelParameters)
dataType (videoData)
videoData
h263VideoCapability
qcifMPI: 1
maxBitRate: 2048
unrestrictedVector: False
arithmeticCoding: False
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False

4-65

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
enhancementLayerInfo (EnhancementLayerInfo)
baseBitRateConstrained: False

multiplexParameters (h2250LogicalChannelParameters)
h2250LogicalChannelParameters
sessionID: 2
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network:

191.169.150.171

(191.169.150.171)
tsapIdentifier: 40002
mediaGuaranteedDelivery: False
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network:

191.169.150.171

(191.169.150.171)
tsapIdentifier: 40003
mediaControlGuaranteedDelivery: False

23) Scenario 23: H.323 PhoneB sends back OLCA message as response. The
message carries the IP address (191.169.31.31) and port number (40002) used
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)
used to transmit quality parameter message of RTCP encapsulated real-time
signal transmission.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 2
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 3
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40002
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)

4-66

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
tsapIdentifier: 40003

flowControlToZero: False

24) Scenario 24: H.323 PhoneB sends OLC message to H.323 PhoneA, 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.31.31) 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.31.31) and port number (40001) used to transmit
quality parameter message of RTCP encapsulated real-time signal transmission.
ITU-T Recommendation H.245
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.31.31 (191.169.31.31)
tsapIdentifier: 40000
mediaGuaranteedDelivery: False
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40001
mediaControlGuaranteedDelivery: False

25) Scenario 25: H.323 PhoneA sends back OLCA message as response. 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.
ITU-T Recommendation H.245

4-67

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

response
openLogicalChannelAck
forwardLogicalChannelNumber: 1
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 1
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
tsapIdentifier: 40000
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
tsapIdentifier: 40001
flowControlToZero: False

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
carries the IP address (191.169.31.31) and port number (40002) used 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) used to transmit
quality parameter message of RTCP encapsulated real-time signal transmission.
ITU-T Recommendation H.245
request
openLogicalChannel
forwardLogicalChannelNumber: 2
forwardLogicalChannelParameters
(OpenLogicalChannel-forwardLogicalChannelParameters)
dataType (videoData)
videoData
h263VideoCapability
qcifMPI: 1
maxBitRate: 2048
unrestrictedVector: False
arithmeticCoding: False
advancedPrediction: False
pbFrames: False
temporalSpatialTradeOffCapability: False
errorCompensation: False

4-68

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
enhancementLayerInfo (EnhancementLayerInfo)
baseBitRateConstrained: False

multiplexParameters (h2250LogicalChannelParameters)
h2250LogicalChannelParameters
sessionID: 2
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40002
mediaGuaranteedDelivery: False
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40003
mediaControlGuaranteedDelivery: False

27) Scenario 27: H.323 PhoneA sends back OLCA message as response. The
message carries the IP address (191.169.150.171) and port number (40002) used
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)
used to transmit quality parameter message of RTCP encapsulated real-time
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.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 2
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 3
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
tsapIdentifier: 40002
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)

4-69

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
tsapIdentifier: 40003

flowControlToZero: False

28) Scenario 28: H.323 PhoneB hooks on, and sends Q.931 Release Complete
message to the GK to close the channel.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8004
Message type: RELEASE COMPLETE (0x5a)
User-user
Information element: User-user
Length: 35
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (releaseComplete)
releaseComplete
protocolIdentifier: 0.0.8.2250.0.3
reason (undefinedReason)
undefinedReason: undefinedReason
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: False

29) Scenario 29: H.323 PhoneB sends RAS DRQ message to the GK to tell the GK
that the occupied bandwidth can be released.
ITU-T Recommendation H.225.0
disengageRequest
requestSeqNum: 91
endpointIdentifier: 22-3
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
callReferenceValue: 32772
disengageReason (normalDrop)
normalDrop: normalDrop
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
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.
ITU-T Recommendation H.225.0
disengageConfirm
requestSeqNum: 91

4-70

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: EFD1
Message type: RELEASE COMPLETE (0x5a)
Cause
Information element: Cause
Length: 2
Coding standard: ITU-T standardized coding
Location: User (U)
Cause value: Normal unspecified
User-user
Information element: User-user
Length: 30
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (releaseComplete)
releaseComplete
protocolIdentifier: 0.0.8.2250.0.2
reason (undefinedReason)
undefinedReason: undefinedReason
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: False

32) Scenario 32: H.323 PhoneA sends RAS DRQ message to the GK to tell the GK
that the occupied bandwidth can be released.
ITU-T Recommendation H.225.0
disengageRequest
requestSeqNum: 1931
endpointIdentifier: 22-2
conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92
callReferenceValue: 28625
disengageReason (normalDrop)
normalDrop: normalDrop
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
answeredCall: False

4-71

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.
ITU-T Recommendation H.225.0
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
11 Q931_ReleaseComplete
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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

19 Q931_ReleaseComplete
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 0157
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 4
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Circuit mode
Information transfer rate: Multirate (64 kbit/s base rate)
Rate multiplier: 186
User information layer 1 protocol: Recommendation H.221 and H.242
Display
Information element: Display
Length: 30
Display information: Huawei Technologies Co.,
Calling party number
Information element: Calling party number
Length: 12
Type of number: National number
Numbering plan: E.164 ISDN/telephony numbering
Number: 02055500011
Called party number
Information element: Called party number
Length: 9
Type of number: National number
Numbering plan: E.164 ISDN/telephony numbering
Number: 66500010
User-user
Information element: User-user
Length: 181

4-74

Ltd.

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

Protocol discriminator: X.208 and X.209 coded user information


ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (setup)
setup
protocolIdentifier: 0.0.8.2250.0.2
sourceAddress (AliasAddress)
Item 0 (e164)
e164: 02055500011
sourceInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
destinationAddress (AliasAddress)
Item 0 (e164)
e164: 66500010
destCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.1.110 (191.169.1.110)
port: 1720
activeMC: False
conferenceID: 908552FC-3018-E030-844A-AC14C86413C4
conferenceGoal (create)
create: create
callType (pointToPoint)
pointToPoint: pointToPoint
sourceCallSignalAddress (ipAddress)
ipAddress
ip: 191.169.1.112 (191.169.1.112)
port: 5122
callIdentifier (CallIdentifier)
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

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8157
Message type: CALL PROCEEDING (0x02)
User-user
Information element: User-user
Length: 70
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (callProceeding)
callProceeding
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
guid: 908552FC-3018-E030-8449-AC14C86413C4
h245Tunneling: False

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8157
Message type: ALERTING (0x01)
User-user

4-76

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

Information element: User-user


Length: 129
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (alerting)
alerting
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8157
Message type: CONNECT (0x07)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Circuit mode
Information transfer rate: 64 kbit/s
User information layer 1 protocol: Recommendation H.221 and H.242
Display
Information element: Display
Length: 30
Display information: Huawei Technologies Co.,
User-user

4-77

Ltd.

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

Information element: User-user


Length: 86
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (connect)
connect
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
conferenceID: 908552FC-3018-E030-844A-AC14C86413C4
callIdentifier (CallIdentifier)
guid: 908552FC-3018-E030-8449-AC14C86413C4
h245Tunneling: False

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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8157
Message type: FACILITY (0x62)
User-user
Information element: User-user
Length: 38
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (facility)
facility
protocolIdentifier: 0.0.8.2250.0.2

4-78

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

conferenceID: 908552FC-3018-E030-844A-AC14C86413C4
reason (startH245)
startH245: startH245
h245Address (ipAddress)
ipAddress
ip: 191.169.1.110 (191.169.1.110)
port: 5259
h245Tunneling: False

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.

ITU-T Recommendation H.245


request
terminalCapabilitySet
sequenceNumber: 2
protocolIdentifier: 0.0.8.245.0.3
multiplexCapability (h2250Capability)
h2250Capability
maximumAudioDelayJitter: 50
receiveMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: False
distributedControl: False
centralizedAudio: False
distributedAudio: False
centralizedVideo: False
distributedVideo: False
transmitMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: False
distributedControl: False
centralizedAudio: False
distributedAudio: False
centralizedVideo: False

4-79

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
distributedVideo: False

receiveAndTransmitMultipointCapability
(MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: False
distributedControl: False
centralizedAudio: False
distributedAudio: False
centralizedVideo: False
distributedVideo: False
mcCapability (H2250Capability-mcCapability)
centralizedConferenceMC: False
decentralizedConferenceMC: False
rtcpVideoControlCapability: True
mediaPacketizationCapability
(MediaPacketizationCapability)
h261aVideoPacketization: False
logicalChannelSwitchingCapability: False
t120DynamicPortCapability: False
capabilityTable (CapabilityTableEntry)
Item 0 (CapabilityTableEntry)
capabilityTableEntryNumber: 1
capability (receiveAudioCapability)
receiveAudioCapability
g711Alaw64k: 20
capabilityDescriptors (CapabilityDescriptor)
Item 0 (CapabilityDescriptor)
capabilityDescriptorNumber: 1
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
array: 1

7)

Scenario 7: SoftX3000A receives TCS message from SoftX3000B, and sends


back TCSA message to acknowledge.

ITU-T Recommendation H.245


response
terminalCapabilitySetAck
sequenceNumber: 2

4-80

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.

ITU-T Recommendation H.245


request
terminalCapabilitySet
sequenceNumber: 1
protocolIdentifier: 0.0.8.245.0.3
multiplexCapability (h2250Capability)
h2250Capability
maximumAudioDelayJitter: 50
receiveMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: False
distributedControl: False
centralizedAudio: False
distributedAudio: False
centralizedVideo: False
distributedVideo: False
transmitMultipointCapability (MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)
centralizedControl: False
distributedControl: False
centralizedAudio: False
distributedAudio: False
centralizedVideo: False
distributedVideo: False
receiveAndTransmitMultipointCapability
(MultipointCapability)
multicastCapability: False
multiUniCastConference: False
mediaDistributionCapability
(MediaDistributionCapability)
Item 0 (MediaDistributionCapability)

4-81

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
centralizedControl: False
distributedControl: False
centralizedAudio: False
distributedAudio: False
centralizedVideo: False
distributedVideo: False

mcCapability (H2250Capability-mcCapability)
centralizedConferenceMC: False
decentralizedConferenceMC: False
rtcpVideoControlCapability: True
mediaPacketizationCapability
(MediaPacketizationCapability)
h261aVideoPacketization: False
logicalChannelSwitchingCapability: False
t120DynamicPortCapability: False
capabilityTable (CapabilityTableEntry)
Item 0 (CapabilityTableEntry)
capabilityTableEntryNumber: 1
capability (receiveAudioCapability)
receiveAudioCapability
g711Alaw64k: 20
capabilityDescriptors (CapabilityDescriptor)
Item 0 (CapabilityDescriptor)
capabilityDescriptorNumber: 1
simultaneousCapabilities (AlternativeCapabilitySet)
Item 0 (AlternativeCapabilitySet)
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.

ITU-T Recommendation H.245


response
terminalCapabilitySetAck
sequenceNumber: 1

10) Scenario 10: SoftX3000A sends MSD message to SoftX3000B, to start master
slave determination procedure.
ITU-T Recommendation H.245
request
masterSlaveDetermination
terminalType: 120
statusDeterminationNumber: 14134743

4-82

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

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.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (master)
master: slave

12) Scenario 12: SoftX3000B sends MSD message to SoftX3000A, to start master
slave determination procedure.
ITU-T Recommendation H.245
request
masterSlaveDetermination
terminalType: 120
statusDeterminationNumber: 4335996

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.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (slave)
slave: master

14) Scenario 14: SoftX3000A sends OLC message to SoftX3000B, to start


OpenLogicalChannel procedure. This channel is used to transmit G.711 audio
signals and RTP encapsulated real-time media information (audio). The message
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.
ITU-T Recommendation H.245
request
openLogicalChannel
forwardLogicalChannelNumber: 4
forwardLogicalChannelParameters
(OpenLogicalChannel-forwardLogicalChannelParameters)
dataType (audioData)
audioData
g711Alaw64k: 20
multiplexParameters (h2250LogicalChannelParameters)
h2250LogicalChannelParameters

4-83

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323
sessionID: 1
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
tsapIdentifier: 30001
mediaControlGuaranteedDelivery: False
silenceSuppression: False

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
(audio signals), and the IP address (191.169.1.135) and port number (30019)
used to transmit quality parameter message of RTCP encapsulated real-time
signal transmission.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 4
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 1
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.1.135 (191.169.1.135)
tsapIdentifier: 30018
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.1.135 (191.169.1.135)
tsapIdentifier: 30019

16) Scenario 16: SoftX3000B sends OLC message to SoftX3000A, to start


OpenLogicalChannel procedure. This channel is used to transmit G.711 audio
signals and RTP encapsulated real-time media information (audio). The message
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.
ITU-T Recommendation H.245
request
openLogicalChannel
forwardLogicalChannelNumber: 2

4-84

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

forwardLogicalChannelParameters
(OpenLogicalChannel-forwardLogicalChannelParameters)
dataType (audioData)
audioData
g711Alaw64k: 20
multiplexParameters (h2250LogicalChannelParameters)
h2250LogicalChannelParameters
sessionID: 1
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.1.135 (191.169.1.135)
tsapIdentifier: 30019
mediaControlGuaranteedDelivery: False
silenceSuppression: False

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.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 2
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 1
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
tsapIdentifier: 30000
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
tsapIdentifier: 30001

18) Scenario 18: PhoneB hooks on. SoftX3000B sends ESD message to SoftX3000A
to request converstation end.

4-85

Signaling & Protocols Technical Manual


U-SYS SoftX3000 SoftSwitch System

Chapter 4 H.323

ITU-T Recommendation H.245


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
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 0157
Message type: RELEASE COMPLETE (0x5a)
Cause
Information element: Cause
Length: 2
Coding standard: ITU-T standardized coding
Location: User (U)
Cause value: Normal unspecified
User-user
Information element: User-user
Length: 30
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (releaseComplete)
releaseComplete
protocolIdentifier: 0.0.8.2250.0.2
reason (undefinedReason)
undefinedReason: undefinedReason
callIdentifier (CallIdentifier)
guid: 908552FC-3018-E030-8449-AC14C86413C4
h245Tunneling: False

20) Scenario 20: PhoneA hooks on. SoftX3000A sends ESD message to SoftX3000B.
Now, whole call procedure is over.
ITU-T Recommendation H.245
command
endSessionCommand
disconnect: disconnect

4-86

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

5.1.3 Structure of Protocol Stack


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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
shown in Figure 5-1.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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).

Path 1: The local transport address 1 (10.11.23.14:2905) transmits SCTP packets


to the peer transport address 2 (10.11.23.17:2904).

Path 2: The local transport address 2 (10.11.23.15:2905) transmits SCTP packets


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

Path 3: The local transport address 2 (10.11.23.15:2905) transmits SCTP packets


to the peer transport address 2 (10.11.23.17: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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Sequenced delivery within streams

User data fragmentation


Association
startup
and
takedown

Acknowledgement and congestion avoidance


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)

Sequenced delivery within streams

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)

User data fragmentation

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 congestion avoidance

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.
The following information is passed with the notification:
SEND FAILURE

Association ID: local handle to the SCTP association.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

The following information is passed with the notification:


y

Association ID: local handle to the SCTP association.

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.
The following information is passed with the notification:

COMMUNCIATION
UP

Association ID: local handle to the SCTP association.

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.
The following information is passed with the notification:

COMMUNICATION
LOST

Association ID: local handle to the SCTP association.

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

The following information is passed with the notification:


y

Association ID: local handle to the SCTP association.

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

5-16

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

127

IETF-defined Chunk Extensions

128 to
190
191
192 to
254
255

Reserved by the IETF


IETF-defined Chunk Extensions
Reserved by the IETF
IETF-defined Chunk Extensions
5-19

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Stop processing this SCTP packet and discard it. Do not process any further
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Stop processing this SCTP packet and discard it. Do not process any further
chunks within it.

01

Stop processing this SCTP packet and discard it. Do not process any further
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Chunk Flags (8 bits)

This field is set to zero on transmit and ignored on receipt.

5-30

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Chunk Flags (8 bits)

This field is set to zero on transmit and ignored on receipt.


z

Heartbeat Ack Length

5-31

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Chunk Flags (8 bits)

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.
Chunk Flags (8 bits)

This field is set to zero on transmit and ignored on receipt.


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Chunk Flags (8 bits)

This field is set to zero on transmit and ignored on receipt.


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

This error cause indicates that


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

This error cause indicates that


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

This error cause indicates that


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.

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

This error cause is returned to


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

This error cause is returned to


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

This error cause is returned to


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.


Chunk Flags (8 bits)

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


Chunk Flags (8 bits)
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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.

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. Suppose the stream sequence number is 0.

User Data: This field contains the payload user data.

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.

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. In this case, the stream sequence number is 1.

User Data: This field contains the payload user data.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

5.3.3 Structure of Protocol Stack


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


I. Message Structure
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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#

Parameter length(16)
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Value
10

Meaning
Interface identifier management (IIM) messages (M2UA)

11127

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

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

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


message received from a remote M2UA peer.

ASP Inactive Ack (INACTIVE ACK)

It is used to acknowledge an ASP Inactive


message received from a remote M2UA peer.

5127

Reserved by the IETF

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

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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
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-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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 start2
Interface Identifier stop2

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

Interface Identifiers
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 start2
Interface Identifier stop2

Interface Identifier start n


Interface Identifier stop n
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 tag=0x03(String)

Parameter length

Interface Identifiers
Additional Interface Identifiers
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

15

31

Parameter tag=0x01(Integer)

Parameter length

Interface Identifiers
Parameter tag=0x08(Integer range)

Parameter length

Interface Identifier start1


Interface Identifier stop1
Interface Identifier start2
Interface Identifier stop2

Interface Identifier start n


Interface Identifier stop n
Additional Interface Identifier of Tag type 0x1 or type 0x8
Parameter tag=0x04

Parameter length
INFO string

Figure 5-50 Structure of ASP Inactive message (integer formatted interface identifier)

15

31

Parameter tag=0x03(String)

Parameter length

Interface Identifiers
Additional Interface Identifiers
Parameter tag=0x04

Parameter length
INFO string

Figure 5-51 Structure of ASP Inactive message (text formatted interface identifier)
The format of the optional Interface Identifiers parameter is the same as for the ASP
Active message.
The format and description of the optional INFO String parameter are the same as for
the ASP Up message.
4)

ASP Inactive Ack

ASP Inactive Ack message contains the optional Interface Identifier and INFO String
parameters.
The format of the optional Interface Identifiers parameter is the same as for the ASP
Active message.
The format and description of the optional INFO String parameter are the same as for
the ASP Up message.

5-68

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Interface Identifier
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Diagnostic Information

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 tag=0x11(Integer)

Interface Identifiers
Parameter tag=0x08(Integer range)

Parameter length

Interface Identifier start1


Interface Identifier stop1
Interface Identifier start2
Interface Identifier stop2

Interface Identifier start n


Interface Identifier stop n
Additional Interface Identifier of Tag type 0x1 or type 0x8
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

Parameter tag=0x03(String)

Interface Identifiers
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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.

5.3.6 Basic Signaling Procedures


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


received from a remote M3UA peer.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


received from a remote M3UA peer.

5-79

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


received from a remote M3UA peer.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Message class

Message class code (hexadecimal)

ASP traffic maintenance (ASPTM) messages

04

Reserved for other SIGTRAN adaptation layers

05

Reserved for other SIGTRAN adaptation layers

06

Reserved for other SIGTRAN adaptation layers

07

Reserved for other SIGTRAN adaptation layers

08

Routing key management (RKM) messages

09

Reserved by the IETF

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

Reserved by the IETF

02 to 7F

Reserved for IETF-defined MGMT extensions

80 to FF

Table 5-37 M3UA transfer message types


Message type

Message type code (hexadecimal)

Reserved

00

Data (DATA)

01

Reserved by the IETF

02 to 7F

Reserved for IETF-defined transfer extensions

80 to FF

Table 5-38 M3UA signaling network management (SSNM) message types


Message type

Message type code (hexadecimal)

Reserved

00

Destination unavailable (DUNA)

01

Destination available (DAVA)

02

Destination state audit (DAUD)

03

SS7 network congestion (SCON)

04

5-83

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Message type

Message type code (hexadecimal)

Destination user part unavailable (DUPU)

05

Destination restricted (DRST) (not in use temporarily)

06

Reserved by the IETF

7 to 7F

Reserved for IETF-defined SSNM extensions

80 to FF

Table 5-39 M3UA state maintenance (ASPSM) message types


Message type

Message type code (hexadecimal)

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

Reserved by the IETF

7 to 7F

Reserved for IETF-defined ASPSM extensions

80 to FF

Table 5-40 M3UA traffic maintenance (ASPTM) message types


Message type

Message type code (hexadecimal)

Reserved

00

ASP active (ASPAC)

01

ASP inactive (ASPIA)

02

ASP active acknowledgement (ASPAC ACK)

03

ASP inactive acknowledgement (ASPIA ACK)

04

Reserved by the IETF

5 to 7F

Reserved for IETF-defined ASPTM extensions

80 to FF

Table 5-41 M3UA routing key management (RKM) message types


Message type

Message type code (hexadecimal)

Reserved

00

5-84

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Message type

Message type code (hexadecimal)

Registration request (REG REQ)

01

Registration response (REG RSP)

02

Deregistration request (DEREG REQ)

03

Deregistration response (DEREG RSP)

04

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Parameter

Parameter tag code (hexadecimal)

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

Diagnostic information

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

Parameter tag code (hexadecimal)

Network appearance

0x0200

Reserved

0x0201

Reserved

0x0202

Reserved

0x0203

User/cause

0x0204

Congestion indications

0x0205

Concerned destination

0x0206

Routing key

0x0207

5-86

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Parameter

Parameter tag code (hexadecimal)

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

Reserved by the IETF

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
more than three bytes. The receiver must ignore the padding bytes.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Context, mandatory Affected Point Code, and optional INFO String parameters.
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
Context, mandatory Affected Point Code, and optional INFO String parameters.
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

5-92

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

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.

5-94

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

The format and description of the INFO String are the same as for the DUNA message.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

The format and description of the INFO String are the same as for the DUNA message.
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
Context, mandatory Affected Point Code, and optional INFO String parameters.
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.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Figure 5-65 Structure of ASP Up message


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 format and description of the optional INFO String parameter are the same as for
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

Figure 5-66 Structure of ASP Up Ack message


z

INFO String

5-99

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

The format and description of the optional INFO String parameter are the same as for
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

Figure 5-67 Structure of ASP Down message


INFO String

The format and description of the optional INFO String parameter are the same as for
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

INFO String

The format and description of the optional INFO String parameter are the same as for
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)
Destination Point Code
Network Appearance (optional)
Service Indicators (optional)
Originating Point Code List (optional)
Circuit Range List (optional)

Destination Point Code


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Destination Point Code

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
Destination Point Code

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Origination Point Code #2

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
Origination Point Code #1

Lower CIC Value #1


Mask = 0

Upper CIC Value #1


Origination Point Code #2

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 format and description of the optional INFO String parameter are the same as for
the DUNA message.
2)

ASP Active Acknowledgement (ASP Active Ack)

The ASP Active Ack message is used to acknowledge an ASP Active message
received from a remote M3UA peer.
The ASP Active Ack message contains the optional Traffic Mode Type, optional
Routing Context, and optional INFO String parameters.

5-112

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 format and description of the optional INFO String parameter are the same as for
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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
received from a remote M3UA peer.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

The format of the Routing Context parameter is the same as for the ASP Inactive
message.
z

INFO String

The format and description of the optional INFO String parameter are the same as for
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
Diagnostic Information

Figure 5-88 Structure of Error message


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
notification, based on the value of the Status Type.
If the Status Type is AS-State_Change, the Status Information values are shown in
Table 5-52.

5-117

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

5.4.3 Basic Signaling Procedures


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)
ASP active Ack (RCn)

Figure 5-91 Procedure to set up an M3UA message (example 2)

5-119

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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)
ASP active Ack (RCn)

Figure 5-92 Procedure to set up an M3UA message (example 3)

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)
Interface Identifier(32)

Parameter tag(16)
IUA message 0#

Parameter length(16)
Parametervalue(32)

Parameter tag(16)
IUA message n#

Parameter length(16)
Parametervalue(32)

Figure 5-99 IUA message structure

II. Common Message Header


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

Transfer messages [M3UA]

02

SS7 signaling network management (SSNM) messages [M3UA/SUA]

03

ASP state maintenance (ASPSM) messages [IUA/M2UA/M3UA/SUA]

04

ASP traffic maintenance (ASPTM) messages [IUA/M2UA/M3UA/SUA]

05

Q.921/Q.931 boundary primitives transport (QPTM) messages [IUA]

06

MTP2 user adaptation (MAUP) messages [M2UA]

07

Connectionless messages [SUA]

08

Connection-oriented messages [SUA]


5-128

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

Value

Meaning

09

Routing key management (RKM) messages (M3UA)

0A

Interface identifier management (IIM) messages (M2UA)

0B-7F

Reserved by the IETF

80-FF

Reserved for IETF-defined message class extensions

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

Reserved by the IETF

5-129

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

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


status of a specific TEI.

04

TEI Status Indication

It is interchanged between peers of IUA layer to indicate the


status of a specific TEI.

05-7F

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
more than three bytes. The receiver must ignore the padding bytes.
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

Interface Identifier (Integer)


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Figure 5-104 Structure of ASP Up message

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
are the same as those of the INFO String in the ASP Up message.
0

15

31

Parameter tag=0x04

Parameter length
INFO string

Figure 5-105 Structure of ASP Up Ack message

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

Figure 5-106 Structure of ASP Down message

5-135

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 start2
Interface Identifier stop2

Interface Identifier start n


Interface Identifier stop n
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 tag=0x03(String)

Parameter length

Interface Identifiers
Additional Interface Identifiers
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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 format and description of the optional [INFO String] parameter are the same as for
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 format and description of the optional [INFO String] parameter are the same as for
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
Diagnostic information

Figure 5-110 Structure of Error message


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Diagnostic Information

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 tag=0x01(Integer)

Parameter length

Interface Identifiers
Parameter tag=0x08(Integer range)

Parameter length

Interface Identifier start1


Interface Identifier stop1
Interface Identifier start2
Interface Identifier stop2

Interface Identifier start n


Interface Identifier stop n
Additional Interface Identifier of Tag type 0x1 or type 0x8
Parameter tag=0x04

Parameter length
INFO string

Figure 5-111 Structure of Notify message (with integer-formatted interface identifiers)

5-141

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

15

31

Parameter tag=0x0d

Parameter length=8

Status type

Status information

Parameter tag=0x03(String)

Parameter length

Interface Identifiers
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
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-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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Interface Identifiers

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

5.5.9 Basic Signaling Procedures


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)

Figure 5-115shows the example IUA message flows for the establishment of traffic
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
SG

Chapter 5 SIGTRAN
ASP1

ASP Up

ASP2

ASPUP ACK
ASP Up
ASPUP ACK
ASP Active (Load-sharing)
ASP Active ACK
ASP Active (Load-sharing)
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)

Figure 5-117shows the example IUA message flows for the establishment of traffic
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 (Load-sharing)


ASP Active ACK
ASP Active (Load-sharing)
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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)

Figure 5-120shows the example IUA message flows for the establishment of traffic
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


multiple frame operation.

MDL ESTABLISH indication

It is used to indicate the outcome of the procedures for establishing


multiple frame operation.

MDL RELEASE request

It is used to request the outcome of the procedures for terminating


multiple frame operation.

MDL RELEASE confirm

It is used to confirm the outcome of the procedures for terminating


multiple frame operation.

MDL RELEASE indication

It is used to indicate the outcome of the procedures for terminating


multiple frame operation.

5-152

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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


I. Message Structure
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)
Interface Identifier(32)

Parameter tag(16)
V5UA message 0#

Parameter length(16)
Parametervalue(32)

Parameter tag(16)
V5UA message n#

Parameter length(16)
Parametervalue(32)

Figure 5-127 V5UA message structure

5-154

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 5 SIGTRAN

II. Common Message Header


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
ignored by the receiver.
Message Class

Table 5-71 Message class codes


Value

Description

00

Management (MGMT) messages [IUA/M2UA/M3UA/V5UA]

01

Transfer messages [M3UA]

02

SS7 signaling network management (SSNM) messages [M3UA/SUA]

03

ASP state maintenance (ASPSM) messages [IUA/M2UA/M3UA/SUA]

04

ASP traffic maintenance (ASPTM) messages [IUA/M2UA/M3UA/SUA]

05

Q.921/Q.931 boundary primitives transport (QPTM) messages [IUA]

06

MTP2 user adaptation (MAUP) messages [M2UA]

07

Connectionless messages [SUA]

08

Connection-oriented messages [SUA]

09

Routing key management (RKM) messages (M3UA)

0A

Interface identifier management (IIM) messages (M2UA)

0B-7F

Reserved by the IETF

80-FF

Reserved for IETF-defined message class extensions

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

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

Reserved by the IETF

80-FF

Reserved
IETF-defined
extensions

for
ASPSM

5-157

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Reserved by the IETF

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


status of a specific TEI.

03

TEI Status Confirm

It is interchanged between peers of V5UA layer to confirm the


status of a specific TEI.

04

TEI Status Indication

It is interchanged between peers of V5UA layer to indicate the


status of a specific TEI.

05-7F

Reserved by the IETF

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
more than three bytes. The receiver must ignore the padding bytes.
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

Interface Identifier (Integer)


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

Interface Identifier (Integer)

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
ignored by the receiver.
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 6 SS7

6.2 MTP
6.2.1 Basic Concepts
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

6.3.2 Singnaling Message


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)

A context is created in MG2. 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. MG2 returns its RTP port number and voice
compression algorithm through the Reply command.

6-11

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
6.4.1 Basic Concepts
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.

6.4.2 Singnaling Message


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
0001 Protocol class 1
0010 Protocol class 2
0011 Protocol class 3
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 6 SS7

Table 6-8 SCCP messages and their corresponding parameters


Message parameter

CR

Destination local
reference

CC
M

Origin local reference

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)

Origin local reference

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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

X: (To be determined)

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

X: (To be determined)

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

X: (To be determined)

6.5 TCAP
6.5.1 Basic Concepts
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)

6.5.2 Singnaling Message


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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
6.6.1 Basic Concepts
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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 6 SS7

6.6.2 Singnaling Message


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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)

25 operations of class 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)

11 operations of class 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)

2 operations of class 1

Prompt and collect user information, and prompt and accept information.
6)

4 operations of class 2

Close script, script information, run script, play announcement, and assist request
instruction.
7)

Operations of class 3

None.
8)

2 operations of class 4

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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.
This flow example is based on the following conventions:
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.

MG1 and MG2 are controlled by the same SoftX3000.

The callee hooks on first.

Figure 6-23 shows the flow.

6-14

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
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)

A context is created in MG1. TDM termination and RTP termination are added in
the context. [Mode] is set to ReceiveOnly. The jitter buffer and voice
compression algorithm are also set. MG1 returns its RTP port number and voice
compression algorithm through the Reply command.

6-15

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

8)

Chapter 6 SS7

A context is created in MG2. 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. MG2 returns its RTP port number and voice
compression algorithm through the Reply command.

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

ISUP is taken as an example of SS7.

MG1 and MG2 are controlled by the same SoftX3000.

Figure 6-24 shows the flow.

6-16

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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)

A context is created in MG1. TDM termination and RTP termination are added in
the context. [Mode] is set to ReceiveOnly. The jitter buffer and voice
compression algorithm are also set. MG1 returns its RTP port number and voice
compression algorithm through the Reply command.

5)

A context is created in MG2. 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. MG2 returns its RTP port number and voice
compression algorithm through the Reply command.

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 7 R2 Signaling

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

Chapter 7 R2 Signaling

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System

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

Chapter 7 R2 Signaling

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

Technical Manual Signaling & Protocols


U-SYS SoftX3000 SoftSwitch System
z

Chapter 7 R2 Signaling

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 t