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:
[email protected] 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. z Chapter 2 H.248 details the architecture, message specifications and call signaling procedures of H.248. z Chapter 3 SIP presents the architecture, message specifications and call signaling procedures of SIP. z 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. z Chapter 5 SIGTRAN provides the architecture, message specifications and call signaling procedures of SIGTRAN protocol stack, including SCTP, M2UA, and M3UA. z Chapter 6 SS7 gives a detailed description of the architecture, message specifications and call signaling procedures of SS7. z Chapter 7 R2 Signaling elaborates the architecture, message specifications and call signaling procedures of the R2 signaling. z 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 z NGN network administrators z NGN system engineers Conventions The manual uses the following conventions: I. Note: Means a complementary description. II. They are defined as follows: Caution. . Notes and Tips are in Arial Narrow. General conventions Convention Description Arial Normal paragraphs are in Arial.: Means reader be extremely careful during the operation. Cautions. Arial Narrow Warnings. Boldface Headings are in Boldface. Symbols Eye-catching symbols are also used in the manual to highlight the points worthy of special attention during the operation. Courier New Terminal Display is in Courier New. .......1..............................................................2 Related Terms...................................................................................1...... 1-1 1.....4 Implementation in SoftX3000 .......................................... 3-10 i ................................................................................................4 Successful Termination Call Procedure ..... 3-1 3..........3................................. 1-9 1................................2...........................1 Overview ....................1....................................................................3 Gateway Initialization Procedure........................................4 Implementation in SoftX3000 ........................... 3-6 3...............................................................................................................................1.............................................................................. 2-28 2..........................................................................................................................1 Overview ................................................................... 2-39 Chapter 3 SIP . 3-7 3..................................................................2.............. 1-1 1............1.............................................1 Message Types .................................................................................... 1-12 1...........3 Structure of Protocol Stack ........................................................................................................................................... 2-9 2.. 2-1 2........3..... 2-7 2................................................................. 1-23 1.................................................... 3-6 3.......................................................2 Protocol Messages ..........................1.........................................3 Structure of Protocol Stack ................................................................................. 1-24 1.............. 3-7 3.........................5 Successful Trunk Call Procedure................................................1............................................................................................................. 3-2 3.. 2-1 2............................. 1-9 1......... 1-23 1................... 2-8 2....................................... 1-37 Chapter 2 H.................. 1-1 1....1 Basic Concepts ........................3 Basic Control Procedures .................................2 Message Structure ........2 Message Structure ................................................................................................... 3-1 3...............2..................2....3........................................... 2-1 2............................3........2 Protocol Messages ...............................................................................................1 Overview .............1 Message Types ....................... 2-8 2...........2 Protocol Messages .............................2 Message Structure ...........2...........3..........................................3..................................... 2-27 2...................................Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Table of Contents Table of Contents Chapter 1 MGCP .......................................1..........................................1 Basic Concepts .................................... 1-8 1..................................1 Gateway Registration Procedure ........3. 3-1 3..............................2 Successful Termination Call Procedure (in the Same MG) ..............................1 Basic Concepts ..............248 ..................................................................... 2-25 2................................. 1-8 1..................1................................ 2-25 2.......... 2-26 2...........3 Basic Control Procedures .................................................1..............2 Related Terms............................2 Gateway Cancellation Procedure.........................................................................3.................. 2-6 2...........................1 Message Types ........1 Gateway Registration Procedure ............ 2-1 2........................................................2.................1........................4 Implementation in SoftX3000 ............................ 1-1 1..............................................................................................................1...............................................2 Related Terms................3 Successful Termination Call Procedure (in Different MGs) ...........3 Structure of Protocol Stack ........................................... .3..1..............................................225............3.... 4-1 4...........................245.......................................... 5-4 5...................2.................... 4-19 4...323 Trunk Call Procedure ................... 5-1 5...........................2................4 SIGTRAN Implementation in SoftX3000.......................................................................Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Table of Contents 3..................................... 4-1 4..... 3-25 3........2 H...................1 SIP User Registration Procedure .......................................................3.........................3 Basic Procedures .2....................................................................1........................ 4-8 4...................................3...5...................................................4 SCTP Primitives .....................................................2 H.............................................. 4-20 4............... 4-7 4........323 ..4 Successful SIP-T Trunk Call Procedure ...............................................................................1 What is H........................6 Basic Procedures ............1............................................3 Basic Procedures .........................0 Call Signaling Protocols ..2.... 4-7 4............................................................................2 RAS Protocol .......................323 Applications in SoftX3000.................. 3-25 3...........2 Definition of Terms ..3.................................................................................... 4-21 4.... 4-16 4...................................................................................................................1 Overview of RAS .........................5 A typical example of Q.............................4 H....................2......................................................................................... 4-29 4.............. 5-9 5.................. 3-39 Chapter 4 H........................245 .............................................................................................2 SCTP ................................4.............................3 Structure of Protocol Stack ..........................................................................................4..........................................1 Overview ....................................................................................................................................5 SCTP Messages .......................................323....................... 4-1 4................3......................1 Successful H......................................2 RAS Messages..........323 User Call Procedure (Normal Start) ....................................... 4-42 4...............3 Basic Message Procedures .......................2 Terminology.. 4-27 4.....................................2 Successful SIP User Call Procedure.................. 4-18 4............3............................................................225.....................................1 Overview of H...................... 4-32 4.................................................................... 4-44 4..............................................................2..... 3-28 3....3............1 Overview of H...............5....................................................................... 4-1 4...... 5-12 5.....................................4 Recommendation H....3 Successful H................................... 4-44 4....................................................................3 Message Format ..3 SCTP Functions ..............................................................1........ 5-4 5.4.................1 Overview of H.323 Protocol Stack.....................................3 H..................................1...........................................................................................1 Introduction........................... 5-2 5.....................................................3 Structure of H................... 5-3 5.....................................323 .0...........................................5.......................................................... 4-72 Chapter 5 SIGTRAN........................................................1...............................................................1........................... 5-17 ii ......................0 Messages ....245 Messages .............2..........................................3 Successful SIP Trunk Call Procedure ...............323 Call Procedures........3....... 5-2 5........................................ 4-72 4.............................1 Functions..................................2 Terminology.. 4-18 4....................1............................. 5-4 5..........4 Information Elements .931 message .................................. 4-29 4.................................... 5-1 5........................................................... 4-24 4..................................3......................2....................225............... 4-4 4............. 5-1 5.......................................5 H.323 User Call Procedure (Fast Start)..2 Successful H................................................. 4-6 4..................................... 3-36 3........ ..................................................................................................................................................................4........... 6-3 6................................................................. 5-121 5... 6-10 6........................... 5-153 5...................................................................................................................6......................... 5-121 5...............3 M2UA ...............6 Implementation of V5UA ........................... 6-3 6....6..1 Overview .................5.............6......................................................2 Terminology:........................................................................................................3........ 6-2 6.................5.............................................................6..............................5 Definition of V5UA Boundaries......... 5-144 5......................................3.................5....................................2 Terminology....4 SCCP ..5 Structure of IUA Protocol Stack .................3...... 5-46 5........................ 5-125 5...........................................................................................................4 Structure of V5UA Protocol Stack ................................................................. 5-75 5...........................6 V5UA......8 Basic Signaling Procedures of V5UA...........................................................................1 Introduction..3................. 6-1 6......... 5-46 5................................................3 V5UA Functions ................................................1 Basic Concepts ..............2 Singnaling Message....................................................................... 5-152 5..................................... 5-127 5...........................................................5....................4.................................. 5-75 5.............. 5-122 5.................................... 5-40 5.........................................................2...................................................................................... 5-119 5......... 5-123 5..................5........................8 IUA Protocol Messages..............................................................................................................................5...................................................................................3..4................................... 5-48 5..................... 5-48 5......1 Introduction.......................2...............................................................................9 Basic Signaling Procedures ..............3 Structure of Protocol Stack ........................................... 5-123 5...................................1 Basic Concepts ...... 5-74 5......1 Introduction.......................................................................................3.....................................................4 Functions Implemented by the IUA Layer...................................................................... 5-149 5............................................... 5-127 5........................................................................................................2 MTP ....................... 5-154 5................. 6-12 6.....................1 Overview ................ 6-1 6...............................................7 Implementation of IUA...........................5 Protocol Messages..................................3 ISUP..................................................6............................... 5-49 5............6 Definition of IUA Boundaries ..................6 Basic Signaling Procedures .............1 Introduction.. 6-2 6.................5..................5................2............................................................3.................................Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Table of Contents 5............................3 Basic Signaling Flow ........... 5-46 5............3.. 5-162 Chapter 6 SS7 ..........................................................................................................................................3 Basic Signaling Procedures ....5.............. 6-4 6............................................... 5-125 5...............6...........................3............ 5-152 5............................... 6-6 6............................................3 Services Provided by the IUA Layer ..4................. 5-151 5..................................7 V5UA Protocol Messages ..........2 Terminology.2 M3UA Messages ...................................................................... 6-12 iii .........................................................................................6 Basic Signaling Procedures ...........................................................................6........ 5-149 5........................................ 5-149 5........................................................5 IUA .........................................................................4 M3UA .............2 Singnaling Message.............6................................................ 5-77 5......................4 Implementation of M2UA.................................................................................................................................... ...................................................2 Interface ................................................................... 6-13 Chapter 7 R2 Signaling ................................................3 Application of DSS1 ............................................................................................4..................................................... 7-6 7. 8-15 8.........................................................................................................................................................5 Call Control Message................................... 6-8 6................1.......1..........6...... 8-1 8...2 Application of V5 Protocol ....1..........................................................................................................................................Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Table of Contents 6...................................................... 8-13 8.............................................................. 8-19 8.................................................6.............................1 DSS1 Signaling..................................... 8-19 8......................4 Layer 3 Protocol Message ................................................1 Basic Concepts ...... 8-22 8.................................6 INAP.3 Protocol Structure of V5...1.........2 Singnaling Message........................................2 Basic Concepts .....1 Overview of DSS1 Signaling ........... 8-7 8...................................................2 Interface ....................................5..................................2 Application of R2 Signaling.................................................. 7-1 7..........6 Basic Signaling Process.............................................................. 8-1 8..................................2 Register Signaling ........1 Basic Concepts .....................3 Basic Signaling Flow ...6......................................2 Singnaling Message........1 Basic Concepts ......................................2 Singnaling Message.........................................2............1.................... 8-1 8....................4 Protocol Structure of DSS1 .................................................................................... 8-8 8...................1........................... 7-1 7....................................................2.......................... 8-10 8...................................................................................1.....................................................................1................................................................................................................................................................................................................................................. 6-8 6........3 Basic Signaling Flow..................................................5 TCAP ...... 7-1 7.1 Basic Concepts .............................................................. 8-27 iv ..................... 7-3 Chapter 8 DSS1 Signaling and V5 Protocol... 8-1 8...................2................... 6-3 6.. 6-11 6......2...2.............................. 6-13 6.5.............................................................................. 6-5 6............................. 7-2 7........................................................5 Call Control Flow of V5...................... 6-3 6.....................................1 Line Signaling....................2 V5 Protocol ................ 8-15 8.............................................................................................................................. Gateway A gateway is a network element that provides interconnection and interworking between networks of various architectures.2 Related Terms I. 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). Such gateways typically manage a large number of digital circuits.1 Basic Concepts RFC2705 document describes an application programming interface and a corresponding protocol (media gateway control protocol. MGC Control streams MG Media streams Figure 1-1 MGCP concept 1. Such gateways can 1-1 . AMGs can achieve the conversion between bearer channels of a circuit switched network and media streams of a packet switched network. MGCP assumes a call control architecture where call control is independent of service bearer. As shown in Figure 1-1. built-in Signaling Gateway (SG) and Access Gateway (AG) functions.1 Overview 1. a master/slave protocol. PSTN) and a VoIP network. z Access Media Gateways (AMG): that convert media in one network to a suitable format required by another network. For example.1. 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. universally to implement Trunking Gateway (TG). z Universal Media Gateways (UMG): that provide functions to convert media streams and signaling. in essence. MGCP) for controlling Voice over Internet Protocol (VoIP) gateways from external call control elements. where the MGs are expected to execute commands sent by the MGCs.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP Chapter 1 MGCP 1.1. MGCP is. V. SoftX3000 also supports digit collection through an MRS. and a port on an access gateway connected to E-phones. SoftX3000 provides MGCP call agent functionality. access networks. Endpoint identifiers have two components that both are case insensitive: the domain name of the gateway that is managing the endpoint.0). The syntax of the local name depends on the type of endpoint being named.3 of the RFC2705 (Version 1. SoftX3000 supports the controlling of an MGCP MRS to provide announcements and Interactive Voice Response (IVR) services.1. routers. Creation of physical endpoints requires hardware installation. 1-2 . Private Branch Exchanges (PBX). However.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP connect to a variety of devices such as PSTN switches. beginning with a term that identifies the physical gateway containing the given endpoint and ending in a term that specifies the individual endpoint concerned. It is an external call control element for controlling telephony gateways. Between the components. II. Examples of physical endpoints are an interface on a trunk gateway that terminates a trunk connected to a PSTN switch. An example of a virtual endpoint is an audio source in an MRS. and wireless base stations. and a local name within that gateway. an “at” sign (@) is used as a delimiter. while creation of virtual endpoints can be done by software. Call agent A Call Agent provides signaling and call processing functions. compliant with the Internet Engineering Task Force (IETF) RFC2705 (MGCP). III. SoftX3000 supports Calls and Connections management procedure as specified in Section 2. IV. the local name for each of these types is naturally hierarchical. 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. Endpoint Endpoints are sources or sinks of data and can be physical or virtual. Endpoint identifier Endpoints are identified by endpoint identifiers. and conference bridge access point. MRS can be used to provide announcements to all kinds of users in the system. interactive voice response access point. 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 (“/"). SoftX3000 can act as an access point for MGCP E-phones and Softphones in the network. With this in mind. data transfer between these endpoints can take place. and white spaces. Once this association is established for both endpoints. The local name is structured with the name of the physical interface (for example aaln) and the terminal identifier (that is. digits or other printable characters.com which is the name of an endpoint of an AMG.net which is the name of an endpoint of a TG. “$”) 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”. Figure 1-2 illustrates the concepts of endpoints. A multipoint connection is established by connecting the endpoint to a multipoint session.hauwei.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 1 MGCP The individual terms are character strings composed of letters.com. with the exception of characters used as delimiters (”/”. That refers to the first port of the aaln interface of the AMG with the domain name amg1. connections. the gateway is identified by a domain name. Calls and connections Connections may be either point to point or multipoint. Another example is X35V3+A4/13@gw23. the corresponding port number of the telephone number accessing the Media Gateway). calls and gateways. A point to point connection is an association between two endpoints with the purpose of transmitting data between these endpoints. as well as their relations. 1-3 .hauwei. The terminal identifier is separated from the name of the physical interface by a fraction bar (“/”).hauwei. An example is aaln/1 @ amg1. Connections and calls are set up at the initiative of one or several MGCs. 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. such as amg1. One or more connections can belong to one call. “@”).example.com. Connections are grouped in calls. VI. That refers to the thirteenth Time Division Multiplexing (TDM) circuit on the X35V3+A4 interface of the gateway numbered 23 in the example network. z Characters used for wildcarding (“*”. Connections can be established over several types of bearer networks. and responds to the command by providing a “session description”. Gateways assign unique connection identifiers to local ends. and packetization parameters. communication can proceed in both directions. The gateway allocates resources to that connection. IX. the connections must pertain to the same call. The session description contains the information necessary for a third party to send packets towards the newly created connection. 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. Connection identifier Connections managed at endpoints can be converged into calls. 2) The call agent then asks the second gateway to “create a connection” on the second endpoint. calls and gateways When the two endpoints are located on gateways that are managed by the same call agent. Once this is done. Call Agents are identified by domain names. for example. Connection identifiers are character strings composed of hexadecimal numbers. User Datagram Protocol (UDP) port. IP 1-4 . For enhanced network reliability. Names of calls agents and other entities In MGCP. When an MGC builds several connections for the same call. The gateway allocates resources to that connection. Connections are created by gateways. Call identifiers must be unique within the system. connections. such as IP address. VII. VIII. 3) The call agent uses a “modify connection” command to provide the second “session description” to the first endpoint. Call identifiers are treated in MGCP as unstructured octet strings.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP Figure 1-2 Relations between endpoints. Call identifier Calls are identified by unique identifiers which are created by the MGC. and responds to the command by providing a “session description”. MGCP has been designed to allow the implementation of redundant Call Agents which share the same domain name but have different network addresses. The command carries the “session description” provided by the first gateway. Event names and package names are case insensitive. as in: Call-agent@ca. ringback tone.net indicating the busy signal in the information server numbered 12 in the example network X. A Call Agent may ask to be notified about certain events occurring in an endpoint. because the domain name is relatively stable while network addresses can be easily changed. In addition. the default package name for that endpoint type is assumed. any connection”. For Call Agents and gateways. This redundancy mechanism is significant to improve the reliability of the system. such as off-hook events. Other entities. the gateway fetches the list of network addresses of the Call Agent from the domain name server. In MGCP. When an event is applied on a connection. they identify these entities through domain name. instead of individual names. For example. time-out (TO). and uses an appropriate network address for communication with the Call Agent according to specific situations. or dialing events. The dollar sign (“$”). flash-hook events. Call Agents and other entities are represented by e-mail address in essence. Events and signals are grouped in packages. the range and wildcard notation of events can be used. The package name is in fact optional. and busy tone. such as gateways and information servers. the IP address of the entity will be changed but the domain name can be retained. these entities can make full use of redundancy to enhance the reliability of the system. The asterisk sign (“*”). are also identified by their domain names. the name of the connection is added to the name of the event. can be used to denote “all connections”. on-hook events. such as dial tone. Each signal has an associated signal type. Each package is supported by a particular endpoint. Similarly.net indicating a Call Agent in the example network Busy-signal@ann12. and if the package name is excluded from the event name. 1-5 . Each endpoint type has a default package associated with it.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP addresses. a wildcard character. 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. Event and signal The concept of events and signals is central to MGCP. using an “at” sign (“@”) as a delimiter.example. such as on/off (OO). For lower-layer operations. Domain name prevents these entities from being identified directly through network addresses. a package name and an event name. A Call Agent may request certain signals to be applied to an endpoint. A gateway identifies a Call Agent through its domain name.example. can be used to denote “the current. if an entity is moved to a different Local Access Network (LAN). and brief (BR). separated by a slash (“/”). An event name is composed of two logical parts. a wildcard character. 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 . 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.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 G DTMF package D MF package M Trunk package T Line package L Handset emulation package H RTP package R Network access server package N Announcement server package A Script package Script Table 1-2 lists some valid event names. Digit map The Call Agent can ask the gateway to collect digits dialed by the user. It is preferable to accumulate the dialed numbers in a buffer. including zero number of letters. “*” indicates the sign “*” used in DTMF. The solution to this problem is to load the gateway with a digit map that corresponds to the dial plan. The letter “x” indicates any digit. using the phone on our disk.”. is that it is hard for the gateway to predict how many numbers it needs to accumulate before transmission. as soon as they are dialed. The letter “T” indicates the timer is detected time out. such a procedure generates a large number of interactions and occupies a large number of network resources. The digit strings separated by “|” are alternative number schemes. [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. the letters from “A” to “D”. An alternative procedure is for the gateway to notify the Call Agent of the dialed digits. and to transmit them in a single message. this event will be detected. the letters “T” and “x”. can appear before it. and the dot sign “. What are supported in the definition of digit strings include the digits from 0 to 9. This digit map is expressed using a strict syntax. “[]” indicates “any of them”. If a connection lasts for more than an hour. a residential gateway collects the number that a user dials and the credit card number. the pound sign “#”.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.” indicates any number of letters. It is composed of a list of digits and letters. For example. If collected dial sequence matches one of the defined strings. However. however. the asterisk sign “*”. For example. it indicates necessary digits have been collected. 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 . The sign “. “#” indicates the sign “#” used in DTMF. The problem with this accumulation approach. MGCP UDP IP MAC Figure 1-3 MGCP protocol stack MGCP messages are transmitted over UDP/IP. 1-8 .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. while the MG sends the responding signals back to the MGC.1. which allow it to be underlying bearer system independent. The transport layer protocol is UDP and the network layer protocol is IP. The commands and signals of MGCP are defined as IP packets.3 Structure of Protocol Stack Media Gateway Control Protocol is both a definition of commands and a definition of signaling. the MGC can control the MG. 1.1. The structure of MGCP protocol stack is shown in Figure 1-3. By MGCP commands.4 Implementation in SoftX3000 Implementation of MGCP in SoftX3000 is illustrated in Figure 1-4. SoftPhone PSTN G M MG C P 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).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP SoftX3000 23 / H. and it controls and manages the operating procedures of the MG and the SG. while called responses when being returned from MG or MGC. 1. There are connection processing and endpoint processing commands. AG. The Call Agent is also known as MGC (SoftX3000). The TMG achieves the conversion of voice signals between a Circuit Switched (CS) network and a Packet Switched (PS) network. to achieve functions such as signaling processing and call processing. IAD and Softphone through MGCP. 1-9 . 1.2 Protocol Messages Nine types of MGCP messages in total are exchanged between MGC and MG. MG (or MGC) will return a response immediately. SoftX3000 controls the TMG through the H. Command and response are inseparable.1 Message Types I.2. upon receiving a command. and the SG implements the conversion of signaling between a CS network and a PS network. There are nine commands defined in this protocol. which are called commands when being sent to MG or MGC. mainly used for signaling functions related to the call process.3 /S IP P C MG SS7 E1 CP MRS IP Core n tra Sig 8 24 H. Command The names and meanings of MGCP commands are shown in Table 1-4.248 protocol (H.248 is covered in a separate chapter) and controls the MRS. After MG has registered successfully. This command is used by the Call Agent to provide the first endpoint with the session description of the second endpoint. Whether to return response parameters depends on specific commands. used by the gateway to notify the Call Agent that the gateway. The Call Agent uses the command to transfer that information to the corresponding gateway. such as IP address. Response All MGCP commands are acknowledged. used by the Call Agent to audit the status of a connection on an endpoint. Apart from that. The acknowledgement carries a return code which is an integer. z Values between 500 and 599 indicate a permanent error. NotificationRequest RQNT Used to instruct the gateway to watch for specific events on a specified endpoint. used by the Call Agent to associate an endpoint with a specified IP address and UDP port. or a group of endpoints managed by the gateway. a CreateConnection command is also sent to the remote endpoint. ModifyConnection MDCX MGC→MG. Once this process is completed. used to change the parameters associated to a previously established connection. z Values between 400 and 499 indicate a transient error. both parties can communicate in bi-directional ways. CreateConnection II. RestartInProgress RSIP MG→MGC. is being taken out of service or is being placed back in service. which is required to create the connection between the two endpoints. used by the Call Agent to audit the status of an endpoint or a group of endpoints. AuditEndpoints AUEP MGC→MG. the Call Agent will be notified. used to delete an existing connection. If it happens. Notify NTFY MG→MGC. The response codes that have been defined are listed in Table 1-5. AuditConnection AUCX MGC→MG. 1-10 . for which four ranges of values have been defined: z Values between 100 and 199 indicate a provisional response. used by the gateway to notify the Call Agent that a specific event requested to watch for takes place. used to specify the encoding of the signals that will be received by the endpoint (A-law or µ-law). CRCX MGC→MG. DeleteConnection DLCX MGC→MG. z Values between 200 and 299 indicate a successful completion. UDP port and packetization parameters.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP Table 1-4 MGCP commands Command name Code Description EndpointConfiguration EPCF MGC→MG. because the endpoint does not have sufficient resources at this time. 512 The transaction could not be executed. because the gateway cannot send the specified announcement. 522 No such event or signal. 200 The requested transaction was executed normally. 402 The phone is already on hook. 250 The connection was deleted. 502 The transaction could not be executed. 523 Unknown action or illegal combination of actions 524 Internal inconsistency in LocalConnectionOptions. 520 The transaction could not be executed. because the endpoint is unknown. 404 Insufficient bandwidth at this time. 403 The transaction could not be executed. because the endpoint is “restarting”. 518 Unsupported or unknown package. 516 The transaction refers to an unknown call-id. 1-11 . because the endpoint is not ready. 515 The transaction refers to an incorrect connection-id (may have been already deleted). 400 The transaction could not be executed. 511 The transaction could not be executed.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. 401 The phone is already off hook. 521 Endpoint redirected to another Call Agent. 514 The transaction could not be executed. due to a transient error. 517 Unsupported or invalid mode. An actual completion message will follow on later. 510 The transaction could not be executed. because the gateway is not equipped to detect one of the requested events. because the command contained an unrecognized extension. because the gateway is not equipped to generate one of the requested signals. 513 The transaction could not be executed. 501 The transaction could not be executed. 500 The transaction could not be executed. because the endpoint does not have sufficient resources. 519 Endpoint does not have a digit map. because a protocol error was detected. 528 Incompatible protocol version. Its values can be set to “A” which represents A-law and “µ” which represents µ-law. 19030-19044 z BearerInformation (B) It refers to bearer attributes. is defined. a BearerInformation code is B: e:mu z CallId (C) 1-12 . 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. The code of “encoding” attribute is “e”. Command name Transaction ID Endpoint Protocol version Command line Parameter name: parameter value Parameter line .2 Message Structure I. facility failure). 527 Missing RemoteConnectionDescriptor. A line feed character distinguishes the command line and each parameter line. Parameter name: parameter value Figure 1-5 Structure of MGCP command 2) Command parameters z ResponseAck (K) The response acknowledgement attribute indicates the transaction identifiers which have received the response command. 530 CAS signaling protocol error. 526 Insufficient bandwidth. For example. 6257. 531 Failure of a grouping of trunks (for example.2. “encoding”. For example: K: 6234-6255.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP Response code Meaning 525 Unknown extension in LocalConnectionOptions.. 529 Internal hardware failure. It contains a comma separated list of “confirmed transaction-id ranges”. Currently only one attribute. 1. recvonly The gateway should only receive packets. a:G726-32 L: p:10-20. e:off z Connection Mode (M) The connection mode describes the mode of operation of the connection. Connections that belong to the same call share the same call-id. When several parameters are present. and the type of network (encoded as the keyword “nt”). RequestIdentifier (X) z RequestIdentifier is used to correlate this request with the notifications that it triggers. NotifiedEntity (N) z NotifiedEntity specifies where the notifications should be sent. When this parameter is absent. Examples of connection descriptors are: L: p:10. the silence suppression parameter (encoded as the keyword “s”). b:64 L: b:32-64.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. the bandwidth in kilobits per second (encoded as the keyword “b”). 1-13 . z ConnectionId (I) 3) The ConnectionId parameter is expressed as a hexadecimal character string which is composed of a maximum of 32 characters. the notifications should be sent to the originator of the NotificationRequest. composed of a maximum of 32 characters. Call-id identifies calls. 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 gain control parameter (encoded as the keyword “gc”). The call-id can be used to identify calls for reporting and accounting purposes. Table 1-6 Connection mode values and meanings Connection mode Meaning sendonly The gateway should only send packets. RequestIdentifier is expressed as a hexadecimal character string which is composed of a maximum of 32 characters. Each of the parameters is optional. the encryption key (encoded as the keyword “k”). which is expressed as a hexadecimal character string. a:PCMU L: p:10. the resource reservation parameter (encoded as the keyword “r”). the echo cancellation parameter (encoded as the keyword “e”). the type of service parameter (encoded as the keyword “t”). LocalConnectionOptions (L) z The local connection options describe the operational parameters that the Call Agent suggests to the gateway. the values are separated by commas. Table 1-7 Action codes Code Action N Notify immediately A Accumulate D Treat according to digit map S Swap I Ignore K Keep signal(s) active E Embedded notification request When no action is specified. enclosed in parenthesis and separated by commas. the default action is to notify the event. Events that are not listed are ignored.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP Connection mode Meaning sendrecv The gateway should send and receive packets. Each event can be qualified by a requested action. ft and ft(N) are equivalent. or by a list of actions. netwtest The gateway should place the connection in network continuity test mode. The requested list is encoded on a single line. conttest The gateway should place the circuit in test mode. [0-9#T](D) z SignalRequests (S) 1-14 . inactive The gateway should neither send nor receive packets. This means that. with event/action groups separated by commas. letters and inter-digit timers in the MF and DTMF packets. RequestedEvents (R) z The RequestedEvents parameter provides the list of events that have been requested. or in other packages that would define the encoding of digits and timers. hf(S. for example. netwloop The gateway should place the connection in network loopback mode. data The gateway should use the circuit for network access for data. when specified.N) R: hu(N). Examples of RequestedEvents encoding are: R: hu(N). Table 1-7 shows the codes for the various actions. loopback The gateway should place the circuit in loopback mode. confrnce The gateway should place the connection in conference mode. are encoded as a list of keywords. The digit-map action can only be specified for the digits. The actions. can be qualified by additional parameters: the name and parameters of the announcement. rg ObservedEvents (O) z The ObservedEvents parameter provides the list of events that have been observed.9. Types are separated from value by an “=” sign. where the type is either a letter identifier of the parameter or an extension type. Several signals. L/hu ConnectionParameters (P) z Connection parameters are encoded as a string of type and value pairs.5. LA Latency Average latency. and the value is decimal integer. L/hf. as in: S: adsi("123456 Francois Gerard") S: ann(no-such-number. Examples of observed actions are: O: L/hu O: 8295555T O: 8. as in: S: asdi(123456 Your friend). the string that should be displayed. OR Octets received The number of octets that were received on the connection. OS Octets sent The number of octets that were sent on the connection. separated by commas and enclosed within parenthesis.L/hf.5. for example announcement or Analogue Display Server Interface server (ADSI) display. Parameters are encoded from each other by commas. These parameters will be encoded as a set of UTF8 character strings.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.5. PL Packets lost The number of packets that were not received on the connection. expressed as an integer number. as deduced from gaps in the sequence number.5. their codes are separated by commas. 1234567) When several signals are requested. in milliseconds. 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.T O: L/hf. Table 1-8 shows the connection parameter types. JI Jitter The average inter-packet arrival jitter. PR Packets received The number of packets that were received on the connection. expressed as an integer number. in milliseconds. 1-15 .2. NotifiedEntity. RestartReason. The reason code is an integer number. if one wants to audit the value of the NotifiedEntity. the (possibly empty) RequestedInfo parameter describes the information that is requested for the EndpointId specified. PL=0. the Call Agent should use it as the EndpointId value in successive commands referring to this call. QuarantineHandling. OR=0. The reason code is optionally followed by a white space and commentary. The SpecificEndpointId is an optional parameter that identifies the responding endpoint. and Capabilities parameters. z RequestedInfo (F) When a non-wildcard EndpointId is specified. It can be used when the EndpointId parameter referred to a “any of” wildcard name.X. EventStates.) 900 Endpoint malfunctioning 901 Endpoint taken out of service 902 Loss of lower layer connectivity Reason codes are three-digit numeric values. OS=62345.Q. The following endpoint information can be audited with this command: RequestedEvents. DigitMap. LA=48 ReasonCode (E) z Reason codes are used by the gateway when deleting a connection to inform the Call Agent about the reason for deleting the connection. RequestIdentifier.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP An example of connection parameter encoding is: P: PS=1245.A z QuarantineHandling (Q) 1-16 . ConnectionIdentifiers.R. DetectEvents. ReasonCode. JI=0. DigitMap. 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. For example.D. DetectEvents.S. The RequestedInfo parameter contains a comma separated list of parameter codes. They may also be used in a RestartInProgress command. When a SpecificEndpointId is returned. (This code is used only in response to audit requests. and Capabilities. PR=0. the value of the RequestedInfo parameter will be: F:N. to inform the gateway of the Restart’s reason. SiganalRequests. RestartDelay. SignalRequests. RequestedEvents. as in: 900 Endpoint malfuctioning z SpecificEndpointId (Z) The endpoint identifier specified by the gateway is returned in a CreateConnection response. ObservedEvents. RequestIdentifier.T. in response to the request.[0-9#*] z RestartMethod (RM) The RestartMethod parameter specifies the type of restart. A “restart” method indicates that service will be restored on the endpoints after the specified “restart delay”.) whether the gateway is expected to generate at most one notification (step by step). are lost. For example: RM:restart z RestartDelay (RD) 1-17 . A “cancel-graceful” method indicates that a gateway is canceling a previously issued “graceful” restart command. The DetectEvent parameter is encoded as a comma separated list of events. The parameter provides a set of handling options: whether the quarantined events should be processed or discarded.) For example: Q:loop Q:process Q:discard. The established connections are not yet affected. A “forced” restart method indicates that the specified endpoints are taken abruptly out of service. (The default is exactly one. The established connections.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The QuarantineHandling parameter specifies the handling of “quarantine” events. but the Call Agent should refrain to establish new connections. For example: T: hu. 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. but have not yet been notified to the Call Agent. A “disconnected” method indicates that the endpoint has become disconnected and is now trying to establish connectivity. if any. or multiple notifications (loop). Established connections are not affected.hd. that is. The “restart delay” specifies the number of seconds the endpoint has been disconnected. There are no connections that are currently established on the endpoints. and should try to gracefully tear down the existing connections.loop z DetectEvents (T) The list of events that are currently detected in the quarantine mode.hf. (The default is to process them. events that have been detected by the gateway before the arrival of the NotificationRequest command. z LocalConnectionDescriptor (LC) The LocalConnectionDescriptor is a session description that contains information about IP address and port number suitable for the local connection. This occurs because the entity that builds a connection starts by sending a CreateConnection to one of the two gateways involved in it. The encoding of capabilities is based on the Local Connection Options encoding for the parameters that are common to both. UDP port and packetization parameters. a null delay indicates that the Call Agent should simply wait for the natural termination of the existing connections. BearerInformation) z NotificationRequest 1-18 . there is no information available about the other side of the connection. as defined in SDP. This information may be provided in SDP packets later through a ModifyConnection call. capabilities can also contain a list of supported packages and a list of supported modes. In addition.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The restart delay parameter is expressed as a number of seconds. without establishing new connections. type of network (nt). and so on. this parameter may have a null value when the information for the remote end is not known yet. Modes (m). A restart delay of null for the “restart” method indicates that service has already been restored. such as IP address. For example: E: hu z Capabilities (A) Capabilities inform the Call Agent about endpoints’ capabilities when audited. This will typically occur after gateway startup/reboot. a list of supported codecs (*). If the number is absent. For the CreateConnection command. 4) Command expressions What are within the parenthesis preceded by the command name are input parameters. the delay value should be considered null. Those enclosed by […] are optional. For the first CreateConnection issued. The restart delay is always considered null in the case of the “forced” method. z EndpointConfiguration EPCF (EndpointId. In the case of the “graceful” method. z EventStates (ES) The EventStates parameter is encoded as a comma separated list of events. z The RemoteConnectionDescriptor (RC) RemoteConnectionDescriptor includes the same fields as in the LocalConnectionDescriptor. The parameters used are Event Packages (v). ]RequestIdentifier.][Encapsulated EndpointConfiguration]) z DeleteConnection DeleteConnection from the Call Agent: DLCX (CallId.[NotifiedEntity.][Encapsulated EndpointConfiguration]) z ModifyConnection MDCX (CallId.]LocalConnectionOptions.com MGCP 1.0 C.][Re moteConnectionDescriptor.Connection-parameters) DeleteConnection from the Call Agent to delete multiple connections: DLCX (CallId.EndpointId.][Encapsulated NotificationRequest.[RemoteConnection Descriptor.EndpointId.ConnectionId.]RequestIdentifier.EndpointId. G/ld(N) S: 1-19 .][Mode.P:20 M:inactive X:65000108 R:D/[0-9*#T] (D).EndpointId) z AuditEndpoint AUEP (EndpointId.][QuarantineHandling.][Encapsulated EndpointConfiguration]) DeleteConnection from the VoIP gateway: DLCX (CallId.[NotifiedEntity.][SignalRe quests.RequestedInfo) z RestartInProgress RSIP (EndpointId.a265 L:a:PCMA.][encapsulated EndpointConfiguration]) z Notify NTFY (EndpointId.ConnectionId.RequestedInfo) z AuditConnection AUCX (EndpointId.[Encapsulated NotificationRequest.][DetectEvents.][Reason-code]) 5) Command sample The following is an MGCP command encoding sample: CRCX 693585490 aaln/2@zd0068.[NotifiedEntity.ConnectionId.ObservedEvents) z CreateConnection CRCX (CallId.[NotifiedEntity.][RequestedEvents.]Mode.RestartMethod.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP RQNT (EndpointId.ConnectionId.][Encapsulated NotificationRequest.EndpointId.][LocalConnectionOptions.Reason-code.[RestartDelay.[DigitMap. usually followed by a group of optional parameter lines. the asterisk sign “*”. The protocol version of MGCP is 1. What are involved are the digits from 0 to 9. II. indicating the MGC requires the MG to stop any signal being sent currently. The 5th line: The encapsulated NotificationRequest in this CreateConnection command. “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. used to correlate this command with the responses that it triggers. and an optional commentary. Those characters can be part of “digit strings”. indicating the execution status of the command. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds. the connection mode is changed to “sendrecv”. If a digit string matches at least one of available dial plans defined in the digit map. 1-20 . neither sending nor receiving packets. (Long duration connection refers to a connection lasting for more than one hour. the pound sign “#”. The response line consists of the response code. It means to create a connection between SoftX3000 and the second port of the access gateway whose domain name is zd0068.0.) The 7th line: The signal is null. “D/[0-9*#T]” indicates the digits and letters in the DTMF packages. used to correlate this request with the notifications that it triggers. representing the dial keys for user. The 3rd line: The local connection options. The request identifier is 65000108. 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.com and the interface name is aaln. The 4th line: The connection mode is “inactive”. and the timer identifier “T”. Only after the ModifyConnection command is executed. The transaction identifier is 693585490. that is. The response code is a three-digit numeric value. Response format 1) Response structure Similar to the format of MGCP command.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 1st line: The CreateConnection command. transaction identifier. the response format is composed of a response line. “D/[0-9*#T](D)” indicates to process the “digit strings” dialed by user according to the digit map. which are separated by white spaces. The 2nd line: The call identifier is a265. the endpoint1 resident gateway will send the current digit string to the Call Agent. 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 .][LocalConnectionDescriptor]) z ModifyConnection MDCX (ReturnCode.][DetectEvents. 3) Response expressions What are within the parenthesis preceded by the command name are response parameter values..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. earlier in this chapter. For more information.ConnectionId.][NotifiedEntity.[LocalConnectionDescriptor]) z DeleteConnection DeleteConnection from the Call Agent: DLCX (ReturnCode. Those enclosed by […] are optional.][Ev 1-21 .. z EndpointConfiguration EPCF (ReturnCode) z NotificationRequest RQNT (ReturnCode) z Notify NTFY (ReturnCode) z CreateConnection CRCX (ReturnCode.][ObservedEvents. Parameter name: parameter value Figure 1-6 Structure of MGCP response 2) Response parameters The optional response parameter lines depend on the corresponding commands. refer to the section “Command parameters”.][Reques tIdentifier.][ConnectionIdentifiers.][DigitMap.][SignalRequests.[SpecificEndpointId. “CRCX OK” is a commentary. “IN” refers to network indicator in the form of a text string. Udp. audio/video application document.[CallId.][RestartReason.][RemoteConne ctionDescriptor. and “nas” used for data access. The currently defined IN is Internet.][Mode. It indicates all the formats may be used in the session but the first one is the default. a great number of media service streams are transferred over RTP/UDP.][ConnectionParameters]) z RestartInProgress RSIP (ReturnCode.][BearerInformation.4. Its value is associated with the type of address in the “c” line. The 6th line: Media description. There are two classes of protocols defined: RTP/AVP. At this time. For IP4.][RestartDelay. “IP4” indicates the type of connection address is IP4.165 m=audio 5012 RTP/AVP 8 0 a=ptime:20 The 1st line: “200” indicates the successful receipt of the command. ("audio” is used for audio connections.) “5012” is the transport layer port number to which media streams are transmitted.][LocalConnectionOptions. The 5th line: “c” in the response identifies the connection information. The 4th line: The SDP protocol version is 0. transported over UDP. “RTP/AVP” is the transport layer protocol. “audio” indicates the type of media is audio.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP entStates. The 3rd line: Null. It is the local connection descriptor at this time. the DUP protocol. “8 0” represents the type of media payload defined in the RTP audio/video application document.][Capabil ities]}) z AuditConnection AUCX (ReturnCode.[NotifiedEntity]) 4) Response sample The following is a sample of connection response. indicating what is preceded is an SDP session description. 200 693585490 CRCX OK I:1607901 v=0 c=IN IP4 191. “693585490” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response.169.][LocalConnectionDescriptor.4. The 2nd line: The connection identifier is “1607901”.169. “191.165” represents the network address of the gateway that has a connection with the MGC.][NotifiedEntity.][ReasonCode. For audio and video signals. the mapping relation from RTP payload type to encoding is that “8” 1-22 . For example. Attribute is the basic method for SDP extension. 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 following is an RSIP encoding sample: RSIP 836 aaln/*@iad-v2a-he. A “restart” method indicates that service will be restored on the endpoints after the specified “restart delay”. as numeric value attribute. It can be defined as session-level attribute or media-level attribute.0. The 2nd line: The restart method is “restart”. Sample 1: 1-23 . “0” corresponds to the media encoding format PCM .3 Basic Control Procedures 1. a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.1 Gateway Registration Procedure The gateway must have registered to SoftX3000 before the subsequent procedures or connections are made. 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. There are two forms of attributes: a=<flag>. used to correlate this command with the responses that it triggers. It is a binary attribute. 2) Event 2: The MGC sends a response to the MG registration request. as feature attribute. 1. indicating the session has this nature.3. The 7th line: Attribute.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP corresponds to the media encoding format PCMA. The following are RestartInProgress response samples. There are no connections that are currently established on the endpoints of the gateway.com MGCP 1. For example. a=<attribute>:<value>. a=recvonly indicates the “receive only” feature. The transaction identifier is 836. An application of gateway registration procedure is illustrated in Figure 1-7. The protocol version of MGCP is 1.0 NSC 1. reporting the MG has completed a load or restart and requesting to register to the MGC.0 RM:restart The 1st line: The RestartInProgress command. 4.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP 200 836 OK “200” indicates the successful receipt of the command. 1-24 . it indicates an unsuccessful registration. “The endpoint is unknown” is a commentary. “OK” is a commentary. Sample 2: 500 836 The endpoint is unknown “500” indicates the transaction could not be executed because the endpoint is unknown. it indicates a successful registration. z The IP address of the MG is 191.165. z The UserA makes a call to the UserB. it is assumed that z The endpoint identifier of the Endpoint1 is aaln/
[email protected]. which is connected to the UserA. “836” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. 1.com.3. z The endpoint identifier of the Endpoint2 is aaln/2@zd0068. If the MG receives this response. “836” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. If the MG receives this response. which is connected to the UserB.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. and the called party hooks on first. In the following example.169. com and the interface name is aaln.0 X:6500010a R:l/hd(N) S: The 1st line: The NotificationRequest command. requesting it to detect the off-hook event on the endpoint. used to correlate this request with the notifications that it triggers. 1-25 . The transaction identifier is 59659850. It indicates SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068. used to correlate this command with the responses that it triggers.com MGCP 1.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 2 NTFY NTFY_RSP 3 RQNT RQNT_RSP 4 NTFY NTFY_RSP 5 CRCX CRCX_RSP CRCX CRCX_RSP 7 RQNT RQNT_RSP 6 Ringback tone 8 11 RQNT RQNT_RSP MDCX MDCX_RSP 9 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. z RQNT encoding RQNT 59659850 aaln/1@zd0068. The 3rd line: SoftX3000 requests the MG to detect the off-hook event in the endpoint. The 2nd line: The request identifier is 6500010a. The MG keeps monitoring such an event until the user at the Endpoint1 hooks off. The MG acknowledges the command.0. The protocol version of MGCP is 1. it indicates SoftX3000 has received that notification.0 X:65000102 R:D/[0-9*#T](D).# |[0-9*#]. z NTFY encoding NTFY 32008010 aaln/
[email protected] X:6500010a O:hd The 1st line: The Notify command. notifies SoftX3000. The Endpoint1 acknowledges the command and sends dial tone to the UserA at the same time. z RQNT encoding RQNT 59663957 aaln/1@zd0068. The 3rd line: The MG detects the off-hook event. “OK” is a commentary. 3) Event 3: SoftX3000 sends a RQNT command to the Endpoint1. SoftX3000 should acknowledge the information sent by the Endpoint1. Upon detecting a specific event happening on its first port. That value is the same as the value of the parameter contained in the RQNT command that triggers this notification. the Endpoint1 sends to SoftX3000 an NTFY command which carries the message of the off-hook event happening in the detected endpoint. It is used to correlate the RQNT command with the NTFY command. 2) Event 2: After the UserA hooks off.G/ld(N) D:([1-9]xxxxxxx|0xxxxxxxxxx|*|x. “OK” is a commentary.T) S:L/dl 1-26 . The 2nd line: The request identifier is 6500010a. the access gateway.com MGCP 1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 4th line: The signal is null. “32008010” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. Here. z RQNT_RSP encoding 200 59659850 OK “200” indicates the successful receipt of the command. requesting it to collect dialed digits according to the dial plan as well as sending the dial tone. Here. it indicates the MG has received and is executing the request. “59659850” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response.com MGCP 1. whose domain name is zd0068.com and interface name is aaln. indicating the MGC requires the MG to stop any signal being sent currently. z NTFY_RSP encoding 200 32008010 OK “200” indicates the successful receipt of the command. T).com and the interface name is aaln. meanwhile it is sending the dial tone to the Endpoint1. the pound sign “#”.com MGCP 1. The transaction identifier is 59663957.0 X:65000102 O:66500008 1-27 . “D/[0-9*#T](D)” indicates to process the “digit strings” dialed by user according to the digit map. Upon receiving all necessary digits. “[0-9*#]. “0xxxxxxxxxx” indicates any 11-digit number started with 0. “D/[0-9*#T]” indicates the digits and letters in the DTMF packages. 4) Event 4: The Endpoint1 receives the digits according to the dial plan in the event 3. requesting the MG to acknowledge this command and then send dial tone to the UserA. The protocol version of MGCP is 1. the Endpoint1 sends an NTFY command to notify SoftX3000. 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. the endpoint1 resident gateway will send the current digit string to the Call Agent. “[1-9]xxxxxxx” indicates user can dial any 8-digit number started with an integer in the range of 1 to 9.T” indicates any length of digits started with 0 ~ 9. What are involved are the digits from 0 to 9. it indicates the MG has received and is executing the request. (Long duration connection refers to a connection lasting for more than one hour. the asterisk sign “*”. used to correlate this command with the responses that it triggers. One event is digit collection according to the dial plan specified by the digit map. * or # are reported after an expiration. “59663957” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “x. representing the dial keys for user. “*” indicates each digit is reported as soon as it is dialed. and the timer identifier “T”. z RQNT_RSP encoding 200 59663957 OK “200” indicates the successful receipt of the command. The 5th line: The request signal. Those characters can be part of “digit strings”. It indicates SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068. If a digit string matches at least one of available dial plans defined in the digit map.# |[0-9*#].Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 1st line: The NotificationRequest command. SoftX3000 acknowledges the command. z NTFY encoding NTFY 32008011 aaln/1@zd0068. The 3rd line: SoftX3000 requests the MG to detect two events that will happen in the endpoint. “OK” is a commentary. SoftX3000 delivers a dial plan to the Endpoint1 resident gateway: ([1-9]xxxxxxx|0xxxxxxxxxx|*|x. The 2nd line: The request identifier is 65000102. used to correlate this request with the notifications that it triggers. The command carries the collected digits with the parameter ObservedEvents. Here.#” indicates any length of digits are reported whenever # is dialed.0.) The 4th line: Digit map. The 3rd line: The local connection options. That value is the same as the value of the parameter contained in the RQNT command that triggers this notification.0. The 3rd line: The MG detects what the UserA dials is 66500008. Huawei design supports that several connections belonging to one call use different call identifiers. At present. The transaction identifier is 59688530. notifies SoftX3000. The protocol version of MGCP is 1. 5) Event 5: SoftX3000 creates a connection with the Endpoint1. it indicates SoftX3000 has received that notification. It means to create a connection between SoftX3000 and the first port of the access gateway whose domain name is zd0068.com MGCP 1. the access gateway. Upon detecting a specific event happening on its first port. The 2nd line: The request identifier is 65000102.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 1st line: The Notify command. It is used to correlate the RQNT command with the NTFY command. that is.0 C:4965 L:a:PCMA. 1-28 . z CRCX encoding CRCX 59688530 aaln/1@zd0068. the connection mode is changed to “sendrecv”. The 2nd line: The call identifier is 4965. whose domain name is zd0068. “OK” is a commentary. The endpoint acknowledges the command and returns the information about the connection at the local endpoint. used to correlate this command with the responses that it triggers.com and interface name is aaln. Here.P:20 M:inactive X:65000106 R: G/ld(N) S: The 1st line: The CreateConnection command. Only after the ModifyConnection command is executed. The 4th line: The connection mode is “inactive”. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds. z NTFY_RSP encoding 200 32008011 OK “200” indicates the successful receipt of the command.com and the interface name is aaln. neither sending nor receiving packets. “32008011” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. Call identifier is used for charging purposes. The protocol supports that several connections belonging to one call share the same call identifier. “59688530” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. 1-29 . what is returned is the “session description” of the local endpoint (Endpoint1). indicating what is preceded is an SDP session description.169. “8 0” represents the type of media payload defined in the RTP audio/video application document. ("audio” is used for audio connections. transported over UDP. Udp. audio/video application document. The 5th line: “c” in the response identifies the connection information. “IN” refers to network indicator in the form of a text string.4. indicating the MGC requires the MG to stop any signal being sent currently. the DUP protocol. There are two classes of protocols defined: RTP/AVP. (Long duration connection refers to a connection lasting for more than one hour. It indicates all the formats may be used in the session but the first one is the default. The 4th line: The SDP protocol version is 0. At this time. 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.) The 7th line: The signal is null. The 2nd line: The connection identifier is “2008012”. a great number of media service streams are transferred over RTP/UDP. The request identifier is 65000106. The 6th line: Media description. For IP4. the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. “IP4” indicates the type of connection address is IP4.4. “audio” indicates the type of media is audio. Here. z CRCX_RSP encoding 200 59688530 CRCX OK I:2008012 v=0 c=IN IP4 191. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For audio and video signals. “CRCX OK” is a commentary.) “5012” is the transport layer port number to which media streams are transmitted.169. and “nas” used for data access. The currently defined IN is Internet.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 5th line: The encapsulated NotificationRequest in this CreateConnection command. “191. used to correlate this request with the notifications that it triggers. The 3rd line: Null.165” represents the network address of the connection.165 m=audio 5012 RTP/AVP 8 0 a=ptime:20 The 1st line: “200” indicates the successful receipt of the command. “0” corresponds to the media encoding format PCM . It can be defined as session-level attribute or media-level attribute. The 5th line: The encapsulated NotificationRequest in this CreateConnection command. For example. z CRCX encoding CRCX 59696722 aaln/2@zd0068. a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”. the connection mode is changed to “sendrecv”. It means to create a connection between SoftX3000 and the second port of the access gateway whose domain name is zd0068. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds. Call identifier is used for charging purposes. a=recvonly indicates the “receive only” feature. At present. that is. The request identifier is 65000008. Attribute is the basic method for SDP extension. indicating the MGC requires the MG to stop any signal being sent currently. 6) Event 6: SoftX3000 creates a connection with the Endpoint2. Only after the ModifyConnection command is executed. The 6th line: SoftX3000 requests the MG to detect a specific event that will happen in the endpoint. The protocol supports that several connections belonging to one call share the same call identifier. as numeric value attribute.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 7th line: Attribute. The transaction identifier is 59696722. The 4th line: The connection mode is “inactive”. It is a binary attribute.com MGCP 1. For example. The endpoint acknowledges the command and returns the information about the connection at the local endpoint. The 7th line: The signal is null. neither sending nor receiving packets. There are two forms of attributes: a=<flag>. z CRCX_RSP encoding 1-30 . used to correlate this request with the notifications that it triggers.0 C:4a65 L:a:PCMA. used to correlate this command with the responses that it triggers. The protocol version of MGCP is 1.P:20 M:inactive X:65000008 R: S: The 1st line: The CreateConnection command. The 3rd line: The local connection options.0. as feature attribute. The 2nd line: The call identifier is 4a65.com and the interface name is aaln. a=<attribute>:<value>. Huawei design supports that several connections belonging to one call use different call identifiers. indicating the session has this nature. The 6th line: Media description. The 5th line: “c” in the response identifies the connection information. “59696722” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “RTP/AVP” is the transport layer protocol. transported over UDP. It indicates all the formats may be used in the session but the first one is the default. the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. and “nas” used for data access. There are two classes of protocols defined: RTP/AVP. indicating what is preceded is an SDP session description. 7) Event 7: SoftX3000 requests the MG to play the ringing tone to the UserB.169. The 7th line: Attribute. The currently defined IN is Internet. Udp. Its value is associated with the type of address in the “c” line. audio/video application document. “0” corresponds to the media encoding format PCM . a=<attribute>:<value>. For IP4. “CRCX OK” is a commentary. a=recvonly indicates the “receive only” feature. The 2nd line: The connection identifier is “2008013”.169.4. as numeric value attribute. what is returned is the “session description” of the local endpoint (Endpoint2). “IP4” indicates the type of connection address is IP4. as feature attribute. It can be defined as session-level attribute or media-level attribute.) “5004” is the transport layer port number to which media streams are transmitted. a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.4.165 m=audio 5004 RTP/AVP 8 0 a=ptime:20 The 1st line: “200” indicates the successful receipt of the command. There are two forms of attributes: a=<flag>. For audio and video signals. “IN” refers to network indicator in the form of a text string. For example. “audio” indicates the type of media is audio. “191. the DUP protocol. The 3rd line: Null.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP 200 59696722 CRCX OK I:2008013 v=0 c=IN IP4 191. a great number of media service streams are transferred over RTP/UDP. For example. “8 0” represents the type of media payload defined in the RTP audio/video application document. The MG acknowledges the request and meanwhile plays the ringing tone to the UserB. indicating the session has this nature. At this time. z RQNT encoding 1-31 . Here.165” represents the network address of the connection. The 4th line: The SDP protocol version is 0. It is a binary attribute. Attribute is the basic method for SDP extension. ("audio” is used for audio connections. The 3rd line: The MG is requested to detect events that will happen in the Endpoint1. The 3rd line: The endpoint notifies SoftX3000 that the UserB hooked off.com MGCP 1.0 X:6500000a O:hd The 1st line: The Endpoint2 sends a notification to SoftX3000. z NTFY encoding NTFY 32008014 aaln/
[email protected] MGCP 1.0 X:6500010c R: S:G/rt The 1st line: SoftX3000 sends a request to the Endpoint1. it indicates the MG has received and is executing the request. z NTFY_RSP encoding 200 32008014 OK SoftX3000 acknowledges the receipt of the notification. The 2nd line: The request identifier is 6500000a. z RQNT_RSP encoding 200 59713109 OK Here. z RQNT encoding RQNT 59713109 aaln/1@zd0068. meanwhile it is sending the ringing tone to the UserB. The MG notifies the Call Agent of that event.com MGCP 1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP RQNT 59704917 aaln/2@zd0068. meanwhile it is sending the ringback tone to the UserA. it indicates the MG has received and is executing the request. z RQNT_RSP encoding 200 59704917 OK Here. 9) Event 9: The UserB hooks off. The 2nd line: The request identifier is 6500010c. 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 ringback tone to the UserA. 1-32 . The 2nd line: The request identifier is 6500000a. 8) Event 8: SoftX3000 requests the MG to play the ringback tone to the UserA.0 X:6500000a R: S:L/rg The 1st line: SoftX3000 sends a request to the Endpoint2. The 4th line: The MG is requested to play the ringing tone to the UserB. Meanwhile. The 4th line: The local connection options. The transaction identifier is 59721299. the connection parameters of the Endpoint1 are provided for the Endpoint2. The connection is created by the MG. The 3rd line: The connection identifier is 2008013. The 5th line: The connection mode is sendrecv. The 10th line: The SDP protocol version is 0. 1-33 .P:20 M:sendrecv X:6500000e R:G/ft(N).a:PCMA.com MGCP 1. it will modify the connection and stop sending the ringback tone. The MG assigns a unique connection identifier to the local end. indicating the MGC requires the MG to stop any signal being sent currently.4. and the encapsulation delay is 20 milliseconds.0 C:4a65 I:2008013 L:e:on. The command carries some connection parameters of the Endpoint1. The “session description” carries some connection parameters of the Endpoint1. “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.165 m:audio 5012 RTP/AVP 8 The 1st line: SoftX3000 sends a ModifyConnection command to the Endpoint2. indicating what is preceded is an SDP session description. Through the MDCX command. The Call Agent suggests to the MG that the echo cancellation parameter is set to on. 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. requesting to modify the connection.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP 10) Event 10: SoftX3000 sends an MDCX command to the Endpoint2. The Endpoint2 acknowledges the receipt of the command.169. The 6th line: The encapsulated NotificationRequest in this ModifyConnection command.G/mt(N) S: v:0 c:IN IP4 191. The 2nd line: The call identifier is 4a65. The 9th line: Null. used to correlate this request with the notifications that it triggers. z MDCX encoding MDCX 59721299 aaln/2@zd0068. The request identifier is 6500000e. the compression algorithm is PCMA. The 2nd line: The SDP protocol version is 0.0 C:4965 I:2008012 L:e:on. is determined in the MDCX_RSP. UDP port and RTP description. earlier in this chapter.) “5012” is the port number for the media of the Endpoint1. PCMA. and then the UserA and the UserB enjoy a conversation. In general. “IN” refers to network indicator in the form of a text string. the Call Agent provides connection description parameters for the Endpoint2 through MGCP.165” represents the network address of the connection.G/mt(N) S: v:0 c:IN IP4 191. ("audio” is used for audio connections. “c” indicates the connection information of the Endpoint1. and “nas” used for data access. 11) Event 11: SoftX3000 sends an MDCX command to the Endpoint1.169.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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 11th line: Here. The Endpoint1 acknowledges the command.a:PCMA. Here. z MDCX_RSP encoding 200 59721299 MDCX OK v:0 c:IN IP4 191. “IP4” indicates the type of connection address is IP4. such as the Endpoint1’s IP address.4. it can be found that the encoding format for media.169. “RTP/AVP” is the media protocol. The 3rd line: Compared with the “session description” returned in the CRCX_RSP. The CRCX_RSP only provided two options: PCMA and PCM . z MDCX encoding MDCX 59729491 aaln/
[email protected]:20 M:sendrecv R:G/ft(N). The command carries some connection parameters of the Endpoint2. “191.165 m:audio 5004 RTP/AVP 8 1-34 . what is returned is the “session description” of the local endpoint (Endpoint2). “8” indicates PCMA is the encoding format for the media which is negotiated by the Endpoint1 and the Endpoint2. requesting to modify the connection. The 12th line: Media description. “audio” indicates the type of media of the Endpoint1 is audio. The currently defined IN is Internet.4.com MGCP 1.4.169. requesting to modify the connection mode to “sendrecv”. Compared with the “session description” returned in the CRCX_RSP.com MGCP 1.0 C:4a65 I:2008013 M:inactive X:65000002 R: S: 1-35 . It indicates the Notify command is triggered by the encapsulated NotificationRequest command in the ModifyConnection command described in the event 10. z MDCX encoding MDCX 59754067 aaln/
[email protected] 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. is determined in the MDCX_RSP. PCMA. it can be found that the encoding format for media. The 3rd line: The MG reports to SoftX3000 that the Endpoint2 detected an on-hook event happening at the UserB. and notifies SoftX3000 of the event.0 X:6500000e O:hu The 1st line: The Endpoint2 detects a specified event that happened at the UserB. The “session description” of the Endpoint2 is also carried and provided for the Endpoint1.com MGCP 1. The Endpoint2 sends an NTFY command to SoftX3000.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP SoftX3000 sends an MDCX command to the Endpoint1. which is the same as the request identifier carried in the encapsulated NotificationRequest command in the ModifyConnection command described in the event 10.169. z NTFY encoding NTFY 32008015 aaln/2@zd0068. z NTFY_RSP encoding 200 32008015 OK 13) Event 13: SoftX3000 sends an MDCX command to the Endpoint2.4. SoftX3000 acknowledges the command. earlier in this chapter. The CRCX_RSP only provided two options: PCMA and PCM . 12) Event 12: The UserB hooks on. z MDCX_RSP encoding 200 59729491 MDCX OK v:0 c:IN IP4 191. The 2nd line: The request identifier is 6500000e. z DLCX_RSP encoding 250 59762260 OK “250” indicates the connection is deleted. requesting to delete the existing connection. z DLCX encoding DLCX 59770452 aaln/1@zd0068. indicating the MGC requires the MG to stop any signal being sent currently. “OK” is a commentary. The 3rd line: The MG is requested to detect events that will happen in the Endpoint2. requesting to modify the mode of the connection between them to “inactive”.com MGCP 1. z MDCX_RSP encoding 200 59754067 MDCX OK v:0 c:IN IP4 191. The 4th line: The signal is null. The transaction identifier is 59762260.4. In the ModifyConnection command.169. there is an encapsulated NotificationRequest command with the request identifier as 65000004. 1-36 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP SoftX3000 sends an MDCX command to the Endpoint2. 15) Event 15: SoftX3000 sends a DLCX command to the Endpoint1. requesting to delete the existing connection. requesting to delete the existing connection. there is an encapsulated NotificationRequest command with the request identifier as 65000002.com MGCP 1. z DLCX encoding DLCX 59762260 aaln/2@zd0068. The 2nd line: In the DeleteConnection command. indicating that the MGC requests the MG to detect the subsequent events happening in the Endpoint2 and stop any signal played currently.0 X:65000004 R: S: The 1st line: SoftX3000 sends a DLCX command to the Endpoint2. The Endpoint1 acknowledges the command and sends busy tone to the UserA at the same time. requesting to delete the existing connection.165 m:audio 5004 RTP/AVP 8 a:ptime:20 14) Event 14: SoftX3000 sends a DLCX command to the Endpoint2.0 X:65000106 R: S:L/bz The 1st line: SoftX3000 sends a DLCX command to the Endpoint1. 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. z NTFY_RSP encoding 200 32008016 OK 18) Event 18: SoftX3000 sends a RQNT command to the Endpoint1.169. The Endpoint1 sends an NTFY command to notify SoftX3000 of the event. The involved command encoding and response encoding are simple.com MGCP 1. and thus no more information is provided here. The 2nd line: The request identifier is 65000106. requesting the MG to detect events and signals that will happen in the Endpoint1. 1-37 .3.com. The 4th line: SoftX3000 requests the MG to send the busy tone signal to the UserA. it is assumed that z The IP address of the MG1 is 191. z The IP address of the MG2 is 191. which is the same as the request identifier carried in the encapsulated NotificationRequest command in the DeleteConnection command described in the event 15. z The UserA is connected to the MG1.38. The 3rd line: The MG reports to the MGC that the Endpoint1 detected an on-hook event happening at the UserA. there is an encapsulated NotificationRequest command with the request identifier as 65000106.25.3. 1.huawei. 17) Event 17: The UserA hooks on. and the corresponding endpoint identifier of the UserA is aaln/
[email protected]. and thus no more information is provided here. The 3rd line: SoftX3000 requests the MG to detect events that will happen in the Endpoint1. requesting the MG to detect events and signals that will happen in the Endpoint2.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP The 2nd line: In the DeleteConnection command. In the following example. z NTFY encoding NTFY 32008016 aaln/
[email protected] 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.169. z DLCX_RSP encoding 250 59770452 OK 16) Event 16: SoftX3000 sends a RQNT command to the Endpoint2. The involved command encoding and response encoding are simple. 3. The response contains some connection parameters. indicating it to create a connection. and then sends a CRCX_RSP as the response to SoftX3000.2. Judging from the following CRCX_RSP encoding. The MG creates a connection as requested. the “IP address” refers to the IP address of the MG1: 191.com. For the remaining events. z CRCX encoding 1-38 . refer to the section 1. port number.38. and the called party hooks on first.huawei.3. bearer parameter and connection identifier. z The UserA makes a call to the UserB.169.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 1 MGCP The UserB is connected to the MG2. earlier in this chapter. Only the events involved those are described. the MGCP call procedure between two endpoints in different MGs helps us easily understand some commands and responses. The connection parameters describe the connection information of the local gateway MG1. 1) Event 5: SoftX3000 sends a CRCX command to the MG1. and the corresponding endpoint identifier of the UserB is aaln/1@iad2. UserA MG1 1 Off-hook dial-tone dialing SoftX3000 MG2 UserB RQNT RQNT_RSP 2 NTFY NTFY_RSP 3 RQNT RQNT_RSP 4 NTFY NTFY_RSP 5 CRCX CRCX_RSP CRCX CRCX_RSP 7 RQNT RQNT_RSP 6 Ringback tone 8 11 RQNT RQNT_RSP MDCX MDCX_RSP 9 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. such as CRCX and MDCX. As shown in Figure 1-9. such as IP address. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP CRCX 269174338 aaln/1@iad1. requesting to modify the connection.169.com MGCP 1. The response contains some connection parameters. The MG creates a connection as requested. z CRCX encoding CRCX 269182530 aaln/1@iad2. such as IP address.0 C:2a64 L:a:PCMA. The connection parameters describe the connection information of the local gateway MG2. the parameters contained in the CRCX_RSP from the MG1.1.38 m:audio 30000 RTP/AVP 8 2) Event 6: SoftX3000 sends a CRCX command to the MG2. port number.huawei.huawei.169.com MGCP 1. that is. Judging from the following CRCX_RSP encoding. Judging from the following MDCX encoding. The command carries some connection parameters of the MG1.3. and then sends a CRCX_RSP as the response to SoftX3000.169.P:20 M:inactive X:64000204 R: S: z CRCX_RSP encoding 200 269182530 CRCX OK I:4708075 v:0 c:IN IP4 191. 1-39 . the command carries the IP address of the MG1. indicating it to create a connection.0 C:2964 L:a:PCMA.1. that is. the “IP address” refers to the IP address of the MG2: 191. bearer parameter and connection identifier.25 m:audio 5004 RTP/AVP 8 0 4 18 a:ptime:20 3) Event 10: SoftX3000 sends an MDCX command to the MG2.25. Subsequently. the connection mode is changed to be “sendrecv”.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. com MGCP 1. that is.P:20 X:6400000c 1-40 . both the MG1 and the MG2 know the connection information of the local end and the opposite end.P:20 M:sendrecv X:6400020a R: S: v:0 c:IN IP4 191. that is. requesting to modify the connection.1.huawei. some connection parameters of the MG2 are provided to the MG1. the command carries the IP address of the MG2. and other connection information of the MG1.a:PCMA.169. Subsequently.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP 191.38.0 C:2964 I:1 L:e:on. z MDCX encoding MDCX 269207107 aaln/
[email protected]. Through the MDCX command.169. the parameters contained in the CRCX_RSP from the MG2. The command carries some connection parameters of the MG2. After negotiation. At this time. 191. Judging from the following MDCX encoding.3. Conversation conditions are satisfied. z MDCX encoding MDCX 269215299 aaln/1@iad1. the connection mode is changed to be “sendrecv”. The MG2 sends to SoftX3000 an MDCX_RSP carrying the connection information of the local gateway (MG2).com MGCP 1.169. the MG1 and the MG2 determine PCMA as the encoding mode.38 m:audio 30000 RTP/AVP 8 z MDCX_RSP encoding 200 269207107 MDCX OK v:0 c:IN IP4 191. The MG1 sends to SoftX3000 an MDCX_RSP carrying the connection information of the local gateway.25 m:audio 5004 RTP/AVP 8 4) Event 11: SoftX3000 sends an MDCX command to the MG1. the MG1 and the MG2 determine PCMA as the encoding mode. After negotiation. and other connection information of the MG2.169. some connection parameters of the MG1 are provided to the MG2. Through the MDCX command.0 C:2a64 I:4708075 L:e:on.a:PCMA.huawei.1.25. 3.169.25 m:audio 5004 RTP/AVP 8 z MDCX_RSP encoding 200 269215299 MDCX OK v:0 c:IN IP4 191.169.1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 1 MGCP R: S: v:0 c:IN IP4 191.38 m:audio 30000 RTP/AVP 8 1-41 . the H.1. and other standardization organizations are optimizing the H.1. Therefore.1 Overview 2. and bearer parameters are encapsulated within the Termination. Terminations representing ephemeral information flows. The ITU-T. Famous telecommunication equipment vendors are investing much in the development and application of the H. which are grouped in a set of descriptors that are included in commands. a Termination representing a TDM channel might exist for as long as it is provisioned in the gateway. 2. They are destroyed by means of a Subtract command.248 protocol is more outstanding in flexibility. In contrast. assigned by the MG at the time of their creation. would usually exist only for the duration of their use.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. when a physical Termination 2-1 . II. the H. Compared with the MGCP protocol.248 protocol can support more types of access technologies and support the mobility of terminations. Terminations representing physical entities have a semi-permanent existence. such as RTP flows.248 is the same type of protocol as MeGaCo and completed by the International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) and IETF together. The media stream parameters. Terminations have unique identities (TerminationIDs). and thus is replacing MGCP gradually to grow to be the standard of media gateway control protocols.248 protocol currently. Type of Termination There are two types of terminations: semi-permanent terminations and ephemeral terminations. 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. In addition.248 Chapter 2 H.248 protocol. Ephemeral Terminations are created by means of an Add command.248 2.1 Basic Concepts H.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. as well as modem. used as a media gateway control protocol between a Media Gateway Controller (MGC) and a Media Gateway (MG). the IETF.2 Related Terms I. For example. the International Softswitch Consortium (ISC). the H. A series of descriptors are composed of the properties. When ALL is used in the TerminationID of a command. Properties not included in the base protocol are defined in Packages. for instance. The two wildcards are ALL and CHOOSE. There are a number of common properties for Terminations and properties specific to media streams. Signals are MG generated media streams such as tones and announcements as well as line signals such as hookswitch. VI. Descriptor Descriptor is a syntactic element of the protocol that groups related properties.248 is Added to or Subtracted from a Context. For each media stream. ALL is used to address multiple Terminations at a time. In this way. the TerminationID R13/3/* would match all of them. that an MGC instructs an MG to choose a circuit within a trunk group. The common properties are not specific to media streams and also called the termination state properties. V. These properties are referred to by a 2-2 . respectively. or action by the MG. the occurrence of which can trigger notification messages to the MGC. R13/3/2 and R13/3/3 in a text encoding of the protocol. The properties have unique PropertyIDs. Terminations may be programmed to detect Events. it is taken from or to the null Context. The CHOOSE TerminationID “$” may be used when it is required to refer to one TerminationID but it is uncertain that the Termination exists exactly. Termination function Terminations may have signals applied to them. TerminationID Terminations are referenced by a TerminationID. if there are TerminationIDs of R13/3/1. III. CHOOSE is used to indicate to a media gateway that it must select a Termination satisfying the partially specified Terminations. the effect is identical to repeating the command with each of the matching TerminationIDs.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. the properties of a media flow on the MG can be set by the MGC by including the appropriate descriptor in a command. There are some circumstances where ALL Terminations must be referred to. Statistics may be accumulated on a Termination. there are local properties and properties of the received and transmitted flows. IV. 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. and is referred to as ALL. For example. This allows. which is chosen by the MG. The TerminationID “*” suffices. For instance. A wildcarding mechanism using two types of wildcards can be used with TerminationIDs. Termination Property Terminations have properties. the TerminationID R13/3/$ would match one of them. For instance.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. For properties that are read/write. “Root”. When “Root” is included in a command as a parameter. Similarly. The Context describes the topology and the media mixing and/or switching parameters if more than two Terminations are involved in the association. It contains Terminations that are not associated to any other Termination. all idle lines are represented by Terminations in the null Context. Properties not mentioned in the Modify command retain their prior values.248 name consisting of the PackageName and a PropertyID. There is a special Context called the null Context. Properties may be read-only or read/write. the command can take effect on the entire gateway rather than a Termination within it. the value of its read/write properties by including the appropriate descriptors as parameters to the Add command. the MGC can set their values. VII. a property of a Termination in a Context may have its value changed by the Modify command. Figure 2-1 gives several examples of Termination and Context and is not meant to be an all-inclusive illustration. Properties may also have their values changed when a Termination is moved from one Context to another as a result of a Move command. refers to the entire MG. Properties not mentioned in the Add command retain their prior values. Root Termination A special TerminationID. 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 . VIII. When a Termination is Added to a Context. Context A Context is an association between a number of Terminations. in a decomposed access gateway. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. the mode of a Termination (send/receive/_) describes the flow of the media at the ingress/egress of the media gateway. X. Context ALL 0xFFFFFFFF "*" Refers to all Contexts in the MG. IX. The encodings of special Contexts are shown in Table 2-1. There are three connection values: oneway (indicating the oneway media stream between two Terminations). Context CHOOSE 0xFFFFFFFE "$" Refers to requesting the MG to create a new Context. Signals and Statistics implemented by MGs.248 The maximum number of Terminations in a Context is an MG property. Priority: The priority is used for a Context in order to provide the MG with information about a certain precedence handling for a Context. The MG would preferentially handle a call using an emergency indicator. and can be used in the “Add” and ”Modify” commands. and be unique within the scope of the MG. and isolate (indicating no media stream between two Terminations). Variations in Terminations are accommodated in the protocol by allowing Terminations to have optional Properties. Package Different types of gateways may implement Terminations that have widely differing characteristics. 0 represents the lowest priority and 15 represents the highest priority. Events. In contrast. Table 2-1 Encodings of special Contexts Binary encoding Context Text encoding Meaning Context NULL 0 "_" Refers to Terminations that are not associated to any other Termination in the MG. The topology structure can only be used to describe a Context. To achieve MG/MGC interoperability. 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. Topology: The topology of a Context describes the flow of media between the Terminations within a Context. Media gateways that support multipoint conferences might allow three or more Terminations per Context. Media gateways that offer only point-to-point connectivity might allow at most two Terminations per Context. such options are grouped 2-4 . bothway (indicating the bothway media stream between two Terminations). which should be 32-bit integers specified by the MG. Context attribute The attributes of Contexts are: ContextID: Context identifier. Table 2-2 lists some packages commonly used. and Procedures. An MGC can audit a Termination to determine which Packages it realizes. Network Package nt This package defines properties of network terminations independent of network type. MGs are expected to be provisioned with the characteristics of appropriate tones for the country in which the MG is located. The continuity test includes provision of either a loopback or transceiver functionality. Analog Line Supervision Package al This package defines events and signals for an analog line. “end tone detected” and “long tone detected” events. Generally. This package extends the possible values of tone id in the “start tone detected”. Signals and Statistics defined in Packages. Tonegen This package defines signals to generate audio tones. Tones are selected by name (tone id). Root This package defines Gateway wide properties. 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. as well as parameters to them. 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. Call Progress Tones Detection Package cd This package defines the basic all progress detection tones. Signals. Base Package Root Tone Generator Package 2-5 . Definition of a Package is composed of Properties. representing “interdigit” time delay. and a tone id to be used with playtones. This package extends the possible values of tone id in the “start tone detected”. Statistics. are referenced by identifiers (IDs). Table 2-2 Basic packages Package Generic Package ID Description G Generic package for commonly encountered items. 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. This package does not specify parameter values. A tone id should be kept consistent with any tone generation for the same tone. DTMF detection Package dd This package defines the basic DTMF tones detection.248 into Packages.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. ind. Properties. Basic Continuity Package ct This package defines events and signals for continuity test. It is intended to be extendable. and a Termination realizes a set of such Packages. tones are defined as an individual signal with a parameter. “end tone detected” and “long tone detected” events. Events. The general formats are PackageID/PropertyID.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). 7 Message Transfer Part 3-User Adaptation Layer (M3UA) borne over the IP network.1.3 Structure of Protocol Stack H. and Message Transfer Part Broadband (MTP3-B) borne over Asynchronous Transfer Mode (ATM). 2-6 . and Signals commonly used in Packages. and PackageID/Signal. 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. Stream Control Transmission Protocol (SCTP) and Signaling System No.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Package Chapter 2 H. such as Transmission Control Protocol (TCP). the messages can be transported over other transport protocols. Circuit Table 2-3 lists some Properties.248 messages are transported over UDP/IP. Events. PackageID/EventID. Table 2-3 Examples of PropertyIDs. TDM Package tdmc This package is used to support TDM circuit terminations. In addition. H.248 MGC functionality to control Integrated Services Digital Network User Part (ISUP) trunks in the trunk gateways.248 protocol assumes that the transport network under it is not reliable.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). as shown in Figure 2-2.2 48 IAD TMG8010 E-phone E-phone Figure 2-3 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. SoftX3000 . 2. 2-7 . SoftX3000 provides the H.4 Implementation in SoftX3000 As shown in Figure 2-3. H.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. MG CP/ H.248 protocol stack in SoftX3000 The H. H. SoftX3000 will ensure that a matching capability set between the two MGs will be used to establish the call.248 implementation in SoftX3000 SoftX3000 communicates with the trunk gateways through the H.248 protocol in SoftX3000 may be UDP/TCP/SCTP borne over IP and MTP3-B borne over ATM.248 UDP/TCP/SCTP IP MAC Figure 2-2 H.1.248 MG will be configured.323 IP/ H S / P MGC SoftPhone SS7 PSTN E1 CP MG MRS IP Core n tra Sig 8 24 H.248 The transport layer of the H. thus the state and reliability of a transaction is achieved by the protocol itself.248 protocol. 248 commands Command name Command code Description Add ADD MGC→MG.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. Command The H. The Subtract command on the last Termination in a Context deletes the Context. 2-8 . Modify MOD MGC→MG. If no ContextID is specified. a Context will be first generated and then a Termination is added into it.248 protocol z Supporting creation of ephemeral Terminations z Supporting destruction of ephemeral Terminations z Supporting modification of RTP parameters on ephemeral Terminations 2.1 Message Types I.2 Protocol Messages 2. Move MOV MGC→MG. The Subtract command disconnects a Termination from its Context and returns statistics on the Termination’s participation in the Context. and ServiceChange may be sent by either entity. H. The Modify command modifies the properties. Contexts and Terminations.248 protocol z Supporting reservation of trunks on TMG z Supporting release of trunks on TMG z Supporting Hairpin connection of trunks on TMG z Supporting modification of trunk parameters z Applying tones to trunks z 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. events and signals of a Termination. Most commands are for the specific use of the MGC as command initiator in controlling MGs as command responders. The Move command atomically moves a Termination to another Context.2. The Add command adds a Termination to a Context. Subtract SUB MGC→MG. Commands provide for complete control of the properties of Contexts and Terminations.248 protocol defines eight commands for manipulating the logical entities of the protocol connection model.248 commands and meanings are shown in Table 2-4. The exceptions are the Notify and ServiceChange commands: Notify is sent from MG to MGC. Table 2-4 H. “Pending" indicates the command is actively being processed but has not been completed. events. one ore more commands are encapsulated in a message. and BER rules defined in X. MGs may support one of or both formats. In the H. specifications defined in ITU-T X. 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. The AuditValue command returns the current state of properties. The structure of a response is basically the same as that of a command. “Reply” indicates the execution of the command has been completed and returns information about the execution success or failure. Response All H. ServiceChange is also used by the MG to announce its availability to an MGC (registration). namely Reply and Pending. RFC 2234 ABNF specifications are followed. Any H. in the case of text format. SVC_CHG MGC↔MG or MG→MGC. In the case of binary codes.2. It is used to prevent the sender from assuming the TransactionRequest was lost where the command will take some time to complete.248 protocol. Command format 1) Encapsulation format for command A message is an information unit sent or received by the H. The AuditCapabilities command returns a collection of termination capabilities. MGCs should support both encoding formats.690 for encoding. Notify NTFY MG→MGC. ServiceChange II.680 (ASN. The MGC may announce a handover to the MG by sending it a ServiceChange command.2 Message Structure I. 2-9 .248 message shares the same structure as shown in Figure 2-4. signals and statistics of Terminations. A message may be encoded in a binary format or in a text format. AuditCapabilities AUD_CAP MGC→MG. 2.1) are used for description.248 commands are acknowledged. There are two types of responses. The Notify command allows the MG to inform the MGC of the occurrence of events in the MG.248 protocol.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Command name Chapter 2 H.248 Command code Description AuditValue AUD_VAL MGC→MG. and to notify the MGC of impending or completed restart of the MG. TransactionID correlates a command with its response. 248 message structure z Message Messages start with a header which is followed by several transactions.. Command Descriptor Figure 2-4 H.. 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. and responses are divided into two types: TransactionReply and TransactionPending. The transactions in a message are treated independently. domain name or device name. Versions consist of one or two digits.248 Megaco/H.. Transaction Req or Reply ... There is one Transaction per request invocation. Command } }) z Action 2-10 .. Domain name is a suggested default. .. beginning with version 1 for the present version of the protocol. refer to the description later in this chapter. A transaction contains one or more actions and each action includes one or more commands related to a single Context.248 message Header Transaction Transaction Req or Reply Req or Reply Trans Hdr Ctx Hdr Action Ctx Properties Trans Hdr . Transactions include requests and responses... Action Command Descriptor . z Transaction A message contains one or more transactions. ContextID {Command .. There is no order implied... Command}. Commands are encapsulated in transaction requests which are described here.... The Version Number identifies the version of the protocol the message conforms to. For the structure of transaction responses.. The structure is as follows: TransactionRequest(TransactionId { ContextID {Command ..Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. .. An action begins with the Context header (CtxHdr) in which ContextID is contained for identifying the Context this action corresponds to.. Message TransactionID1 ContextID1 Command CMD1 Descriptor Des-1 Des-n .. The H. ContextID is assigned by the MG and is unique within the scope of the MG. an empty descriptor is represented by its name unaccompanied by any list...248 message mechanism is shown in Figure 2-5. They control the Context and Termination attributes including specifying the topology structure of the Context and specifying the event reported by the Termination. In the H. CtxHdr is followed by several commands. Descriptors may be returned as output from a command. what signals and actions can be imposed on the Termination. the text format of descriptors is as follows: DescriptorName=<someID> { parm = value.. In an action.. In any such return of descriptor contents. command parameters are grouped into “Descriptors”..CMDn . A command is composed of the command header (CMDHdr) and command parameters. parm = value . In general. The MGC shall use the ContextID in all subsequent transactions relating to that Context. Actions are identified by a ContextID.248 protocol. Many commands share common descriptors.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H..248 message. ContextIDn TransactionIDn Figure 2-5 Message mechanism 2) Descriptor The parameters to a command are termed Descriptors. and these commands are related to the Context identified by the ContextID.248 Actions are related to Contexts. A descriptor consists of a name and a list of items. } 2-11 . z Command Commands are the major contents in an H. commands should be processed in order. for example.. Some items may have values. A stream is identified by a StreamID. Local. 2-12 .223. and one or more Stream descriptors each of which describes a single media stream. Those commonly used descriptors are described below.18. The state “in service” indicates that a Termination can be used or is being used for normal traffic. The ServiceStates (SI) property describes the overall state of the Termination. The multiplex (Mux) descriptor associates the media and the bearers. and possible extensions. By default.91. Synchronous ISDN. or Remote descriptor may be included in the Media descriptor without an enclosing Stream descriptor. a LocalControl. H. V. These parameters are structured into two descriptors. V32bis. which specifies the properties of a Termination that are not stream dependent.32. “in service” is the default state.22. The state “out of service” indicates that the Termination cannot be used for traffic. The “test” state indicates that the Termination is being tested.221{ MyT3/1/2. As a convenience. and Remote.221. The descriptor includes the following modem types: V. no Modem descriptor is present in a Termination. V. a Termination State descriptor. V.MyT3/3/6. and allows for extensions. Definition of the Mux descriptor is composed of the multiplex type and a set of TerminationIDs representing the multiplexed inputs.226. V.248 protocol defines 19 types of descriptors. H. The descriptor includes the multiplex type: H. Local.MyT3/21/22} z Media (M) descriptor The Media descriptor specifies the parameters for all the media streams. V. V. In this case. z Mux (MX) descriptor In multimedia calls.248 The H. The relationship between these descriptors is like this: z Media Descriptor z TerminationStateDescriptor z Stream Descriptor z LocalControl Descriptor z Local Descriptor z Remote Descriptor z Termination State (TS) descriptor The Termination State descriptor contains the ServiceStates property.22bis. a number of media streams are carried on a (possibly different) number of bearers.90.76. or “in service” (IV). namely LocalControl. the EventBufferControl property and properties of a Termination (defined in Packages) that are not stream specific. “out of service” (OS). There are three types of Stream descriptors. A Termination can be in one of the following states: “test” (TE). the StreamID is assumed to be 1. For example.MyT3/2/3. Mux=H.34. z Modem (MD) descriptor The Modem descriptor specifies the modem type and other parameters.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. V. and they are assigned by the MGC. The Stream descriptor includes a StreamID which identifies the stream. z LocalControl (O) descriptor The LocalControl descriptor contains the Mode (MO) descriptor.248 The EventBufferControl (EB) property specifies whether events are buffered following detection of an event in the Events descriptor.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. 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. inactive (IN) and loop-back (LB). Within a Context. or processed immediately. StreamID is a means by which to indicate which media flows are interconnected: streams with the same StreamID are connected. The MG includes these descriptors in its response to indicate what it is actually prepared to support. the ReserveGroup (RG) and ReserveValue (RV) properties and properties of a Termination (defined in Packages) that are stream specific. 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. The allowed values for the Mode property are send-only (SO). receive-only (RC). and Remote. and the Remote descriptor refers to the media sent by the MG. Streams are created by specifying a new StreamID on one of the Terminations in a Context. for example. 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 Local and Remote descriptors consist of session descriptions as defined in SDP (RFC 2327). The Boolean-valued Reserve properties. Signals and Events are not affected by mode. The RequestIdentifier is used to correlate the request 2-13 . StreamIDs are of local significance between the MGC and the MG. send/receive (SR). z Stream (ST) descriptor A Stream descriptor specifies the parameters of a single bi-directional stream. ReserveValue and ReserveGroup. namely LocalControl. There are three types of Stream descriptors. a stream set to mode=sendonly does not pass received media into the Context. of a Termination indicate what the MG is expected to do when it receives a local and/or remote descriptor. “Send” and “receive” are with respect to the exterior of the Context. Local. z Events (E) descriptor The Events descriptor contains a RequestIdentifier and a list of events that the MG is requested to detect and report. When text encoding the protocol. z Local (L) and Remote (R) descriptors The Local descriptor refers to the media received by the MG. so that. optional actions. no timeout value is needed. that the MG is requested to detect and buffer when EventBufferControl equals LockStep. Signals. There are three types of signals: on/off: The signal lasts until it is turned off. Each event in the descriptor contains the Event name. al/on indicates the onhook event in the Analog Line Supervision Packages. Requested events include. SG{SL=0{cg/dt}}. Possible items are: Modem. 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. Media. DigitMap. For example. z Audit (AT) descriptor An Audit command (AuditValue and AuditCapabilities commands) specifies what information is to be audited. for example. and on-hook and off-hook transitions. ObservedEvents. z EventBuffer (EB) descriptor The EventBuffer descriptor contains a list of events. fax tones. and “cg/dt” indicates the dial tone signal in the Call Progress Tones Generator Packages. Signals shall be named with a Package name (in which the signal is defined) and a SignalID in the format of PackageName/SignalID.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. For example. Statistics. A SignalsDescriptor may contain zero signals and sequential signal lists. 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. Events can have parameters which are defined and named in the Package. Packages. Mux. established connections are not yet affected. and EventBuffer. Events. hookflash. A SignalsDescriptor contains a number of signals and/or sequential signal lists. and optional parameters. In which. The Event name consists of a Package Name (where the event is defined) and an EventID in the format of PackageName/EventID. 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. with their parameters if any. “SL” is the abbreviation of SignalList. timeout: The signal lasts until it is turned off or a specific period of time elapses.248 with the notifications that it may trigger. but the 2-14 . 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. The actions parameter indicates one or more possible actions to be taken at the occurrence of an event. this reason indicates that the MGC is going out of service and a new MGC association must be established. Forced: Indicates that the specified Termination(s) were taken abruptly out of service and any established connections associated with them were lost. Disconnected: Always applied with the Root TerminationID.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. optionally. indicates that the MG lost communication with the MGC. It consists of an alphanumeric token (IANA registered) and. but it was subsequently restored. Sent from the MG to the MGC. the MGC may wish to use the Audit command to resynchronize its state with the MG’s. Handoff: Sent from the MGC to the MG. The ServiceChangeReason (RE) parameter specifies the reason why the ServiceChange has occurred or will occur. Restart: Indicates that service will be restored on the specified Terminations after expiration of the ServiceChangeDelay. Since the MG state may have changed. 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 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 . 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. an explanatory string.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. In this case.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. The Extension parameter may contain any value whose meaning is mutually understood by the MG and the MGC.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. 2-16 . The collection of digits according to a DigitMap may be protected by three timers. The start timer is started at the beginning of every digit map use. The timers are configurable parameters to a DigitMap. The optional ServiceChangeDelay parameter is expressed in seconds. short timer (S). It can be used by the responder to determine how its notion of time differs from that of its correspondent. The ServiceChangeProfile includes the version of the profile supported. The optional ServiceChangeProfile parameter specifies the profile. The optional ServiceChangeVersion parameter contains the protocol version and is used if protocol version negotiation occurs. but can be overridden. The start timer (T) is used prior to any digits having been dialed. that is. IP port number for IP networks. The optional TimeStamp parameter specifies the actual time as kept by the sender. The MGC specified in a ServiceChangeMgcId. the ServiceChangeMgcId is the new MGC that will take over form the current MGC. and long timer (L). if provided. of the protocol supported. the MG shall reissue the ServiceChange command to the new MGC. for example. The DigitMap descriptor contains a DigitMap name and the DigitMap to be assigned. describing the MGC that should preferably be contacted for further service by the MG. On a HandOff message from the MGC to the MG. to be used for subsequent communications. a start timer (T). shall be contacted before any further alternate MGCs. if any. The ServiceChangeMGCId parameter can be returned by the MGC to the MG. 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. T2. 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. If the digit string has matched one of the patterns in a digit map. nor vice versa. but it is possible that more digits could be received which would cause a match with a different pattern. isolate) means that the Terminations matching T2 do not receive media from the Terminations matching T1. earlier in this manual. the Packages descriptor returns a list of Packages realized by the Termination. Used with the AuditValue command. the MG must apply the short timer (S). association). possibly using the ALL or CHOOSE wildcard. By default. for example. then instead of reporting the match immediately. The Topology descriptor is optional to implement. refer to MGCP protocol. For more information on digit map. (T1. T2. z ObservedEvents (OE) descriptor ObservedEvents is supplied with the Notify command to inform the MGC of which event(s) were detected. the event(s) detected and the detection time(s). The default topology of a Context is that each Termination’s transmission is received by all other Terminations. the ObservedEvents descriptor returns events in the event buffer which have not been notified. T2. T1 and T2 specify Terminations within the Context. 8 seconds. statistics are reported when the Termination is Subtracted from the Context. 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. A Topology descriptor consists of a sequence of triples of the form (T1. 16 seconds. for example. oneway) means that the Terminations that match T2 receive media from the Terminations matching T1. Detection times are reported with a precision of hundredths of a second.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. z Packages (PG) descriptor Used only with the AuditValue command. and wait for more digits. 2-17 . Statistics may also be returned from the AuditValue command.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. then the interdigit timer value should be set to a long (L) duration. ObservedEvents contains the RequestIdentifier of the EventsDescriptor that triggered the notification. The association specifies how media flows between these two Terminations are follows: (T1. or any Add/Move/Modify command using the Audit descriptor. but not vice versa. T2. T2 receives media flow from T3). Oneway 3 4 5 A oneway connection from T3 to T2 (that is. T1 and T3 remain bothway connected. T3. Oneway A oneway connection from T2 to T3. Isolate 2 Removes the connection between T1 and T2. all Terminations have a bothway connection to all other Terminations.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. T3 Bothway T2 is bothway connected to T3. A bothway connection between T1 and T3. Context 1 Context 1 T2 Context 1 T2 T2 T1 T3 T1 T1 T3 T3 1. T2. This results in the same as 2.T3 Bothway T1 T3 6. T3 One way T1 T2 T3 5. 2-18 . T2. Table 2-6 Topology description Topology Description No topology descriptors 1 When no topology descriptors are included. T1. T1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. T3. T1 and T2 have a bothway connection to T3. and vice versa. T2. T2. T2. No topology descriptors 2. T3 has a bothway connection with both T1 and T2. T2 Isolate 3. T1.248 (T1. Figure 2-6 shows some topology examples. T3. T2 One way Context 1 Context 1 Context 1 T2 T2 T1 T3 4. bothway) means that the Terminations matching T2 receive media from the Terminations matching T1. T2. Bothway 6 (T2.) All Terminations have a bothway connection to all other Terminations.248 Topology Description T1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. T2. T3 bothway and T1. T3 bothway may be implied or explicit. 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 . the reply of the command shall contain an Error descriptor. The Notify command may also contain an Error descriptor. Sending the explanatory string is optional. Errors consist of an IANA registered error code and an explanatory string. Error (ER) descriptor z If a Transaction execution encounters an error. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. Signal. Event.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. and Statistics to be audited do not exist 2-20 . AuditDescriptor]) z Notify Notify (TerminationID.AuditDescriptor]) z Move MOV (TerminationID[.AuditDescriptor]) z AuditValue AuditValue (TerminationID[.ErrorDescriptor]) z ServiceChange ServiceChange (TerminationID.{ MF=A0{ E=369099784{ dd/ce{DigitMap=dmap1}.AuditDescriptor]) z AuditCapabilities AuditCapabilities (TerminationID[. MEGACO/1 [191.EventsDescript or][.MediaDescriptor][.248 command. 2-21 .ModemDescriptor][. z ADD ADD (TerminationID[.MuxDescriptor][.ModemDescriptor][.EventsDescript or][.MediaDescriptor][.EventBufferDescriptor][.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.EventsDescript or][.ServiceChangeDescriptor) 4) Command sample The following example is a text description of H.DigitMapDescriptor][.ModemDescriptor][.SignalsDescriptor][.150.EventBufferDescriptor][. al/*}.248 Error code 581 3) Meaning Does Not Exist Command expressions What are within the parenthesis preceded by the command name are input parameters.MediaDescriptor][.MuxDescriptor][.169.EventBufferDescriptor][.SignalsDescriptor][.DigitMapDescriptor][.AuditDescriptor]) z Subtract SUB (TerminationID[.DigitMapDescriptor][.170]:2944 T=372794021{ C= .MuxDescriptor][.AuditDescriptor]) z Modify MOD (TerminationID[. Those enclosed by […] are optional.ObservedEventsDescriptor[.SignalsDescriptor][. The 9th line: The dial plan “dmap1”.169. The MID is the identifier of the sender of this message. The 7th line: The Signals descriptor. The 5th line: The Events descriptor with the RequestIdentifier “369099784”.170]:2944. The 2nd line: The TransactionID is 372794021. refer to the preceding section. E or F are reported after an expiration of the long timer. “[2-9]xxxxxx” indicates that user can dial any 7-digit number started with an integer in the range of 2 to 9. Every transaction should have its Reply. “9xxxx” indicates any 5-digit number started with 9.150.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. events and signals of the Termination A0. “1[0124-9]x” indicates any 3-digit number started with 1 which is followed by a decimal integer except 3. The 3rd line: In this case.F|[0-9EF]. “E” is the letter “E”. we will detail two types of transactions of responses.L)}}}} The 1st line: The MeGaCo protocol version is 1. Transactions include requests and responses. “0xxxxxxxxx” indicates any 10-digit number started with 0. II. The other event is detection of all events defined in the Analog Line Supervision Packages (al). The RequestIdentifier is used to correlate the request with the notifications that it may trigger. The 8th line: The DigitMap descriptor. DM=dmap1{ ([2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|x. The MGC delivers the dial plan (dmap1) to the termination A0. z Transaction Reply Transaction Reply is a response of the transaction receiver to the Transaction Request. In this case. In the dial plan. “13xxxxxxxxx” indicates any 11-digit number started with 13. used to correlate the request with the responses that it will trigger. The 6th line: The MGC requests the MG to detect two events that will happen in the termination A0. The 4th line: The Modify command. and responses are divided into two types: TransactionReply and TransactionPending. the encapsulated Context in this Transaction is null. A TransactionRequest stops being executed 2-22 .248 SG{cg/dt}. Response format 1) Encapsulation format for response The same as the encapsulation format for command. Here. used to modify the properties. One event is digit collection according to the dial plan (dmap1) specified by the digit map. it is the IP address of and port [191. “[0-9EF]. For the encapsulation command of the Transaction Request.L” indicates that any length of digits started with 0 ~ 9. It indicates that the MGC requests the MG to send the dial tone to the termination A0. EventsDescript or][. but has not been completed.MediaDescriptor][. It is used to prevent the sender from assuming the TransactionRequest was lost where the command will take some time to complete.SignalsDescriptor][. The structure of Transaction Reply is as follows: TransactionReply(TransactionID { ContextID { Response .EventsDescript 2-23 .MuxDescriptor][.MediaDescriptor][. refer to the description of command descriptors.. 3) Response expressions What are within the parenthesis preceded by the command name are response parameter values.. A Transaction Pending indicates that the transaction is actively being processed.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.MuxDescriptor][.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.PackagesDescriptor]) z Modify MOD (TerminationID[.SignalsDescriptor][. possibly preceded by a number of TransactionPending messages. z ADD ADD (TerminationID[. Those enclosed by […] are optional.StatisticsDescriptor][.Response }. The structure of Transaction Pending is as follows: TransactionPending (TransactionID { } ) Transactions are presented as TransactionRequests...MediaDescriptor][.PackagesDescriptor]) z Subtract SUB (TerminationID[.ModemDescriptor][.MuxDescriptor][.ObservedEventsDescriptor][.EventsDescript or][.EventBuffer Descriptor][.ModemDescriptor][..DigitMapDescriptor][.EventBuffer Descriptor][. .Response } }) z Transaction Pending The receiver invokes the Transaction Pending.. earlier in this chapter. Corresponding response to a TransactionRequest is received in a single reply.StatisticsDescriptor][.ObservedEventsDescriptor][.ModemDescriptor][. ContextID { Response . 2) Response descriptors For response descriptors.DigitMapDescriptor][. The MID is the identifier of the sender of this message. used to correlate the command with the response.ObservedEventsDescriptor][. The TransactionID of the response is 372794021.EventsDescript or][.169.Statistics Descriptor]) z ServiceChange ServiceChange (TerminationID[.172]:2944.MediaDescriptor][.169.150.SignalsDescriptor][.EventBuffer Descriptor][.ModemDescriptor][. MEGACO/1 [191.PackagesDescriptor]) z AuditValue AuditValue (TerminationID[.ModemDescriptor][.StatisticsDescriptor][.MediaDescriptor][.ModemDescriptor][.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.172]:2944 P=372794021{ C= .EventBuffer Descriptor][.EventBuffer Descriptor][.150.ObservedEventsDescriptor][.PackagesDescriptor]) z Move MOV (TerminationID[. The 4th line: Acknowledgement that the Termination A0 has received the TransactionRequest from the MGC.EventsDescript or][.MediaDescriptor][.StatisticsDescriptor][. it is the IP address of and port [191.ObservedEventsDescriptor][.PackagesDescriptor]) z AuditCapabilities AuditCapabilities (TerminationID[. indicating that the MG is executing it.SignalsDescriptor][.EventsDescript or][.ServiceChangeDescriptor]) 4) Response sample The following is a text encoding sample of a transaction response.DigitMapDescriptor][.DigitMapDescriptor][.MuxDescriptor][.MuxDescriptor][. which is the same as the TransactionID described in the command sample.{ MF=A0}} The 1st line: The MeGaCo protocol version is 1.StatisticsDescriptor][.248 or][. 2-24 .ObservedEventsDescriptor][.MuxDescriptor][.SignalsDescriptor][. In this case.DigitMapDescriptor][. The 3rd line: Here the Context is null.SignalsDescriptor][. The 2nd line: TransactionID.EventBufferDescriptor][. The 3rd line: Here the Context is null. If the protocol stack version implemented in the opposite end is later or earlier than that. indicating that the command refers to the entire gateway. The TerminationID is ROOT.150. The registration procedure is illustrated in Figure 2-7.172]:2944. the MG responds with Error 406 Version Not Supported.169. The 4th line: The ServiceChange command.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. The 5th line: The encapsulated ServiceChange descriptor in the ServiceChange command.RE=902}}}} The 1st line: The MeGaCo protocol. The protocol version is 1. 2) Event 2: On receipt of the registration message from the MG.{ SC=ROOT{ SV{ MT=RS. The following is the text description of the SVC_CHG_REQ command.248 2. The IP address and port of the MG is [191.248 MG must register with SoftX3000 before providing services. The 6th line: The parameters contained in the ServiceChange descriptor. indicating a registration failure.3 Basic Control Procedures 2. MG SoftX3000 SVC_CHG_REQ SVC_CHG_REPLY Figure 2-7 MG registration procedure 1) Event 1: The H.1 Gateway Registration Procedure An H.0.3. The 2nd line: The TransactionID is “3”. The following is the text description of the SVC_CHG_REPLY. Currently. 2-25 . the MGC sends a reply to the MG. the supported protocol stack version is 1.172]:2944 T=3{ C= .169. indicating the ServiceChange method is Restart and the reason is Warm Boot.248 MG sends a SVC_CHG_REQ message to SoftX3000 for registration. The command is sent from the MG to the MGC.150. MEGACO/1 [191. The following is the text description of the SVC_CHG_REQ command.172]:2944 T= 9998 {C= .150. The IP address and port of the MG is [191. 2.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. indicating that the MGC has received the registration transaction from the MG and responds to the MG that the registration is completed successfully. 2-26 . The ServiceChange command refers to the entire gateway.150. The IP address and port of the MGC is [191. The ServiceChangeMethod in the command is set to Graceful or Forced.170]:2944 P=3{C= . The command is sent from the MG to the MGC. RE = 905}}}} The 1st line: The MeGaCo protocol. The 4th line: The ServiceChange descriptor. and the Context is null. The 3rd line: The ServiceChange command. The command is sent from the MGC to the MG.169.2 Gateway Cancellation Procedure To take out of service.248 MG needs to cancel the registration to SoftX3000.3. The protocol version is 1.172]:2944. an H.169.{ SC = ROOT { SV { MT= FO. The 2nd line: The TransactionID is “3”.{SC=ROOT{SV{}}}} The 1st line: The MeGaCo protocol.150. indicating that the command refers to the entire gateway. 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. MEGACO/1 191.170]:2944. The 2nd line: The TransactionID is “9998”. The TerminationID is ROOT.150.169. The cancellation procedure is illustrated in Figure 2-8. and the encapsulated Context in the Transaction is null.169.248 MEGACO/1 [191. The protocol version is 1. 169. It is assumed that three semi-permanent Terminations including A0. 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 SVC_CHG_REPLY.169.170]:2944. SG{}}}} 2-27 . A1 and A3 are configured on the MG. MEGACO/1 [191. The IP address and port of the MGC is [191.248 The 5th line: The parameters contained in the ServiceChange descriptor. The following is the text description of the MOD_REQ command. 2.{ MF=A0{ E=369099777{al/*}.{SC=ROOT{ER=505}}} The 1st line: The MeGaCo protocol. The protocol version is 1. the Termination can receive or originate calls. 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. with the Error 505 Command Received Before Restart Response. indicating that the ServiceChange method is Forced and the reason is Termination taken out of service. and the Context is null.170]:2944 P=9998{C= . Here we illustrate the specific message interaction by using the Termination A0. 2) Event 2: SoftX3000 responds with a message.169. MEGACO/1 [191. The 2nd line: The TransactionID is “9998”.150. At this time.3. The command is sent from the MGC to the MG.150. MG SoftX3000 MOD_REQ MOD_REPLY Figure 2-9 MG Termination initialization procedure 1) Event 1: After a successful registration.3 Gateway Initialization Procedure After the MG completes a successful registration procedure.150. The MGC will respectively send an MOD_REQ command to the three Terminations for initialization purposes. The ServiceChange command refers to the entire gateway.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.170]:2944 T=372794419{C= . which is connected to the UserB.3. indicating the MGC requires the MG to stop any signal played currently.169. which is connected to the UserA. z The IP address and port of the MG is 191.169.61:2944. The 3rd line: The Modify command. the MG responds with a reply.122:2944. 2) Event 2: On receipt of the Modify command. The protocol version is 1.150.{MF=A0}} 2.4 Successful Termination Call Procedure A call setup and release procedure between two Terminations in the same MG is illustrated in Figure 2-10. Here the signal is null.248 The 1st line: The MeGaCo protocol. 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.172]:2944 P=372794419{ C= . it is assumed that z The physical TerminationID of the Termination1 is A0. to modify the properties of the Termination A0. The following is the text description of the MOD_REPLY. The call setup and release procedure between two Terminations in different MGs is basically the same and thus not detailed in this chapter. MEGACO/1 [191. z The IP address and port of SoftX3000 is 191. The IP address and port of the MGC is [191. The 2nd line: The TransactionID is “372794419”. and the calling party hooks on first.150. In the procedure.150. The command is sent from the MGC to the MG.169.170]:2944. 2-28 . z The physical TerminationID of the Termination2 is A1. The 5th line: The Signals descriptor. and a null Context is encapsulated in the Transaction. z The UserA makes a call to the UserB.200.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.169. 150. The command is sent from the MG to the MGC. z NTFY_REQ text description MEGACO/1 [191. The protocol version is 1. which refers to the Termination A0. The IP address and port of the MG is [191.122]:2944 T=883{C= .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. SoftX3000 acknowledges the receipt of the off-hook event in a reply message.{ N=A0{ OE=369109250{al/of}}}} The 1st line: The MeGaCo protocol. The 2nd line: The TransactionID is “883”.169.122]:2944.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System UserA Termination1 Off-hook Chapter 2 H. 2-29 .150.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 3rd line: The Notify command. the MG sends an NTFY_REQ command to notify SoftX3000 of the off-hook event. and the encapsulated Context in the Transaction is null.169. z MOD_REQ text description MEGACO/1 [191.{ N=A0{ OE=369109251{ 2-30 .248 The 4th line: The ObservedEvents descriptor. z NTFY_REPLY text description MEGACO/1 [191.122]:2944 P=372771555{ C= .F|[0-9EF]. SoftX3000 acknowledges the receipt of the NTFY_REQ.150.150. refer to the response sample. The Termination A0 collects the dialed digits and tries to match the digit map. z MOD_REPLY text description MEGACO/1 [191. with an NTFY_REPLY.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.200. In addition. DM=dmap1{ ([2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|x.{ MF=A0}} For details of the parameters. earlier in this chapter.61]:2944 P=883{C= . z NTFY_REQ text description MEGACO/1 [191. the TerminationA resident MG detects the off-hook event and reports the event to SoftX3000. sent by the A0.{ MF=A0{ E=369109251{ dd/ce{DigitMap=dmap1}. earlier in this chapter. SoftX3000 notifies the Termination A0 of the digit map (dmap1). which is the same as the RequestIdentifier contained in the request that triggers NTFY_REQ.169. In this case.122]:2944 T=884{C= .200. 3) Event 3: The UserA dials a number.{ N=A0}} 2) Event 2: On receipt of the off-hook event. the Termination A0 sends an NTFY_REQ command to SoftX3000. 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.169. In the case of a successful match. The RequestIdentifier is 369109250. al/*}.61]:2944 T=372771555{ C= .L)}}}} For details of the parameters. refer to the command sample. SG{cg/dt}.169. The Termination A0 sends an MOD_REPLY to SoftX3000 as the response of the MOD_REQ and sends the dial tone to the UserA.169. based on which digits will be collected. PM: Partial match. SoftX3000 is designed to create a Context after the calling party dials the called number. indicates what the UserA dials is 6540100. based either on the default timing rules given above or on explicit timing specified in one or more alternative event sequences.122]:2944. The DigitMap Termination Method (Meth) has three possible values: UM: Unambiguous match. a completion event is generated indicating an unambiguous match. even dials a number. It is the same as the RequestIdentifier of the preceding MOD_REQ.150. The MG responds with an ADD_REPLY with a new allocated connection descriptor and a new RTP termination descriptor. The 4th line: The ObservedEvents descriptor.169. indicating this notification is triggered by that MOD_REQ command. which refers to the Termination A0.{ 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. At each step. a timeout completion with partial match is reported. The DigitString (ds). The IP address and port of the MG is [191. The 2nd line: The TransactionID is 884. This event has two parameters: Termination Method (Meth) and DigitString (ds). The 5th line: The TimeStamp for reporting the DigitMap event. the dialed number is found inexistent or other reasons. If exactly one candidate alternative event sequence remains and it has been fully matched. The 3rd line: The Notify command.M. “20030429T06132700” indicates 06:13:27 A.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. The RequestIdentifier is 369109251. a timer is set to wait for the next event. The 6th line: What is observed by the Termination A0 is a DigitMap Completion event in the DTMF detection package. z ADD_REQ text description 2-31 .ds=6540100}}}}} The 1st line: The command is sent by the MG to the MGC. a timeout completion with full match is reported.169.248 20030429T06132700: dd/ce {Meth=UM. to avoid wasting resources in the event that the calling party hooks off but does not dial a number or.200. If the timer expires and a member of the candidate set of alternative event sequences is fully satisfied. the encapsulated Context in this Transaction is null.61]:2944 P=884{C= . FM: Full match. If the timer expires and part or none of any candidate alternative event sequence is satisfied. on April 29th 2003. z NTFY_REPLY text description MEGACO/1 [191. in this case. In this case. 169. The new RTP Termination is ephemeral. The 7th line: The Signals descriptor. The 2nd line: The TransactionID is “369363687”. used to add a RTP Termination to the new Context. “m=audio $ RTP/AVP 8” indicates the media description of the new RTP Termination suggested by the MGC. “v=0” indicates that the SDP protocol version is 0. “audio” indicates that the type of media for the RTP Termination is audio.RG=OFF}}. Here the signal is null. “OFF” ReserveGroup property. “$” is used. “RTP/AVP” is the transport layer protocol.200.200. indicates that the RTP Termination has an “inactive” mode property. such as on-hook events. and the local IP address is unknown currently. the type of address for the Context is IP4. The MGC requests the MG to detect all events in the Analog Line Supervision Packages that will happen. a great number of media 2-32 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. A=${ M{O{MO=IN.RV=OFF. E=369109253{al/*}. The 8th line: The ADD command. the network indicator of the Context is Internet. “$” indicates that the media port number for the RTP Termination is unknown currently.61]:2944. in this case. For IP4. indicating the MGC requires the MG to stop any signal played currently. L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8}}}}} The 1st line: The command is sent by the MGC to the MG. “nt/jit=40” indicates that the maximum jitter buffer in the Network Packages is 40 milliseconds. Its value is associated with the type of address in the “c” line. and “OFF” ReserveValue property. that is. The 3rd line: “$” indicates that the MG is requested to create a new Context. “$” is used because the Context is not determined currently. and “OFF” ReserveValue property.RG=OFF. in this case. “c=IN IP4 $” indicates the Context information of the RTP Termination. The LocalControl (O) descriptor.RV=OFF. The 5th line: The Media descriptor. indicates that the Termination A0 has a “send/receive” mode property.61]:2944 T=369363687{ C=${ A=A0{ M{O{MO=SR. “OFF” ReserveGroup property. SG{}}. used to add the Termination A0 to the new Context. The IP address and port of the MGC is [191. The RequestIdentifier is 369109253. The 4th line: The ADD command. The 9th line: The Media descriptor.248 MEGACO/1 [191. The 10th line: The MGC suggests a set of Local descriptor parameters for the new RTP Termination.nt/jit=40}. The LocalControl (O) descriptor. The 7th line: The Events descriptor. Because the descriptor for the RTP Termination is not determined yet.169. and sets the Termination A100000035 to be in the inactive mode.169. and fills the local IP address to be 191. 2-33 . the MGC sends an ADD_REQ. The MG responds with an ADD_REPLY with a new allocated connection descriptor “287” and a new RTP termination descriptor “A100000035”. 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.729.122]:2944 P=369363687{C=286{ A=A0.248 protocol is as follows: G. The IP address and port of the MG is [191. “8” represents the type of media payload defined in the RTP audio/video application document.169.122.150.711A as the media encoding format for the RTP Termination.729A = 18 z ADD_REPLY text description MEGACO/1 [191. The 4th line: The Media descriptor.711A = 8.122 m=audio 18300 RTP/AVP 8}}}}} The 1st line: The command is sent by the MG to the MGC. G.61]:2944 T=369363688{ C=${ A=A1{ M{O{MO=SR. fills the local IP address to be 191.RG=OFF}}.RG=OFF. the MG determines G. L{v=0 c=IN IP4 191. requesting the MG to add the physical Termination A1 and a certain RTP Termination to a new Context. G.723. Requested by the MGC.150. G.122]:2944. transported over UDP) and Udp (the UDP protocol).711A as the codec type for the Termination A100000035 of the MG.RV=OFF. The 5th line: Requested by the MGC.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. The 2nd line: The TransactionID is “369363687”.711A as the media encoding format for the Termination A100000034. sets its RTP port number to be 18296. Therefore.169. It indicates that the MGC suggests G.nt/jit=40}.150.726 = 2. G. the MG confirms G.RV=OFF.A=A100000034{ M{O{MO=IN.200. G.122. “C=286” indicates that the requested Context is created and the MG assigns an identifier “286” to identify the created Context. The mapping relationship from RTP payload type to encoding defined in the H. The 3rd line: It is confirmed that the physical Termination A0 and the ephemeral Termination A100000034 have been added in the Context 286.150.169.248 service streams are transferred over RTP/UDP.169. sets its RTP port number to be 18300. For audio and video signals. G. z ADD_REQ text description MEGACO/1 [191.7231 = 4.169.711U = 0.150. There are two classes of protocols defined: RTP/AVP (audio/video application document. The MG acknowledges with an MOD_REPLY.RV=OFF.200.169.169.122]:2944 P=372771561{C=287{MF=A1}} 7) Event 7: The MGC sends an MOD_REQ command to the Termination A0. refer to Event 4.61]:2944 T=372771561{C=287{ MF=A1{ E=369108999{al/*}.122]:2944 P=369363688{C=287{ A=A1.RG=OFF. to modify the properties of the Termination A1 and request the MG to play the ringing tone to the UserB.200.169.169.61]:2944 T=372771562{C=286{ MF=A0{ E=369109256{al/*}. earlier in this section. refer to Event 4. L{v=0 c=IN IP4 191. The MG acknowledges with an MOD_REPLY. SG{cg/rt}}}} z MOD_REPLY text description MEGACO/1 [191. SG{al/ri}}}} z MOD_REPLY text description MEGACO/1 [191. z MOD_REQ text description MEGACO/1 [191. SG{}}. and meanwhile the MG plays the ringing tone to the UserB.A=A100000035{ M{O{MO=IN. z ADD_REPLY text description MEGACO/1 [191.RG=OFF. and meanwhile the MG plays the ringback tone to the UserA.150. earlier in this section.nt/jit=40}. L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8}}}}} For details of the parameters. A=${ M={O{MO=IN. 6) Event 6: The MGC sends an MOD_REQ command to the Termination A1.248 E=369108998{al/*}.RV=OFF.150.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. to modify the properties of the Termination A0 and request the MG to play the ringback tone to the UserA.150.150.122]:2944 P=372771562{C=286{MF=A0}} 2-34 .nt/jit=40}. z MOD_REQ text description MEGACO/1 [191.122 m=audio 18296 RTP/AVP 8}}}}} For details of the parameters.169.169. 169.200.169.122 m=audio 18300 RTP/AVP 8}}}}} The 1st line: The command is sent by the MGC to the MG. E=369109001{al/*}. The 3rd line: The Modify command.150. L{v=0 c=IN IP4 . “O” represents the LocalControl descriptor. The 4th line: The MGC requests the MG to detect events that will happen in the Termination A1.169. that is. “M” represents the Media descriptor. SG{}}.RG=OFF}. The 2nd line: The TransactionID is 370281195.RV=OFF. The 6th line: The Modify command. Here the signal is null. The MG acknowledges with an MOD_REPLY.150. z NTFY_REQ text description MEGACO/1 [191. “O” represents the LocalControl 2-35 . “MO=SR” indicates that the MGC modifies the mode property of the Termination A1 to be send/receive. indicating the MGC requires the MG to stop any signal played currently.RTP/AVP 8}.61]:2944 T=370281195{C=287{ MF=A1{M{O{MO=SR. the Context created for the MGC and the Termination2. The MG notifies the MGC of the off-hook event with an NTFY_REQ command.m=audio . “tdmc/ec=ON” indicates that the MGC suggests ON to be the echo canceler in the TDM Circuit Packages. The MGC acknowledges with an NTFY_REPLY. “M” represents the Media descriptor. 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. such as on-hook events.122]:2944 T=885{C=287{ N=A1{ OE=369108999{al/of}}}} z NTFY_REPLY text description MEGACO/1 [191.200. MF=A100000035{M{O{MO=SR. The IP address and port of the MGC is [191.tdmc/ec=ON}}.61]:2944. R{v=0 c=IN IP4 191.61]:2944 P=885{C=287{N=A1}} 9) Event 9: Through an MOD_REQ command. to modify the properties of the RTP Termination A100000035. and the ContextID is 287. and modifies the mode property of the RTP Termination A100000035 to be send/receive.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 8) Chapter 2 H.RV=OFF.169.200. The 5th line: The Signals descriptor.RG=OFF.RG=OFF” indicates that both the ReserveGroup property and the ReserveValue property are set to OFF.169. to modify the properties of the Termination A1.248 Event 8: The called UserB hooks off. “RV=OFF. z MOD_REQ text description MEGACO/1 [191. carrying the connection description of the local RTP (associated with the Termination A1) Termination A100000035.200.MF=A100000035{ M{L{v=0 c=IN IP4 191.122 m=audio 18296 RTP/AVP 8}}}}} For details of the parameters.RV=OFF. z MOD_REPLY text description MEGACO/1 [191. and a conversation can start.RG=OFF” indicates that both the ReserveGroup property and the ReserveValue property are set to OFF.122]:2944 P=370281196{C=286{ MF=A0.122 m=audio 18296 RTP/AVP 8}}}}} 10) Event 10: Through an MOD_REQ command.122]:2944 P=370281195{C=287{ MF=A1. z MOD_REPLY text description MEGACO/1 [191. SG{}}.tdmc/ec=ON}}. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.RG=OFF}.248 descriptor. “MO=SR” indicates that the MGC modifies the mode property of the RTP Termination A100000035 to be send/receive. The 7th line: The Local descriptor. R{v=0 c=IN IP4 191.15. z MOD_REQ text description MEGACO/1 [191.15. earlier in this section. The MG acknowledges with an MOD_REPLY. 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. At this time.150.150. E=369109258{al/*}. “RV=OFF.RV=OFF. The 8th line: The Remote descriptor. the Terminations A0 and A1 know the connection information of the local end and the opposite end.169.169. L{v=0 c=IN IP4 .150.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.m=audio .RTP/AVP 8}.RG=OFF. refer to Event 9.150. carrying the connection description of the remote RTP (associated with the Termination A0) Termination A100000034. and modifies the mode property of the RTP Termination A100000034 to be send/receive. The MG sends an NTFY_REQ command to notify the MGC.169. The conversation conditions are satisfied.165.122]:2944 T=886{C=286{ 2-36 .165.122 m=audio 18300 RTP/AVP 8}}}}} 11) Event 11: The calling party UserA hooks on.169.169.MF=A100000034{ M{L{v=0 c=IN IP4 191.61]:2944 T=370281196{C=286{ MF=A0{M{O{MO=SR. z NTFY_REQ text description MEGACO/1 [191. MF=A100000034{M{O{MO=SR. the MGC sends an MOD_REQ command to the MG to modify the properties of the Termination A0. z SUB_REQ text description MEGACO/1 [191. The MG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.169. Therefore.200. The MGC also requests the MG to detect events that will happen in the Termination A1. 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.RV=OFF.122]:2944 P=372509424{C=286{ S=A0. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ.169.169. and the ContextID is “286”. and “*” represents All. The IP address and port of the MGC is [191.MF=A100000034}} 13) Event 13: On receipt of the on-hook event of the UserA.200. 2-37 . such as on-hook events. “S” represents Subtract.122]:2944 P=370281199{C=286{MF=A0.169. The MGC also requests the MG to detect events that will happen in the Termination A0.200. and meanwhile sends the busy tone to the UserB. such as off-hook events. MF=A100000034{M{O{MO=IN. z SUB_REPLY text description MEGACO/1 [191.SG{}}.150.RG=OFF}}}}} z MOD_REPLY text description MEGACO/1 [191.169. 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.61]:2944. The 2nd line: The TransactionID is “372509424”. “O-S=*” indicates to subtract all Terminations from the Context 286.248 N=A0{OE=369109258{al/on}}}} z NTFY_REPLY text description MEGACO/1 [191.200. “O” represents Optional. and modify the mode property of the RTP Termination A100000034 to be inactive.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. and requests the MG to send the busy tone to the Termination A1. In “O-S=*”.61]:2944 T=370281199{C=286{ MF=A0{E=369109259{al/*}.61]:2944 T=372509424{C=286{O-S=*}} The 1st line: The command is sent by the MGC to the MG.150.S=A100000034}} 14) Event 14: The MGC sends an MOD_REQ command to the MG to modify the properties of the Termination A1.61]:2944 P=886{N=A0}} 12) Event 12: On receipt of the on-hook event of the UserA. 61]:2944 T=372771570{C= .169.169.200.150.150. z SUB_REQ text description MEGACO/1 [191. the Context is null.61]:2944 P=887{C=287{N=A1}} 17) Event 17: On receipt of the on-hook event of the UserB. z NTFY_REPLY text description MEGACO/1 [191. the MGC sends an MOD_REQ command to the MG.122]:2944 P=372771570{C= . which is the same as the RequestIdentifier in the MOD_REQ command described in the event 14.169. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.169.122]:2944 T=887{C=287{ N=A1{OE=369109004{al/on}}}} The RequestIdentifier is 369109004.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 2 H.200.122]:2944 2-38 . z MOD_REQ text description MEGACO/1 [191. requesting the MG to detect events that will happen in the Termination A0.248 MOD_REQ text description MEGACO/1 [191.200. 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. At this time. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ command.SG{}}}} z MOD_REPLY text description MEGACO/1 [191. The MG sends an NTFY_REQ command to notify the MGC.61]:2944 T=372509427{C=287{O-S=*}} z SUB_REPLY text description MEGACO/1 [191. It indicates that the NTFY_REQ is triggered by the MOD_REQ command in the event 14.169.{MF=A0}} 16) Event 16: The called party UserB hooks on.169. the RTP Termination and the MGC are cleared.{ MF=A0{E=369109261{al/*}.61]:2944 T=372771569{C=287{ MF=A1{E=369109004{al/*}.SG{cg/bt}}}} z MOD_REPLY text description MEGACO/1 [191. such as off-hook events.169.150.200.169. z NTFY_REQ text description MEGACO/1 [191.122]:2944 P=372771569{C=287{MF=A1}} 15) Event 15: After the call and the Context between the Termination A0. The MG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.150. 10.150. the MGC sends an MOD_REQ command to the MG.169. 2-39 . In the procedure.S=A100000035}} 18) Event 18: After the call and the Context between the Termination A1.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.169. and the called party hooks on first.172.169.122]:2944 P=372771572{C= .3.248 P=372509427{C=287{ S=A1.169. SoftX3000 H. z The PSTN user is the calling party.150.169.{ MF=A1{E=369109006{al/*}. such as off-hook events.170. requesting the MG to detect events that will happen in the Termination A1.{MF=A1}} 2. and the associated PSTN switch is connected to SoftX3000 through a TMG. The networking diagram is shown in Figure 2-11.200.61]:2944 T=372771572{C= .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H. it is assumed that z The IP address of SoftX3000 is 191. where a PSTN user under a TMG makes a call through SoftX3000 to a user under an AMG5000. At this time.150. z The IP address of the TMG is 191.SG{}}}} z MOD_REPLY text description MEGACO/1 [191. the RTP Termination and the MGC are cleared. the Context is null. z The IP address of the AMG is 191. z The AMG user is the called party.5 Successful Trunk Call Procedure The following example illustrates a call procedure under the control of SoftX3000. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ command.150. z MOD_REQ text description MEGACO/1 [191.248 Core Networ k MTP3+M2UA+Trunk+H. 170]:2944 T=369379680{C=${A=A29{M{O{MO=SR. and sets the Termination A2147489806 to be in the send/receive mode. On receipt of the IAM. A=A2147489806{M{ST=1{ L{v=0 c=IN IP4 191.RG=OFF.169.723 as the codec type for the Termination A2147489806 of the TMG. The TMG responds with an ADD_REPLY with a new allocated connection descriptor “15” and a new RTP termination descriptor “A2147489806”.169. Requested by the MGC. fills the local IP address to be 191.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System SG TG Chapter 2 H.10 m=audio 13388 RTP/AVP 4}}}}}} 2-40 . the MGC sends an ADD_REQ.150. the TMG determines G.tdmc/ec=ON}}}.150.150. sets its RTP port number to be 13388.169. L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 4}}}}} z ADD_REPLY text description MEGACO/1 [191.010]:2944 P=369379680{C=15{A=A29. An Initial Address Message (IAM) is sent to the MGC through the Signaling Gateway (SG) built in the TMG.10.nt/jit=40}.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.150.169. requesting the TMG to add the physical Termination A29 and a certain RTP Termination to a new Context. z ADD_REQ text description MEGACO/1 [191. A=${M{O{MO=SR.RV=OFF.RV=OFF. 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.nt/jit=40}. and plays the ringing tone to the UserB. The AMG responds with an ADD_REPLY with a new allocated connection descriptor “218” and a new RTP termination descriptor “A100000379”.RV=OFF. z MOD_REQ text description MEGACO/1 [191.150.169.SG{}}.723 as the codec type for the Termination A100000379 of the AMG. requesting the AMG to add the physical Termination A0 and a certain RTP Termination to a new Context. 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.RV=OFF. Therefore.150.169.170]:2944 T=369379681{C=${ A=A0{M{O{MO=SR.169.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. fills the local IP address to be 191. Requested by the MGC. requesting the TMG to play the ringback tone to the PSTN user. the AMG determines G. z ADD_REQ text description MEGACO/1 [191.RV=OFF. The TMG acknowledges with an MOD_REPLY.172]:2944 P=372787554{C=218{MF=A0}} 4) Event 4: The MGC sends an MOD_REQ command to the TMG. A=A100000379{M{O{MO=IN.RG=OFF}}. and sets the Termination A100000379 to be in the inactive mode. SoftX3000 sends an Address Complete Message (ACM) to the SG.SG{al/ri}}}} z MOD_REPLY text description MEGACO/1 [191.169.170]:2944 T=371870051{C=15 2-41 .RG=OFF. A=${M{O{MO=IN.150. such as off-hook events.169. sets its RTP port number to be 18300.170]:2944 T=372787554{C=218{ MF=A0{E=369099790{al/*}. L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 4}}}}} z ADD_REPLY text description MEGACO/1 [191. The MGC also requests the AMG to detect events that will happen in the Termination A0.RG=OFF.E=369099789{al/*}.169. z MOD_REQ text description MEGACO/1 [191.169.150. On receipt of the message. the MGC sends an ADD_REQ. and meanwhile the AMG plays the ringing tone to the UserB.172]:2944 P=369379681{C=218{A=A0.150.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 2) Chapter 2 H. L{v=0 c=IN IP4 191.172.150.nt/jit=40}.150. Subsequently. The AMG acknowledges with an MOD_REPLY. 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. MF=A100000379{M{L{v=0 c=IN IP4 191.150.RG=OFF}.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 2 H.150.170]:2944 P=2470{C=218{N=A0}} 6) Event 6: Through an MOD_REQ command.169.tdmc/ec=ON}}. At this time. Subsequently.169.010]:2944 P=371870051{C=15{MF=A29}} 5) Event 5: The UserB hooks off. E=369099791{al/*}. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.OR}}}}}}} z ADD_REPLY text description MEGACO/1 [191.169. SoftX3000 sends an Answer Message (ANM) to the SG.SG{}}.169. L{v=0 c=IN IP4 – m=audio – RTP/AVP 4}. The AMG sends an NTFY_REQ command to notify the MGC.169.169.170]:2944 T=370297190{C=218{ MF=A0{M{O{MO=SR. R{v=0 c=IN IP4 191. The AMG acknowledges with an MOD_REPLY.RV=OFF.150. z NTFY_REQ text description MEGACO/1 [191.150.172 m=audio 18300 RTP/AVP 4 }}}}} 7) Event 7: Through an MOD_REQ command. 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.150.172]:2944 P=370297190{C=218{ MF=A0. 2-42 .150.RG=OFF.172]:2944 T=2470{C=218{ N=A0{OE=369099790{al/of}}}} z NTFY_REPLY text description MEGACO/1 [191. 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.248 {MF=A29{SG{SL=0{cg/rt{NC={TO. The TMG acknowledges with an MOD_REPLY. On receipt of the message. MF=A100000379{M{O{MO=SR. z MOD_REQ text description MEGACO/1 [191.10 m=audio 13388 RTP/AVP 4}}}}} z MOD_REPLY text description MEGACO/1 [191.RV=OFF. and modifies the mode property of the RTP Termination A100000379 to be send/receive. 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.169.150. 169.150.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 2 H.172]:2944 T=2471{C=218{ N=A0{OE=369099791{al/on}}}} z NTFY_REPLY text description MEGACO/1 [191.169.150.MF= A2147489806}} 8) Event 8: The called UserB hooks on.172 m=audio 18300 RTP/AVP 4} z MOD_REPLY text description MEGACO/1 [191. 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 MGC sends an MOD_REQ command to the AMG to modify the properties of the Termination A0.RG=OFF}}}. such as off-hook events. and modify the mode property of the RTP Termination A100000379 to be inactive.150. The MGC also requests the gateway to detect events that will happen in the Termination A0. z MOD_REQ text description MEGACO/1 [191.RV=OFF.169. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ and indicate the execution of the command.169.169. z NTFY_REQ text description MEGACO/1 [191.170]:2944 T=370297192{C=15{ MF=A29{M{O{MO=SR.170]:2944 T=370297199{C=218{ MF=A0{E=369099776{al/*}. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.150.172]:2944 P=370297199{C=218{MF=A0.170]:2944 T=372525424{C=218{O-S=*}} 2-43 .MF= A100000379}} 10) Event 10: On receipt of the on-hook event of the UserB. R{ v=0 c=IN IP4 191.RV=OFF.SG{}}. MF=A2147489806{M{L{ v=0 c=IN IP4 – m=audio – RTP/AVP 4}. z SUB_REQ text description MEGACO/1 [191. MF=A100000379{M{O{MO=IN.248 MOD_REQ text description MEGACO/1 [191.150.169.RG=OFF}}}}} z MOD_REPLY text description MEGACO/1 [191. The MG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.170]:2944 P=2471{C=218{N=A0}} 9) Event 9: On receipt of the on-hook event of the UserB.150.150.169.150.169.010]:2944 P=370297192{C=15{MF=A29. The AMG sends an NTFY_REQ command to notify the MGC. 150.170]:2944 T=372525425{C=15{O-S=A29. The TMG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command. the SG transfers it to the MGC through the M2UA protocol.150.010]:2944 P=372525425{C=15{ S=A29. On receipt of the RLC message. the PSTN switch acknowledges with a Release Completed (RLC) message which triggers the release of the voice circuit. z SUB_REQ text description MEGACO/1 [191. On receipt of the message. O-S=A2147489806}} z SUB_REPLY text description MEGACO/1 [191.150. On receipt of the REL message. On receipt of the RLC 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. the MGC sends a Release (REL) message to the SG.S= A100000379}} 11) Event 11: On receipt of the SUB_REQ command from the AMG.169. 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.169.248 SUB_REPLY text description MEGACO/1 [191.S=A2147489806}} 2-44 .169.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 2 H.172]:2944 P=372525424{C=218{ S=A0. compatibility and expendability with security issues taken into account. and similar applications. or a combination of these. Sessions can be advertised using multicast protocols such as Session Announcement Protocol (SAP). electronic mail. On one hand. telemedicine. Members in a session can communicate through multicast or through a mesh of unicast relations. SIP is not tied to any particular conference control protocol. Internet telephone calls. all interactive two-party or multiparty multimedia communication activities over the Internet are multimedia sessions. distance learning. SIP is being developed and studied.1 Overview 3. 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 . SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. among others. On the other hand. which can be used for creating. allowing the implementation of ISDN and IN telephony subscriber services. Being an application-layer multimedia session signaling protocol. These facilities also enable personal mobility.1 Basic Concepts Put forward and studied by the IETF. SIP is designed to be independent of the underlying transport protocol and can be extended with additional capabilities. These sessions include Internet multimedia conferences. SIP transparently supports name mapping and redirection services. SIP can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Chapter 3 SIP 3. SIP fully considers the support for traditional PSTN services including Intelligent Network (IN) services and Integrated Services Digital Network (ISDN) services. web pages or Lightweight Directory Access Protocol (LDAP). SIP supports user mobility by proxying and redirecting requests to the user’s current location. the Session Initiation Protocol (SIP) is an application-layer control protocol for multimedia communication over IP network.1. Users can register their current location. that is. SIP learns from the design concepts of other Internet standards and protocols and follows Internet principles such as concision. modifying and terminating sessions with one or more participants. That is. openness. 225. call-in conference. or multicast. z Call handling and control: including redirection.323. For example. In another example. each participant uses a separate call to invite himself to the MCU. a call can be established by a third party who does not participate in the media communication. For multicast conferences. obtain the H. transfer and termination of calls. SIP can be used in conjunction with other signaling systems or protocols for call setup. all participants in a conference invited by the same source comprise one call. SIP does not reserve resources. establishment of call parameters at both called and calling party. A point-to-point Internet telephony conversation is a kind of simplest session and maps into a single SIP call. In an MCU-based. The IETF has included extensibility and compatibility of SIP with other protocols.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP z User location: determination of the end system to be used for communication. z User availability: determination of the willingness of the called party to engage in communications. In normal cases. possibly suggesting an Internet-to-PSTN gateway be used. 3. SIP can initiate multiparty sessions using a multipoint control unit (MCU). For example. where the calling party of the session is not the same as the inviter of the session. A SIP call is identified by a globally unique call-ID. but can convey to the invited system the information necessary to do this.2 Related Terms I. SIP could be used to determine that the party can be reached through H. a call is established by the calling party. Call A call consists of all participants in a conference invited by a common source. z Call setup: "ringing". each of these invitations will be a unique call. z User capabilities: determination of the media and media parameters to be used.1. More generally. 3-2 . but SIP can be used to introduce conference control protocols. SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP might be used to determine that the callee is reachable through the PSTN and indicate the phone number to be called. if a user is invited to the same multicast session by several people.0 to establish the call. unicast mesh.245 gateway and user address and then use H. supporting gateway functionality between PSTN and Internet calls. “user parameter” is added to 3-3 . it does not require a response. Username is composed of any characters in a form of e-mail address or telephone number. Especially. The first problem is addressing. III. SIP Uniform Resource Locators (URLs) are used for addressing purposes. Port refers to the port number to which request message is sent.) Host is either a domain name or an IPv4 address. A normal call consists of three transactions. 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. The former requires a response. SIP URL To transfer protocol messages correctly. Transaction SIP is a client/server protocol. server address parameter? header name=header value SIP indicates that the SIP is used for the communication to the specified end system. The default port is 5060. 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. The second problem is user location. which will be described later. time-to-live. SIP URL syntax is defined according to the Uniform Resource Identifier (URI) guidelines specified in the RFC 2396.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP II. TCP or UDP. The latter is only an acknowledgement that the final response is received. user parameter. A SIP URL has the syntax: SIP: Username:password@host:port. The default transport parameter is UDP. For user parameter. Transport parameter indicates the used transport protocol. Call initiation consists of two operation requests. that is. SIP utilizes the WWW technology to solve those problems. a function of SIP URL is to allow the host to be an IP telephony gateway with a telephone number as the username. (SoftX3000 adopts telephone number as the username. Because BNF syntax cannot distinguish telephone number from general username. method parameter. there are two significant problems in SIP to be solved. the form of address used to identify end users. transport parameter. the public SIP port number. namely BYE. Call termination consists of one operation request. Password can be included in a SIP URL. namely INVITE and ACK. which is not recommended for the sake of security. Two values are available for this field: IP and phone. Time-to-live (TTL) indicates the life of UDP multicast data packets. When the field is set to “phone”. “191.com.1:5061. After a SIP user terminal is powered on. V. “55500200” is a username. overwrites the address in the “host” field.0. It. “registrar.1. REGISTER request and registration procedure are defined in SIP. SoftX3000 acts as a location server. The user parameter is “phone”. it starts to register to a registrar (SoftX3000). “127. usually the multicast address. 3-4 .
[email protected]. “Register” is a method to be used. The following are some SIP URL examples. “time-to-live”. Server address parameter indicates the address of the server communicating with the user. method=REGISTER. User=phone. User location User location is based on registration. 55500200@127. Location services are offered by location servers. “55500200” is a username. For that specific purpose.0. IV. but the manner in which a SIP server requests location services is beyond the scope of this document. and “method parameter” are URL parameters used only in a redirect address. that is the Contact field which will be mentioned later.1. “Transport parameter”. Location service A location service is used by a SIP redirect or proxy server to obtain information about a callee’s possible location(s). Method parameter refers to the method (operation) to be used. Sip.112” is the IP address of an IP telephony gateway. the username is a telephone number and the corresponding end system is an IP telephony gateway.0.0.112.com” is the domain name of a host. “5061” is a port number of the host. This parameter is valid only when the transport parameter is set to “UDP” and the server address parameter is set to “multicast address”. Sip: alice@registrar. In the U-SYS Solution proposed by Huawei.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP follow the domain name.169. indicating the username is a telephone number.1” is the IP address of a host. Location servers may be co-located with a SIP server. Sip. “server address parameter”. “Alice” is a username. 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. Stateful and Call Stateful. A proxy server may be in one of the states: Stateless. Note: The distinguishing of UAC and UAS is based on one transaction. An example of UAS is SoftX3000. X. charging monitoring. Registrar A register is a server that accepts REGISTER requests. SoftX3000 also acts as a redirect server. can support personal mobility. SoftX3000 also acts as a proxy server. so that the client can directly initiate requests to these new addresses again. A proxy server attempts to forward requests to multiple addresses with a branch or cycle method. User agent server A user agent server (UAS) is a server application that receives the SIP request. The redirect server. call control and service provision. A registrar may offer location services. User agent client A user agent client (UAC) is a client application that initiates the SIP request. In the U-SYS Solution proposed by Huawei. A proxy server implements the functions of routing. VIII. authentication. In the U-SYS Solution proposed by Huawei. XI. An example of UAC is SIP phone. VII. Proxy. 3-5 . and returns these addresses to the client. A registrar needs to store the address mapping relationship in REGISTER requests in a database for subsequent call processes. SoftX3000 also acts as a registrar. Proxy server A proxy. A redirect server implements the routing function rather than receive or reject calls. In the U-SYS Solution proposed by Huawei. Redirect server A redirect server is a server that accepts a SIP request. maps the address into zero or more new addresses. IX. or proxy server.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP VI. in coordination with a registration process. A registrar is typically combined with a proxy or redirect server into a single application. User agent A logical entity that can initiates or receive SIP requests. The network layer protocol is IP and the transport layer protocol is TCP or UDP. H. RTP TCP UDP IP PPP AAL3/4 Sonet AAL5 ATM PPP Ethernet V. the real-time transport protocol (RTP) for transporting real-time data and providing quality of service (QoS) feedback. 3-6 . the real-time streaming protocol (RTSP) for controlling delivery of streaming media.4 Implementation in SoftX3000 Through SIP or Session Initiation Protocol for Telephones (SIP-T).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP 3. Transport-layer support: SIP lies in the layer above the IP layer. the functionality and operation of SIP does not depend on any of these protocols.263 etc.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.3 Structure of Protocol Stack The structure of SIP protocol stack is shown in Figure 3-1. SoftX3000 interworks with other SoftSwitch systems and other SIP domain equipment such as SIP phone and UniPhone.1.1. the session announcement protocol (SAP) for advertising multimedia sessions through multicast and the session description protocol (SDP) for describing multimedia sessions. However. The implementation of SIP in SoftX3000 is illustrated in Figure 3-2.323 SIP RTCP RSVP RTSP H. 3. UDP is preferred. They are INVITE. OPTIONS. The message body contains a description of the session to which the callee is being invited. ACK is used only with INVITE messages. I.2 Protocol Messages 3. For two-party calls. 3-7 . identified either by the SIP Call-ID or a globally unique identifier within the session description. A server may automatically respond to an invitation for a conference the user is already participating in.2. CANCEL and REGISTER messages. with a 200 (OK) response. BYE The user agent client uses BYE to indicate to the server that it wishes to release the call.1 Message Types SIP messages are encoded in a text form. Table 3-1 Request messages Request message INVITE Function The INVITE message indicates that the user is being invited to participate in a session. There are two types of messages: request messages and response messages. the caller indicates the type of media it is able to receive as well as their parameters. The functions of these messages are listed in Table 3-1.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. BYE. ACK The ACK request confirms that the client has received a final response to an INVITE request. Request messages Request messages are SIP messages sent from a client to a server. 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. for the purpose of invoking a particular operation. ACK. 400 Bad Request 3-8 . but does not affect a completed request. II. and accepted. 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. Table 3-2 Response messages Serial No. The last two digits indicate the response in detail. (A request is considered completed if the server has returned a final status response. understood. 1xx 2xx 3xx 4xx Status-Code Message functions Informational (provisional) Request received.) REGISTER A client uses the REGISTER request to register an address with a SIP server. 200 OK Redirection Further action needs to be taken in order to complete the request. 100 Trying 180 Ringing 181 Call Is Being Forwarded 182 Queued Success The action was successfully received. OPTIONS The OPTIONS request is used to query servers about their capabilities. continuing to process the request. 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 first digit of the Status-Code defines the class of response. The Status-Code is a 3-digit integer.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Request message Function CANCEL The CANCEL request cancels a pending request. The classification of response messages and their meanings are shown in Table 3-2. 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Serial No. 500 Server Internal Error 501 Not Implemented 3-9 . Request messages 1) Request format Figure 3-3 illustrates the format for a SIP request that consists of a start line. 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.2. 3. Some parameters are optional for different request messages. 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Serial No.2 Message Structure I. A line feed character distinguishes each parameter line in the message header. a message header. 3-10 . SDP message fields are added into SIP messages. and a message body. if a user invites a single individual several times to the same (long-running) conference. for example. for example. A single multimedia conference can give rise to several calls with different Call-IDs.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. 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. Call-IDs have a generic format: Call-ID: localID@host 3-11 . session identifier and version number carried in the o (source) field in the SDP. z Call-ID The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. the local ID must be a globally unique value to ensure the global uniqueness of Call-ID. The tag in the To header field is put by each instance in the response message. Otherwise.61> To: <sip:
[email protected]” is the IP address of a host. Call-IDs are case-sensitive. The tag parameter in the field distinguishes different user instances that are identified by the same SIP URL. home telephone) of the user. “call-973636852-4” is a globally unique local ID.tag=62beb3ca 3-12 . it is required to use the tag to distinguish the responses from different instances.150. A user should maintain the same Call-ID and tag value in the whole process of a call. This field has a generic format: From:Display-name<SIP-URL>.101 “191.169. and the same request might reach different instances (for example. An example of the From field: From: <sip:
[email protected]>. The tag value must be globally unique.tag=xxxx The “display-name” is meant to be rendered by a human user interface.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP in which.150. The server duplicates this field from the request message to response messages. “tag” is a string of hexadecimal numbers in which the hyphen “-“ can be added.169.200. Examples of the To field: To: <Sip:1000@191. z Form All requests and responses must contain the From header field that indicates the initiator of the request.169.61>.169. Because the instances might all respond to the request. A system should use the display name “Anonymous” if the identity of the client is to remain hidden. 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”. The “display-name” is optional. “host” is a domain name defined globally or an IP address routable globally. When two user instances sharing the same SIP address use the same Call-ID to initiate a call invitation. All requests and responses must contain this field.200.tag=1c17691 z To The To header field specifies the logical recipient of the request. Call-ID example: Call-Id: call-973636852-4@191. A proxy server can concurrently deliver several requests. The local ID is composed of unique URI characters in the scope of “host".200. this tag should be used for distinguishing purposes. A CSeq header field in a request contains a command name and a single decimal sequence number. At requesting for forward. Call-ID. the proxy server should check the top Via header field. used to correlate the request with the response it triggers. the proxy server returns a response indicating a loop detection. Strictly speaking. for example. A retransmitted request contains the same sequence number. To avoid that. The initial value of the sequence number is arbitrary. the CSeq sequence number should be increased by one.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP In SIP. Several requests concurrently delivered by the agent server have the same CSeq value. 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. in firewall occasions. Upon receipt of an INVITE request with a lower sequence number. firewall). and To header fields identify one call branch. For example: 3-13 . The server duplicates the CSeq value from the request to the response message. The client originating a request must add its host name or network address in the Via header field of the request. The subsequent values share the same Call-ID. the server sends a response and discards the INVITE request. The server must remember the highest sequence number of an INVITE request having the same Call-ID. a call might have several call branches. the server add a “receive” parameter in the Via which is thus called “Via header field tagged by the receiver”. An example of the CSeq field: Cseq: 1 INVITE z Via The Via header field indicates the path taken by the request. When a proxy server concurrently delivers requests. When a request is passing a Network Address Translation (NAT) entity (for example. From. The field can avoid loops during the transport of the request and ensure the same path taken by the responses. the proxy server must add its address in a new Via header field that is put before the existing Via. For a request with a different command name and a different message body. it must add the used port number in the field. The CSeq sequence number of a BYE request should be higher than that of the corresponding INVITE request. If the client does not use the default port. If the proxy server receives a request containing its address in a Via header field. Request client defines the sequence number which is unique inside the Call-ID. z CSeq CSeq is command sequence. the requested source address and the port number might be changed and thus the Via cannot be the base for routing responses. If the value of the top Via is different from the previous hop’s address that is detected by the proxy server. The CSeq value (decimal sequence number) of an ACK or a CANCEL request is the same as that of the corresponding INVITE request. 0/UDP 10.12.0. the proxy server or the user agent client uses a port number 5060. The “ttl” and “maddr” parameters are coordinated with each other. the response should reach the destination. The used port number is specified in the “sent-by” parameter. the proxy server or the user agent client sends the response to the address specified in the “sent-by” parameter. If not. the proxy server or the user agent client discards the message.169. Rule 5: If there is neither a “maddr” parameter nor a tag.received=191.bell-telephone. it indicates that the field has been encrypted by the previous proxy for privacy purposes. branch The “sent-protocol” is expressed “protocol-name/protocol-version/transport”. hidden. the proxy server must add a parameter “maddr” in the Via to indicate that. The “hidden” parameter has a key word—hidden.com. received. 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.bell-telephone. The Via header field has a generic format: Via: sent-protocol sent-by. the proxy server or the user agent client sends the response according to the multicast address indicated in the parameter. the request reaches the proxy server—softx3000. The lifetime of the response should be specified in the “ttl” parameter. otherwise. Rule 2: If there is no a second Via header field. If the proxy server sends a request to multicast address. at the end of the top Via and then adds its own address in a new Via that is put at the topmost.com:5060 Via:SIP/2. 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. see earlier descriptions.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Via:SIP/2. proceed as follows. Otherwise.0.169. the proxy server or the user agent client deletes the Via header field. the proxy server or the user agent client sends the response to the address specified in the “received” parameter. If there is a hidden parameter. For the meanings of the “maddr” and “received” parameters. The “branch” parameter is used by the proxy server concurrently delivering requests to 3-14 .0/UDP softx3000. If not specified. maddr. If not specified. the proxy server adds the actual sending address.1 passes a NAT point with the external address 191.30.12. Rule 4: If the second Via header field does not contain a “maddr” parameter but has a field tagged by the receiver. At noticing the mismatch between the previous hop’s address and the Via header field address.0.1:5060.30 When the request from 10. as a receiver’s tag. ttl.0. the proxy server or the user agent client sets it to “1”. Rule 3: If the second Via header field contains a “maddr” parameter. 169. action. 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. a CANCEL request cannot be directly sent to that address. Instead.116:5061. call process responses. With the field. which can be used for a response to a BYE. that address indicates the proxy server. If the parameter is not specified.branch=z9hG4b kbc427dad6 z Contact The Contact header field is present in INVITE. instead of asking a series of proxy servers to forward the request by using the Via header field. Call process response to an INVITE request contains a Contact header field that has the same meaning as the success response message.ttl=16.20. If the host is behind a firewall. BYE) to that address. The Contact header field in a redirect response such as Moved Temporarily. INVITE or OPTIONS request. the “expires” field value is taken as its default value. or Address Ambiguous specifies other alternative addresses for retry. 1] indicating the relative priority of the given location. the CANCEL must be forwarded through the same path of the original request. success responses. An example of the Via field: Via:SIP/2. The Contact header field in a success response to the REGISTER request returns all locations that are currently reachable for the user. ACK. Moved Permanently. The greater the 3-15 .169.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP tag the branches. it is considered that the expiration interval of the SIP URI is one hour. If neither case is adopted. If the response reaches the destination. and REGISTER requests. However. which helps to send the subsequent SIP requests (for example. The “q” parameter has a value range [0. expires. the proxy uses it to judge the branch from which the response comes.maddr=191. The Contact header field has a generic format: Contact: address. extension The “address” is expressed in the same form as To and From.0/UDP191. the callee can directly send a request (for example. ACK) directly to that address specified in the field. and redirection responses to provide an address for direct communication with the user. q.1. the “expires” parameter (optional) can also be specified to indicate the expiration interval of the registration. That address usually indicates the host of the callee. A success response to INVITE might contain the Contact header field.10. The Contact header field in an INVITE or ACK request indicates the location from which the request is originated. The initial field value is 70.1. An example of the Allow field: Allow: INVITE.169.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. the higher the priority becomes. The “expires” parameter indicates how long the URI is valid either in seconds or by SIP date. If a message does not contain a message body. regardless of the media type of the entity. Applications use this field to indicate the size of the message body to the transferred. in decimal number of octets. If the Max-Forwards value reaches 0 before the request reaches its destination. ACK. 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. If the Contact header field does not contain an “action” parameter. the action to be performed depends on the configurations of the server. The Content-Length header field has a generic format: Content-Length: decimal value 3-16 . the value of the Content-Length header field must be set to “0”.110:5061>. It consists of an integer that is decremented by one at each hop. An example of the Contact field: Contact: <Sip:66500002@191. The size of the message body does not include the Carriage Return Line Feed (CRLF) that separates the message header from the message body. If the used transport protocol is based on streams. The “extension” attribute is actually the extension name. this header field must be used.7. for example. The Content-Length value must be greater than or equal to 0. indicating the server is required to perform the proxy service or redirection service on the subsequent requests to the client. it will be rejected with a 483 (Too Many Hops) error response. sent to the recipient. SDP serves to construct the message body of a request or 2xx response. The “action” parameter is only used in a REGISTER request.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP value is. CANCEL.q=0. TCP. BYE z Content-Length The Content-Length header field indicates the size of the message body. OPTIONS. The purpose of inserting this field is to avoid consuming proxy server resources in an event of loop. If the body is empty and a Content-Type header field is present. In other words. the User-Agent header field should be set to be a configurable option. If a UA wants to send a provisional response carrying a SDP message body. it indicates that the body of the specific type has zero length (for example. the UAC adds a “Supported: 100rel” header field in the message transmitted. an empty audio file). The acknowledgement request method for a provisional response in “100rel” is PRACK. If the response is required to carry information about media. the UAS adds a “Require: 100rel” header field in the 100 response transmitted. Therefore. If the UAC supports the extension. the Content-Type header field must be present. it must be guaranteed that the message can be reliably transported to the peer. the UAC is required to send a PRACK request to the UAS.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. If the UAS supports the extension. the UAC and the UAS must support and use the “100rel” extension to guarantee the reliable transportation of the message. notifying the UAS of the receipt of the provisional response. 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. there is no guarantee that UAC can receive the provisional response sent by the UAS. For example: User-Agent: Softphone Beta1. 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. “100rel” extension provides an appropriate mechanism for the reliable transportation of the 100 response. 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.5 3-17 . The UAS sends a 2xx response to the UAC to terminate the acknowledgement process of the provisional response. For example: Supported: 100rel z User-Agent The User-Agent header field contains information about the UAC originating the request. Upon receipt of the response. and URI. The earlier nonce is returned with the cnonce parameter. For example: Accept-Language: en z Authorization The Authorization header field contains authentication credentials of a UA. the server re-generates a nonce and re-initiates a user authorization procedure. If the server requires authorizing the user when the UA originates a request. If the nonce is generated locally but the authorization expires. or status responses carried as message bodies in the response. The UA sends the response through a new request message to the server. The following introduces a general process for a UA to request an authorization from the server. If no Accept-Language header field is present. the server assumes all languages are acceptable to the client. Otherwise. If the responses match. the server firstly checks the correctness of the nonce. Upon receipt of the authorization request. For example: Expires: 5 z Accept-Language The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases. If the nonce passes the verification. username. the UA generates an encrypted response using a particular algorithm according to the information returned from the server and the user configurations. Upon receipt of the new request with the authorization response. the user successfully passes the authorization.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. password (the server can obtain the password of the user from the local user information). The Authorization field has a generic format: 3-18 . In addition. the server generates a response with the same algorithm as the UA according to the nonce. the server compares the generated response with the response carried in the request message. 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. If the nonce is not generated locally. session descriptions. the authorization fails. the server returns a failure message. Username indicates the authenticated user. URI.116>.169. according to the nonce. except password. Upon receipt of an authorization request. Currently SoftX3000 supports only the HTTP-digest method. basic.1. URI="sip:191.110> CSeq: 1 INVITE 3-19 . chap-password.30" 3) Example of request message The following is an example of SIP request message. 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. The string contains the encrypted password of the user. Digest is an HTTP-digest method. Realm is used to identify the domain from which the authorization procedure is initiated. some fields including request-URI might be changed at a passed network server. This is to ensure the correctness of the authorization procedure. NONCE="200361722310491179922". Algorithm is used to transfer the algorithm for generating the “response”. the UA has to re-originate a request that carries the authorization response information to the server. nonce.169.169.0 From: <sip:44510000@191. realm. algorithm The authorization methods include digest. the UA and the server exchange other information. password.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Authorization: method username. The nonce parameter carries the new nonce. and carddigest. (During the authorization procedure. If the UA returns a new request message with the authorization response after expiration at the server.150.com".) URI refers to the request-URI of the originated call request message. The cnonce parameter carries the earlier nonce to the UA. In the request.169. by using a particular algorithm.110 SIP/2. cnonce. and URI from the server upon receipt of the authorization request.1. For example: Authorization: DIGEST USERNAME="6540012". response. RESPONSE="b7c848831dc489f8dc663112b21ad3b6". the server has to re-generate a nonce to authenticate the user. Nonce is an encryption factor that is generated by the entity initiating the authorization procedure. in plain text in SIP messages. Response is a string of characters that the UA generates.tag=1ccb6df3 To: <sip:66500002@191. username. REALM="huawei.1. SoftX3000 will support the carddigest method to achieve Uniphone card number calls. INVITE sip:66500002@191. It indicates an INVITE request message for URI.1. The SIP protocol version is 2. The 4th line: This is a CSeq header field. Integrated Access Device (IAD).PRACK.110”.1.169.1. this is used to distinguish the users. we can find: A terminal.110”. 66500002.116:5061> Supported: 100rel. This header field identifies an INVITE that is globally unique. The tag is “1ccb6df3”.CANCEL.N OTIFY.110>”.169. When several users sharing the same SIP address originate INVITEs with the same Call-ID.169. The current address of the invited user is “sip:
[email protected]. The 3rd line: This is a To header field. used to correlate the INVITE request with the triggered responses and corresponding ACK and CANCEL requests.169. or Access Gateway (AG). The 5th line: This is a Call-ID header field. under the control of an MGC with the IP address “191.REFER Content-Length:230 Content-Type: application/sdp v: 0 o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.REGISTER.SUBSCRIBE. The terminal type might be ESL connected to SIP.INFO.OPTIONS.0.169.UPDATE.1. It indicates that the address of the request originator is “<sip:
[email protected]/UDP 191. It indicates that the address of the request recipient is “<sip:66500002@191. From the From and To header fields.100rel Max-Forwards:70 Allow:INVITE.branch=z9hG4bkbc427dad6 Contact: <sip:
[email protected]:5061.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. under the control of an MGC with the IP address “191.1. 44510000. The 2nd line: This is a From header field.MESSAGE.1.323.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000 Via: SIP/2.1.116 s: Sip Call c: IN IP4 191.169.116” dials a terminal.116>”.BYE.169. The Call-ID is “20973e49f7c52937fc6be224f9e52543@sx3000” in 3-20 .169. H. The second “1073741831” is the version number of the session announcement.0”. “branch=z9hG4bkbc427dad6” is the branch parameter. and the transport layer is “UDP”. indicating that the body carried in the message is a single message body based on the SDP. The 6th line: This is a Via header field. “191. which is provided for the proxy server to detect the latest one from the several announcements of the same session.1. “191. the session identifier.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. session identifier.169. “HuaweiSoftX3000” is the username that is used by the user to log into the originating host. and the session version number. “IN” refers to network indicator in the form of a text string. address type. The first “1073741831” is the session identifier. An SDP session description follows the white space.116”. This header field indicates the path through which the request passes.1. “IP4” refers to the address type in the form of a text string.116:5061” indicates that the IP address of the SoftX3000. network type. and address) to construct the session’s globally unique identifier. SoftX3000 tags all the branches. When concurrently delivering a request.1.169. The basic principle is to increment that version number once the session data is modified. Currently “IP4” and “IP6” are defined.169.1. Currently it is the version 0.116” and the used port is “5061”. This header field provides a reliable transmission mechanism for 100 response. used to give the originator (username and host address) of the session.169.116:5061> without the help of a Via header field. indicating that the maximum number of hops the request can transit on the way to its destination is 70. If the host does not support user identifier. The 8th line: This is a 100rel extension. “SIP/2. The 9th line: This is a Max-Forwards header field. the sender. 3-21 .169. The currently defined IN is Internet. The 14th line: This line contains the session owner/creator and the session identifier. in which the protocol name is “SIP”. The 10th line: This is an Allow header field. is “191. The 12th line: This is a white space. indicating that the subsequent requests (for example.0/UDP” represents the protocol for the transmission.1. BYE) can be directly sent to <sip:44510000@191. This header field lists the types of request messages that are supported by the SoftX3000 with a given IP address “191.116” is the IP address of the host that creates the session. The 13th line: This is the SDP protocol version number. The 11th line: This is a Content-Type header field. The 7th line: This is a Contact header field. The session identifier in the form of a digit string helps the multiple tuples (username. this field is tagged to be a sign “-“. the protocol version is “2. for audio and video. Udp. application.169. The 18th line: This line contains the media-level description. The format of such a line is a: rtpmap:<payload type><encoding name>/<clock rate>[/<coding parameter>]. It means that all the formats carried in the session might be used.323 phone). the IP address might be a full domain name or a compressed text IP6 address. 3-22 .323 terminal (the terminal type is SIP or H. There are two classes of protocols defined: RTP/AVP.1. It provides information that is suitable only for the media stream.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. the DUP protocol.323 terminal (the terminal type is SIP or H.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP If the address type is IP4. The whole line indicates that A-law PCM single-channel audio signal is used by default. “0” represents the start time. <coding parameter> refers to the number of audio channels. transported over UDP. specifying the mapping correspondence from RTP payload type to encoding. Each session description necessarily has one and only one session name. It provides a time segment when the session can be activated. The values of “start time” and “end time” are expressed in the decimal form of Network Time Protocol (NTP) time values. its static payload type is numbered 8 in the RTP audio/video application document. audio/video application document.323 phone). a great number of media service streams are transferred over RTP/UDP.169. In the format. the media payload type that is defined in the RTP audio/video application document. This parameter is unavailable to video signals. “RTP/AVP” is the transport layer protocol. “191. and control. 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. data. “8 0 4 18” is. For IP4.1. The 17th line: This line contains the time description.169.1. allowing the session to periodically occur. the IP address might be a full domain name or a dotted decimal IP4 address. If the address type is IP6.95” might also be the IP address of a SIP or H. that is. “30000” represents the transport-layer port to which the media stream is transmitted. Currently the network type and the address type are defined to be “IN” and “IP4”. and the signal is transmitted to a UDP port 30000.116. but the first one is the default format for the session. “191. Its value is associated with the type of address in the “c” line. The format for the field is t:<start time><end time>. The unit is second. “audio” refers to the media type. Currently five types of media are defined: audio. video. The 16th line: This line contains the connection related data. The 15th line: This line contains the session name. The 19th to 22nd lines: These lines introduce rtpmap attributes. 169. SIP/2.116>.1. 3) Example of response message The following is an example of SIP response message.169. 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. and a message body. Some parameters are optional for different response messages.tag=58877b85 Cseq:1 INVITE 3-23 . Response messages 1) Response format Figure 3-4 illustrates the format for a SIP response that is composed of a start line.tag=1ccb6df3 To: <sip:
[email protected] 180 Ringing From: <sip:44510000@191. A line feed character distinguishes each parameter line in the message header. a message header.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP II.1.110>. used to give the originator (username and host address) of the session.110 s=Sip Call c=IN IP4 191. and the session version number.0. Currently it is the version 0. The first “1073741824” is the session identifier.110:5061.1. The 2nd and 3rd lines: Refer to the example of SIP request. The 12th line: This is a white space. indicting to send the ringing tone to the callee. If the host does not support user identifier. The currently defined IN is 3-24 . which is provided for the proxy server to detect the latest one from the several announcements of the same session. The 4th line: This is a CSeq header field. The session identifier in the form of a digit string helps the multiple tuples (username. address type.1.116:5061.1. The basic principle is to increment that version number once the session data is modified.branch=z9hG4bkbc427dad6 Require:100rel RSeq:1 Contact:<sip:66500002@191. Both are “1 INVITE”. “HuaweiSoftX3000” is the username that is used by the user to log into the originating host. The 5th to 11th lines: Refer to the example of SIP request.169.0/UDP 191. The 14th line: This line contains the session owner/creator and the session identifier. “IN” refers to network indicator in the form of a text string. The 13th line: This is the SDP protocol version number. this field is tagged to be a sign “-“. network type.transport=udp> Content-Length:157 Content-Type:application/sdp v=0 o=HuaweisoftX3000 1073741824 1073741824 IN IP4 191.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000 Via: SIP/2. The protocol version is 2. The CSeq header field in this response has the same meaning as that in the earlier described request. The status code is 180. and address) to construct the session’s globally unique identifier.169.169. An SDP session description follows the white space. indicating the response is trigger by the previous request.169. the session identifier.135 t=0 0 m=audio 30016 RTP/AVP 8 a=rtpmap:8 PCMA/8000 The 1st line: The SIP protocol. “Ringing” is a descriptive phrase.1. used to correlate the INVITE request with the triggered responses and corresponding ACK and CANCLE requests. session identifier. The second “1073741824” is the version number of the session announcement. Its value is associated with the type of address in the “c” line. The SIP must periodically update the registration information. z The IP address of SIP Phone is 191. Each session description necessarily has one and only one session name.150.135” might also be the IP address of a SIP or H. 3-25 . “8” is the media payload type defined in the RTP audio/video application document.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. There are two classes of protocols defined: RTP/AVP.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.3.323 terminal (the terminal type is SIP or H.110. It provides a time segment when the session can be activated. “audio” refers to the media type. the SIP phone must re-register itself to the associated server. “191. The 18th line: This line contains the media-level description.3 Basic Message Procedures 3.323 phone). “RTP/AVP” is the transport layer protocol. “30016” represents the transport-layer port to which the media stream is transmitted.150.1. The 16th line: This line contains the connection related data.169.1. When the address of a SIP client changes. The RTP payload type “8” represents PCMA.169. audio/video application document. Currently the network type and the address type are defined to be “IN” and “IP4”. transported over UDP.323 phone). The 15th line: This line contains the session name. specifying the mapping correspondence from RTP payload type to encoding. “191. In the following example.1.323 terminal (the terminal type is SIP or H. 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.110” is the IP address of the host that creates the session. “191.30. it is assumed that z The IP address of SoftX3000 is 191. The 19th line: This line introduces a rtpmap attribute. For IP4. that is. Currently “IP4” and “IP6” are defined. the SIP phone must register itself to the associated server. 3. the DUP protocol. Udp.169. a great number of media service streams are transferred over RTP/UDP.1.169. allowing the session to periodically occur. The following scenario presents how a SIP phone registers itself to the SoftX3000 to illustrate the SIP user registration procedure. The 17th line: This line contains the time description. It provides information that is suitable only for the media stream.169.251.1 SIP User Registration Procedure When user powers on a SIP phone. 0/UDP 191.251 The 1st line: This is the start line of the request.30 SIP/2.251” in which “191.30.30.30.150.169.169. It indicates that the Register originator is a SIP Phone controlled by the MGC whose IP address is 191. The SIP protocol version is 2. In this example.30.169.2. 3-26 .169.30.169.150.150. The terminal is originating to register itself to the MGC whose IP address is 191. 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.150.150.150.251” is the IP address of SIP Phone originating the Register request and “1-reg” is the local identifier. The following is an example of Register request. This header field identifies an INVITE that is globally unique.169. It indicates a Register request message.251 Cseq: 2762 REGISTER Contact: sip:
[email protected]=16838c16838 To: sip:
[email protected]. The 2nd line: This is a From header field. notifying SoftX3000 of an on-power event or a restart event and requesting to register to MGC.150. It indicates the address of the Register recipient.169.7 (VxWorks) Via: SIP/2. MGC.150. The 4th line: This is a Call-ID header field. timer User-Agent: Pingtel/1. sip-cc-01.150. REGISTER sip:191.169.169. is 191.0.169. The 3rd line: This is a To header field.251 Expires: 100 Content-Length: 0 Accept-Language: en Supported: sip-cc.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 3 SIP SIP Phone requests to register itself to SoftX3000. the address of the Register recipient.150.0 From: sip:
[email protected]=946e6f96 Call-Id: 1-reg@191. The Call-ID is “1-reg@191. 2) Event 2: SoftX3000 returns a 401 Unauthorized response.com". and timer extension protocols. The WWW-Authenticate field carries the authorization method.nonce="200361722310491179922" Content-Length: 0 3) Event 3: SIP Phone re-originates a Register request to SoftX3000. URI. “191.150. the message does not carry a session description.0/UDP 191. used to correlate the Register request with the responses it triggers.169. indicating that MGC requires authenticating the user. It indicates that the current IP address of SIP Phone is “191. The request carries an Authorization header field that contains an authorization method (“digest”).251 WWW-Authenticate: Digest realm="huawei. MGC’s domain name.150.tag=946e6f96 CSeq: 2762 REGISTER Call-ID: 1-reg@191. “SIP/2.150. This header field indicates the path taken by the request.251” and the telephone number is “6540012”.30>.169.150. SoftX3000 generates a nonce required for this authorization.169. “huawei. The 11th line: This line contains information of the user terminal that originates the request. The Contact header field in the Register request indicates the reachable location of the user.150. “2.251 Via: SIP/2.150. (The contained 3-27 . SIP Phone’s user identifier (a telephone number in this example).30>. The 7th line: This line indicates that the lifetime of the Register is 100s.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP The 5th line: This is a CSeq header field. and response parameters.0/UDP” represents the protocol used for the transmission. supports sip-cc. “digest”. “timer” represents that the terminal supports the session-timer extension protocol. the information includes the type and the version number of SIP Phone. This response carries those parameters to the terminal to initiate an authorization procedure.169. The 12th line: This is a Via header field. nonce.169. In this example. The 6th line: This is a Contact header field.com”.0” is the protocol version number. and “UDP” is the transport layer. The 10th line: This line indicates that the message sender.0 401 Unauthorized From: <sip:6540012@191. that is supported by MGC and the domain name of MGC. The 8th line: This line indicates that the length of the message body of the request is null. in which “SIP” is the protocol name. a UA entity.tag=16838c16838 To: <sip:
[email protected]. that is.251” represents the IP address of the request sender. SIP/2. or the status answer contents carried in the answer message. The 9th line: This line indicates that English is the preferred language to mention the reason phrase. sip-cc01. the session description. 150. the authorization fails.30.30>. REGISTER sip:191.150. 3-28 .169. If they are consistent.251 4) Event 4: Upon receipt of the Register request from SIP Phone.169. by using a particular algorithm according to the information returned from the server as well as the user configurations. MGC will return a failure message.expires=3600 Content-Length: 0 3.169.30 SIP/2.com".150.169.tag=16838c16838 To: sip:6540012@191. timer User-Agent: Pingtel/1.0 200 OK From: <sip:
[email protected] From: sip:6540012@191. If the received nonce is the same as that carried in the 401 Unauthorized response message.169. MGC compares the new response parameter with that carried in the request message.3.169. sip-cc-01. Otherwise.169.150.30.251 Cseq: 2763 REGISTER Contact: sip:
[email protected]/UDP 191.tag=946e6f96 Call-Id: 1-reg@191. RESPONSE="b7c848831dc489f8dc663112b21ad3b6". Subsequently.7 (VxWorks) Authorization: DIGEST USERNAME="6540012".251>.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP response parameter contains a response that SIP Phone encrypts.169. indicating the success of the terminal authorization. NONCE="200361722310491179922". password (obtained from the local user information).30>. MGC collects the nonce. upon receipt of the 401 Unauthorized response message.tag=946e6f96 CSeq: 2763 REGISTER Call-ID:
[email protected] Via: SIP/2. REALM="huawei.169.150.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. URI="sip:191.150.251 Expires: 100 Content-Length: 0 Accept-Language: en Supported: sip-cc.169.0/UDP 191. MGC returns a 200 OK response message.150.150.251 Contact: <sip:6540012@191. otherwise. and URI and uses the same algorithm as used at the terminal to generate a new response parameter.169.150.) The following is an example of Register request. username.150. SIP Phone passes the check. SIP/2.150.169. MGC checks the correctness of the nonce. the user successfully passes the authorization.2.tag=16838c16838 To: <sip:
[email protected]" Via: SIP/2.150. INVITE sip:
[email protected] Cseq: 1 INVITE Contact: sip:1000@191. z SIP Phone A originates a call to SIP Phone B.169. z The IP address of SIP Phone B is 191. REGISTER. payload type.150.169. OPTIONS.200.169.61 SIP/2.0 From: sip:1000@191. and the telephone number of SIP Phone B is 1001. encoding information matching the payload type to MGC.169.169.100.169. SUBSCRIBE 3-29 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP In the following example. requesting MGC to invite SIP Phone B to a session.150. it is assumed that z The IP address of SoftX3000 is 191. SIP Phone A 1 2 3 4 SoftX3000 SIP Phone B INVITE 100 Trying 407 ACK 5 INVITE 6 100 Trying 10 180 Ringing 12 13 200 OK ACK INVITE 7 8 100 Trying 9 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.169.150. z The IP address of SIP Phone A is 191.101). The session description of the INVITE message carries SIP Phone A’s IP address (191.tag=1c12674 To: sip:
[email protected] Content-Type: application/sdp Content-Length: 203 Accept-Language: en Allow: INVITE. BYE. z The telephone number of SIP Phone A is 1000.61 Call-Id: call-973598097-16@191. NOTIFY. and the calling party hooks on first.169.101.150.150.61. ACK. CANCEL.200. port number (8766).169. REFER. 101 Proxy-Authenticate: Digest realm="huawei.169.nonce="1056131458" Content-Length: 0 4) Event 4: SIP Phone A sends an ACK message to MGC.150.169.169.169.169. refer to the example of request message in the Request Messages section. notifying SIP Phone A of the receipt of the request and also that MGC is processing the request. indicating that MGC requires authenticating the user.200.101 s=phone-call c=IN IP4 191.150. This response message carries those parameters to the terminal to initiate an authorization procedure.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Supported: sip-cc.0 407 Proxy Authentication Required From: <sip:
[email protected] Content-Length: 0 3) Event 3: MGC sends a 407 Proxy Authentication Required response to SIP Phone A.0 100 Trying From: <sip:
[email protected] 3-30 . that is supported by MGC and the domain name of MGC.61>.101 v=0 o=Pingtel 5 5 IN IP4 191.tag=de40692f CSeq: 1 INVITE Call-ID: call-973598097-16@191. The Proxy-Authenticate field carries the authorization method.101 Via: SIP/2.61>.169.169.150.169.150. SIP/2.169.61 SIP/2.com".150.169. “digest”.0/UDP 191. sip-cc-01.com”.61>.169. ACK sip:
[email protected]/UDP 191.200.200.150.0 Contact: sip:1000@191. acknowledging the receipt of the final response to the INVITE request from MGC.tag=1c12674 To: <sip:
[email protected] (VxWorks) Via: SIP/2.150.169.0/UDP 191.169.200. “huawei. SIP/2. MGC generates a nonce required for this authorization.2.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.101 Via: SIP/2.tag=1c12674 To: <sip:
[email protected]> CSeq: 1 INVITE Call-ID:
[email protected]. timer User-Agent: Pingtel/1. 2) Event 2: MGC returns a 100 Trying response to SIP Phone A. 7 (VxWorks) Proxy-Authorization: DIGEST NONCE="1056131458".169. CANCEL.61>.200.169. URI="sip:1001@191. REALM="huawei.tag=1c12674 To: <sip:
[email protected] Cseq: 2 INVITE Contact: sip:
[email protected]=de40692f Call-Id:
[email protected]>.169. nonce. The request carries a Proxy-Authorization field that contains an authorization method (“digest”).169.61.101 v=0 o=Pingtel 5 5 IN IP4 191.150.169.7 (VxWorks) Via: SIP/2. RESPONSE="1b5d3b2a5441cd13c1f2e4d6a7d5074d". REFER.101 Content-Type: application/sdp Content-Length: 203 Accept-Language: en Allow: INVITE.150. (The contained response parameter contains a response that SIP Phone A encrypts.61 SIP/2. upon receipt of the 407 response message.169. and response parameters.0/UDP 191.169. SUBSCRIBE Supported: sip-cc.169.169. timer User-Agent: Pingtel/1.150. ACK.150.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP From: <sip:1000@191. OPTIONS. REGISTER.150. URI. USERNAME="1000".169.com".) INVITE sip:
[email protected] From: sip:
[email protected] Content-Length: 0 5) Event 5: SIP Phone A re-originates an INVITE request to SoftX3000.200.101 Cseq: 1 ACK Accept-Language: en User-Agent: Pingtel/1.169. sip-cc-01. by using a particular algorithm according to the information returned from the server as well as the user configurations.61" Via: SIP/2.tag=1c12674 To: sip:
[email protected]/UDP 191. BYE.2.101 s=phone-call c=IN IP4 191.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 .200. MGC’s domain name. NOTIFY. SIP Phone’s user identifier (a telephone number in this example).61 Call-Id:
[email protected]. REGISTER.0 From: <sip:
[email protected] 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.169.61>. SIP/2.tag=1c12674 To: <sip:
[email protected]> CSeq: 2 INVITE Call-ID:
[email protected]. INVITE sip:
[email protected] Content-Length: 0 7) Event 7: MGC sends an INVITE message to SIP Phone B.169.169.61>.169.200.61:5061. The INVITE message carries SIP Phone A’s session description to SIP Phone B.61>.150.0 100 Trying From: <sip:
[email protected] 100 Trying From: <sip:
[email protected]. notifying SIP Phone A of the receipt of the request and also that MGC is processing the request.150. MESSAGE.169.tag=1fd84419 To: <sip:1001@191. requesting SIP Phone B to participate in the session.100rel Max-Forwards: 70 Allow: INVITE.0/UDP 191.101 Via: SIP/2.tag=4239 Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 1 INVITE 3-32 .SUBSCRIBE.branch=z9hG4bK8fd4310b0 Contact: <sip:
[email protected]> CSeq: 1 INVITE Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Via: SIP/2.BYE.200.169.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.ACK. SIP/2.100>.NOTIFY.150.200.tag=1fd84419 To: <sip:
[email protected]:5061> Supported: 100rel.150.100 SIP/2.169.PRACK.UPDATE.169.169.61 s=Sip Call c=IN IP4 191.0/UDP 191.200.REFER Content-Length: 183 Content-Type: application/sdp v=0 o=HuaweiSoftX3000 1073741833 1073741833 IN IP4 191. notifying MGC of the receipt of the request and also that SIP Phone B is processing the request.INFO.200.169.200.169. tag=4239 Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 1 INVITE Content-Type: application/sdp Content-Length: 164 Via: SIP/2.169.100>.100 User-Agent: Pingtel/1.169.169.150.200.169.tag=1c12674 To: <sip:1001@191. The message carries its IP address (191.0/UDP 191.150.transport=udp> Content-Length: 0 11) Event 11: SIP Phone B sends a 200 OK response to MGC.branch=z9hG4bK8fd4310b0 Contact: sip:
[email protected]:5061. BYE.61:5061.150. ACK.tag=e110e016 CSeq: 2 INVITE Call-ID:
[email protected]. payload type.0/UDP 191.61:5061.0. CANCEL.tag=1fd84419 To: <sip:
[email protected] Via: SIP/2.150.0 (VxWorks) CONTENT-LENGTH: 0 10) Event 10: MGC sends a 180 Ringing response to SIP Phone A.0/UDP 191.150.0.0 180 Ringing From: <sip:
[email protected] Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Via: SIP/2.0 (VxWorks) 3-33 .200.169.200.169.169.0/UDP 191.169.101).61>. encoding information matching the payload type to MGC.150.0 180 Ringing From: <sip:1000@191. SIP/2.200. REFER.tag=4239 Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 1 INVITE Via: SIP/2. notifying that SIP Phone B has successfully received and processed the INVITE request.169.200.200.branch=z9hG4bK8fd4310b0 Contact: sip:1001@191. SIP/2.61>.200.tag=1fd84419 To: <sip:
[email protected]:5061. SIP/2. SIP Phone A receives the ringback tone.200.101 Contact: <sip:1001@191. port number (8766).0 200 OK From: <sip:
[email protected] Allow: INVITE.150.100>.100 User-Agent: Pingtel/1.150.0. OPTIONS.169.169.61>.0 (VxWorks) CONTENT-LENGTH: 0 9) Event 9: SIP Phone B receives the ringing tone and returns a 180 Ringing response to MGC.61>.branch=z9hG4bK8fd4310b0 Session-Expires: 36000 Contact: sip:1001@191. NOTIFY User-Agent: Pingtel/1. 61>.61>.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.transport=udp> Content-Length: 183 Content-Type: application/sdp v=0 o=HuaweiSoftX3000 1073741834 1073741834 IN IP4 191.200.169. ACK sip:
[email protected]=1c12674 To: <sip:
[email protected]=e110e016 CSeq: 2 INVITE Call-ID:
[email protected]:5061. acknowledging the receipt of the final response to the INVITE request from MGC.169.101 Via: SIP/2.0 Contact: sip:
[email protected]>.169.169.169.101 Content-Length: 0 3-34 .150.169.150.100 s=phone-call c=IN IP4 191.101 Contact: <sip:
[email protected] 200 OK From: <sip:
[email protected] Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP v=0 o=Pingtel 5 5 IN IP4 191.150.tag=e110e016 Call-Id:
[email protected]=1c12674 To: <sip:
[email protected] From: <sip:
[email protected]. SIP/2.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.7 (VxWorks) Via: SIP/2.101 Cseq: 2 ACK Accept-Language: en User-Agent: Pingtel/1.0/UDP 191.61 s=Sip Call c=IN IP4 191.2.150.169.transport=UDP SIP/2.0/UDP 191.169. and MGC sends the session description of SIP Phone B to SIP Phone A. notifying that MGC has successfully received and processed the INVITE request.61>.61:5061.169.169.150.200.150.200. SIP/2.transport=UDP SIP/2.200.169.169.branch=z9hG4bKf5dbf00dd Max-Forwards: 70 Content-Length: 0 3-35 .0 From: sip:
[email protected]:5061.0 487 Request Terminated From: <sip:
[email protected]:5061.169. BYE sip:
[email protected]=e110e016 Call-Id:
[email protected] (VxWorks) Via: SIP/2. indicating the termination.169.branch=z9hG4bK44cfc1f25 Max-Forwards: 70 Content-Length: 0 15) Event 15: SIP Phone A hooks on and sends a BYE message to MGC.200.169.61. the calling and called parties know both session descriptions and then starts a conversation.100 SIP/2.200.150.169.169.61>.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP 14) Event 14: MGC sends an ACK message to SIP Phone B.tag=e110e016 CSeq: 4 BYE Call-ID:
[email protected] Content-Length: 0 16) Event 16: MGC returns a 487 response to SIP Phone A.100 SIP/2.100>.61:5061.200.169.0/UDP 191.101 Via: SIP/2. acknowledging the receipt of the final response to the INVITE request from SIP Phone B.0 From: <sip:
[email protected]. requesting to terminate the session.0/UDP 191.101 Cseq: 4 BYE Accept-Language: en Supported: sip-cc.150. sip-cc-01.150.2.150.tag=1c12674 To: <sip:1001@191. ACK sip:
[email protected]=1c12674 To: sip:1001@191. BYE sip:
[email protected]=4239 CSeq: 2 BYE Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Via: SIP/2. Now.tag=4239 CSeq: 1 ACK Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Via: SIP/2.150.tag=1fd84419 To: <sip:
[email protected]/UDP 191. requesting to terminate the session.169.169.tag=1fd84419 To: <sip:
[email protected]. MGC sends a BYE request to SIP Phone B.0 From: <sip:
[email protected]/UDP 191.200.100>.150.200.169.61>.61>.169.169. timer User-Agent: Pingtel/1.200.101 Content-Length: 0 17) Event 17: MGC receives the BYE from SIP Phone A and knows the on-hook event.61>. 3 Successful SIP Trunk Call Procedure Figure 3-7 illustrates an example of a successful SIP trunk call procedure where two SoftX3000s communicate with each other through SIP. z The IP address of SoftX3000 B is 191.112.tag=1fd84419 To: <sip:
[email protected]. SIP/2.1. and the called party hooks on first.169. z SIP Phone B controlled by SoftX3000 B has a telephone number 5550045. BYE.branch=z9hG4bKf5dbf00dd Contact: sip:
[email protected]:5061.150. SoftX3000 A sends an INVITE message to SoftX3000 B. The session description of the INVITE message carries SoftX3000 A’s IP address (191. SoftX3000 A 1 SoftX3000 B INVITE 2 100 Trying 3 180 Ringing 4 200 OK 5 ACK 6 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.0/UDP 191.169.200.100>. CANCEL.tag=4239 Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000 Cseq: 2 BYE Via: SIP/2.100 Allow: INVITE.200.169. z SIP Phone A controlled by SoftX3000 A has a telephone number 66600003. REFER.169.61). In the following example.169.61>.150.110. ACK.0 (VxWorks) CONTENT-LENGTH: 0 3.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.169.3. indicating that the session is successfully terminated.200.0 200 OK From: <sip:1000@191. inviting SoftX3000 to the session.0. NOTIFY User-Agent: Pingtel/1. OPTIONS. it is assumed that z The IP address of SoftX3000 A is 191. z SIP Phone A originates a call to SIP Phone B.1. SIP Phone 3-36 . 50>.SUBSCRIBE.101).0 From: <sip:
[email protected]/UDP 191.169.169. supported payload type.REGISTER. encoding information matching the payload type to SoftX3000 B.100rel Max-Forwards: 70 Allow: INVITE.100.200.branch=z9hG4bKff661c627 Contact: <sip:
[email protected]:5061> Supported: 100rel.61:5061.200.169.50> CSeq: 1 INVITE Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 Via: SIP/2.169.200. SIP/2.50> CSeq: 1 INVITE Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 Via: SIP/2.100. SIP/2. notifying SoftX3000 A of the ringing event at SIP Phone B. MESSAGE.61>.200.tag=64e3f587 To: <sip:
[email protected]=64e3f587 To: <sip:
[email protected] 100 Trying From: <sip:
[email protected]>.200.UPDATE.branch=z9hG4bKff661c627 Content-Length: 0 3) Event 3: SoftX3000 B sends a 180 Ringing response to SoftX3000 A.0 180 Ringing From: <sip:
[email protected] Content-Length: 184 Content-Type: application/sdp v=0 o=HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.200.169. notifying SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing the request.169. INVITE sip:
[email protected]=2dc18caf CSeq: 1 INVITE Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 3-37 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP A’s IP address (191.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.169.200.61>.169. port number (30014).169.61 s=Sip Call c=IN IP4 191.169.50 SIP/2.0/UDP 191.INFO.OPTIONS.100.tag=64e3f587 To: <sip:
[email protected]:5061.CANCEL.BYE.200.169. 100.100. BYE sip:
[email protected]:5061 SIP/2.0/UDP 191.61:5061.tag=2dc18caf CSeq: 1 INVITE Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 Via: SIP/2.branch=z9hG4bKff661c627 Contact: <sip:
[email protected]:5061.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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Via: SIP/2.169.169.100.169.200.100.0/UDP 191.branch=z9hG4bKff661c627 Contact: <sip:5550045@191. supported payload type.50).100.tag=2dc18caf CSeq: 1 ACK Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 Via: SIP/2.50>.100.200.200.transport=udp> Content-Length: 0 4) Event 4: SoftX3000 B sends a 200 OK response to SoftX3000 A.200. The message carries its IP address (191.50>. port number (40000).169.61:5061.169.0 From: <sip:
[email protected]>.transport=udp SIP/2.169.50 s=Sip Call c=IN IP4 191. SIP Phone B's IP address (191.200. SoftX3000 B sends a BYE message to SoftX3000 A.169. requesting to terminate the session.61>.100.50:5061.169.50:5061.200.tag=64e3f587 CSeq: 1 BYE Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 3-38 .0/UDP 191.169.169.50:5061. acknowledging the receipt of the final response to the INVITE request from SoftX3000 B. notifying that SoftX3000 B has successfully received and processed the INVITE request.0 From: <sip:
[email protected]>.tag=64e3f587 To: <sip:
[email protected]. ACK sip:
[email protected]=udp> Content-Length: 159 Content-Type: application/sdp v=0 o=HuaweiSoftX3000 1073741826 1073741826 IN IP4 191.100.169.0 200 OK From: <sip:
[email protected]>.tag=64e3f587 To: <sip:
[email protected]=2dc18caf To: <sip:
[email protected]). SIP/2. encoding information matching the payload type to SoftX3000 A.200.100.branch=z9hG4bK7d4f55f15 Max-Forwards: 70 Content-Length: 0 6) Event 6: SIP Phone B hooks on. 0/UDP 191.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 3 SIP Via: SIP/2.0/UDP 191.50:5061.3. There are three application models: PSTN-IP. A successful SIP-T trunk call procedure is shown in Figure 3-8.branch=z9hG4bK2a292692a Content-Length: 0 3. z Mapping: mapping between ISUP signaling and SIP messages and mapping between ISUP parameters and SIP header fields. SIP-T has the following characteristics: z Encapsulation: SIP message body carries ISUP messages.tag=2dc18caf To: <sip:
[email protected] 487 Request Terminated From: <sip:
[email protected]. SIP/2. indicating the termination.169. IP-PSTN.100.100. and PSTN-IP-PSTN.branch=z9hG4bK2a292692a Max-Forwards: 70 Content-Length: 0 7) Event 7: SoftX3000 A returns a 487 response to SoftX3000 B.100. 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.50>. Based on SIP.tag=64e3f587 CSeq: 1 BYE Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000 Via: SIP/2.169.200.61>. 3-39 .50:5061. SIP-T provides an extension mechanism of how to achieve the interworking between SIP network and PSTN network.169.4 Successful SIP-T Trunk Call Procedure SIP-T is not a new protocol. 3) Event 3: The called PSTN user receives the ringing tone. 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.1). supported payload type.169. encoding information matching the payload type to SoftX3000 B. SoftX3000 B encapsulates the ACM in a 180 Ringing response message and sends it to SoftX3000 A. notifying SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing the request. 2) Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A. port number (30014).200. encoding information matching the payload type to SoftX3000 A. Upon receipt of the IAM from SG A. SG A receives the ACM. Upon receipt of the 180 Ringing message. SG B sends an Address Complete Message (ACM) to SoftX3000 B. Meanwhile. The session description of the 180 Ringing message carries SG B’s IP address (191. The session description of the INVITE message carries SG A’s IP address (191.188). SoftX3000 A extracts the ACM from the 180 Ringing message and transfers the extracted ACM to SG A. port number (13304).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 7 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.150. supported payload type.169. 3-40 . and meanwhile the calling PSTN user receives the ringback tone. Upon receipt of the ACM. acknowledging the receipt of the final response to the INVITE request from SoftX3000 B. SoftX3000 A extracts the ANM from the 200 OK message and transfers the extracted ANM to SG A. SoftX3000 B encapsulates the RLC to the message body (SDP) of a 200 OK response message and sends it to SoftX3000 A. a bi-directional signaling channel is set up between the calling and called parties for them to make a conversation. Now. Upon receipt of the RLC. 3-41 . SG B sends an Answer Message (ANM) to SoftX3000 B. Upon receipt of the REL message. Upon receipt of the 200 OK response. Upon receipt of the ANM. SoftX3000 A encapsulates the REL in the message body (SDP) of a BYE request message and sends it to SoftX3000 B. SG B sends a Release Complete Message (RLC) to SoftX3000 B. The PSTN switch receives the message and sends the busy tone to the called PSTN user. The called PSTN user hooks on. Upon receipt of the 200 OK message. 6) Event 6: The calling PSTN user hooks on. 7) Event 7: Upon receipt of the REL message. SG B knows that the calling PSTN user has hooked on. Upon receipt of the BYE message. SG A sends a Release (REL) message to SoftX3000 A. SoftX3000 A extracts the RLC from the 200 OK response and transfers the extracted RLC to SG A.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 4) Chapter 3 SIP Event 4: The called PSTN user hooks off. and then transfers the REL to the associated PSTN switch. SoftX3000 B encapsulates the ANM to the message body (SDP) of a 200 OK response message and sends it to SoftX3000 A. 5) Event 5: SoftX3000 A sends an ACK message to SoftX3000 B. SoftX3000 B extracts the REL from the BYE message and transfers the extracted REL to SG B. Terminals.323 entity An H.323 H. It can be integrated in 4-1 . It can generate and terminates media streams. multipoint processor (MP) for the centralized processing of audio. The latest version of H. and MCUs. two-way communications with another H. An endpoint can generate and terminate calls. multipoint controller (MC) for controlling participation of terminals in multipoint conferences.323 entity is any H. AAA AAA stands for authentication. and allowing the user to access certain network resources.323 entities (call control for instance) might be used in point-to-point sessions and multipoint conferences. or MCU. H.1. and accounting. Authentication is the process of checking whether the user has certain permission. H. 4. Authorization is the process of granting the permission to the user.323 describes the components of an H. including gateway (GW) between switched circuit network (SCN) and PBN.323 terminal is an endpoint on the network which provides real-time. gateways. including terminals.323 4. H. Accounting is the process of recording information when the subscriber is using a certain service. gatekeepers.323 is an ITU-T Recommendation which covers the technical requirements for multimedia communications systems in a packet based network (PBN). Such information is used to generate bills. III.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.1 What is H. II.2 Definition of Terms I.323 Chapter 4 H. gateways and MCU are known as endpoints. gateway. MCs.1 Overview of H. H. MPs. and multipoint control unit (MCU) for providing the capability for terminals and gateways to participate multipoint conferences.323 4.323 is Version 4 (V4). gatekeeper (GK) for address translation and access control.323 terminal. video. authorization. and/or data streams in a multipoint conference.323 component.323 terminal An H.1.323 system. V.323 GW interconnects different types of network. They all serve for conferencing purpose. controlling bandwidth variation. It can call and be called. The GK provides the following services and features for the H. Gateway An H.323 endpoints: z Access control: Permitting the use of network resources after identity check. or can be an independent device. When a terminal joins or leaves the conference. the MC will adjust the capability set sent to all terminals.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. gateways. z Bandwidth management: Applying for initial bandwidth.323 control signaling.323 control signaling and signaling of the other type of network. A zone has one and only one GK. 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 a personal computer. z Zone management: Managing terminals. Multipoint conference The components of multipoint conference are MC. and MCU. two-way communications between H.323 Gateway (GW) is an endpoint on the network which provides for real-time. If the GW connects two different networks.323 entity interacts with an end user directly. An H. z Charging management: Providing basic charging data to the billing center. PBN and SCN for instance. and may or may not include GWs or MCUs. MP. An H.323 terminals on PBN and other ITU Terminals on an SCN or to another H.323 entity on the network that manages the H. z Address translation: Translating between alias and network address. The MC provides for capability negotiation with all terminals to achieve common levels of communications. it needs to convert between H. GWs and MCUs in the zone. and MCUs in a zone. such as Ethernet-phone or video phone. It may also control conference resources such as who is multicasting video. It can also process media streams. A zone includes at least one terminal. The multipoint controller (MC) provides for the control of three or more terminals participating in a multipoint conference. converts the format and content of signaling messages. and also the communication protocol procedures and media stream format. IV. 4-2 . z Call control: Providing supplementary services. Gatekeeper The gatekeeper (GK) is an H.323 terminals. VI.323 gateway. 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. video. The MP within the MCU processes the audio. The terminals transmit their control. 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. The MCU consists of two parts: a mandatory MC and optional MPs. It controls and manages the multipoint conference and all attended terminals. audio. the MP can implement the codec algorithms of all types of media streams. and/or data streams to the MCU. The MC within the MCU centrally manages the conference. 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. video. Figure 4-1 shows a typical networking model of centralized multipoint conference. 4-3 . and/or data streams. Figure 4-2 shows a typical networking model of decentralized multipoint conference. Therefore. and returns the processed streams to each terminal. video.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. The MC and MP are functional entities rather than physical ones. and performs mixing or switching of audio. The MCU manages the control messages and data messages only. video and data. and returns the processed streams to each terminal. and data streams in a multipoint conference.323 The multipoint processor (MP) processes the audio. Radius specifies the format of the authentication. call signaling and media control messages. which transmits data signals. 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. 4.3 Structure of H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. The three layers at the bottom of the stack are bottom-layer protocols of PBN. which transmits audio-visual signals in real time. the physical layer is MAC-IPX. The other is reliable transmission protocol like Transmission Control Protocol (TCP). There are two types of transport-layer protocols. Radius Radius stands for Remote Authentication Dial-In User Service. One is unreliable transmission protocol like User Data Protocol (UDP). It is an AAA protocol widely in use. In IP network. 4-4 .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. In LAN. the network layer is IP.323 protocol stack.323 Protocol Stack Figure 4-4 shows the structure of H. and sends registration messages to GK.1. authorization and accounting messages interacting at Radius server and client. It defines call signaling protocols and media stream packetization for packet-based multimedia communication systems.225.723.711 for PCM is mandatory and other G series Recommendations are optional. All H. defining RAS. and provides QoS monitoring feature.225. such as H.0 also covers two other features: specifying the use of RTP/RTCP for media stream packetization and synchronization. which stands for Registration.261 and H.729A and G. The principal function of H.245 TPKT T.26x RTCP RTP Terminal to Gatekeeper Signaling (RAS) H. z Recommendation T.711.323 protocol stack The H. Admission and Status.245 control channel between H.225. z RAS.7xx H. z H.323 protocol processing software includes the following parts: z All H.323 endpoints before starting a call.323 terminals shall have an audio codec.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System A/V Application Chapter 4 H.323 terminals shall be capable of encoding and decoding speech according to Recommendation G.123 Reliable Transport (TCP) Network Layer (IP) Link Layer Physical Layer Figure 4-4 H.120 is the default basis of data interoperability in multimedia conferences.1. z 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.260 Recommendation series. The RAS signaling function uses 4-5 .323 protocol stack.323 Terminal Control and Management Data Application Conference Manager T.0 Call Signaling Unreliable Transport (UDP) H. H.0 is the core of H.124 T.263 specify the video codec.0 serves for call control. specifies a type of message used between endpoint and GK.125 G. z H.225 is to establish call connections and H. H.225. The most frequently-used Recommendations in IP telephony are G. G. H.0 and H.0 is drafted based on Q.323 network.323 Domain H.323 Terminal SoftX SoftX H.225.245 is the control protocol for multimedia communication. and the transport protocol is UDP and TCP.323 Applications in SoftX3000 SoftX3000 implements multimedia communication services in H.245 is the control protocol in H. H. and controls the establishment.323 GK+GW H. while H.323 GW and an H. admissions.225. SoftX3000 can serve as an H. SoftX3000 provides two H.245 are borne over TCP.323 interfaces. z Recommendation H.245 will be detailed in the following sections.323 domain.225.225. z Recommendation H. RAS is borne over UDP. status.0 messages to perform registration. SoftX3000 serves as an H. H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. ITU-T Recommendation Q. Figure 4-5 shows the H. bandwidth changes.323 Applications in SoftX3000 4-6 H.931 and Q.323 Domain H.323 GW. 1) One is called SoftX3000 H.323 applications in SoftX3000.323.0 and H.323 GK H.225. 2) The other is called H.323 GW Other Networks H. maintenance and release of channels.323 GW Figure 4-5 H. which is the interface of H. which interfaces the external H.323 domain.245 are used in SoftX3000.323 GK at the same time.323 H. It is designed for conference communication.931 is ISDN user-network interface layer-3 specification for basic call control.932. The network protocol is IP. and disengage procedures between endpoints and GKs. 4.4 H.323 Terminal . RAS.323 terminals under direct control of SoftX3000.0 and H.1. z RAS. H.323 stack. z SoftX3000 verifies the username and password retrieved from the H. and provides SIP. Q.245. SoftX3000 H. and implements management function. ISUP and MGCP interfaces to other networks.2 RAS Protocol 4.323 interfaces support signaling and protocol of RAS.225.1 Overview of RAS RAS is a part of H. IV. 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. must register at an external H.323 GW.323 terminals in the domain must register at SoftX3000 before using any services provided by SoftX3000. All H. including all H.323 domain.2. Q. H. all RAS messages will be transmitted between the endpoint and its homed GK.323 terminals in the domain.323 interfaces support signaling and protocol of RAS. 4-7 . Afterwards. including alias and transmission layer address of call control channel. 4. z SoftX3000 registers the addresses of all terminals connecting through itself to the external GK. as an H. to request the GK whether the call can be originated.323 I.0. It includes the following seven categories of procedures: I.323 terminal. II.323 domain z SoftX3000.931 and H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. II. z The H. z The H.245. This procedure also includes deregistration procedure. z SoftX3000 serves as an H. Terminal to GK admission It is the first operation when a call is initiated. which is used between endpoint and GK.323 GW.323 GK in the domain.931 and H. III. Terminal and GW registration It is used by an endpoint to register its information with the GK. GK discovery An endpoint uses multicast mode to discover the homed GK.323 GK before using the services provided in the H.323 domain z SoftX3000 services as an H. Terminal to GK requests for changes in bandwidth During a call.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. 4. GW resource availability It is used to report the available resources of a gateway to the GK. and the GK determines whether to change. Status request It is used by GK to request the power on/off status of terminal.2 RAS Messages I. the endpoint can request to GK for changes in bandwidth. VII. Disengage After a call is over. VI. this procedure is used to notify the GK that the endpoint exits the call and resumes free.323 V.2. 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 . VIII. 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 Message name URJ Chapter 4 H. Any associated response messages (success or failure) shall have the corresponding requestSeqNum returned with it. For instance.0 Message name Parameter 1 Parameter 2 ……… Figure 4-6 Generic architecture of RAS message III. It is assigned by the request party and increments by 1. These parameters vary in different messages. ITU-T Recommendation H. RAS common message elements This section describes ASN. and consists of message name and some mandatory and optional parameters.1 structures that are used in more than one RAS messages. RAS message format A RAS message is in text format. Retransmitted messages shall have the same requestSeqNum.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. Figure 4-6 illustrates a generic architecture of RAS message. 1) RequestSeqNum All RAS messages include requestSeqNum. 4-10 .225.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. GRQ message and the triggered GCF or GRJ share the same requestSeqNum. If it is not supplied. it identifies the GK that will respond to the request. and are translated to the same transport-layer address. 6) GatekeeperIdentifier For RAS request messages. endpointType. E-mail name or other identifier name. the latter of which identifies the GW. 8) EndpointAlias It is a list of alias addresses. the GK can also return a sequence of prioritized endpoint alternatives for rasAddress.225 Recommendation.164 address contains access code and telephone number. then the mc Boolean would be true.164 address or an H. All these alias addresses are sent to GK in the PRQ messages.323 element has an MC. An E. the request message is valid to all reachable GKs. 7) CallServices It provides information on support of optional Q-series protocols to GK and called terminal.323 ProtocolIdentifier The protocolIdentifier “determines the vintage of the implementations involved”.323 identifier is a string of subscriber name. This parameter is used to improve call connection rate. 4) RasAddress This is the registration and status transport address for this endpoint. If the H. GK returns a prioritized endpoint as called party. it identifies the GK that returns the response message. An H. 9) AlternateEndpoints When an endpoint calls another or an alias. One endpoint can have multiple alias addresses corresponding to PRQ messages. set to FALSE if registering only. It defines the version number of the H. 5) EndpointType It specifies the type of the endpoint—terminal.323 identifier. Alternatively. or endpointAlias.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System 2) Chapter 4 H. 10) DiscoveryComplete It is included in RRQ message. GW or MCU. RAS messages are transmitted on top of UDP in well-known port 1719. 3) NonStandardData It carries the non-standard information such as proprietary data that is not defined in H. by which other terminals may identify this terminal. Set to TRUE if the requesting endpoint has preceded this message with the gatekeeper discovery procedure.225 Recommendation used. 11) CallSignalAddress 4-11 . For RAS response messages. An alias address can be an E. tokens and timeToLive. The parameter is included in PRQ and PCF messages. 19) CallModel H. the endpoint is requesting the direct terminal to terminal call model. thus protecting the privacy of subscribers.323v2 versionId:2. gatekeeperIdentifier. When the callModel is gatekeeperRouted. For instance: VendorIdentifier Vendor T35CountryCode:82 T35Extension:0 manufacturerCode:2290 productId:Cns H. A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE should ignore fields other than endpointIdentifier. keepAlive. 18) CallType Using this value. the Gatekeeper will send an IACK or INAK message in response to an unsolicited IRR message with its needsResponse field set to TRUE. productId and versionId are text strings that can provide product information. 17) RejectReason It is included in RRJ message.0 13) TimeToLive TimeToLive is a number seconds that a registration is to be considered valid. When the callModel is direct. 12) VendorIdentifier The VendorIdentifier structure allows a vendor to identify a product. 14) KeepAlive An endpoint can send a lightweight RRQ consisting of only rasAddress. Either end knows the address of the other end. The GK participates in the call signaling procedure. Q.323 Recommendation defines two transmission models for end-to-end (E2E) call signaling. gatekeeperIdentifier. called party's GK can attempt to determine 'real' bandwidth usage. 15) EndpointIdentifier 16) WillRespondToIRR When it is set to True. extension.323 This is the registration and status transport address for this endpoint. 4-12 . and identifies the reason for the rejection of the registration. endpointIdentifier. The default value is pointToPoint for all calls.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. and manufacturer code. the endpoint is requesting the GK mediated model. The vendor element allows identification in terms of country code.931 messages are transmitted on top of TCP in well-known port 1720. tokens and timeToLive. 931 messages.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. In ARQ and ACF messages. For instance: The call model in gatekeeperRouted. 26) ConferenceID It is the unique identification of the conference to which the call belongs. The call ID serves for E2E message transmission.323 After GK provides the transport-layer address of the called party. it no longer involves in the call signaling procedure. a 128 kbit/s call would be signalled as a request for 256 kbit/s. 21) DestCallSignalAddress It is the translated call signaling transport address of destination terminal or GK itself. supplementary service. Unlike CRV. the call ID is a global parameter. It includes IP address and port number of Q. GK establishes the association between two CRVs. This is used by a GK to associate the ARQ with a particular call. and ensures accurate transmission of signaling messages. All calls shares the same conferenceID. The call reference value is chosen at the side originating the call and has to be locally unique. 24) BandWidth The parameter is used by GK to control the number of H. all H. all RAS messages and call signaling messages of a particular call share the same call ID. The bandwidth defined by GK in ACF can be less than the one defined in ARQ. which is adopted for all H. such as E. conference initiation time and protocol version. such as call admission. 4-13 . 22) SrcInfo It is a sequence of alias addresses for the source endpoint. and from destination endpoint to GK. Each call of a particular conference has its own call ID. The GK can reject a call when there is not enough bandwidth to support the call.0 messages in the conference. CRV at the two signaling segment—source terminal-GK and GK-destination terminal—are different. 23) SrcCallSignalAddress It is the transport address used at the source for call signaling. CID consists of three parts—endpoint network address. and call termination share the same CRV.931. 27) Call ID It identifies a call. bandwidth change. 25) CallReferenceValue (CRV) It is the CRV cited from Q. 20) EndpointIdentifier It is a GK-assigned terminal identity string.164 addresses or H323_IDs. in the same signaling segment. For example.0 messages of a particular call. BandWidth is the number of 100 bits requested for the bidirectional call.164 addresses or H323_IDs. call establishment. from source endpoint to GK. such as E. Nevertheless.225. In other words.323 terminals accessing PBN at the same time. from source endpoint to destination endpoint.225. A typical example of RAS message This is an example of RRQ message. the endpoint shall always send ARQ to get permission to answer a call.323 It can be encapsulated and transmitted in the Q.931 user-to-user messages.169.8. it indicates that the endpoint will supply Q.200.169.0. If the answerCall flag is FALSE.169.200.0.2250.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.31) port: 1720 rasAddress (TransportAddress) Item 0 (ipAddress) ipAddress ip: 191. IV. 30) WillSupplyUUIEs If it is set to TRUE.200.3 discoveryComplete: True callSignalAddress (TransportAddress) Item 0 (ipAddress) ipAddress ip: 191.31 (191. 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. 28) ActiveMC It defines whether the source endpoint has an active MC.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 .169.31 (191. The call ID is assigned by the source endpoint. It can be used in supplementary services.200.931 message information in IRR messages if requested by the Gk. registrationRequest requestSeqNum: 969 protocolIdentifier: 0. and the H.200. the country code is 82. The requestSeqNum is the same as the ones in the response messages RCF and RRJ.31. Therefore. tokens and timeToLive. and is used to associate RRQ. Line 32 has the following implications. Line 5 to line 9 list the information of the endpoint that is transmitting Q.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. gatekeeperIdentifier. IP address: 191.323 identifier. It is set to TRUE. A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE should ignore fields other than endpointIdentifier. gatekeeperIdentifier.323 identifier is also 666302. 4-15 . IP address: 191.323 t35Extension: 0 manufacturerCode: 2290 productId: CnS H. Line 19 to 23 are content of the terminalAlias.164 address is a telephone number 666302.200.0 timeToLive: 3600 keepAlive: True endpointIdentifier: 24-3 Line 1 indicates that the message is RRQ. tokens and timeToLive. Line 24 to 30 specify information about the endpoint vendor.169. and True for all the subsequent ones. extension is 0 and manufacturer code is 2290.225 Recommendation used. port number: 1720. which is included in RRQ only.323v2 versionId: 2. port number: 1719. which defines the version number of the H. the E. Line 10 to line 14 list the information of the endpoint that is transmitting RAS messages.931 messages. which indicates that the requesting endpoint has preceded this message with the GK discovery procedure. keepAlive. productId and versionId are text strings that can provide product information.323 terminal.31.164 address or an H. it is an H. An endpoint can send a lightweight RRQ consisting of only rasAddress. Here. Line 3 is protocolIdentifier. It can be an E. keepAlive is set to False in the first RRQ message. Line 15 to line 18 specify the type of the endpoint that is registering. Line 31 indicates that the registration is valid for 3600 seconds. endpointIdentifier. Line 4 is discoveryComplete. Line 32 is endpointIdentifier.169. Here. RCF and RRJ. Line 2 indicates that the request sequence number is 969. In this example. rasAddress. Terminal registration and unregistration An endpont must register itself in the GK discovery procedure before it can start and receive calls. Overview of basic procedures This section introduces three procedures: z GK discovery z Terminal registration and unregistration z Terminal to GK admission and disengagement Each procedure is explained with a generic example of several events.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. Each process step represents an individual event. 4-16 . Alternatively. III. and returns a GCF message. and returns a GRJ message with cause of rejection. GRQ message includes parameters endpointType. II. 2) GK analyzes the endpoint information.323 4.3 Basic Procedures I. searching for GK. and gatekeeperIdentifier. GK rejects the registration request of the endpoint. determines that it is a local endpoint. it sends a GRQ message.2. GK discovery Endpoint GK 1 GRQ 2 GCF 3 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. The registration of endpoint to the GK includes the former under the control of the latter. 4) In normal cases. 4-17 . When GK finds no registration information of the endpoint. The first pair indicates the start and the last pair indicates the end of the call. The RRQ message includes two important parameters: endpontAlias and callSignalAddress. When the GK finds that the endpoint is not a locla one. 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. 2) The GK analyzes the endpoint information. 3) When the endpoint is to end the service.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Endpoint Chapter 4 H. The endpoint then informs the GK of its call signaling transport address.323 GK 1 ARQ 2 ACF 3 ARJ 4 DRQ 5 DCF 6 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 GK will then record the endpointAlias and callSignalAddress in translation table. it returns an RRJ message to reject the call. or change the mapping relation between alias and address. it sends a URQ message to GK and requests for unregistration. IV. determines that it is a local endpoint. and returns a GCF message. it returns a URJ message. GK returns a URF message for confirmation. In the ARQ message.225. the endpoint specifies the destination information and required bandwidth.932. requesting to disengage the call. Recommendation Q.3 H. GK returns a DCF message for confirmation. Recommendation Q.931 is ISDN user-network interface layer-3 specification for basic call control. the GK rejects the call with an ARJ message. The ACF message includes two key parameters—bandWidth which specifies the allowed maximum bandwidth for the call.1 Overview of H.323 GK 1 ARQ 2 ACF 3 ARJ 4 DRQ 5 DCF 6 DRJ Figure 4-9 Message flow diagram of terminal to GK admission and disengagement 1) When the endpoints initiates a call.0 is drafted based on Q. and destCallSignalAddress.3.0 Call Signaling Protocols 4. Alternatively.931 and Q. 2) If the GK admits the call.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Endpoint Chapter 4 H. If the GK refuses the request.932 specifies the generic procedures for the control of ISDN supplementary services. it returns an ACF message. 4. the endpoint sends a DRQ message to the GK. it sends an ARQ message to GK for authentication and address resolution.225. 4) In normal cases. which might be an endpoint or GK address depending on the call model in use. 3) When the call completes.225. it returns a DRJ message. 4-18 .0 Recommendation H. 0 messages H. Setup Acknowledge To indicate that call establishment has been initiated.932 messages are thereby simplified here.225. such as subsequent called address.225.0 Messages I.931 and Q.323 4. Overview of H. we will focus on H.3. Connect To indicate acceptance of the access connection. The former provides a greater share.0 call signaling messages only. Here. 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). such as call suspension and resume. Call Proceeding To respond to Setup message. and request for subsequent address information. and indicate that requested access connection establishment has been initiated.225. many Q.932.225. Miscellaneous messages Table 4-12 Description of call miscellaneous messages Message name Meaning Information To provide additional information. 4-19 . II. As H. Progress To indicate the progress of an access connection establishment in the event of interworking within a private network.0 basic call control messages are borrowed from Q.2 H.225. and called number is complete. III. Call establishment messages Table 4-10 Description of call establishment messages Message name Meaning Setup To initiate call establishment.0 call signaling messages contain no call connection information. IV. Alerting To indicate that the called subscriber alerting has been initiated.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. Notify To indicate information pertaining to a call.931 and Q. Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. 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. or to send to the subscriber to deliver information from the other subscriber. Overview of message format Figure 4-10 illustrates the generic format of a Q.931 message. or to send to the subscriber to deliver information from the other subscriber. Q. Status To respond to the STATUS ENQUIRY message. V.3. 4.3 Message Format I.932 messages Message name User Information Meaning To transfer information to a remote subscriber. Facility To convey supplementary service information to the network. User Information To transfer information to a remote subscriber.323 Message name Meaning Status Enquiry To solicit a STATUS message from the peer layer-3 entity.931 message 4-20 . or at any time during a call to report certain error conditions. If this information element is received in a call between two H.931.931.450. the field shall be set either to 'unrestricted digital information'.323 terminals. GK establishes the association between two CRVs. Message type Its value is coded by Q. which will not be elaborated here. the CRV is a virtual call reference. This is to allow some advance information about the nature of the connection to be forwarded to the H. video. for example.3. If this information element appears in a Setup message for a call-independent signaling connection as defined in Recommendation H.1.450.323 endpoint.323 endpoint shall use this field to indicate their wish to place an audiovisual call. and it is only valid in part of the call segment. and is used for supplementary services. If a speech only call is to be placed. the coding shall follow 7.1. For audiovisual call.4 Information Elements I.323 terminal shall set the information transfer capability to either 'speech' or to '3. Calls that originate from an H.0. V. The CRV is generally used to associate multiple calls in three-party service or multi-party service.2.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. IV. H. Protocol descriminator It is set to Q. Length of call reference When the length of call reference is set to zero. CRV at the two signaling segments—source terminal-GK and GK-destination terminal—are different.323 II.1. 4-21 .2/H. data vs. For instance: The call model in gatekeeperRouted. Call reference value This parameter is used to identify a call.3. meaning that it is irrelevant to any call. though less significant as specified in Q. this would have an impact on the bandwidth required as well as on the ability/willingness to accept the call or not. Bearer capability It is a mandatory information element (IE) in H. as described in Section 4.1 kHz audio'.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. and ensures accurate transmission of signaling messages.225. the H. it may be ignored by the receiver. III. 4.225.931. voice only vs. Table 4-13 Mapping between the Cause IE and ReleaseCompleteReason ReleaseCompleteReason code Corresponding Q. For a call originating from an ISDN endpoint.164 address is not present in Setup message. IV. III.323 endpoint.931 cause value noBandwidth 34 – No circuit/channel available gatekeeperResources 47 – Resource Unavailable unreachableDestination 3 – No route to destination 4-22 .323 videophone call. the gateway shall simply pass on the information that it receives from the ISDN. and the call will be routed by an alias address in the user-to-user information.242 to indicate an H.931. If the numbering plan identification is set to “Private Numbering Plan” in a PBN originated call. while ReleaseCompleteReason is for PBN. Table 4-1 shows the mapping between the Cause IE and ReleaseCompleteReason. If a gateway is involved. this value shall reflect the number of external connections to be set up. The Cause is borrowed from Q.711 to indicate a voice-only call and H. but optional elsewhere.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. Layer 1 protocol It is set to G.221 and H. Called party number and calling party number The calling party number is used for charging and caller number display. Cause It indicates the generation of the message for future diagnosis. II. For a call originated from an H. The Cause is mandatory in Release Complete. this shall be used to indicate the bandwidth to be used for this call on the SCN side.323 Rate multiplier The segment shall be present if information transfer rate is set to 'multirate'. The called party number is used for routing. Gateways shall map from a ReleaseCompleteReason to the Cause IE when sending a Release Complete message to the SCN side from the PBN side. The Cause information element and the ReleaseCompleteReason (a part of the Release Complete message) are mutually exclusive. Display The network will send American Standard Code for Information Interchange (ASCII) to subscriber to be displayed. this indicates that the E. Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. CallProceeding. User-User Information Element User-User Information Element (UUIE) is the most significant IE in H. unspecified The reverse mapping is not required as packet-based network entities are required to decode the Cause IE. Figure 4-11 shows the format of UUIE. and represents the call signaling capability of the entire H. The call control information is the essence of H. It shall be used by all H.931 cause value destinationRejection 16 – Normal call clearing invalidRevision 88 – Incompatible destination noPermission 111 – Protocol error.0 call signaling. It means that the user information is changed from IA5 of Q. UUIE is indispensable for messages such as Setup. Release Complete.323 call signaling system. 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. Connect.1. and User Information. Facility.323 ReleaseCompleteReason code Corresponding Q. 4-23 . V.323-specific call control information in addition to normal E2E subscriber data. UUIE discriminator UUIE length Protocol identifier (ASN.323 entities to convey H.1) H323-UU-pdu (Mandatory) User data (Optional) Figure 4-11 Format of UUIE The protocol discriminator is changed to ASN.323 system.225. Alerting.1.932 to a generic ASN. z Conference identifier: It is the conference identifier carried in Setup message.242 Display Information element: Display Length: 7 Display information: 7670000 Calling party number 4-24 .323 The user information contains two parts.225. whose maximum length is 131 bytes. It is equivalent to user-user information defined in Q. it is called user data.225.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. 4. the calling endpoint can establish the H. As an element in the data sequence.3. containing the UUIE contents of related messages. the signaling information of H323. This parameter can also be transmitted by UUIE of Alerting message or Call Processing message. making the calling endpoint able to determine whether the call is related to gateway. Q.931 message This is an example of Setup message.225 protocol supported by the endpoint.245 control channel to the called endpoint or GK.1.245 control channel of called endpoint or GK.0 call.221 and H.932. This is the major purpose of H.931 Protocol discriminator: Q. The optional part is the user data transmitted between terminals.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.5 A typical example of Q. but it is encapsulated in UUIE data structure defined by ASN. z Call identifier: It is set by calling endpoint. and then establish the required media channel. z H.0 defines the contents of h323-UU-pdu in UUIE of each related message. that is. For example. and the data is IA5 character string. H. 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. According to this address.245 address: It is the transmission layer address of H. z Destination information: It is used to indicate the endpoint type. The body part is h323-UU-pdu. 225.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.0.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.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.208 and X.323v2 versionId: 2.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (setup) setup protocolIdentifier: 0.164 ISDN/telephony numbering Number: 7670001 User-user Information element: User-user Length: 126 Protocol discriminator: X.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 .0.2250.8.209 coded user information ITU-T Recommendation H. Line 32 to 33 indicates the following is UUIE. Now.931.323 endpoint. the E. it is Setup. Layer 1 protocol is set to H.323 identifier is also 7670000. which means that the call is an H.150. Line 26 to 31 The called party number: used for routing.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. Line 6 to line 15 means that the caller is an H.221/H. 4-26 . Here.242. Line 34 indicates that the UUIE length is 126 bytes.164 address is a telephone number 7670000.150.164 address or an H. Now. The UUIE contains the following contents: sourceAddress (AliasAddress): It can be an E.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.171 (191. It implies that the caller is about to make a video call. Line 2 is protocol descriminator. and the information transfer capability is “Unrestricted digital information”. It is 6FD1. Line 20 to 25 The calling party number: used for charging and caller number display. Line 4 is call reference value.323 identifier. Line 3 defines the length of call reference value.169. Line 35 protocol discriminator.323 video call. Line 5 is message type.169. it is set to Q. and the H.323 create: create callType (pointToPoint) pointToPoint: pointToPoint sourceCallSignalAddress (ipAddress) ipAddress ip: 191. It is set to 2 bytes.931 message. Line 36 to end The UUIE contents in the Setup message. Line 16 to line 19 The network will send American Standard Code for Information Interchange (ASCII) to subscriber to be displayed. and follows brief description.323 identifier. the country code is 82. II.164 address is a telephone number 7670001.323 identifier. Here. destinationAddress (AliasAddress): It can be an E.164 address or an H. the E. Here.6 Basic Procedures I. Basic call setup procedure (direct routing mode) Figure 4-12 shows the signaling procedure. 4-27 . productId and versionId are text strings that can provide product information. Endpoint 1 GK 1 ARQ 2 ACF Endpoint 2 Setup 3 4 Call proceeding 7 Alerting 8 Connect ARQ 5 ACF 6 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.3. extension is 0 and manufacturer code is 2290. and there is no H.323 system. Overview of basic procedures This section takes the example that two endpoints register with the same GK. it is an end-to-end call. and the port number is 1074. sourceCallSignalAddress (ipAddress): It is the transmission layer address (IP address plus TCP port number) of cal signaling channel of local endpoint. and describes the signaling procedures in two message transmission modes. for the purpose of detailing the call control procedure of H.169. callIdentifier: the call identifier is 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4. Here. to request the GK to originate a call to endpoint 2.200.323 sourceInfo (EndpointType): Here. called party's GK can attempt to determine 'real' bandwidth usage. 4. callType (pointToPoint): Using this value.31. the IP address is 191.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. to endpoint 1. there is no explanation information. If the call is between H. 4-28 . If the ARQ has CRV. 5) Scenario 5: Endpoint 2 sends ARQ to the GK through RAS channel to accept the call.323 terminal and ISDN terminal. 3) Scenario 3: Endpoint 1 establishes call signaling channel to endpoint 2. 6) Scenario 6: The GK agrees to accept and sends back ACF.323 terminal. it will send back ARJ. In this case.245 control channel TCP port number of endpoint 2.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System 2) Chapter 4 H. 8) Scenario 8: The subscriber answers the call. and sends Setup message through the channel. It translates the transmission layer address (IP address plus TCP port number) of call signaling channel of endpoint 2. the Setup message and following signaling messages have the same CRV. the messages except UUIE do not carry other information element. If endpoint 1 is also a gateway. For the call between two H. Now .323 terminals. and the message carries H. that is. If the GK does not allow endpoint 2 to accept the call. Endpoint 2 sends Connect message to endpoint 1. endpoint 2 will transparently transmit the information elements from SCN side. such information elements will be transmitted to the calling party at SCN side.323 Scenario 2: The GK agrees to accept the call. the call is set up. and the sends the address in ACF message to endpoint 1. endpoint 2 will send Release Complete message to endpoint 1. such as bearing capability and proceeding indicator. 7) Scenario 7: Endpoint 2 sends back Alerting message to endpoint 1. indicating that the call has been processed. 4) Scenario 4: Endpoint 2 sends back Call Proceeding message. If endpoint 1 is an H. if endpoint 2 is a gateway. and waits for answer by subscriber. 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. the ACF message carries the transmission layer address of call signaling channel of the GK. Meanwhile. Then TCP connection is disconnected. which transfers the messages to endpoint 2.245 control channel transmission layer address in Connect message. 3) After the call is set up.245 control message. a Release Complete message is sent to the GK.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. In this case. the call signaling messages from endpoint 1 can only be transmitted to the GK. 2) Afterward. the GK establishes the call signaling channel to endpoint 2. Basic call setup procedure (gatekeeper routed mode) Endpoint 1 GK 1 ARQ 2 ACF 3 Setup Endpoint 2 Setup 4 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. but the information in Connect message sent by the GK to endpoint 1 is up to the transmission mode of H. if the GK uses transfer mode. which then sends a Release Complete message to the peer end. Instead. When either calling party or called party hooks on. If the GK uses direct routing mode to transmit media control messages. endpoint 2 tells the GK the H. which transfers the messages to endpoint 1. the messages contain the H. 4-29 . Because endpoint 2 establishes signaling channel only with the GK.245 control channel address of endpoint 2. the messages contain the H.323 III. it can only send signaling messages to the GK.245 control channel address of the GK. the GK has MC functions. 0 call setup procedure. which is composed of a pair of uni-directional logical channels occupying two logical channel numbers. In H.245 OpenLogicalChannel procedure supports uni-directional channel establishment and bi-directional channel establishment. most of logical channels are uni-directional channels.120 data communication protocol and ordinary point-to-point telephone communication require bi-directional channel. and they can be established or released when necessary.323. The logical channels used to transmit audio and video signals are unreliable channels (such as UDP channels). which exists during the call and will be released after the call is over. especially those in conference call.323 entities transmit H. In H. whose channel number is 0.4. maintenance and release of channels.245 Recommendation H. there are two kinds of channels defined as follows: 1) Control channel: also called H.245 messages to control the establishment and release of media channel. However.245 is the control protocol for multimedia communication.245. This is the capability exchange procedure of H. Their port numbers are allocated dynamically. In H. 2) Communication channel: also called media channel. Control channel is a reliable channel.323 stack.245. and the numbers of the connected ports are allocated dynamically. Logical channels are opened or closed by H. T. establishment is called Open and release is called Close. there might be multiple logical channels between two entities. The H. After the call is set up. the calling and called endpoints (or GK) use Setup and Connect messages to exchange the allocated H. H.245 control channel is established. Control channel can be regarded as a special permanent logical channel. it is defined as logical channel. H. H. two H. Generally.245 4-30 .1 Overview of H.245. both parties must negotiate these parameters before a logical channel is established. to determine the acceptable parameter ranges.225.323 4.245.245 4. Each logical channel use a specific coding algorithm and bandwidth to transmit a specific kind of media information. In H. In the H.245 is the control protocol in H. used to transmit user communication information.245. Each call has only one H. In this case.245 port address.245 peer signaling entities in different H. Logical channel establishment is actually that both parties use OLC and OLCA messages to exchange their allocated port numbers.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.245 control channel.245 channel. Through this channel. which corresponds to a TCP connection in IP network.4 Recommendation H. It is designed for conference communication. and controls the establishment. and each logical channel is assigned with an identifier when opened. the logical channels used to transmit data are reliable channels (such as TCP channel). 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 z 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 z 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 z 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 z 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 0 Capability 0 1 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 terminal’s 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 0 Simultaneous capability 0 1 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 such as audio or video. If the terminaltype values are the same.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. z Channel parameters The parameters define whether data type and media information are transmitted surely. 3) Logical channel signaling procedure Logical channel is opened by transmitter side. In IP multicast mode. the transmission layer addresses of the participants are different because their network addresses are different. the transmission layer addresses of the participants might be the same. with rejection reason as “same number”. Media channel 4-40 . the endpoint with larger StatusDeterminationNumber is “Master”. and the message contains ForwardLogicalChannelNumber and channel parameters. Generally. If the StatusDeterminationNumbers are still the same. the peer terminal sends back determination reject message. once an MC has been selected as the active MC in a conference. Then. It sends a OpenLogicalChannel message to the receive terminal. it starts the determination calculation procedure. The RTP sessions are distinguished by different port pair and/or different multicast addresses. the session is defined by a pair of transmission layer addresses (network layer address plus RTP and RTCP ports numbers). Therefore. “undetermined” will be resulted. For each participant. each media signal is transmitted by an individual RTP session.323 After the peer end receives the masterSlaveDetermination message. whether silence suppression is performed. and starts master-slave determination procedure again. If the status cannot be determined. if an MC becomes the active MC. In a multimedia session. in a conference call. and has its own RTCP group. and the acknowledge message carries this value to match the request message. If the channel is used to transmit RTP encapsulated real-time media information. An MC that is already acting as an MC shall always remain the active MC. its terminaltype value becomes 240. the local terminal regenerates a StatusDeterminationNumber. z ForwardLogicalChannelNumber ForwardLogicalChannelNumber must be assigned by the transmitter side. and destination terminal tag. In unicast mode. the status can be determined. the channel parameters also include the following three parameters: Session ID RTP session ID. Besides. An RTP session is the communication of a group of participants through RTP. the peer terminal sends back determination acknowledge message to tell the determination result. Then. The determination principle is: the endpoint with larger terminaltype value is "Master". it shall use the Active MC value for all subsequent connections to the conference. 245 message.150.169. and other transmission QoS parameters. Example of H. 4-41 .171 (191. IV.150.150.323 Used to transmit the IP address and port number of RTP encapsulated real-time media messages.245 message An example of OpenLogicalChannel message is shown as follows: ITU-T Recommendation H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.150.169.171 (191.171) tsapIdentifier: 40000 mediaGuaranteedDelivery: False mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.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.169.171) tsapIdentifier: 40001 mediaControlGuaranteedDelivery: False Line 1 indicates that the message is an H. Media control channel Used to transmit the IP address and port number of QoS parameter messages of RTCP encapsulated real-time signal transmission. see RTP related documents. Line 2 indicates that the message is a request message. For more information about the above parameters. Here.723 audio data. Capability Exchange Endpoint A Timeout Endpoint B 1 TCSReq 2 TCSAck 3 TCSRej 4 TCSRel Figure 4-16 Capability exchange procedure 4-42 .169. the IP address is 191. and destination terminal tag. That is. whether silence suppression is performed. This parameter must be assigned by transmit party. the IP address is 191. Lines 12 to 13: H. without silence suppression. and the port number is 40001.171.225 logical channel parameter. the IP address and port number used by the endpoint to transmit RTP encapsulated real-time media information. Line 4: Forward logical channel number. Lines 5 and 6: Forward logical channel parameters.150.169. That is. Here the value is 1. The parameters define whether data type and media information are transmitted surely. Lines 7 to 11: Data type. Here. the data type is G. such as audio or video. Here the value is 1.4.3 Basic Procedures I. and the acknowledge message returns this value to match the request message. 4. Here. which is mandatory because the channel is used to transmit RTP encapsulated real-time media information. the IP address and port number used by the endpoint to transmit QoS parameter message of RTCP encapsulated real-time signal transmission.150.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. Lines 15 to 21: Media channel parameters. and the port number is 40000.323 Line 3 indicates that the message name is openLogicalChannel. Line 14: RTP session ID.171. Lines 22 to s8: Media control channel parameters. Open Logical Channel Endpoint A Timeout Endpoint B 1 OLCReq 2 OLCAck 3 OLCRej 4 OLCRel Figure 4-18 Open logical channel procedure 4-43 .323 II. Master Slave Determination Endpoint B Endpoint A Timeout 1 MSDReq 2 MSDAck 3 MSDRej 4 MSDRel Figure 4-17 Master slave determination procedure III.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. 323 call procedure can be established in normal start and fast start mode. A complete H.5 H.170. For endpoint registration procedure.323 call needs RAS.245. End Session Endpoint A Endpoint B 1 ECS 2 ECS Disconnect TCP connection Figure 4-20 End session 4.323 User Call Procedure (Normal Start) Figure 4-21 shows a successful call procedure (normal start) between two H.2. 4-44 . Q.323 Call Procedures H. see Section 4.931 and H.171.323 IV.169. 4.323 PhoneA is 191.323 users in the same SoftX3000. Close Logical Channel Endpoint A Timeout Endpoint B 1 OLCReq 2 OLCAck 3 OLCRej 4 OLCRel Figure 4-19 Close logical channel V. The following example complies with the conventions below: z SoftX3000 serves as the GK.1 Successful H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.150. z The IP address of H.150.3.169. and its IP address is 191.5. H.323 z The IP address of H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. H.323 user call procedure (normal start) 1) Scenario 1: H. and the phone number of H.31. z H.323 PhoneB 3 Q931_SETUP 4Q931_CALLPROCEEDING 5 Q931_SETUP 6 RAS_ARQ 7 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.31. In the ARQ message.323 PhoneA SoftX3000 1 RAS_ARQ 2 RAS_ACF H.323 PhoneB is 191.323 PhoneA gives the 4-45 . and the called party first hooks on.323 PhoneA hooks off.323 PhoneB is 7670001.323 PhoneB is the called party.323 PhoneA is 7670000.169. H.323 PhoneA is the calling party. z The phone number of H. and it sends ARQ to the GK to request whether the call can be initiated. and the port number is 1720. while the peer endpoints do not know the addresses of each other.323 PhoneA. and the GK is involved in the call signaling procedure.169. 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). there is allowed bandwidth.0 admissionConfirm requestSeqNum: 1930 bandWidth: 5120 callModel (gatekeeperRouted) gatekeeperRouted: gatekeeperRouted 4-46 . It should be noted that the CallModel is gatekeeperRouted.225.170.323 destination information.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.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. ITU-T Recommendation H.323 PhoneB. Meanwhile. and translated transmission layer address of call signaling of destination or the transmission layer address of call signaling of the GK.225. In the message. Because the CallModel is “gatekeeperRouted”. and sends ACF message to H. required bandwidth.150. ITU-T Recommendation H. and call ID. The IP address is 191. the GK establishes call signaling channel to H. 169. In the UUIE field of the message.169.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.150.323 destCallSignalAddress (ipAddress) ipAddress ip: 191.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. to request call establishment.150. used to receive the Q. the transmission layer address of the source call signaling channel is given (IP address plus TCP port number).323 PhoneA sends Setup message to the GK. and the port number is 1074.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. Q.221 and H.171.242 Display Information element: Display Length: 7 Display information: 7670000 Calling party number 4-47 .931 messages from the GK.931 Protocol discriminator: Q.169.170 (191. The IP address is 191.150. 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 .323 Information element: Calling party number Length: 8 Type of number: Unknown Numbering plan: E.323v2 versionId: 2.208 and X.209 coded user information ITU-T Recommendation H.0.0.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.8.2250.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.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (setup) setup protocolIdentifier: 0.164 ISDN/telephony numbering Number: 7670001 User-user Information element: User-user Length: 126 Protocol discriminator: X.225.164 ISDN/telephony numbering Number: 7670000 Called party number Information element: Called party number Length: 8 Type of number: Unknown Numbering plan: E. 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.171 (191.0.323 create: create callType (pointToPoint) pointToPoint: pointToPoint sourceCallSignalAddress (ipAddress) ipAddress ip: 191. the country code is 28. The VendorIdentifier in the UUIE field of the message indicates the vendor ID of the GK.150.2250.169.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 . it is indicated that the GK is Huawei NGN SoftX3000 product. Q.150. Here.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.8.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.169. extension is 21 and manufacturer code is 0. Besides.209 coded user information ITU-T Recommendation H. whose version is SoftX3000V3.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (callProceeding) callProceeding protocolIdentifier: 0.208 and X.0. indicating that the call has been processed.225.931 Protocol discriminator: Q. 221 and H.169.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. If the GK agrees to establish the call.164 ISDN/telephony numbering Number: 7670001 User-user Information element: User-user Length: 113 Protocol discriminator: X.. The IP address is 191. Q.31. Called party number Information element: Called party number Length: 8 Type of number: National number Numbering plan: E. Then.169.323 PhoneB. and the port number is 1720.931 Protocol discriminator: Q.242 Display Information element: Display Length: 30 Display information: Huawei Technologies Co. it will translate and get the transmission layer address (IP address plus TCP port number) of call signaling channel of H. the GK transfers the Setup message to 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 PhoneB.209 coded user information 4-50 .150.208 and X. and the port number is 5011. used to receive the Q.323 PhoneA. The IP address is 191. In the UUIE field of the message.31.931 messages from H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. the transmission layer address of the source call signaling channel is given (IP address plus TCP port number).170.323 PhoneB to request call establishment. Ltd. 170) port: 5011 callIdentifier (CallIdentifier) guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4 mediaWaitForConnect: False canOverlapSend: False h245Tunneling: False 6) Scenario 6: H.0.31) port: 1720 activeMC: False conferenceID: 4E2C3030-DCBC-9839-3FB8-EB4A020D3C92 conferenceGoal (create) create: create callType (pointToPoint) pointToPoint: pointToPoint sourceCallSignalAddress (ipAddress) ipAddress ip: 191.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.31 (191.150.31.169. ITU-T Recommendation H.169.225.31.169.0.323 ITU-T Recommendation H.8. to tell the GK it accepts the incoming call.225.0 4-51 .150.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (setup) setup protocolIdentifier: 0.2250.169.323 PhoneB agrees to accept the call. and sends ARQ message to the GK through RAS channel.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.170 (191. ITU-T Recommendation H.169.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.0 admissionConfirm requestSeqNum: 90 bandWidth: 5120 callModel (gatekeeperRouted) gatekeeperRouted: gatekeeperRouted destCallSignalAddress (ipAddress) ipAddress ip: 191.. and sends ACF message to H.170) port: 1720 irrFrequency: 60 destinationInfo (AliasAddress) Item 0 (h323_ID) h323_ID: 7670001 willRespondToIRR: False uuiesRequested (UUIEsRequested) 4-52 .323 PhoneB.150.225.323 PhoneB. the GK sends the transmission layer address (IP address plus TCP port number) of its call signaling channel to H.150. In the message.169.170 (191. 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.209 coded user information ITU-T Recommendation H. and tells H.931 Protocol discriminator: Q.225. Q.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.931 Call reference value length: 2 Call reference value: EFD1 Message type: ALERTING (0x01) User-user Information element: User-user Length: 70 4-53 .323 PhoneA to send ringback tone.323 PhoneA.2250.323 PhoneB to H.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 sends Alerting message to the GK.0.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (alerting) alerting protocolIdentifier: 0.0.931 Protocol discriminator: Q. indicating that the call has arrived. Q.8.208 and X. and it is ringing. 169.2250.0.31.225.8. The IP address is 191.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.245 control channel of PhoneB.8.209 coded user information ITU-T Recommendation H.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.3 h245Address (ipAddress) ipAddress 4-54 . Q.323 PhoneB.0. and the message carries the IP address and TCP port number of the H.208 and X.323 PhoneB sends Connect message to the GK. product and version information of H. the message carries the vendor ID.323 Protocol discriminator: X.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (connect) connect protocolIdentifier: 0.208 and X. and the port number is 2722.209 coded user information ITU-T Recommendation H.931 Protocol discriminator: Q.2250.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (alerting) alerting protocolIdentifier: 0.225.0.31.0. Besides. 323 PhoneB.31. the call is set up. the message carries the vendor ID. and transfers the message to H.31 (191.169. Q.245 control channel of H.31.931 Protocol discriminator: Q. The IP address is 191.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. The message carries the IP address and TCP port number of the H..323v2 versionId: 2. User-user Information element: User-user Length: 93 4-55 Ltd. Besides.323 PhoneB.242 Display Information element: Display Length: 30 Display information: Huawei Technologies Co.221 and H.31.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.169.169. Now . and the port number is 2722. .323 ip: 191.31) port: 2722 destinationInfo (EndpointType) vendor (VendorIdentifier) vendor (H221NonStandard) t35CountryCode: 82 t35Extension: 0 manufacturerCode: 2290 productId: CnS H. product and version information of the GK.31.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 PhoneA. 8.323 PhoneA can know the receive and transmit capabilities of PhoneB.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (connect) connect protocolIdentifier: 0.169.0.323 PhoneA to start capability exchange procedure.0.209 coded user information ITU-T Recommendation H.0.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.0.208 and X.245 request message TCS to H.245 request terminalCapabilitySet sequenceNumber: 1 protocolIdentifier: 0. ITU-T Recommendation H.31.169.323 Protocol discriminator: X.31 (191.2 h245Address (ipAddress) ipAddress ip: 191.323 PhoneB sends H.245.8.2250.225.3 multiplexCapability (h2250Capability) h2250Capability maximumAudioDelayJitter: 60 receiveMultipointCapability (MultipointCapability) multicastCapability: False multiUniCastConference: False mediaDistributionCapability (MediaDistributionCapability) 4-56 . so that H.31.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. H. 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 . 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 PhoneA receives the TCS message from H. so that H.245 4-59 .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 PhoneB can know the receive and transmit capabilities of PhoneA. and sends back TCSA message to confirm.245 request message TCS to H. ITU-T Recommendation H.245 response terminalCapabilitySetAck sequenceNumber: 1 14) Scenario 14: H.323 PhoneB.323 PhoneB to start capability exchange procedure.323 PhoneA sends H. ITU-T Recommendation H. 245.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 .8.0.0.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.323 request terminalCapabilitySet sequenceNumber: 1 protocolIdentifier: 0. 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 . 323 PhoneA.245 response terminalCapabilitySetAck sequenceNumber: 1 16) Scenario 16: H.323 PhoneA receives the MSD message from H. and sends back TCSA message to confirm. ITU-T Recommendation H.323 PhoneA through MSDA message. ITU-T Recommendation H.323 PhoneA.245 request masterSlaveDetermination terminalType: 50 statusDeterminationNumber: 4947 19) Scenario 19: H. Then.245 response masterSlaveDeterminationAck decision (master) master: master 4-63 . ITU-T Recommendation H. ITU-T Recommendation H. Now.323 PhoneB sends the result to H.245 response masterSlaveDeterminationAck decision (slave) slave: slave 18) Scenario 18: H.323 PhoneA sends MSD message to H.323 PhoneB sends MSD message to H.323 Item 1 (AlternativeCapabilitySet) array: 1 15) Scenario 15: H.245 request masterSlaveDetermination terminalType: 50 statusDeterminationNumber: 6814 17) Scenario 17: H. the capability exchange procedure is over. to get the result that it is Master. and it compares the carried terminalType and statusDeterminationNumber with its corresponding values. ITU-T Recommendation H.323 PhoneB receives the MSD message from H. and it compares the carried terminalType and statusDeterminationNumber with its corresponding values. H.323 PhoneA sends the result to H. Then. to start master slave determination procedure.323 PhoneB. to start master slave determination procedure.323 PhoneB receives the TCS message from H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. to get the result that it is Slave. H.323 PhoneA.323 PhoneB through MSDA message.323 PhoneB. ITU-T Recommendation H.150.171) tsapIdentifier: 40000 mediaGuaranteedDelivery: False mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.31) and port number (40000) used by H.323 PhoneB.323 20) Scenario 20: H.31.171) and port number (40000) used by H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.323 PhoneB sends back OLCA message as response. and the IP address (191.169. and the IP address (191.169.169.169.171) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.323 PhoneA to transmit RTP encapsulated real-time media information (audio signals).323 PhoneB to transmit RTP encapsulated real-time media information (audio signals).169.171 (191.150. This channel is used to transmit G. The message carries the IP address (191.171 (191. The message carries the IP address (191.169.150.150.31) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.150. 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.171) tsapIdentifier: 40001 mediaControlGuaranteedDelivery: False 21) Scenario 21: H. to start OpenLogicalChannel procedure.723 audio signals and RTP encapsulated real-time media information (audio).150.323 PhoneA sends OLC message to H.169.245 4-64 .31.169. 171) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.31) tsapIdentifier: 40001 flowControlToZero: False 22) Scenario 22: H.31) tsapIdentifier: 40000 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.31.169.31. ITU-T Recommendation H.31.169.171) and port number (40002) used by H.323 PhoneA to transmit RTP encapsulated real-time media information (video signals).323 response openLogicalChannelAck forwardLogicalChannelNumber: 1 forwardMultiplexAckParameters (h2250LogicalChannelAckParameters) h2250LogicalChannelAckParameters sessionID: 1 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191. The message carries the IP address (191.150.323 PhoneB.169.31 (191. and the IP address (191.263 video signals and RTP encapsulated real-time media information (video).31.169.323 PhoneA sends OLC message to H.31 (191. to start OpenLogicalChannel procedure.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 .169.169. This channel is used to transmit H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.150. 31) and port number (40002) used by H.323 enhancementLayerInfo (EnhancementLayerInfo) baseBitRateConstrained: False multiplexParameters (h2250LogicalChannelParameters) h2250LogicalChannelParameters sessionID: 2 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191.169.150.169.31) tsapIdentifier: 40002 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.169.171 (191. and the IP address (191.31.171) tsapIdentifier: 40003 mediaControlGuaranteedDelivery: False 23) Scenario 23: H.323 PhoneB sends back OLCA message as response. The message carries the IP address (191.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.31) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.245 response openLogicalChannelAck forwardLogicalChannelNumber: 2 forwardMultiplexAckParameters (h2250LogicalChannelAckParameters) h2250LogicalChannelAckParameters sessionID: 3 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191.150.31) 4-66 .169.31 (191.169.169.169.169.31.31 (191.169.323 PhoneB to transmit RTP encapsulated real-time media information (video signals).31.31.171) tsapIdentifier: 40002 mediaGuaranteedDelivery: False mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191. ITU-T Recommendation H.150.31.171 (191.169.31.150. 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.723 audio signals and RTP encapsulated real-time media information (audio).169.169.169. This channel is used to transmit G. ITU-T Recommendation H.31) and port number (40000) used by H. ITU-T Recommendation H. The message carries the IP address (191.31.31.323 PhoneA to transmit RTP encapsulated real-time media information (audio signals).31) tsapIdentifier: 40000 mediaGuaranteedDelivery: False mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.31.245 4-67 .150.323 PhoneB sends OLC message to H.169.171) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission. to start OpenLogicalChannel procedure.323 PhoneA to transmit RTP encapsulated real-time media information (audio signals).31 (191.31.31 (191.150.171) and port number (40000) used by H.169.169.31.169.323 PhoneA.169.323 tsapIdentifier: 40003 flowControlToZero: False 24) Scenario 24: H. The message carries the IP address (191.323 PhoneA sends back OLCA message as response.31) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.31.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. and the IP address (191.31) tsapIdentifier: 40001 mediaControlGuaranteedDelivery: False 25) Scenario 25: H. and the IP address (191. 169. to start OpenLogicalChannel procedure.169.169.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 . ITU-T Recommendation H.150.171) tsapIdentifier: 40001 flowControlToZero: False 26) Scenario 26: H.171 (191.169.323 response openLogicalChannelAck forwardLogicalChannelNumber: 1 forwardMultiplexAckParameters (h2250LogicalChannelAckParameters) h2250LogicalChannelAckParameters sessionID: 1 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.171) tsapIdentifier: 40000 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.323 PhoneA.169. and the IP address (191.169.31) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.323 PhoneB to transmit RTP encapsulated real-time media information (video signals).31) and port number (40002) used by H.31.150.171 (191. The message carries the IP address (191.150. This channel is used to transmit H.323 PhoneB sends OLC message to H.263 video signals and RTP encapsulated real-time media information (video).31.150. 169.171) tsapIdentifier: 40002 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.31.31.171 (191.169.169.31) tsapIdentifier: 40002 mediaGuaranteedDelivery: False mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.150.169.245 response openLogicalChannelAck forwardLogicalChannelNumber: 2 forwardMultiplexAckParameters (h2250LogicalChannelAckParameters) h2250LogicalChannelAckParameters sessionID: 3 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191.323 enhancementLayerInfo (EnhancementLayerInfo) baseBitRateConstrained: False multiplexParameters (h2250LogicalChannelParameters) h2250LogicalChannelParameters sessionID: 2 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191.150.150.323 PhoneA sends back OLCA message as response.169.150.31 (191.31.150. and the IP address (191.169.323 PhoneA to transmit RTP encapsulated real-time media information (video signals). that is the logical channel signaling procedure is over.31 (191.169.169. The message carries the IP address (191. the audio and video logical channels at both ends are opened.31) tsapIdentifier: 40003 mediaControlGuaranteedDelivery: False 27) Scenario 27: H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.171) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.31.171 (191.171) and port number (40002) used by H. Now.171) 4-69 . and both parties begin converstation.169. ITU-T Recommendation H.169.150. 0.209 coded user information ITU-T Recommendation H.931 Release Complete message to the GK to close the channel.225.931 Protocol discriminator: Q.225.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. ITU-T Recommendation H.323 PhoneB hooks on.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (releaseComplete) releaseComplete protocolIdentifier: 0.8.225.323 PhoneB.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. to confirm that it has received DRQ message and released corresponding bandwidth.208 and X.2250.3 reason (undefinedReason) undefinedReason: undefinedReason callIdentifier (CallIdentifier) guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4 h245Tunneling: False 29) Scenario 29: H.323 tsapIdentifier: 40003 flowControlToZero: False 28) Scenario 28: H.0. ITU-T Recommendation H.0 disengageConfirm requestSeqNum: 91 4-70 . and sends 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.323 PhoneB sends RAS DRQ message to the GK to tell the GK that the occupied bandwidth can be released. Q. 225.225.2 reason (undefinedReason) undefinedReason: undefinedReason callIdentifier (CallIdentifier) guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4 h245Tunneling: False 32) Scenario 32: H.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (releaseComplete) releaseComplete protocolIdentifier: 0. Now.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 .2250.0.931 Protocol discriminator: Q.323 PhoneA to close the channel.8.0. ITU-T Recommendation H. Q. the call is released.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.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.323 PhoneA sends RAS DRQ message to the GK to tell the GK that the occupied bandwidth can be released.931 Release Complete message to H.323 31) Scenario 31: The GK sends Q.209 coded user information ITU-T Recommendation H. but there is no H.323 call procedure in normal start mode. in which SoftX3000 serves as the GK.323 PhoneA.245 channel information in H. whole release procedure is over.323 PhoneA SoftX3000 1 RAS_ARQ 2 RAS_ACF 3 Q931_SETUP H.323 user call procedure (fast start) H.323 User Call Procedure (Fast Start) Figure 4-22 shows H. 4-72 .5.323 trunk call procedure. Figure 4-23 shows a successful H.323 call procedure in fast start mode is similar to H.323 call procedure in fast start mode. ITU-T Recommendation H. It should be noted that the Setup message carries H.0 disengageConfirm requestSeqNum: 1931 4.3 Successful H.225.2 Successful H.323 PhoneB 4Q931_CALLPROCEEDING 5 Q931_SETUP 6 RAS_ARQ 7 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.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.323 call procedure in fast start mode.323 Trunk Call Procedure Different SoftX3000 equipment uses H.323 33) Scenario 33: The GK sends DCF message to H. 4.245 negotiation procedure in fast start mode.323 to communicate. H.5. Now. to confirm that it has received DRQ message and released corresponding bandwidth. 4-73 .1. and the called party first hooks on.169.323 The following example complies with the conventions below: z The IP address of SoftX3000A is 191.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.323 PhoneA is the calling party.323 trunk call connection can be implemented in fast start mode.169.112.323 trunk call procedure Note: The H. H. z H. z The IP address of SoftX3000B is 191. z The phone number of PhoneA controlled by SoftX3000A is 55500011.1.110. SoftX3000A 1 SoftX3000B Q931_SETUP 2 Q931_CALLPROCEEDING 3 Q931_ALERTING 4 Q931_CONNECT 5 Q931_FACILITY 6 H245_REQ_TCS 7 H245_REQ_TCSA 8 H245_REQ_TCS 9 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. z The phone number of PhoneB controlled by SoftX3000B is 66500010.323 PhoneB is the called party. to request call establishment. 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.169. Besides. and the transmission layer address (IP address plus TCP port number) of source call signaling channel (IP address is 191.323 Scenario 1: SoftX3000A sends Setup message to SoftX3000B.164 ISDN/telephony numbering Number: 02055500011 Called party number Information element: Called party number Length: 9 Type of number: National number Numbering plan: E.1.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.1. Q. and the port number is 5122).931 message for interworking between both ends. and phone number of PhoneB.221 and H. The message contains call ID. phone number of PhoneA. .Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System 1) Chapter 4 H. and the port number is 1720). used for charging and routing. vendor identifier.931 Protocol discriminator: Q.. Calling party number Information element: Calling party number Length: 12 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. used in subsequent Q.242 Display Information element: Display Length: 30 Display information: Huawei Technologies Co.112.110. 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.0.169.169.110 (191.169.209 coded user information ITU-T Recommendation H.1.1.1.169.112) port: 5122 callIdentifier (CallIdentifier) guid: 908552FC-3018-E030-8449-AC14C86413C4 2) Scenerio 2: SoftX3000B sends back Call Proceeding message.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (setup) setup protocolIdentifier: 0.225.8.0.323 Protocol discriminator: X.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.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.112 (191.208 and X. indicating that the call has been processed. The VendorIdentifier in the UUIE field of the message 4-75 .2250. Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. After SoftX3000A receives the message. vendor identifier is 0. Besides.209 coded user information ITU-T Recommendation H. it is indicated that SoftX3000B is Huawei NGN SoftX3000 product. the country code is 28.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (callProceeding) callProceeding protocolIdentifier: 0. indicating that the call has arrived and asking PhoneB resident gateway to play ringing tone. extension is 21. Here. whose version is SoftX3000V3.931 Call reference value length: 2 Call reference value: 8157 Message type: ALERTING (0x01) User-user 4-76 .323 indicates the vendor identifier of SoftX3000B. it asks PhoneA resident gateway to play ringback tone.8.2250.931 Protocol discriminator: Q. Q.0.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. Q.208 and X.225.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.931 Protocol discriminator: Q. 8.209 coded user information ITU-T Recommendation H.2250.245 TCP connection. User-user 4-77 Ltd.323 PhoneB sends Connect message to SoftX3000A.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.0.225.. to request H.242 Display Information element: Display Length: 30 Display information: Huawei Technologies Co.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (alerting) alerting protocolIdentifier: 0. Q. .931 Protocol discriminator: Q.0.323 Information element: User-user Length: 129 Protocol discriminator: X.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.208 and X.221 and H.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. Q.225.1. Now.169.323 Information element: User-user Length: 86 Protocol discriminator: X.245”.2250.208 and X.0.2 4-78 .931 Protocol discriminator: Q. The "Reason” is “Start H.208 and X. where the IP address is 191.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.8. and the port number is 5259.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (connect) connect protocolIdentifier: 0.209 coded user information ITU-T Recommendation H.0.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (facility) facility protocolIdentifier: 0.0.209 coded user information ITU-T Recommendation H.0. The UUIE in the message carries H.225.110.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.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.8.2250. the call is set up.245 control channel transmission layer address (IP address plus TCP port number) of SoftX3000B. 323 conferenceID: 908552FC-3018-E030-844A-AC14C86413C4 reason (startH245) startH245: startH245 h245Address (ipAddress) ipAddress ip: 191.1.245 request terminalCapabilitySet sequenceNumber: 2 protocolIdentifier: 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 .1.169.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.245.0.0.245 request message TCS to SoftX3000A to start capability exchange procedure.8. ITU-T Recommendation H. SoftX3000B sends H.169.110 (191. so that SoftX3000A can know the receive and transmit capabilities of SoftX3000B.110) port: 5259 h245Tunneling: False 6) Scenario 6: After the call is set up. and sends back TCSA message to acknowledge.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.245 response terminalCapabilitySetAck sequenceNumber: 2 4-80 . ITU-T Recommendation H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. 245 request terminalCapabilitySet sequenceNumber: 1 protocolIdentifier: 0.0.0. so that SoftX3000B can know the receive and transmit capabilities of SoftX3000A.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 .8.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System 8) Chapter 4 H. ITU-T Recommendation H.245 request message TCS to SoftX3000B to start capability exchange procedure.323 Scenario 8: SoftX3000A sends H.245. ITU-T Recommendation H. the capability exchange procedure is over. Now. and sends back TCSA message to acknowledge. ITU-T Recommendation H.245 response terminalCapabilitySetAck sequenceNumber: 1 10) Scenario 10: SoftX3000A sends MSD message to SoftX3000B.245 request masterSlaveDetermination terminalType: 120 statusDeterminationNumber: 14134743 4-82 . to start master slave determination procedure.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.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. 245 request masterSlaveDetermination terminalType: 120 statusDeterminationNumber: 4335996 13) Scenario 13: SoftX3000A receives the MSD message from SoftX3000B. ITU-T Recommendation H. to start master slave determination procedure.711 audio signals and RTP encapsulated real-time media information (audio). SoftX3000B sends the result to SoftX3000A through MSDA message. to get the result that it is Slave.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. ITU-T Recommendation H.245 response masterSlaveDeterminationAck decision (master) master: slave 12) Scenario 12: SoftX3000B sends MSD message to SoftX3000A. Then.38) and port number (30001) used by PhoneA resident gateway to transmit quality parameter information of RTCP encapsulated real-time signal transmission. and it compares the carried terminalType and statusDeterminationNumber with its corresponding values. This channel is used to transmit G. ITU-T Recommendation H. and it compares the carried terminalType and statusDeterminationNumber with its corresponding values. SoftX3000A sends the result to SoftX3000B through MSDA message.169. The message carries the IP address (191.3.245 response masterSlaveDeterminationAck decision (slave) slave: master 14) Scenario 14: SoftX3000A sends OLC message to SoftX3000B.245 request openLogicalChannel forwardLogicalChannelNumber: 4 forwardLogicalChannelParameters (OpenLogicalChannel-forwardLogicalChannelParameters) dataType (audioData) audioData g711Alaw64k: 20 multiplexParameters (h2250LogicalChannelParameters) h2250LogicalChannelParameters 4-83 . Then.323 11) Scenario 11: SoftX3000B receives the MSD message from SoftX3000A. to start OpenLogicalChannel procedure. ITU-T Recommendation H. to get the result that it is Master. 135 (191.169.3. The message carries the IP address (191.711 audio signals and RTP encapsulated real-time media information (audio).169. ITU-T Recommendation H.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.135) and port number (30019) used by PhoneB resident gateway to transmit quality parameter information of RTCP encapsulated real-time signal transmission.1. to start OpenLogicalChannel procedure.169.1.135 (191.38 (191.323 sessionID: 1 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.135) and port number (30019) used by PhoneB resident gateway to transmit RTP encapsulated real-time media information (audio signals).1.135) tsapIdentifier: 30018 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.169.3. and the IP address (191.135) tsapIdentifier: 30019 16) Scenario 16: SoftX3000B sends OLC message to SoftX3000A.1.38) tsapIdentifier: 30001 mediaControlGuaranteedDelivery: False silenceSuppression: False 15) Scenario 15: SoftX3000B sends back OLCA message as response.169.169.245 response openLogicalChannelAck forwardLogicalChannelNumber: 4 forwardMultiplexAckParameters (h2250LogicalChannelAckParameters) h2250LogicalChannelAckParameters sessionID: 1 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191. This channel is used to transmit G.169.135) and port number (30019) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.169.1.1.245 request openLogicalChannel forwardLogicalChannelNumber: 2 4-84 .169.1. The message carries the IP address (191. ITU-T Recommendation H. 169.169.135 (191.169.3. SoftX3000B sends ESD message to SoftX3000A to request converstation end.1.38 (191. Now.38) tsapIdentifier: 30001 18) Scenario 18: PhoneB hooks on.135) tsapIdentifier: 30019 mediaControlGuaranteedDelivery: False silenceSuppression: False 17) Scenario 17: SoftX3000A sends back OLCA message as response.38) and port number (30000) used by PhoneA resident gateway to transmit RTP encapsulated real-time media information (audio signals).169.38 (191.3.3.169. the audio logical channels at both ends are opened. and the IP address (191.1. 4-85 . that is the logical channel signaling procedure is over. ITU-T Recommendation H.169. The message carries the IP address (191.38) tsapIdentifier: 30000 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.169.323 forwardLogicalChannelParameters (OpenLogicalChannel-forwardLogicalChannelParameters) dataType (audioData) audioData g711Alaw64k: 20 multiplexParameters (h2250LogicalChannelParameters) h2250LogicalChannelParameters sessionID: 1 mediaControlChannel (unicastAddress) unicastAddress iPAddress network: 191.3.169. and both parties begin converstation.38) and port number (30001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.3.3.245 response openLogicalChannelAck forwardLogicalChannelNumber: 2 forwardMultiplexAckParameters (h2250LogicalChannelAckParameters) h2250LogicalChannelAckParameters sessionID: 1 mediaChannel (unicastAddress) unicastAddress iPAddress network: 191.Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H. Signaling & Protocols – Technical Manual U-SYS SoftX3000 SoftSwitch System Chapter 4 H.245 command endSessionCommand disconnect: disconnect 4-86 . SoftX3000A sends ESD message to SoftX3000B.2 reason (undefinedReason) undefinedReason: undefinedReason callIdentifier (CallIdentifier) guid: 908552FC-3018-E030-8449-AC14C86413C4 h245Tunneling: False 20) Scenario 20: PhoneA hooks on.931 Release Complete message to SoftX3000B.0. Now. Meanwhile. ITU-T Recommendation H. whole call procedure is over. to close the channel.208 and X. Now. SoftX3000A asks PhoneA resident gateway to play busy tone. Q.931 Protocol discriminator: Q. the call is released.2250.245 command endSessionCommand disconnect: disconnect 19) Scenario 19: SoftX3000A sends 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.0 h323_uu_pdu (H323-UU-PDU) h323_message_body (releaseComplete) releaseComplete protocolIdentifier: 0.8.323 ITU-T Recommendation H.225.0.209 coded user information ITU-T Recommendation H. It also uses the standard IP transport protocol as the transmission bottom layer. ISDN Q. Currently SoftX3000 uses Stream Control Transmission Protocol (SCTP) specified by the IETF.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. The SS7 adaptation protocols are applicable to existing SCN signaling systems and protocols.1. Caution: z The SIGTRAN protocol stack only implements SCN signaling adaptation and transmission on IP network without processing user-layer signaling messages.921-User Adaptation Layer (IUA).2-User Adaptation Layer (V5UA).This protocol stack supports transmission of switched circuit network (SCN) signaling across IP network. and satisfies the special transmission requirements of SCN signaling by adding its own functions.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Chapter 5 SIGTRAN 5. and V5. 7 (SS7) and the Internet Protocol (IP). z z 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. z The second class refers to SS7 adaptation protocols including SS7 MTP2-User Adaptation Layer (M2UA). 5-1 . SS7 MTP3-User Adaptation Layer (M3UA). 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.1 Overview 5. M3UA M2UA IUA SUA M2PA V5UA ….1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 5.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. 5. the MG terminates SCN media streams. When media steams are transmitted from the packet-switching network to the SCN. translate or terminate SS7 signaling. and then transfers the data packets to the packet-switching network.2-User Adaptation Layer IP: Internet Protocol .) III. can receive or transmit internal SCN signaling at the edge of IP network. z Terminating and initiating SCN signaling protocols. reverse processes are performed.1.3 Structure of Protocol Stack Figure 5-1 illustrates the SIGTRAN protocol model. (ISUP is the acronym of ISDN User Part. MGC might have the following capabilities: z Authorizing resource usage according to the local strategies. Media Gateway (MG) When media streams are transferred from the SCN to the packet-switching network. a signaling agent. II. SoftX3000 has MGC functions. SCTP IP M3UA: MTP3-User Adaptation Layer IUA: ISDN Q. such as SS7-ISUP and Q.931. Media Gateway Controller (MGC) MGC processes registration and management of MG resources. The SG in the SS7-Internet gateway can relay. Signaling Gateway (SG) SG.2 Terminology I. puts them into data packets (if the media data is not in form of packets). The SG functions might also be integrated into the MG functions. 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. for example. and media streams (such as trunk voice channel) are accessed by the trunk media gateway (TMG). 5-3 . The SIGTRAN implemented in the SoftX3000 is illustrated in Figure 5-2. thereby achieving the interworking between the circuit switched network and the packet switched network. the SIGTRAN stack is employed between the SG and the SoftX3000.The SG packs the inter-layer primitives (or narrowband signaling) and transmits them to the SoftX3000. not SIGTRAN. for transmission of narrowband circuit-switched signaling over IP network.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.4 SIGTRAN Implementation in SoftX3000 The SIGTRAN is used in SoftX3000 connection with an 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. SS7 ISUP and Intelligent Network Application Part (INAP).1. Depending on the location of the SG. for signaling transmission. The SoftX3000 processes the signaling and controls the bearer connection of the MG through a media gateway control protocol (H.248). In this model. The working principle of the SIGTRAN is as follows: SCN signaling is accessed by the SG. Signaling stream Media stream SIGTRAN/SS7 SS7 SG H. 2. encapsulates the signaling into IP packets. M3UA. The design of the SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. SCTP is chosen as the transport protocol in the SIGTRAN protocol stack. the upper-layer users of the SCTP are SCN signaling adaptation modules. 5. 5. has some disadvantages such as line header block. for example. z Independent SG The SG converts and adapts SCN signaling.2. a transport-layer protocol type.2 SCTP 5. TCP.1 Introduction Before the SCTP is stipulated. The SCTP has optimized real-time performance and supports the multi-homing function. and transmits the packets to the SoftX3000 across the IP network. IUA. and vulnerable to denial of service (DOS) attacks. UDP is a connectionless transport protocol and cannot guarantee the quality of transmission required by SS7 signaling. UDP and TCP carry SS7 signaling traffic over IP network. and transmission-reliable protocol—SCTP. The SCTP is a transport-layer protocol above which SCTP user applications are operating and below which a packet-based network is lying. packet-based. Because the SCTP is transmitted on 5-4 . however. In the SIGTRAN implementation. TCP is a connection-oriented transport protocol and guarantees the reliable transmission of signaling.2 Terminology I. The underlying layer of the SCTP is the IP network. and transmits the packets to the SoftX3000 across the IP network. The SCTP removes those problems existing in the TCP and thus provides a higher reliability of signaling transmission. difficult multi-homing implementation. IUA. Therefore. the IETF put forward a connection-oriented. To solve those problems. poor real-time ability. or V5UA of the SIGTRAN. The position of the SCTP in the SIGTRAN protocol stack is shown in Figure 5-1. The signaling transmission is based on M2UA. and V5UA. M2UA. Signaling transmission is based on M3UAof the SIGTRAN. encapsulates the signaling into IP packets. and a transport-layer port number. Transport Address A transport address is defined by the combination of an IP address.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. 93 and 1024 mean another transport address. Host and Endpoint z Host A host is configured with one or multiple IP addresses. in an SCTP association.28. In SoftX3000. all transport addresses used by the SCTP endpoint must use the same port number. while 10. 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.28. and it is identical to TCP port number in the concept. an SCTP association can be uniquely identified by the combination of four parameters. and peer SCTP port number. An endpoint is the logical sender/receiver of SCTP packets.92 and SCTP port number 1024 indicate a transport address. but can use multiple IP addresses. Because an association depends on the transport addresses used by the endpoints in the association. For example. peer IP address. namely local IP address. Strictly speaking. two SCTP endpoints must not have more than one SCTP association between them at any given time.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN the IP. established between two SCTP endpoints for data transmission. Similarly 10. local SCTP port number. an SCTP transport address is the combination of an IP address and an SCTP port number.92 and 1023 indicate a different transport address. stream.105. an association might be an M2UA link. z SCTP Endpoint Endpoint is one of the basic concepts of SCTP. As prescribed in the SCTP. an M3UA link. the IP address 10. Association and Stream z Association An association is the logical relationship or said channel. A transport address (the combination of an IP address and an SCTP port number) uniquely identifies an endpoint. It is a typical logical entity. An endpoint might be defined by several transport addresses. is a uni-directional 5-5 . or an IUA link. Notes: A host can have more than one endpoint. a V5UA link. II.28. III.105. For the same destination endpoint. It is a typical physical entity. SCTP port number is used for the identification of the users at the same address. by using the four-way handshake mechanism prescribed in SCTP.105. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN logical channel established from one endpoint to the other associated endpoint. An SCTP association might include several paths but has only one primary path.23.23. As shown in Figure 5-3. An association is composed of several uni-directional streams.11. z The data to be delivered in sequence must be conveyed within a single stream. Stream IDs identifies the streams. The number of available streams depends on the negotiation of the endpoints when an association is established between them.11.23.15:2905). This is the multi-address feature of an SCTP association. SoftX3000) has two transport addresses (10.11. any of which is independent of the others. 5-6 .16:2904 and 10. 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. This is also the greatest difference of SCTP from TCP.14:2905 and 10. Note: z Multiple streams might be in the same stream.17:2904). A stream cannot belong to more than one association. an endpoint on the SG also has two transport addresses (10. the SCTP endpoint is multi-homed. and thus there are several paths between the associated endpoints. Each stream transmits data without influence from other streams. z 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. Sending to different destination transport addresses does not necessarily guarantee getting separate paths.11. The number of outgoing streams might be different from that of incoming streams. IV.23. Both SCTP endpoints in an SCTP association can be configured with several IP addresses. 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. If there is more than one destination address to an endpoint. an endpoint on the MGC (for example. 23. z Path 0: The local transport address 1 (10. 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.11.11.11.16 Path0 Path2 MGC 10.23.11. 5-7 .16:2904).23. When the primary path becomes faulty.11. an endpoint should always transmit SCTP packets through the primary path from a local transport address A to the peer endpoint.14:2905) transmits SCTP packets to the peer transport address 2 (10. When a path is idle. The SCTP defines heartbeat messages.11.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 10.23.14 Chapter 5 SIGTRAN 10.11.23.15:2905) transmits SCTP packets to the peer transport address 2 (10.17:2904).11. the SCTP switches the transport addresses of the local endpoint.11. Selections of the paths depend on your data configurations.16:2904).23. z Path 1: The local transport address 1 (10.23.23. furthermore.23.15:2905) transmits SCTP packets to the peer transport address 1 (10. 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. Path 1.17 Figure 5-3 Multi-homing function of SCTP The two endpoints determine an association that includes four paths.11. you configure the four paths and set Path 0 as the primary path. the SCTP automatically switches over to one of the backup paths.23. as shown in Figure 5-4. For example.11. namely Path 0.15 Path1 Path3 SG 10. The SCTP working principles for data transmission from an endpoint are as follows: By default.17:2904).23. and Path 3. z Path 2: The local transport address 2 (10. The SCTP preferentially switches the transport addresses of the peer endpoint. Path 2.11.14:2905) transmits SCTP packets to the peer transport address 1 (10. z Path 3: The local transport address 2 (10.23. to ensure sequenced transmission in the stream. An endpoint in an association assigns a 32-bit sequence number. z SSN The SCTP assigns a 16-bit stream sequence number (SSN) to each data chunk sent in a stream by the local end. 5-8 .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 z TSN The SCTP uses a transmission sequence number (TSN) mechanism to acknowledge data transmission. When it is found that TSNs are not continuous. the TSN mechanism helps to achieve acknowledged transmission and sequenced-delivery of data. 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. Note: In the TCP. 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. TSN is maintained on the basis of association. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN At the establishment of an association. restricting the amount of data it can transmit. the SSNs in all streams are numbered from 0.2. 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. Congestion window (CWND) is maintained on the basis of each destination address and will be adjusted according to the network condition. the SCTP has the following functions: z Association startup and takedown z Sequenced delivery within streams z User data fragmentation z Acknowledgement and congestion avoidance z Chunk bundling z Packet validation z Path management 5-9 . The two RWND values will vary with data transmission and acknowledgement. Once the length of the unacknowledged message sent from the destination address is greater than the CWND value. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association. 5. the endpoint will stop transmitting data to this address. If the RWND is equal to 0. 2) CWND SCTP is a sliding window protocol.3 SCTP Functions As shown in Figure 5-5. During the association establishment. in effect. This is. When an SSN reaches 65535. the data sender can always have one packet in flight to the receiver. The assignments of TSN and SSN are independent to each other. which allows the sender to probe for a change in buffer of the data receiver by means of the acknowledgement message. the subsequent SSN is numbered from 0 again. 3) RWND Receiver window (RWND) indicates the size of the receiver’s inbound buffer in an association. both data sender and receiver will exchange their RWND value with each other. 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. Cookie is a data chunk containing the initialization information and encryption information about the endpoint. When either endpoint performs a shutdown. and uses stream number and SSN to achieve sequenced delivery of data. With streams. shutdown) for an active association on request from the SCTP user. 5-10 . SCTP provides graceful close (that is. the association on each peer will stop accepting request primitives from its user. for example. SCTP delivers the data to the SCTP user. and the stream is the basis for sequenced transmission. The datagrams sent in sequence must be put in one stream. SCTP uses the TSN mechanism to achieve acknowledged transmission of data. SCTP also allows ungraceful close (that is. When the SSNs that SCTP receives are sequential. abort) either on request from the user or as a result of an error condition detected within the SCTP layer. The startup uses a four-way handshake and employs a cookie mechanism. SCTP does not support a half-open state wherein one side might continue sending data while the other end is closed. the startup of an SCTP association is relatively complicated. SCTP provides two mechanisms respectively for data acknowledgement and sequenced delivery. 2) Sequenced delivery within streams SCTP can transport the datagrams in sequence.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. M2UA or M3UA. without waiting for continuity of TSNs of the data. Compared with a TCP connection. z On receipt. SCTP bundles several pieces of user data into the same SCTP packet to improve the utilization ratio of the bandwidth. an SCTP implementation might still perform bundling to improve the efficiency even though the user has requested that SCTP not bundle. 3) User data fragmentation SCTP detects the path maximum transmission unit (PMTU) on the transport path. z During a congestion or retransmission. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received. So does SCTP. The SSN is used to guarantee sequenced delivery of messages within streams. without guarantee of in-sequence delivery. SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the PMTU. The TSN serves to ensure the reliability of the transmission. 4) Acknowledgement and congestion avoidance Acknowledgement and retransmission are measures taken by a protocol to guarantee transmission reliability. the transmission efficiency is very low. z Packet retransmission function is responsible for acknowledgement of TSNs as well as resistance to congestion. based on which SCTP fragments and then packetizes large user data to avoid multiple fragmentations and reassemblies at the IP layer. 5-11 . Congestion avoidance follows the window mechanism implemented in TCP. The receiver acknowledges all TSNs received. the next expected in-sequence SCTP user message can be delivered from other streams. used for appropriate flow control. z SCTP assigns. z An SCTP packet consists of a common header followed by one or more chunks. z The SCTP user has the option to request bundling of more than one user messages into a single SCTP packet. The purpose is to reduce the data load on the IP layer. Therefore. Each chunk might contain either user data or SCTP control information. 5) Chunk bundling If short-length user data is attached with a large SCTP message header. in sequence. z Before transmission. even if there are gaps in the sequence. z TSN and SSN functionally separate reliable transmission from sequenced delivery. SCTP reassembles the fragments into complete messages before passing them to the SCTP user.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN When the stream is blocked. The acknowledgement mechanism is the basis for SCTP to guarantee transmission reliability. a TSN to each user data fragment or un-fragmented message before delivering it to the lower layer. z The TSN is independent of any SSN assigned at the stream level. SCTP also provides non in-sequence delivery service. and is used for normal sending of SCTP packets. The receiver discards packets received without the expected Verification Tag value.4 SCTP Primitives The upper layer protocols (ULP) requests for services by passing primitives to SCTP and receives notifications from SCTP for various events. and for reporting the transport addresses returned from the far end to the SCTP user. 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. At association startup. [optional attributes] 5-12 . [optional attributes] Returned result: mandatory attributes. 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.2. 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. 7) Path management The sending SCTP user can use a set of transport addresses as destinations for SCTP packets. The common header of an SCTP packet includes a Verification Tag field and a 32-bit Checksum field. SCTP primitive description uses the following format: Primitive name: mandatory attributes. The receiver of an SCTP packet with an invalid checksum discards the packet. The SCTP path management function chooses a destination transport address for each outgoing SCTP packet based on the SCTP user’s instructions and the currently perceived reachability status of the eligible destination set.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 path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup. 5. The Verification Tag value is chosen by each end of the association during association startup. On the receiving end. a primary path is defined for each SCTP endpoint. an error code shall be returned. SCTP will return to the ULP an event number (instance) of the SCTP association to be processed locally. 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. which is a local handle to the SCTP association. Request Primitives Sent from SCTP User to SCTP There are 16 request primitives sent from the SCTP user to SCTP. If the action of attempting to abort the association results in a failure. including the complete destination transport addresses of the peer as well as the outbound stream count of the local endpoint. This primitive allows the upper layer to initiate an association to a specific peer endpoint. 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. If the local SCTP instance has not been initialized. This primitive allows the SCTP user to notify SCTP of sending data to a destination transport address in a specified stream ID. If attempting to terminate the association results in a failure. The association will be terminated only after the peer acknowledges all the SCTP packets sent. the ASSOCIATE is considered an error. 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. If an association is successful. Once SCTP is initialized. ASSOCIATE An association ID. Returned result: Association ID This primitive is used to gracefully close an association. Any locally queued user data will be delivered to the peer. A success code will be returned on successful abortion of the association. ULP can communication directly with other endpoints without re-invoking this primitive.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN I. Returned result indicates whether the data is successfully sent. If SCTP is not able to open an SCTP association with the peer endpoint. an error is returned. will be returned on successful establishment of the association. The meanings of the request primitives are shown in Table 5-1. an error code shall be returned. A success code will be returned on successful termination of the association. 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. The peer endpoint shall be specified by one of the transport addresses which defines the endpoint. other association parameters might be returned. SHUTDOWN Returned result indicates whether the association is successfully closed. 5-13 . in bytes. depending on the specific implementation. their SSN might also be returned. an error shall be returned.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. 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. This primitive is used to return a data block containing the following information: STATUS y Association connection state y Destination transport address list y Destination transport address reachability states y Current receiver window size y Current congestion window size y Number of unacknowledged DATA chunks y Number of received DATA chunks y Primary path y Most recent SRTT on primary path y RTO on primary path Returned result is the state of the information that is required to return. also return other information such as the sender’s address. RECEIVE The size of the message read. Returned result indicates the performance of this operation. 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 indicates whether the transmission of the HEARTBEAT chunk to the destination address is successful. 5-14 . will be returned. and whether there are more messages available for retrieval. SET PRIMARY Returned result is a result code. It might. This primitive allows the ULP to instruct the local endpoint to perform a heartbeat on a specified destination address of a given association. If the destination transport address is not idle. 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 is an integer containing the most recent SRTT in milliseconds. indicating whether this operation is successfully performed. the stream ID on which it is received. For ordered messages. heartbeat will not take place. This primitive is used to read available user message in the SCTP queue into the buffer specified by the SCTP user. DESTROY Returned result indicates whether the operation is successful.) Returned result indicates whether it is successful. This primitive indicates the SCTP event number (instance) to be destroyed. y Data retrieval ID: an identification used to retrieve unsent and unacknowledged data. If a message cannot be delivered. Returned result is the number of bytes including the failure message. too long size. DATA ARRIVE The following information is passed with the notification: y Association ID: local handle to the SCTP association. (The SCTP event number is generated in the INITIALIZE primitive. Returned result indicates whether the operation is successful. 5-15 . Table 5-2 SCTP notification primitives Primitive Function When a user message is successfully received and ready for delivery to the SCTP user. The meanings of the notification primitives are shown in Table 5-2. The following information is passed with the notification: SEND FAILURE y Association ID: local handle to the SCTP association. for example. SCTP invokes this primitive to notify the SCTP user. 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. y Stream ID: indicates the stream on which the data is received. Notification Primitives Sent from SCTP to SCTP User There are eight notification primitives sent from SCTP to the SCTP user. SET PROTOCOL PARAMETERS This primitive allows the local SCTP to customize the protocol parameters. y Cause code: indicates the reason of the failure. SCTP invokes this primitive to notify the upper-layer user. II. RECEIVE UNSENT MESSAGE This primitive allows the ULP to instruct the local SCTP to store the received failure message in the ULP buffer. and message lifetime expiration. Returned result is the number of bytes including the unacknowledged message.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. y New-status: indicates the new status. NETWORK STATUS CHANGE The following information is passed with the notification: y Association ID: local handle to the SCTP association. y Destination transport address list: the complete set of transport addresses of the peer. y Outbound stream count: the maximum number of streams allowed to be used in this association by the SCTP user. when SCTP detects a recovery). y Last sent TSN: the TSN last sent to that peer endpoint. y Destination transport address: indicates the destination transport address of the peer endpoint affected by the status change.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Primitive Function When a destination transport address is marked inactive (for example. y Error info: indicates the type of the error and optionally some additional information received through the ERROR chunk.) When SCTP completely loses communication to an endpoint (through heartbeat) or detects that the endpoint has performed an abort operation. The status might indicate a failure or a normal termination event occurred in response to a SHUTDOWN or ABORT request. SCTP invokes this primitive to notify the SCTP user. The following information is passed with the notification: COMMUNCIATION UP y Association ID: local handle to the SCTP association. y Last acknowledged TSN: the TSN last acknowledged by that peer endpoint. y Inbound stream count: the number of streams that the peer endpoint has requested with this association. 5-16 . SCTP invokes this primitive. when SCTP detects a failure) or marked active (for example. y Data retrieval ID: an identification used to retrieve unsent and unacknowledged data. y Status: indicates the type of the event that has occurred. When SCTP receives an ERROR chunk from its peer and decides to notify its upper-layer user. SCTP invokes this primitive to notify the SCTP user. SCTP invokes this primitive to notify the SCTP user. (This might not be the same number as “outbound stream count". COMMUNICATION ERROR The following information is passed with the notification: y Association ID: local handle to the SCTP association. When the local SCTP becomes ready to send or receive SCTP packets or when a lost communication to an endpoint is restored. The following information is passed with the notification: COMMUNICATION LOST y Association ID: local handle to the SCTP association. y Status: indicates the type of the event that has occurred. RESTART The association ID is passed with the notification. 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 . 5. SCTP invokes this primitive to notify the SCTP user. is passed with the notification.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Primitive Function When SCTP detects that the peer has restarted. local handle to the SCTP association. SCTP invokes this primitive to notify the SCTP user.2. SHUTDOWN COMPLETE The association ID. When the local SCTP completes the shutdown procedure.5 SCTP Messages I. Message Structure Figure 5-6 shows the structure of an SCTP packet. a Chunk Length field. If a user message does not fit into one SCTP packet. the endpoints exchange this Tag with each other. a Destination Port Number. INIT ACK. it can be fragmented into multiple chunks. z Verification Tag (32 bits) When an association is established. a Chunk Flags field. the sender must carry the Tag of the peer in the common header for verification purposes. A chunk contains either control information or user data. On data transmission. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint or application. and a Chunk Value field. and SHUTDOWN COMPLETE chunks. 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. Multiple chunks can be bundled into one SCTP packet up to the MTU size. except for the INIT. 2) Format of chunk fields Each chunk is formatted with a Chunk Type field. the local endpoint generates a random identification to the association. and a Checksum. a Verification Tag. 1) Format of the common header SCTP common header is composed of a Source Port Number. z Destination Port Number (16 bits) This is the SCTP port number to which this packet is destined. z Source Port Number: 16 bits This is the SCTP sender’s port number. Table 5-3 SCTP chunk types ID Chunk type 0 DATA (payload data) Description Transmitted user data. Table 5-3 lists the values of Chunk Types. These chunks must not be bundled with any other chunk in a packet. 5-18 . z Chunk Type (8 bits) This field identifies the type of information contained in the Chunk Value field.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN An SCTP packet is composed of a common header and several chunks. the destination port number. 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 can use it in combination with the source IP address. and possibly the destination IP address to identify the association to which this packet belongs. During association startup. 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. 9 ERROR An endpoint sends this chunk to its peer endpoint to notify it of certain error conditions. 5 HEARTBEAT ACK Response to a HEARTBEAT chunk. 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 . 3 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. It is sent by the initiator of an association to its peer to complete the initialization process. 4 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. 6 ABORT This chunk is sent to the peer of an association to close the association. 7 SHUTDOWN An endpoint in an association uses this chunk to initiate a graceful close of the association with its peer. 8 SHUTDOWN ACK This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. 10 COOKIE ECHO This chunk is used only during the initialization of an association.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System ID Chapter 5 SIGTRAN Chunk type Description 1 INIT This chunk is used to initiate an SCTP association between two endpoints. 11 COOKIE ACK This chunk is used to acknowledge the receipt of a COOKIE ECHO chunk. 2 INIT ACK This chunk is used to acknowledge the initiation message (INIT) of an SCTP association. they are set to zero on transmit and are ignored on receipt. and Value fields) must be a multiple of four bytes. 10 Skip this chunk and continue processing. 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. Note: The total length of a chunk (including Type. Chunk Flags (8 bits) The usage of these bits depends on the chunk type as given by the Chunk Type. 5-20 . Report to the initiating endpoint the unrecognized parameter either in an ERROR or in the INIT ACK. Chunk Length. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown in Figure 5-7. Report to the initiating endpoint the unrecognized parameter either in an ERROR or in the INIT ACK. the sender must pad the chunk with all zero bytes and this padding is not included in the chunk length field. Length. and Chunk Value fields. Table 5-4 Meanings of the highest-order two bits of Chunk Type Bits (highest-order two bits) z Meaning 00 Stop processing this SCTP packet and discard it. 11 Skip this chunk and continue processing. Chunk Flags. 01 Stop processing this SCTP packet and discard it. The receiver must ignore the padding bytes. The length is expressed in a binary number. If the length of the chunk is not a multiple of four bytes. followed by zero or more parameters. Table 5-4 shows the meanings of the bit combinations. z Chunk Length (16 bits) This value represents the size of the chunk including the Chunk Type. Unless otherwise specified. Do not process any further chunks within it. The sender should never pad with more than three bytes. Do not process any further chunks within it. The contents depend on the Chunk Type. The length of the Chunk Value is variable. z Chunk Value (variable length) The Chunk Value field contains the actual information to be transferred in the chunk.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. Therefore. a parameter with a zero-length Parameter Value field would have a Length field of 4. z Chunk Parameter Value (variable-length) This field contains the actual information to be transferred in the parameter. The Parameter Length does not include any padding bytes. 5-21 . including the Parameter Type. It takes a value from 0 to 65534. 01 Stop processing this SCTP packet and discard it. Do not process any further chunks within it. Table 5-5 shows the meanings of the bit combinations. The value of 65535 is reserved for IETF-defined extensions.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. Report the unrecognized parameter either in an ERROR or in the INIT ACK. 11 Skip this chunk and continue processing. Parameter Length. Chunk Parameter Length (16 bits) This field contains the size of the parameter. 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. in bytes. and Parameter Value fields. 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 Meanings of the highest-order two bits of Chunk Parameter Type Bits (highest-order two bits) z Meaning 00 Stop processing this SCTP packet and discard it. 10 Skip this chunk and continue processing. z U bit (1 bit) The unordered bit. the sender pads the parameter at the end with all zero bytes. and Value fields) must be a multiple of four bytes. each fragment of the message must have its U bit set to “1”. the receiver must ignore the SSN field. II. 0 1 2 3 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. unordered DATA chunks are dispatched to the SCTP user by the receiver without any attempt to re-order. A sender should not pad with more than three bytes. If the length of the parameter is not a multiple of four bytes. Length. The length of the padding is not included in the parameter length field. After re-assembly (if necessary). if set to “1”. Format of SCTP Chunks 1) Payload data (DATA) Figure 5-8 shows the format for the DATA chunk. indicates that this is an unordered DATA chunk. Therefore. The receiver must ignore the padding bytes.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Note: The total length of a parameter (including Type. z Reserved (5 bits) The Reserved bits are set to all zeros and ignored by the receiver. and there is no stream sequence number assigned to this DATA chunk. If an unordered user message is fragmented. 5-22 . A DATA chunk with no user data field will have Length set to 16 (indicating 16 bytes). z Stream ID This field identifies the stream to which the following user data belongs.1). When a user message is fragmented by SCTP for transport. indicates the first fragment of a user message. z Payload Protocol Identifier (32 bits) This value represents an application (or upper layer) specified protocol identifier. z SSN (16 bits) This value represents the stream sequence number of the following user data within the stream. The upper layer (SCTP user) passes this value to SCTP and sends it to the peer. z TSN (32 bits) This value represents the TSN for this DATA chunk. Table 5-6 shows the meanings of the B and E bits. This means that the TSNs for each fragment of a fragmented user message must be strictly sequential. An unfragmented user message shall have both the B and E bits set to “1”. indicates the last fragment of a user message. if set. the receiver uses the TSNs to reassemble the message. Certain network entities and the peer application use this 5-23 . SCTP does not use this identifier. When a user message is fragmented into multiple chunks. E bit z The ending fragment bit. the same sequence number must be carried in each of the fragments of the message. TSN wraps back to 0 after reaching 4294967295. if set. The valid range of this field is 0 to 65535. Table 5-6 Meanings of the B and E bits B z E Meaning 1 0 First piece of a fragmented user message 0 0 Middle piece of a fragmented user message 1 1 Last piece of a fragmented user message 1 1 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN B bit z The beginning fragment bit. The valid range of TSN is from 0 to 4294967295 (232 . Setting both B and E bits to “0” indicates a middle fragment of a multi-fragment user message. Variable parameters include IPv4 Address. Host Name Address. and Initial TSN. z Chunk Flags The Chunk Flags field in INIT is reserved and all bits in it should be set to “0”. The value 0 indicates no application identifier is specified by the upper layer for this payload data. IPv6 Address. 2) Initiation (INIT) This chunk is used to initiate an SCTP association between two endpoints. Cookie Preservative. Fixed parameters include Initiate Tag. each parameter must only be included once in the INIT chunk. 0 1 2 3 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. A sender should not pad with more than three bytes. The sequence of parameters within an INIT can be processed in any order. This field must be sent even in fragmented DATA chunks to make sure it is available for agents in the middle of the network. Unless otherwise noted. This field must be padded to be a multiple of four bytes. and Supported Address Type. Number of Outbound Streams. Number of Inbound Streams. ECN Capable. Figure 5-9 shows the format of the INIT chunk.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. Advertised Receiver Window Credit. User Data (variable length) z This is the payload user data. z Initiate Tag (32 bits) 5-24 . The receiver must ignore the padding bytes. A receiver of an INIT with the MIS value of 0 will abort the association. the sender of the INIT has reserved in association with this window. z Initial TSN This field defines the initial TSN that the sender will use. and can be used as a destination address of an IP datagram sent from the receiver of the INIT.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. 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. during the lifetime of this association. 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. If the value of the Initiate Tag in a received INIT chunk is found to be 0. During the life of the association this buffer space should not be lessened (that is. however. This value must be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association. That is. An INIT chunk might contain several IPv4 or IPv6 addresses or a combination of addresses. z Advertised Receiver Window Credit (a_rwnd. 32 bits) This value represents the dedicated buffer space. the sender can use an IPv4 Address Parameter for an IPv4 address. The value of 0 must not be used. A receiver of an INIT with the OS value set to 0 will abort the association. A sender must not use an IPv4-mapped IPv6 address. this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT. The Initiate Tag is allowed to take any value except 0. instead. The value of 0 must not be used. 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. z IPv6 Address This field contains an IPv6 address of the sending endpoint. When the INIT sender is 5-25 . z IPv4 Address This field contains an IPv4 address of the sending endpoint. the receiver must treat it as an error and close the association by transmitting an ABORT. in number of bytes. It is binary encoded. This field might be set to the value of the Initiate Tag field. dedicated buffers taken away from this association). An INIT chunk might contain several IPv4 or IPv6 addresses or a combination of addresses. Combined with the Source Port Number in the SCTP common header. It is binary encoded. The peer is responsible for resolving the name. 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 Address Type This parameter is filled with the type value of the corresponding address (for example. IPv4 and IPv6 addresses are allowed in the same INIT chunk. 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. The method for resolving the host name is out of scope of SCTP. 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. If the INIT does not contain any IP Address parameters. IPv6 = 6. 5-26 . 3) Initiation Acknowledgement (INIT ACK) The INIT ACK chunk is used to acknowledge the initiation of an SCTP association. a multi-homed endpoint might have access to different types of network. 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. more than one IP Address parameter can be included in an INIT chunk. Using this parameter might make it more likely for the association to work across a network address translation (NAT) box. Moreover. The receiver might choose to ignore the suggested cookie life-span increase for its own security reasons. z Supported Address Types The sender of INIT uses this parameter to list all the address types it can support. That is.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN multi-homed. 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 Host Name This variable-length field contains a host name defined according to “host name syntax” in RFC1123. Hostname = 11). IPv4 = 5. 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. At least one null terminator is included in the Host Name string and must be included in the length. and thus more than one address type can be present in one INIT chunk. the sender of the INIT ACK has reserved in association with this window. A receiver of an INIT ACK with the MIS value set to 0 will destroy the association discarding its TCB. If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0. z Initial TSN (32 bits) 5-27 . The Initiate Tag is allowed to take any value except 0. It uses two extra variable parameters: State Cookie and Unrecognized Parameter. 16 bits) This field defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. 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 receiver must treat it as an error and close the association by transmitting an ABORT. A receiver of an INIT ACK with the OS value set to 0 will destroy the association discarding its TCB. z Number of Outbound Streams (OS. z Number of Inbound Streams (MIS. in number of bytes. During the life of the association this buffer space should not be lessened. 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 value of 0 must not be used. 0 1 2 3 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. z Advertised Receiver Window Credit (32 bits) This value represents the dedicated buffer space.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Figure 5-10 shows the format of the INIT ACK chunk. The value of 0 must not be used. 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. 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.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. 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. When the INIT ACK sender is multi-homed. 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. 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. z IPv4 Address and IPv6 Address Combined with the Source Port Number in the SCTP common header. Moreover. 5-28 . during the lifetime of this association. The parameter value must contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association. If the INIT ACK contains at least one IP Address parameter. Length. and thus more than one address type can be present in one INIT chunk. this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT ACK. Figure 5-11 shows the format of the SACK chunk. This parameter value field contains unrecognized parameters copied form the INIT chunk complete with Parameter Type. and Value fields. “Gaps” refer to the cases in which the TSNs of the received DATA chunks are not sequential. This field might be set to the value of the Initiate Tag field. and can be used as a destination address of an IP datagram sent from the receiver of the INIT ACK. a multi-homed endpoint might have access to different types of network. IPv4 and IPv6 addresses are allowed in the same INIT chunk. along with a Message Authentication Code. more than one IP Address parameter can be included in an INIT chunk. That is. z State Cookie (variable length) The parameter length depends on the size of cookie. If the INIT ACK does not contain any IP Address parameters. That is. z Advertised Receiver Window Credit (a_rwnd) This field indicates the updated receive buffer space. z Chunk Flags This parameter is set to all zeros on transmit and ignored on receipt.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 Number of Gap Ack Blocks = N This field indicates the number of Gap Ack Blocks included in this SACK. All TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. This parameter acknowledges the receipt of all TSNs that are less than or equal to this value. of the sender of this SACK. z Number of Duplicate TSNs = X 5-29 . Each Gap Ack Block acknowledges the sequence of TSNs received after an insequential TSN. The subsequent TSN is not received by the endpoint sending the SACK chunk. in bytes. z Cumulative TSN Ack This parameter contains the TSN of the last DATA chunk received in sequence before a gap. 0 1 2 3 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. the Cumulative TSN Ack is added to this offset number. To calculate the actual TSN number. Gap Ack Blocks z These fields contain the Gap Ack Blocks. Gap Ack Block Start z This field indicates the Start offset TSN for this Gap Ack Block. 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN This field contains the number of duplicate TSNs the endpoint has received. 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. To calculate the actual TSN number. that has been received. 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. 5-30 . z Chunk Flags (8 bits) This field is set to zero on transmit and ignored on receipt. This calculated TSN identifies the first TSN. the Cumulative TSN Ack is added to this offset number. Duplicate TSN z 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. This calculated TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block. Each duplicate TSN is listed following the Gap Ack Block list. Gap Ack Block End z This field indicates the End offset TSN for this Gap Ack Block. in this Gap Ack Block. Figure 5-12 shows the format of the HEARTBEAT chunk. z Chunk Flags (8 bits) This field is set to zero on transmit and ignored on receipt. The Heartbeat Information has a variable-length and untransparent data structure. 0 1 2 3 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. 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Heartbeat Length z This field is set to the size of the chunk. z Heartbeat Ack Length 5-31 . 6) Heartbeat Acknowledgement (HEARTBEAT ACK) An SCTP endpoint sends this chunk to its peer endpoint as a response to a HEARTBEAT chunk. Heartbeat Information TLV z The heartbeat parameter field contains Heartbeat Information (Heartbeat Information TLV). It is acceptable that only the sender understands the information. 0 1 2 3 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 sender’s current time when this HEARTBEAT chunk is sent and the destination transport address to which this HEARTBEAT is sent. including the chunk header and the Heartbeat Information field. Figure 5-13 shows the format of the Heartbeat Information. Figure 5-14 shows the format of the HEARTBEAT ACK chunk. in bytes. in bytes. otherwise. DATA chunks must not be bundled with ABORT. 7) Abort Association (ABORT) An SCTP endpoint sends an Abort chunk to the peer of an association to close the association. z Chunk Flags (8 bits) The high-order seven bits are reserved. The T bit is set to 1 if the sender did not have a TCB. 8) Shutdown Association (SHUTDOWN) 5-32 . If an endpoint receives an ABORT with a format error or for an association that does not exist. INIT ACK. Heartbeat Information TLV z This variable-length field contains the Heartbeat Information parameter of the Heartbeat Request to which this Heartbeat Acknowledgement is responding. z Zero or more Error Causes This field contains the information contents of the ABORT chunk. Moreover. They are set to zero on transmit and ignored on receipt. an endpoint that receives an ABORT must not respond to that ABORT by sending an ABORT of its own. including the chunk header and all the Error Cause fields present. they will be ignored by the receiver. under any circumstances. The T bit is set to 0 if the sender had a TCB that it destroyed. in bytes. This parameter field has a variable-length and untransparent data structure. including the chunk header and the Heartbeat Information field. and SHUTDOWN COMPLETE) might be bundled with an ABORT. Control chunks (except for INIT. 0 1 2 3 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 T Length zero or more Error Causes Figure 5-15 Format of ABORT z Type (8 bits) The value is 6. z Length (16 bits) This field is set to the size of the chunk.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN This field is set to the size of the chunk. Figure 5-15 shows the format of the ABORT chunk. but they must be placed before the ABORT in the SCTP packet. The ABORT chunk might contain Cause Parameters to inform the receiver the reason of the abort. it must silently discard it. 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 1 2 3 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 z The value is 7. Chunk Flags (8 bits) z This field is set to zero on transmit and ignored on receipt. Length z This field indicates the length of the SHUTDOWN chunk. It is set to 8. Cumulative TSN Ack z 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 1 2 3 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 0 Chapter 5 SIGTRAN 1 2 3 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 1 2 3 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: 5 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: 6 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: 8 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 0 Chapter 5 SIGTRAN 1 2 3 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) z The value is 10. Chunk Flags (8 bits) z This field is set to all zeros on transmit and ignored on receipt. Length (16 bits) z 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) z 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 1 2 3 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 1 2 3 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 T Length=4 Figure 5-22 Format of SHUTDOWN COMPLETE Type (8 bits) z 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) z 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 peer’s 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 peer’s 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 peer’s 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 peer’s 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 z Out queue: A queue of outbound DATA chunks. z In queue: A queue of inbound DATA chunks. 5) Suggested SCTP protocol parameter values z RTO.Initial: 3 seconds z RTO.Min: 1 second z RTO.Max: 60 seconds z RTO.Alpha: 1/8 z RTO.Beta: 1/4 z Valid.Cookie.Life: 60 seconds z Association.Max.Retransmissions: 10 attempts z Path.Max.Retransmissions: 5 attempts z Max.Init.Retransmissions: 8 attempts z 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: z 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. z OS: It represents the maximum number of outband streams expected by the local endpoint. z MIS: It represents the maximum number of inbound streams allowed by the local endpoint. 5-41 endpoint A starts the INIT timer and enters the COOKIE-WAIT state. After sending the INIT. endpoint A starts the COOKIE timer and enters the COOKIE-ECHOED state. 5-42 . endpoint A stops the INIT timer to quit the COOKIE-WAIT state. The necessary information and the MAC constitute the State Cookie parameter. it indicates that the peer endpoint cannot support the number of outbound streams expected by the local endpoint.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Note: For endpoint A and endpoint B. Note: The INIT timer is used to wait for an INIT ACK chunk returned by the peer endpoint. and sends a COOKIE ECHO chunk which echoes the State Cookie parameter contained in the INIT ACK chunk. In this case. After the TCB is created. The INIT ACK chunk must contain the following parameters: z Destination IP Address: It is set to the source IP address of the INIT chunk. z Local transport address z Maximum number of inbound streams z Maximum number of outbound streams 3) Upon receipt of the INIT ACK. If the maximum number of inbound streams of the peer endpoint is smaller than the maximum number of outbound streams of the local endpoint. the local endpoint retransmits an INIT chunk until the maximum number of retransmission reaches. 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. z State Cookie: A temporary TCB is created according to the basic information of the association. z Initiate Tag: It is set to Tag_B. each performs the related checks on the stream information received from the peer endpoint. 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. If no INIT ACK chunk is received when the timer expires. This computation is not reversible. 2) Upon receipt of the INIT message. endpoint B immediately responds with an INIT ACK chunk. Subsequently. create an association to endpoint A according to the information carried in the TCB. which has four message interactions: INIT. but the COOKIE ACK must be the first chunk in the packet. Endpoint B sends a SCOMMUNCIATION UP notification to the SCTP user.c) If the MACs are not the same. but the COOKIE ECHO must be the first chunk in the packet. compare the timestamp in the TCB with the current time to check whether the time expires the lifespan carried in the cookie. 5) Endpoint A sends a DATA chunk to endpoint B and starts the T3-RTS timer. and COOKIE ACK.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. The DATA chunk must contain the following parameters: z TSN: It is the initial TSN of the DATA chunk. b) Compare the computed MAC with the one carried in the State Cookie. Endpoint A notifies the SCTP user of the successful establishment of the association with a COMMUNICATION UP notification. endpoint A moves from the COOKIE-ECHOED state to the ESTABLISHED state and stops the COOKIE timer. Otherwise.d) If so. 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. 4) Upon receipt of the COOKIE ECHO chunk. If the same. COOKIE ECHO. Upon receipt of the COOKIE ACK chunk. the message is discarded. Note: The establishment of an association is a four-way handshake process. the message is discarded. Endpoint B enters the ESTABLISHED state and sends a COOKIE ACK chunk. INIT ACK. The sending endpoint cannot send other packets to the peer endpoint unless the returned COOKIE ACK chunk is received. 5-43 . Caution: The COOKIE ACK chunk can be bundled with one or more DATA or SACK chunks in the same SCTP packet. The SACK chunk must contain the following parameters: z Cumulative TSN Ack: It is the initial TSN of endpoint B. endpoint B returns an SACK chunk. The valid range is 0 to 65535. 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. z Stream Sequence Number: It represents the sequence number of the user data within the stream. endpoint A stops the T3-RTX timer. The SACK chunk must contain the following parameters: z Cumulative TSN Ack: It is the initial TSN of endpoint A. Suppose the stream sequence number is 0. 8) Endpoint B sends a second DATA chunk to endpoint A. 5-44 . z User Data: This field contains the payload user data.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. and the ABORT chunk must not be bundled with any DATA chunk. Upon receipt of the ABORT chunk. endpoint A returns an SACK chunk. z Gap Ack Block: Its value is 0. 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). 6) Upon receipt of the DATA chunk. Suppose the stream identifier is 0. z User Data: This field contains the payload user data. the stream sequence number is 1. Upon receipt of the SACK chunk. 9) Upon receipt of the DATA chunk. If the Verification Tag is the same as the local one. Suppose the stream identifier is 0. Suppose the stream identifier is 0. The SCTP packet sent must contain the Verification Tag of the peer. z User Data: This field contains the payload user data. z Stream Sequence Number: It represents the sequence number of the user data within the stream. The initiating endpoint sends an ABORT chunk to its peer endpoint. In this case. The DATA chunk must contain the following parameters: z TSN: It is the initial TSN of the DATA chunk sent by endpoint B. z Stream Sequence Number: It represents the sequence number of the user data within the stream. the receiving endpoint performs checks on the tag. z Stream Identifier: It identifies the stream to which the user data belongs. z Gap Ack Block: Its value is 0. This method does not take data security into consideration. The association abort procedure is simple. 7) Endpoint B sends a DATA chunk to endpoint A. The DATA chunk must contain the following parameters: z TSN: It is one plus the initial TSN of the DATA chunk sent by endpoint B. z Stream Identifier: It identifies the stream to which the user data belongs. II. starts the local T2-SHUTDOWN timer. With a shutdown of an association. the SCTP does not accept any data sending request from the SCTP user on this association. In addition. 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. Endpoint A starts the T2-shutdown timer and enters the SHUTDOWN-SENT state. The SCTP association moves from the ESTABLISHED state to the SHUTDOWN-PENDING state. endpoint A stops the T2-shutdown timer. 3) Upon receipt of the SHUTDOWN ACK message.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. After endpoint B’s data that is not sent or is sent but not acknowledged is sent or acknowledged. the SCTP waits for endpoint B’s acknowledgement to all sent but not acknowledged data of endpoint A. Meanwhile. sends a SHUTDOWN COMPLETE chunk to endpoint B. 2) Upon receipt of the SHUTDOWN message. endpoint A must retransmit the SHUTDOWN chunk. endpoint A sends a SHUTDOWN chunk to endpoint B. both ends of the association stop receiving new data from the respective SCTP users. endpoint B enters the SHOUTDOWN-RECEIVED state and no longer accepts new data sent from the SCTP user. In this state. the endpoint delivers the data in the packet to its SCTP user. and enters the SHUTDOWN-ACK-SENT state. and 5-45 . If the timer expires. endpoint B sends a SHUTDOWN ACK chunk. If the timer expires. The purpose of starting the T2-shutdown timer is to wait for a SHUTDOWN-ACK chunk returned by endpoint B. 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. endpoint B retransmits the SHUTDOWN ACK chunk. When sending or receiving a SHUTDOWN chunk. 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. When either endpoint performs a shutdown procedure. After all sent but not acknowledged data of endpoint A is acknowledged. 3. narrowband signaling of signaling end point (SEP) uses SG to access MGC. Upon receipt of the SHUTDOWN COMPLETE chunk. The upper layer user of M2UA at the MGC side is MTP3. removes all records about the association. 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. of which one or more are normally actively processing traffic.2 Terminology: I. Application Server (AS) AS is a logical entity. If it is not in this state. the chunk is discarded. See Figure 5-25.3. standing for a certain amount of resources and corresponding to a particular “routing context”. and enters the CLOSED state. endpoint B checks whether it is in the SHUTDOWN-ACK-SENT state. This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). For M2UA. AS is a group of Interface IDs. In the SIGTRAN protocol stack. Each AS contains a set of application server processes (ASPs).3 M2UA 5.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN removes all records about the association. 5-46 . 5. M2UA runs on top of SCTP and is the SCTP user.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. endpoint B stops the T2-shutdown timer. 5. and is MTP2 at the SG side. If the endpoint is in the SHUTDOWN-ACK-SENT state. A M2UA link consists of SG. this architecture can be simplified as in Figure 5-27. backup. Application Server Process (ASP) ASP is a process instance of an AS. and only the active ASP processes traffic. It can be text or integer. if this is not local. M2UA Link M2UA link is a logical connection established between SG and ASP of MGC (SoftX3000). Backhaul Backhaul refers to the transport of signaling from the point of interface for the associated data stream (that is. Interface ID Interface ID is used in the communication between the two ends of M2UA.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN II. After the concept of M2UA LINK is introduced. Its state corresponds to ASP state and SCTP association state. Each ASP contains an SCTP endpoint and can serve a number of ASs. IV. Signaling Gateway Process (SGP) SGP is a process instance that uses M2UA to communicate to and from a signaling link terminal (SLT). 5-47 . VI. ASPs work in the active/standby mode. SG function in the MG) back to the point of call processing (that is. the MGC). The interface ID is a logical ID of the MTP link used between SG and ASP. or load-sharing process of a signaling gateway. ASP. III. and SCTP association between SG and ASP. Each interface ID corresponds to one actual physical link. Figure 5-26 shows the network architecture of M2UA. 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.SGP serves as an active. Link key is used in a dynamic registration. VII. In the M2UA application. V. 3 Structure of Protocol Stack Figure 5-28 shows the M2UA protocol stack.Thus the data coming from an MTP link can be carried over the M2UA link transparently. M2UA SCTP IP MAC Figure 5-28 M2UA protocol stack 5. MTP3.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. 5-48 .Each MTP link will be mapped to a particular M2UA link by the M2UA interface ID. a TMG provides the SG functionality.3. where the correspondence should be configured by executing the related commands.4 Implementation of M2UA In NGN applications. 5. The networking is illustrated in Figure 5-29.3. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN SoftX3000 IP metropolitan area network H. 5. z Support for management layer communication between SG and MGC. Message Structure As shown in Figure 5-30. or as seamless as possible. and several variable-length M2UA messages. SG transports MTP3 messages over the IP network to SoftX3000 for processing. 5-49 . SG embedded in TMG terminates MTP2 layer messages. z Support for management of the SCTP association between SG and MGC.3. M2UA message structure is composed of a common message header. an M2UA message header. including a common message header and an M2UA message header. operation of the MTP2-Users in the PSTN and IP network.248/M2UA H. In other words. M2UA messages are encapsulated in the user data field of an SCTP message. SoftX3000 terminates MTP3 and upper layer messages.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.5 Protocol Messages I. 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. Message Class. Currently.921/Q. and Message Length fields. Message Type.931 boundary primitives transport (QPTM) messages [IUA] 6 MTP2 user adaptation (MAUP) messages [M2UA] 7 Connectionless messages [SUA] 8 Connection-oriented messages [SUA] 9 Routing key management (RKM) messages (M3UA) 5-50 .0. Spare. z Message Class Table 5-11 Message classes Value Meaning 0 Management (MGMT) messages [IUA/M2UA/M3UA/SUA] 1 Transfer messages [M3UA] 2 SS7 signaling network management (SSNM) messages [M3UA] 3 ASP state maintenance (ASPSM) messages [IUA/M2UA/M3UA/SUA] 4 ASP traffic maintenance (ASPTM) messages [IUA/M2UA/M3UA/SUA] 5 Q. z Spare The Spare field is set to all zeros by the sender and ignored by the receiver. Common Message Header The common message header contains the Version. its value is 1 and represents Release 1. z Version The Version field contains the version of M2UA. 4 Release Request It is used to release a channel. 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. to retrieve PDUs from the transmit and retransmit queues or to flush PDUs from the retransmit queue.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Value 10 Meaning Interface identifier management (IIM) messages (M2UA) 11–127 Reserved by the IETF 128–255 Reserved for IETF-Defined extensions Message Type z Table 5-12 lists the message types for the valid message classes. 9 State Indication It is sent from an SGP to an ASP to indicate a condition on a link. 5 Release Confirm It is used to confirm the Release Request message. 6 Release Indication It is used to indicate that the channel has been released. 12 Retrieval Indication It is sent by the SG with a PDU from the transmit or retransmit queue. 7 State Request It is sent from an MGC to cause an action on a particular MTP link supported by the SGP. 11 Retrieval Confirm It is sent by the SG to the related queue. 2 Establish Request When the MGC desires the MTP link to be in-service. 8 State Confirm It is sent by the SGP in response to a State Request from the MGC. 10 Retrieval Request It is sent by the MGC during the MTP Level 3 changeover procedure to request the BSN. 5-51 . Table 5-12 MTP2 user adaptation (MAUP) messages [M2UA] Value Message type Meaning 0 Reserved / 1 Data It contains an SS7 MTP2-User Protocol Data Unit (PDU). it will send the Establish Request message to the SG. 3 Establish Confirm The SG returns the Establish Confirm message to the MGC. 15 Data Acknowledge It is used to acknowledge the Data message. without any change. 6 Heartbeat Ack (BEAT ACK) It is sent in response to a Heartbeat message. 4 ASP Up Ack (UP ACK) Used to acknowledge an ASP Up message received from a remote M2UA peer. It includes all the parameters of the received Heartbeat message. 5 ASP Down Ack (DOWN ACK) It is used to acknowledge an ASP Down message received from a remote M2UA peer. 5-52 .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. 2 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. 16–127 Reserved by the IETF / 128–255 Reserved extensions for IETF-Defined / Table 5-13 Application server process state maintenance (ASPSM) messages Value Message type Meaning 0 Reserved / 1 ASP Up (UP) Used to indicate to a remote M2UA peer that the adaptation layer is ready to receive traffic or maintenance messages. 7–127 Reserved by the IETF / 128–255 Reserved extensions for IETF-Defined / Table 5-14 Application server process traffic maintenance (ASPTM) messages Value Message type Meaning 0 Reserved / 1 ASP Active (ACTIVE) It is sent by an ASP to indicate to an SGP that it is active and ready to be used. An M2UA peer must send a Heartbeat Ack in response to a Heartbeat message. 3 Heartbeat (BEAT) It is optionally used to ensure that the M2UA peers are still available to each other. For example. or a parameter value might be invalid. 1 Notify (NTFY) It is used to provide an autonomous indication of M2UA events to an M2UA peer. the message type might be unexpected given the current state. 4 ASP Inactive Ack (INACTIVE ACK) It is used to acknowledge an ASP Inactive message received from a remote M2UA peer. 5-53 . an ASP would send this message to an SGP. 3 ASP Active Ack (ACTIVE ACK) It is used to acknowledge an ASP Active message received from a remote M2UA peer. 5–127 Reserved by the IETF / 128–255 Reserved extensions for IETF-Defined / Table 5-15 Management (MGMT) messages Value Message type Meaning 0 Error (ERR) It is used to notify a peer of an error event associated with an incoming message. The REG RSP contains indications of success/failure for registration requests and returns a unique Interface Identifier value for successful registration requests. Registration Response (REG RSP) It is used as a response to the REG REQ message from a remote M2UA peer. 2–127 Reserved by the IETF / 128–255 Reserved extensions for IETF-Defined / Table 5-16 Interface identifier management (IIM) messages Value 0 1 2 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Value Chapter 5 SIGTRAN Message type Meaning 2 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. and expect to receive a REG RSP in return with an associated Interface Identifier value. Typically. z Tag The 16-bit Tag field indicates the type of the interface identifier. and expect to receive a DEREG RSP in return reflecting the Interface Identifier and containing a de-registration status. The Length value is 8 if the type of the interface identifier is integer. The Length is equal to the length of the interface identifier plus four bytes (the tag and length fields). including the header. Length. an ASP would send this message to an SGP. III. and Interface Identifier fields. 5–127 Reserved by the IETF / 128–255 Reserved extensions for IETF-Defined / Message Length The Message Length field defines the length of the message in octets.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Value z Chapter 5 SIGTRAN Message type Meaning 3 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. if any. The maximum length does not exceed 255 octets. 5-54 . Table 5-17 Correspondence between tag values and interface identifier types Tag value z 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 variable if the type of the interface identifier is text. Table 5-17 shows the correspondence between the tag values of the M2UA message header and the types of the interface identifier. The Message Length must include parameter padding bytes. Format for M2UA Message Header The M2UA message header includes the Tag. Typically. The Message Length must not be longer than an MTP3 message plus the length of the common and M2UA message headers. 4 Deregistration Response (DEREG RSP) It is used as a response to the DEREG REQ message from a remote M2UA peer. Caution: The integer formatted interface identifier must be supported.The M2UA specific parameters have tags in the range 0x300 to 0x3ff. Parameter Length. Different M2UA messages determine different parameter tags. and parameter values. The format of the interface identifier parameter can be text or integer. the values of which are assigned according to network operator policy. 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 . The values used are coordinated between the SG and the ASP. The common parameters used by the adaptation layers are in the range of 0x00 to 0xff. Format for Variable-Length M2UA Message The common and M2UA message headers are followed by variable-length M2UA messages. IV. and Parameter Value fields.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.Table 5-18 shows the correspondence between values and parameters. parameter lengths. z Parameter Tag The Parameter Tag field is a 16-bit identifier of the type of parameter. An M2UA message includes the Parameter Tag. The text formatted interface identifier may optionally be supported. The receiver must ignore the padding bytes.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Tag value z 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. 5-56 . the sender pads with all zero bytes after the Parameter Value field. A sender must not pad with more than three bytes. The Parameter Length must not be padded with all zero bytes. The Correlation ID parameter is assigned by the sending M2UA.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Parameter Value z The Parameter Value field contains the actual M2UA message contents that are sent or received. 5-57 . the State Request message contains the State parameter. the Data Acknowledge message contains the Correlation ID message. 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. and uniquely identifies the MSU carried in the Protocol Data within an AS. V. MTP2 User Adaptation Messages 1) Data As shown in Figure 5-31. 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 Data message contains the following parameters: Protocol Data (mandatory): The Protocol Data field contains the MTP2-User z application message in network byte order starting with the Signaling Information Octet (SIO). Correlation ID (optional): The Correlation ID parameter permits the new active z ASP to synchronize its processing of the traffic in each ordered stream with other ASPs in the broadcast group. 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 Event message contains the Event parameter.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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. 5-58 . 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. 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. 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 . 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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. the Congestion Indication message contains the Congestion Status and Discard Status parameters. and optional Sequence Number parameter. 5-60 . mandatory Result parameter.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 7) Chapter 5 SIGTRAN Retrieval Request As shown in Figure 5-37.The Sequence Number field contains the forward sequence number (FSN) of the far end if the Action is 0x2. the Sequence Number field is not present if the Action field is 0x01 (ACTION_RTRV_BSN). the Retrieval Request message contains the mandatory Action parameter and optional Sequence Number parameter. 8) Retrieval Confirm As shown in Figure 5-38. Table 5-22 Valid values for Action parameter Value z 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 Retrieval Confirm message contains the mandatory Action 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. If the BSN could not be retrieved. the Retrieval Indication message contains the Protocol Data parameter. 9) Retrieval Indication As shown in Figure 5-39. 5-61 . the SGP will put the BSN in the Sequence Number field and will set Result_Success in the Result field. z Result Table 5-23 shows the valid values for the Result parameter. the Sequence Number field will not be included and Result_Failure will be contained in the Result field.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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. If the Action was ACTION_RTRV_BSN and the SGP successfully retrieved the BSN. it echoes the Action field. Table 5-23 Valid values for Result parameter Value z 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. The SGP should save the ASP Identifier to be used. Length of the INFO String parameter is from 0 to 255 octets. ASP State Maintenance Messages The ASP state maintenance messages only use the common message header. the ASP Up message contains the optional ASP Identifier parameter and optional INFO String parameter. if necessary. an ASP is resident on a host using dynamic address/port number assignment. 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. z INFO string The optional INFO String parameter can carry any meaningful UTF-8 [6] character string along with the message. 1) ASP Up As shown in Figure 5-40.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 15 31 Parameter tag=0x300 Parameter length Protocol data Figure 5-39 Structure of Retrieval Indication message VI. For example. 5-62 . 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. The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. 2) ASP Up Ack As shown in Figure 5-41. with the Notify message. the ASP Up Ack message contains an optional INFO String parameter. No procedures are presently identified for its use but the INFO String might be used for debugging purposes. 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. the ASP Down Ack message contains an optional INFO String parameter. or other implementation specific details. 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.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. It may include a Heartbeat Sequence Number and/or time stamp. the Heartbeat message contains an optional Heartbeat Data parameter. 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. 5-63 . 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. Interface Identifier. the receiver of the Heartbeat message does not process this field. 6) Heartbeat Ack As shown in Figure 5-45.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 Heartbeat Ack message contains an optional Heartbeat Data parameter. ASP Traffic Maintenance Messages ASP traffic maintenance messages use the common and M2UA message headers. the ASP Active message contains the optional Traffic Mode Type. 1) ASP Active As shown in Figure 5-46 and Figure 5-47. The receiver echoes the contents of the Heartbeat Data in a Heartbeat Ack message. and INFO String parameters. according to the text and integer formatted interface identifiers. 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. 5-64 . Additional Interface Identifier. 0 15 Parameter tag=0x09 31 Parameter length Heartbeat data Figure 5-45 Structure of Heartbeat Ack message VII. only one Traffic Mode Type can be used.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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) 0 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. 5-65 . Within a particular AS. Table 5-24 shows the three traffic mode types defined. 2) ASP Active Ack As shown in Figure 5-48 and Figure 5-49. 0x03 Broadcast All of the active ASPs receive all message traffic in the AS. the ASP is noted as Active for all the Interface Identifiers provisioned for that AS. 0x02 Load-share The ASP shares in the traffic distribution with any other currently active ASPs. overriding any currently active ASPs in the AS. while the text formatted Interface Identifier may be supported. the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. 5-66 . the integer formatted Interface Identifier must be supported. z INFO String (optional) The format and description of the INFO String parameter are the same as for the ASP Up message. and INFO String parameters. Interface Identifier. If only a subset of Interface Identifiers for an AS are included.Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. If no Interface Identifiers are included. If integer formatted Interface Identifiers are being used. 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. primary/backup operation). the ASP can also send ranges of Interface Identifiers (Type 0x8). the ASP Active Ack message contains the optional Traffic Mode Type. Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Table 5-24 Traffic mode types Value z Definition Meaning 0x01 Override The ASP takes over all traffic in an AS (that is. Caution: If the optional Interface Identifier parameter is present. Additional Interface Identifier. the ASP Inactive message contains the optional Interface Identifier and INFO String parameters. 3) ASP Inactive As shown in Figure 5-50 and Figure 5-51. 5-67 . The format of the optional Interface Identifiers parameter is the same as for the ASP Active message.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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) 0 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. 5-68 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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) 0 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. 4) ASP Inactive Ack ASP Inactive Ack message contains the optional Interface Identifier and INFO String parameters. The format and description of the optional INFO String parameter are the same as for the ASP Up message. 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. text-based. Invalid Version The "Invalid Interface Identifier" error would be sent by an SGP if an ASP sends a message (that is.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN VIII. 0x04 Unsupported Message Type The "Unsupported Message Type" error would be sent if a message with an unexpected or unsupported Message Type is received. the Error message contains mandatory Error Code.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. or integer range) must be used with this error code to identify the invalid Interface Identifier(s) received. 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. 0x01 The Error message would contain the supported version in the Common header. Layer Management Messages 1) Error As shown in Figure 5-52. The Error message could optionally provide the supported version in the Diagnostic Information area. One of the optional Interface Identifier parameters (integer-based. an ASP Active message) with an invalid (not configured) Interface Identifier value.0x03. 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. optional Interface Identifier. and optional Diagnostic Information parameters. 0 15 31 Tag=0x0C Length=8 Error code Length Tag=0x01. 5-69 . Table 5-25 lists the defined M2UA error codes. 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. Invalid ASP Identifier 5-70 . 0x07 Protocol Error The "Protocol Error" error would be sent for any protocol anomaly (that is. 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. 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. Invalid Stream Identifier The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream (that is. 0x0f The "Invalid ASP Identifier" is sent by an SGP in response to an ASP Up message with an invalid (that is. it will need to resend its message with an integer formatted Interface Identifier. ASP Identifier Required The ASP should resend the ASP Up message with an ASP Identifier. 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. a bogus message). When the ASP receives this error. 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"). An example would be a case in which the ASP sent an ASP Active message with load-sharing traffic handling mode. an MGMT message was received on a stream other than "0"). One of the optional Interface Identifier parameters (integer-based. or integer range) may be used with this error code to identify the Interface Identifier(s). but the SGP did not support load-sharing. text-based. non-unique) ASP Identifier. 0x12 Parameter Field Error The "Parameter Field Error" would be sent if a message with a parameter has a wrong length field. mandatory Status Information. the Diagnostic information includes the supported Version parameter. or integer range) may be used with this error code to identify the Interface Identifier(s). 0x13 Unexpected Parameter The "Unexpected Parameter" error would be sent if a message contains an invalid parameter.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. 0x10 0x14 0x15 0x16 z Diagnostic Information The optional Diagnostic information can be any information germane to the error condition. One of the optional Interface Identifier parameters (integer-based. 2) Notify As shown in Figure 5-53and Figure 5-54. text-based. In the other cases. and optional INFO String parameters. to assist in the identification of the error condition. the Diagnostic information should be the first 40 bytes of the offending message. In the case of an Invalid Version Error Code. 5-71 . a State Request with an undefined State). optional Interface Identifiers. 0x11 Invalid Parameter Value The "Invalid Parameter Value " error is sent if a message is received with an invalid parameter value (for example. optional ASP Identifier. the Notify message contains mandatory Status Type. Not Used in M2UA / Missing Parameter The "Missing Parameter" error would be sent if a mandatory parameter was not included in a message. 5-72 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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) 0 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. 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). based on the value of the Status Type.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 z The Status Information parameter contains more detailed information for the notification. The Interface Identifiers of the AS may be placed in the message if desired. 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. 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 formerly Active ASP is informed when an alternate ASP transitions to the ASP Active state in override mode. ASP failure The ASP Identifier (if available) of the failed ASP must be placed in the message. Alternate ASP active The ASP Identifier (if available) of the Alternate ASP must be placed in the message. The value reflects the new state of the AS. 5-73 . If the Status Type is AS_State_Change. 0x03 The SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. 3. which will first send the request to establish the environment. Data Transfer Procedure When the M2UA layer on ASP has an MAUP message to send to SG. and layer management messages can be transmitted between the peers. the M2UA data. and generate the M2UA message unit z Send the MAUP message to the remote M2UA peer in SG.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.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. Once the environment is ready. MGC maintenance messages. fill in M2UA Message Header. Establishment Procedure of Service Environment Establishment procedure of the M2UA service environment is illustrated in Figure 5-55. II. 5.6 Basic Signaling Procedures I. over the SCTP association 5-74 . it will do the following: z Determine the correct SG z Get the M2UA link number z Find the SCTP association to the chosen SG z Determine the correct stream in the SCTP association based on the SS7 link z Fill in the MAUP message. fill in Common Header. and closes SCTP connection. 5.4 M3UA 5. must have an SS7 point code. z Routing function 5-75 .4.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 begins the release process of M2UA service environment. so as to implement interworking between TDM SS7 and IP. it will do the following: z Get Interface Identifier z Determine the M2UA link number. which supports that MTP link z Get the SCTP association z Determine the correct stream in the SCTP association based on the SS7 link z Fill in the MAUP message. fill in M2UA Message Header. 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. an SG might be charged with representing a set of nodes in the IP domain into the SS7 network for routing purposes. M3UA provides primitive communication service for MTP3 users over IP network and MTP3 (in an SG) at the edge of a network. as a physical node in the SS7 network. fill in Common Header. and generate the M2UA message unit z 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. The SG itself. M3UA supports the following functions: z SS7 signaling point code representation Within an SS7 network.1 Introduction As SS7 MTP3-User adaptation layer. and the SG determines that a signaling point management cluster (SPMC) is now encountering congestion. z IP server process (IPSP) An IPSP is a process instance of an IP-based application. ASPs should initiate the SCTP association to the SGP. Possible SS7 address/routing information that comprises a routing key entry includes. the originating point code (OPC). When an SG receives a congestion message (SCON) from an ASP. 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. An IPSP is essentially the same as an ASP. 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. for example. or MTP3-User specific fields such as the ISUP circuit identification code (CIC). destination point code (DPC). the M3UA adaptation layer is designed to provide an extension of the MTP3 defined user primitives. subject of course to the maximum number of streams supported by the underlying SCTP association. The user port number registered by SCTP is 2905 for M3UA. except that it uses M3UA in a point-to-point fashion instead of using the services of a signaling gateway. MTP3-User traffic can be assigned to individual streams based on. The following introduces some related terms and their definitions. SIO found in the MTP3 routing label. z Client/Server model The SGP and ASP are able to support both client and server operation. M3UA is conveyed over SCTP. for example. it might trigger SS7 MTP3 transfer controlled management messages to concerned SS7 destinations according to congestion procedure of the relevant MTP3 standard. the signaling link selection (SLS) value in the MTP3 routing label. In this case. To accomplish this.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. 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. z Signaling gateway process (SGP) 5-76 . z SS7 and M3UA interworking In the case of SS7 and M3UA interworking. Traffic that requires sequencing must be assigned to the same stream. z Routing key A routing key describes a set of SS7 parameters and parameter values (such as DPC. M3UA Implementations M3UA provides the following service functions: z Support for the transport of MTP3-user messages z Native management functions z Interworking with MTP3 network management functions z Support for the management of SCTP associations between the SGP and ASPs z Support for the management of connections to multiple SGPs 5. SCTP is the lower-layer protocol of M3UA and provides an association to serve M3UA. Table 5-29 lists the SSNM messages. Parameters within the routing key cannot extend across a single destination point code. It serves as an active. SIO + DPC + OPC. and SIO + DPC + OPC + CIC) that uniquely define the range of signaling traffic to be handled by a particular application server. 5-77 . Structure of Protocol Stack Figure 5-57 shows the architecture of the M3UA protocol.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN An SGP is a processing instance of a signaling gateway. M3UA has also unique layer management (LM) to provide management services. I.2 M3UA Messages I. MTP3-User M3UA SCTP LM IP Figure 5-57 Architecture of the M3UA protocol M3UA is the lower-layer protocol of MTP3-User. SIO + DPC. II. It provides a standard MTP3 interface for MTP3-User. 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. backup or load-sharing process of a signaling gateway.4. 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. 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. The MTP3-User at the ASP is expected to stop traffic to the affected destination in the DUNA message. 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. 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. It is recommended for use when the M3UA runs over a transport layer other than the SCTP. Heartbeat (BEAT) The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. 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. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. SSNM.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. 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. 5-78 . 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. 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). 2) ASP management (ASPM) messages Table 5-30 lists the ASPM messages. The BEAT message does not contain any parameter. ASP Up Ack The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer. RKM or ASPTM messages. or to an ASP in response to a DATA or DAUD message as appropriate. The ASP MTP3-User protocol should resume traffic to the affected destination in the DAVA message. 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 z 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 z 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 The network appearance parameter is not used in the M3UA protocol specification temporarily. and the other employs the 14-bit signaling point encoding scheme. coordinated between the SGP and ASP. assisting in the internal distribution of Data messages. In a message. 5-88 . z Routing Context The routing context is a 32-bit value. Therefore. the Routing Context must be sent to identify the traffic flow. but their signaling point formats are different. it represents the routing key. The Routing Context parameter contains the Routing Context value associated with the DATA message. In such a case. the network appearance parameter in the message is required. Where the Network Appearance parameter is present. One area employs the 24-bit signaling point encoding scheme. Where multiple Routing Keys and Routing Contexts are used across a common association. Where a Routing Key has not been coordinated between the SGP and ASP.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Figure 5-60 shows the parameter format of the DATA message. The Network Appearance parameter value is of local significance only. sending of Routing Context is not required. two areas belong to the same NI (national network). the SS7 network indicator value. 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 the case where an ASP is connected to more than one SGP. the Network Appearance implicitly defines the SS7 point code format used. and the MTP3/MTP3-User protocol type/variant/version. the same SS7 network context may be identified by different Network Appearance values depending on which SGP a message is being transmitted or received. For example. it must be the first parameter in the message as it defines the format of the protocol data field. In a DATA message. 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”. 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. Figure 5-61 shows the format of the protocol data parameter. Destination Point Code (DPC). The Protocol Data Parameter contains the Service Indicator (SI). ISUP. Unused bits are coded “0”. Network Indicator (NI).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Protocol Data z The Protocol Data parameter contains the original SS7 MTP3 message. User Protocol Data includes MTP-User protocol elements (for example. and Signaling Link Selection Code (SLS) fields. 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. or TUP parameters). justified to the least significant bit. Originating Point Code (OPC). 0 1 2 3 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 Signaling Link Selection 5-89 . including the service information octet and routing label. z Destination Point Code The Destination Point Code field contains a 32-bit value. SCCP. and optional INFO String parameters. Figure 5-62 shows the structure of the DUNA message. 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. 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. If there is no alternate route through another SG. mandatory Affected Point Code. 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. z Correlation ID The Correlation ID parameter uniquely identifies the MSU carried in the Protocol Data within an AS. V. Unused bits are coded “0”. 5-90 .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. 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. optional Routing Context. The DUNA message contains the optional Network Appearance. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. This Correlation ID parameter is assigned by the sending M3UA. 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-. Affected Point Codes that are less than 24 bits are padded on the left to the 24-bit boundary. z Routing Context The optional Routing Context parameter contains the Routing Context values associated with the DUNA message. 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. 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. sending of Routing Context is not required. Where a Routing Key has not been coordinated between the SGP and ASP.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 . 16.. z INFO String 5-91 . assisting in outgoing traffic management and internal distribution of MTP-PAUSE indications to MTP3-Users at the receiver..and 24-bit binary formatted SS7 Point Codes. z Affected Point Code The format and description of the Affected Point Code are the same as for the DUNA message. 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). z Network Appearance The format and description of the Network Appearance are the same as for the DUNA message. optional Routing Context. z Network Appearance The format and description of the Network Appearance are the same as for the DUNA message. and optional INFO String parameters. z Routing Context The format and description of the Routing Context are the same as for the DUNA message. optional Routing Context. z Routing Context The format and description of the Routing Context are the same as for the DUNA message.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. The ASP M3UA layer now routes the MTP3-user traffic through the SG initiating the DAVA 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. and optional INFO String parameters. z INFO String The format and description of the INFO String are the same as for the DUNA message. or in response to a DAUD message if appropriate. The DAVA message contains the optional Network Appearance. Length of the INFO String parameter is from 0 to 255 octets. The DAUD message contains the optional Network Appearance. mandatory Affected Point Code. mandatory Affected Point Code. z Affected Point Code 5-92 . No procedures are presently identified for its use but the INFO String may be used for debugging purposes. 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. optional Routing Context. optional Congestion Indications. 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.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. optional Concerned Destination. and optional INFO String parameters. Figure 5-63 shows the structure of the SCON message. or to an ASP in response to a DATA or DAUD message as appropriate. ANSI MTP) the SCON message may be sent when the SS7 congestion level changes. mandatory Affected Point Code. 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. 5-93 . For some MTP protocol variants (for example. The SCON message contains the optional Network Appearance. z INFO String The format and description of the INFO String are the same as for the DUNA message. . 5-94 . z Routing Context The format and description of the Routing Context are the same as for the DUNA message. 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. Mask Affected PC n Tag = 0x0206 Length = 8 Reserved Concerned DPC Tag = 0x0205 Length = 8 Reserved Cong. z Affected Point Code The format and description of the Affected Point Code are the same as for the DUNA message..Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 . z INFO String The format and description of the INFO String are the same as for the DUNA message. 5-95 . optional Routing Context. Concerned Destination z The optional 32-bit Concerned Destination parameter is only used if the SCON message is sent from an ASP to the SGP. A Concerned Point Code that is less than 24 bits is padded on the left to the 24-bit boundary.8]. Table 5-44 Congestion level values Value Meaning 0 No congestion or undefined 1 Congestion level 1 2 Congestion level 2 3 Congestion level 3 The congestion levels are defined in the congestion method in the appropriate national MTP recommendations [7. The Concerned Destination parameter contains one Concerned Destination Point Code field. Congestion Indications z The optional 32-bit Congestion Indications parameter contains a Congestion Level field. ISUP or SCCP) at an SS7 node is unavailable. 16. associated with all of the Affected DPC(s) in the Affected Destinations parameter. 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. such as in ANSI MTP3.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. mandatory User/Cause. a three-octet parameter to allow for 14-. Congestion Level z The 8-bit Congestion Level field. and optional INFO String parameters. For MTP congestion methods without multiple congestion levels (for example. contains one of the values as shown in Table 5-44. The DUPU message contains the optional Network Appearance. It contains the point code of the originator of the message that triggered the SCON message.and 24-bit binary formatted SS7 Point Codes. This optional parameter is used to communicate congestion levels in national MTP networks with multiple congestion thresholds. the ITU international method) the parameter is not included. mandatory Affected Point Code. 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. z User/Cause 5-96 . z Routing Context The format and description of the Routing Context are the same as for the DUNA message. 0 1 2 3 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Figure 5-64 shows the structure of the 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. Ranges and lists of Affected DPCs cannot be signaled in a DUPU message. Depending on the MTP3 protocol used in the Network Appearance. are encoded as follows.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN The Unavailability Cause and MTP3-User Identity fields. Table 5-46 MTP3-User identity values Value Meaning 0 to 2 Reserved 3 SCCP 4 TUP 5 ISUP 6 to 8 Reserved 9 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 . associated with the Affected PC in the Affected Point Code parameter. ISUP and SCCP). Table 5-45 Unavailability cause values Value Meaning 0 Unknown 1 Unequipped remote user 2 Inaccessible remote user The values agree with those provided in the SS7 MTP3 User Part Unavailable message. additional values may be used—the specification of the relevant MTP3 protocol variant/version recommendation is definitive. Some of the valid values for the MTP3-User Identity are shown in Table 5-46. Unavailability Cause field z The 16-bit Unavailability Cause parameter provides the reason for the unavailability of the MTP3-User. MTP3-User Identity field z The 16-bit MTP3-User Identity describes the specific MTP3-User that is unavailable (for example. The valid values for the Unavailability Cause parameter are shown in Table 5-45. The DRST message contains the optional Network Appearance. z Affected Point Code The format and description of the Affected Point Code are the same as for the DUNA message. In this case. 5-98 . The ASP Up message contains the optional ASP Identifier and optional INFO String parameters. The relevant MTP3 protocol variant/version recommendation is definitive.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. VI. the M3UA layer should route the traffic through the SG initiating the DRST message. additional values may be used. 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. z Network Appearance The format and description of the Network Appearance are the same as for the DUNA message. mandatory Affected Point Code. 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. optional Routing Context. z INFO String The format and description of the INFO String are the same as for the DUNA message. The MTP3-User should be informed that traffic to the affected destination can be resumed. z INFO String The format and description of the INFO String are the same as for the DUNA message. If the affected destination is currently considered unavailable by the ASP. or in response to a DAUD message if appropriate. and optional INFO String parameters. Depending on the MTP3 protocol variant/version used in the network appearance. z Routing Context The format and description of the Routing Context are the same as for the DUNA message. 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. but only if such an alternate route exists and is available. 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. 0 1 2 3 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 . The SGP should save the ASP Identifier to be used. INFO String z The format and description of the optional INFO String parameter are the same as for the DUNA message. 0 1 2 3 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 z The 32-bit ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Figure 5-65 shows the structure of the ASP Up message. The ASP Up Ack message contains the optional INFO String parameter. with the Notify message. Figure 5-66 shows the structure of the ASP Up Ack message. if necessary. SSNM. RKM or ASPTM messages. Figure 5-67 shows the structure of the ASP Down message. The INFO String in an ASP Up Ack message is independent from the INFO String in the ASP Up message (that is. 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. 0 1 2 3 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 z The format and description of the optional INFO String parameter are the same as for the DUNA message.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. Figure 5-68 shows the structure of the ASP Down Ack 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. it does not have to echo back the INFO String received). 0 1 2 3 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 . The ASP Down message contains the optional INFO String parameter. a Heartbeat Sequence Number and/or Timestamp. 6) Heartbeat Acknowledgement (BEAT Ack) The BEAT Ack message is sent in response to a received BEAT 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). VII. and expects to receive a REG RSP message in return with an associated Routing Context value. 0 1 2 3 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN INFO String z The format and description of the optional INFO String parameter are the same as for the DUNA message. The Heartbeat Data could include. It is recommended for use when the M3UA runs over a transport layer other than the SCTP. an ASP would send this message to an SGP. 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. Typically. 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. The BEAT message contains the optional Heartbeat Data parameter. 5) Heartbeat (BEAT) The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. 5-101 . without any change. for example. It includes all the parameters of the received BEAT message. Figure 5-69 shows the structure of the BEAT message. which has its own heartbeat. 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. 0 1 2 3 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. 5-102 .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-71 shows the format of the Routing Key parameter. This is used to allow the registration of multiple Routing Keys in a single message. if the Routing Key entry does not already exist. The Routing Key parameter may be present multiple times in the same message. Figure 5-70 shows the structure of the REG REQ message. and Circuit Range List parameters may be repeated as a grouping within the Routing Key parameter. Local-RK-Identifier z The 32-bit Local-RK-Identifier field is used to uniquely identify the registration request. The Identifier value is assigned by the ASP. in the structure shown above. Service Indicators. 0 1 2 3 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 0 Chapter 5 SIGTRAN 1 2 3 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. Figure 5-72 shows the format of the Local-RK-Identifier field. The Identifier value must remain unique until the REG RSP message is received. and is used to correlate the response in an REG RSP message with the original registration request. Originating Point Code List. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Traffic Mode Type z The 32-bit Traffic Mode Type parameter identifies the traffic mode of operation of the ASP(s) within an AS. and has the same format as in the DATA message. and identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. 0 1 2 3 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 1 Override 2 Loadshare 3 Broadcast Destination Point Code z The Destination Point Code parameter is mandatory. Figure 5-74 shows the format of the Destination Point Code. The absence of 5-104 . Figure 5-73 shows the format of the Traffic Mode Type Identifier. The format is the same as described for the Affected Destination parameter in the DUNA message. 0 1 2 3 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. 0 1 2 3 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. Figure 5-76 shows the format of the Service Indicators parameter. excluding of course MTP management. 0 1 2 3 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 z 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. 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.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. 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. The absence of the SI parameter in the Routing Key indicates the use of any SI value. Where an SI parameter does not contain a multiple of four SIs. Figure 5-75 shows the format of the Network Appearance. 5-105 . Figure 5-77 shows the format of the Originating Point Code List. the parameter is padded out to 32-byte alignment. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 z An ISUP controlled circuit is uniquely identified by the SS7 OPC. Figure 5-78 shows the format of the Circuit Range. The DPC is implicit as it is mandatory and already included in the DPC parameter of the Routing Key. while the CIC values are 16-bit integers. in the case of ISUP/TUP traffic. DPC. The absence of the Circuit Range parameter in the Routing Key indicates the use of any Circuit Range values. 0 1 2 3 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 . and CIC value. For the purposes of identifying Circuit Ranges in an M3UA Routing Key. each identified by an OPC and Upper/Lower CIC value. The Origination Point Code is encoded the same as the Destination Point Code parameter. the optional Circuit Range parameter includes one or more circuit ranges. a specific result should be in only one REG RSP message. 5-107 . 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. The REG RSP message contains one or more mandatory Registration Result parameters.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. Figure 5-80 shows the format of each Registration Result. to be used in subsequent M3UA Traffic Management protocol. Where multiple REG RSP messages are used in reply to REG REQ message. 0 1 2 3 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. Figure 5-79 shows the structure of the REG RSP message. Table 5-48 lists the values for the Registration Status.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 z The 32-bit Local-RK-Identifier contains the same value as found in the matching Routing Key parameter found in the REG REQ message.Routing Key not Currently Provisioned 8 Error .Permission Denied 6 Error .Insufficient Resources 9 Error .Unsupported/Invalid Traffic Handling Mode 5-108 .Invalid DPC 3 Error .Invalid Network Appearance 4 Error . Registration Status z The 32-bit Registration Result Status field indicates the success or the reason for failure of a registration request.Unknown 2 Error .Unsupported RK parameter Field 10 Error .Invalid Routing Key 5 Error . Table 5-48 Values for Registration Status Value Meaning 0 Successfully Registered 1 Error .Cannot Support Unique Routing 7 Error . 5-109 . It is set to "0" if the registration was not successful. 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. 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. 4) Deregistration Response (DEREG RSP) The DEREG RSP message is used as a response to the DEREG REQ message from a remote M3UA peer. Figure 5-81 shows the structure of the DEREG REQ message. 0 1 2 3 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Routing Context z The 32-bit Routing Context field contains the Routing Context value for the associated Routing Key if the registration was successful. an ASP would send this message to an SGP. Typically. The DEREG RSP message contains one or more mandatory Deregistration Result parameters. Figure 5-82 shows the structure of the DEREG RSP message. Where multiple DEREG RSP messages are used in reply to DEREG REQ message. as found in the DEREG REQ message. a specific result should be in only one DEREG RSP message. 0 1 2 3 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 z The Deregistration Result parameter contains the deregistration status for a single Routing Context in a DEREG REQ message. z Deregistration Status 5-110 . 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. Figure 5-83 shows the format of each Deregistration Result parameter. if present.Permission Denied 4 Error .Unknown 2 Error . Table 5-49 Values for Deregistration Status Value Meaning 0 Successfully Deregistered 1 Error . and optional INFO String parameters. The ASP Active message affects only the ASP state for the Routing Keys identified by the Routing Contexts. Figure 5-84 shows the structure of the ASP Active message. Table 5-49 lists the values for the Deregistration Status.Invalid Routing Context 3 Error .Not Registered 5 Error . 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.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. The ASP Active message contains the optional Traffic Mode Type. optional Routing Context.ASP Currently Active for Routing Context VIII. 0 1 2 3 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 . optional Routing Context. 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Traffic Mode Type z The 32-bit Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. overriding any currently active ASPs in the AS. The ASP Active Ack message contains the optional Traffic Mode Type. 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. For example. Table 5-50 Valid values for Traffic Mode Type Value Traffic mode type 1 Override 2 Loadshare 3 Broadcast Within a particular Routing Context. In Loadshare mode. The Override value indicates that the ASP is operating in Override mode. the Network Appearance parameter is not required in the ASP Active message. and optional INFO String parameters. identified by separate SS7 DPC/OPC/CIC ranges. primary/backup operation). a Routing Context defines a range of signaling traffic that the ASP is currently configured to receive from the SGP. z INFO String The format and description of the optional INFO String parameter are the same as for the DUNA message. and the ASP takes over all traffic in an AS (that is. Loadshare and Broadcast should not be mixed. Override. 5-112 . an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signaling traffic. An ASP may be configured to process traffic for more than one logical AS. Because an AS can only appear in one Network Appearance. There is one-to-one relationship between an index entry and an SGP Routing Key or AS Name. Table 5-50 lists he valid values for Traffic Mode Type. In Broadcast mode. From the perspective of an ASP. the ASP will share in the traffic distribution with any other currently active ASPs. the ASP will receive the same messages as any other currently active ASP. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Figure 5-85 shows the structure of the ASP Active Ack message. The INFO String in an ASP Active Ack message is independent from the INFO String in the ASP Active message (that is. 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 contains the optional Routing Context and optional INFO String parameters. z INFO String The format and description of the optional INFO String parameter are the same as for the DUNA message. if present. z Routing Context The format of the Routing Context is the same as for the ASP Active message. 5-113 . The ASP Inactive message affects only the ASP state in the Routing Keys identified by the Routing Contexts. it does not have to echo back the INFO String received). 0 1 2 3 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. Figure 5-86 shows the structure of the ASP Inactive 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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 z The format and description of the optional Routing Context are the same as for the ASP Active message. INFO String z The format and description of the optional INFO String are the same as for the ASP Active message. Figure 5-87 shows the structure of the ASP Inactive Ack message. 0 1 2 3 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 . The ASP Inactive Ack message contains the optional Routing Context and optional INFO String parameters. Management Messages 1) Error The Error message is used to notify a peer of an error event associated with an incoming message. The Error message contains the mandatory Error Code. For example. IX. and Affected Point Code parameters are only mandatory for specific Error Codes. Figure 5-88 shows the structure of the Error message. Notes: The Routing Context. or a parameter value might be invalid. mandatory Routing Context. mandatory Network Appearance.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. and optional Diagnostic Information parameters. 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). Network Appearance. 5-115 . the message type might be unexpected in the current state. z INFO String The format and description of the optional INFO String parameter are the same as for the DUNA message. mandatory Affected Point Code. optional Routing Context. shows the Error parameter values. and optional INFO String parameters. 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. 5-116 . to assist in identification of the error condition. the variable-length Diagnostic Information can be any information germane to the error condition. z Values for Error parameter Diagnostic Information When included.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 0 Chapter 5 SIGTRAN 1 2 3 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. optional ASP Identifier. the Status Information values are shown in Table 5-52. 5-117 . Table 5-51 lists the valid values for the Status Type.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Figure 5-89 shows the structure of the Notify message. If the Status Type is AS-State_Change. 0 1 2 3 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 z The 16-bit Status Type parameter identifies the type of the Notify message. Table 5-51 Valid values for Status Type Value z Meaning 1 Application Server State Change (AS-State_Change) 2 Other Status Information The 16-bit Status Information parameter contains more detailed information for the notification. based on the value of the Status Type. ASP Failure For the ASP Failure case. The ASP Identifier (if available) of the Alternate ASP must be placed in the message. Table 5-53 Values for Status Information if Status Type is Other Value 1 2 3 Definition Meaning Insufficient ASP Resources Active in AS In the Insufficient ASP Resources case. the Status Information values are defined in Table 5-53. The ASP Identifier (if available) of the failed ASP must be placed in the message. the SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. 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). 5-118 . Alternate ASP Active For the Alternate ASP Active case.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 1 Reserved 2 Application Server Inactive (AS-INACTIVE) 3 Application Server Active (AS-ACTIVE) 4 Application Server Pending (AS-PENDING) These notifications are sent from an SGP to an ASP upon a change in status of a particular AS. These notifications are not based on the SGP reporting the state change of an ASP or AS. 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. z ASP Identifier The format and description of the optional ASP Identifier are the same as for the ASP Up message. The value reflects the new state of the AS. If the Status Type is Other. an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Override mode. dynamic registration This scenario is the same as the former one but with the optional exchange of registration information. In such conditions. I. It is assumed that the SCTP association is already set up.3 Basic Signaling Procedures The following examples show M3UA message flows for the establishment of traffic between an SGP and an ASP.4. the sending of M3UA messages is shown in Figure 5-90. z Single ASP in an application server (“1+0” sparing). no registration In such conditions. SGP ASP1 ASP Up ASP Up Ack REG REQ (LRCn. the sending of M3UA messages is shown in Figure 5-91. In this case the registration is accepted by the SGP. where only one ASP is configured within an AS (no backup). 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).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 5.RKn) ASP active (RCn) ASP active Ack (RCn) Figure 5-91 Procedure to set up an M3UA message (example 2) 5-119 . 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.RKn) LRC: Local Routing Context RK: Routing Key RC: Routing Context REGRSP (LRCn. the sending of M3UA messages is shown in Figure 5-92.RC1 ) LRC: Local Routing Context RK: Routing Key RC: Routing Context ASP active (RC1) ASP active Ack (RC1) REG REQ (LRCn. SGP to ASP1) would not occur. 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). dynamic registration In such conditions.RK1 ) REG RSP(LRC1. withdrawal of ASP. back-up over-ride Referring to Figure 5-93. ASP1 withdraws from service as shown in Figure 5-93.RKn) REG RSP (LRCn. SGP ASP1 ASP Up ASP Up Ack REG REQ( LRC1. ASP traffic fail-over examples 1) 1+1 sparing.RCn) ASP active (RCn) ASP active Ack (RCn) Figure 5-92 Procedure to set up an M3UA message (example 3) II. 5-120 . the initial ASP inactive message exchange (that is.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 5 SIGTRAN Single ASP in multiple application servers (each with “1+0” sparing). 1 Introduction This section describes the need for ISDN Q.5.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 2) Chapter 5 SIGTRAN 1+1 sparing. Defined by RFC 3057. SGP ASP inactive (RCn) ASP1 ASP inactive Ack (RCn) RC: Routing Context DEREG REQ (RCn) DEREG RSP (LRCn. 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. SG ASP1 ASP2 ASP active ASP active Ack NTFY (alternate ASP-active) Figure 5-94 ASP traffic fail-over (example 2) III. IUA defines a 5-121 . back-up over-ride Following on from the example in Figure 5-94.921-User Adaptation (IUA) layer protocol as well as how this protocol shall be implemented. See Figure 5-94.5 IUA 5. if it is to be removed from service. the ASP has received an ASP inactive Ack message) may now proceed to the ASP-DOWN state.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. and ASP2 wishes to over-ride ASP1 and take over the traffic. See Figure 5-95. IV. II. DSS1 IUA SG ISDN EP Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP).921 PSTN MGC IP (NIF) Q.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.921 Q. III. Layer Management Layer management is a nodal function that handles the inputs and outputs between the IUA layer and a local management entity. Interface An interface supports the relevant ISDN signaling channel.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN protocol for backhauling of ISDN Q.931 and call processing for D channels terminated by the Signaling Gateways. An example of an Application Server is a MGC handling the Q.931 IUA IUA SCTP SCTP IP IP Figure 5-96 Location of IUA in the system 5.2 Terminology I.931 Q.5. Figure 5-96 shows the details. Application Server Process (ASP) A process instance of an Application Server. 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. Examples of Application Server Processes are primary or backup MGC instances. Application Server (AS) An AS is a logical entity serving a specific application instance. 5-122 . III. This procedure can be achieved using the M-SCTP ESTABLISH primitive.931 boundary primitives are standard.931 Boundary Primitives In DSS1. In addition.931.4 Functions Implemented by the IUA Layer I.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 5.A physical interface would be a E1 interface or a timeslot on the interface. however.921/Q. It MUST be noted. 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. DL-RELEASE. 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 z M-SCTP RELEASE z M-SCTP STATUS z M-ASP STATUS z M-ASP-UP z M-ASP-DOWN z M-ASP-ACTIVE z M-ASP-INACTIVE z M-AS STATUS 5. IUA layer needs to support all of the primitives of this boundary to successfully backhaul Q. Mapping The IUA layer MUST maintain a map of the interface identifier to a physical interface on the SG. that this mapping is dynamic and could change at any time due to a change of 5-123 . and DL-UNIT DATA.921/Q.5.3 Services Provided by the IUA Layer I. IUA layers on both SG and MGC MAY maintain the status of TEIs and SAPIs. 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. all Q.The primitives are DL-ESTABLISH. The primitives are M-TEI STATUS and M-ERROR. 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. II. Support for Transport of Q.5. for a given interface the SG MUST be able to identify the associated signaling channel. DL-DATA. 5. 5. if it deems appropriate. Also the IUA layer MAY need to inform the local management of the change in status of an ASP or AS. Status of ASPs The IUA layer on the SG MUST maintain the state of the ASPs it is supporting. IV. if an SCTP association fails. Because of the unidirectional nature of streams. Therefore. the interface identifier is in the IUA message header. Likewise. It is the responsibility of the IUA layer to ensure proper management of these streams. V.931) to the local layer management. The layer management could instruct Q. both a primary and a back-up ASP are available. This can be achieved using the M-ASP STATUS or M-AS STATUS primitives. the SG MUST maintain the states of AS/ASP and reference them during the routing of a message to an AS/ASP.921 to take some action. the IUA layer on both the SG and ASP sides MAY generate Release primitives to take the data links out-of-service. an IUA layer is not aware of the stream number to interface identifier mapping of its peer IUA layer. IUA peer protocol is required to control which ASP is currently active. The use of SCTP streams within IUA is recommended in order to minimize transmission and buffering delay. 5-124 . Seamless Network Management Interworking The IUA layer on the SG SHOULD pass an indication of unavailability of the IUA-User (Q. if the currently active ASP moves from the ACTIVE state. therefore improving the overall performance and reliability of the signaling elements. it MAY stop reading from the SCTP association to flow control from the peer IUA. II. The ordered list of ASPs within a logical application server is kept updated in the SG to reflect the active application server process(es). Congestion Management If the IUA layer becomes congested (implementation dependent). 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. III. an application server list MAY contain active and inactive ASPs to support ASP load-sharing and fail-over procedures.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN ASP state. SCTP Stream Management SCTP allows a user specified number of streams to be opened during the initialization. for example. It is recommended that a separate SCTP stream is used for each D channel.5 Structure of IUA Protocol Stack Figure 5-97 shows the IUA protocol stack. When. Instead. 921 Boundary Four primitives are defined for communication between IUA and Q.2. Definition of IUA/Q0.931 Boundary Four primitives are also defined between IUA and Q. Definition of IUA/SCTP Boundary For the primitives defined between IUA and SCTP. 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.6 Definition of IUA Boundaries I.931: z DL-ESTABLISH z DL-RELEASE z DL-DATA z DL-UNIT DATA III.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Q.6 Basic Signaling Procedures. Definition of IUA/Layer-Management Boundary Table 5-54 lists the primitives defined between IUA and the layer management of IUA endpoint. .931 IUA LM SCTP IP Figure 5-97 Structure of IUA protocol stack 5. IV. Definition of IUA/Q.921: z DL-ESTABLISH z DL-RELEASE z DL-DATA z DL-UNIT DATA II. refer to 5.5. M-ASP_DOWN confirm IUA -> LM ASP reports that it has received an ASP DOWN Acknowledgement message from the SG. M-AS_STATUS indication IUA -> LM SG reports status of remote AS. M-ASP_UP confirm IUA -> LM ASP reports that it has received an ASP UP Acknowledgement message from the 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 RELEASE indication IUA -> LM SG informs LM that ASP has released an SCTP association. M-ASP STATUS confirm IUA -> LM SG reports status of remote ASP. M-ASP_ACTIVE confirm IUA -> LM ASP reports that it has received an ASP ACTIVE Acknowledgement message from the SG. M-ASP_UP request LM -> IUA LM requests ASP to start its operation and send an ASP UP message to 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_INACTIVE request LM -> IUA LM requests ASP to send an ASP INACTIVE message to the SG. M-ASP STATUS request LM -> IUA LM requests SG to report status of remote ASP. M-ASP_ACTIVE request LM -> IUA LM requests ASP to send an ASP ACTIVE message to the SG. 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-SCTP RELEASE request LM -> IUA LM requests ASP to release an SCTP association with SG. M-SCTP ESTABLISH indication IUA -> LM SG informs LM that an ASP has established an SCTP association. M-SCTP RELEASE confirm IUA -> LM ASP confirms to LM that it has released SCTP association with SG. M-AS STATUS request LM -> IUA LM requests SG to report status of AS. M-ERROR indication IUA -> LM ASP or SG reports that it has received an ERROR message from its peer. M-SCTP_RESTART indication IUA -> LM IUA informs LM that an instruction to restart SCTP has been received. M-NOTIFY indication IUA -> LM ASP reports that it has received a NOTIFY message from its peer. 5-126 . 5.8 IUA Protocol Messages I.5. 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.7 Implementation of IUA Figure 5-98 shows a typical implementation of IUA in an NGN solution. The SoftX3000 processes the Q. 5. the IUA message structure is composed of a common message header.931 call control messages.931 messages in BRA and PRA to the SoftX3000 through IUA. and several variable-length IUA messages.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-127 . The UMG8900 transparently transmits the Q. Message structure As shown in Figure 5-99. an IUA message header. 5. The currently supported version number is 0000 0001. Message Class. Message Class z 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.0.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 . Message Type. Version z The version field contains the version of the IUA adaptation layer. Spare z The length of the spare field is eight bits. and Message Length fields. This field SHOULD be set to all '0's and ignored by the receiver.921/Q. which means version 1.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. Spare. The message header part applies to all signaling protocol adaptation layer messages. Common Message Header The common message header contains the Version. 03 Unit Data Request A Unit Data Request message contains an ISDN Q. 08 Release Request MGC sends a Release Request to release a data link on a signaling channel.921 user protocol data unit (PDU). 0B-7F Reserved by the IETF - 5-129 . 07 Establish Indication SG sends an Establish Indication message to indicate that a data link has been established in a signaling channel.921/Q. Table 5-57 and Table 5-58 are defined according to different message classes.921 user PDU.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 z The message types as listed in Table 5-55. it sends an Establish 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.931 boundary primitives transport (QPTM) messages Value Message type Meaning 00 Reserved - 01 Data Request A Data Request contains an ISDN Q. A PDU corresponds to a confirmed information transmission service. Table 5-56. Table 5-56 Q. 06 Establish Confirm SG sends an Establish Confirm message to confirm an Establish Request message. 04 Unit Data Indication A Unit Data Indication message indicates that the peer IUA has successfully processed a received Unit Data Request message. When MGC expects channel D to be in the service operation state. MGC controls the status of channel D. 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. A PDU corresponds to a unconfirmed information transmission service. 02 Data Indication A Data Indication message indicates that the peer IUA has successfully processed a received Data Request message. The Heartbeat Ack message includes all the parameters of the received Heartbeat message.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. 5-130 . 06 Heartbeat Ack (BEAT ACK) It is sent in response to a Heartbeat message. without any change. An IUA peer must send a Heartbeat Ack message in response to a Heartbeat message. 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. 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. 03 Heartbeat (BEAT) It is optionally used to ensure that the IUA peers are still available to each other. 03 ASP Active Ack (ACTIVE ACK) It is used to respond to an ASP Active message received from a remote IUA. 02 ASP Inactive (INACTIVE) It is sent by an ASP to indicate to an SG that it is no longer an active ASP. 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. the message type might be unexpected given the current state. as defined by the message type. III. Variable-Length Parameter Format IUA messages consist of a common header followed by zero or more variable-length parameters. 04 TEI Status Indication It is interchanged between peers of IUA layer to indicate the status of a specific TEI. For example. 01 Notify (NTFY) It is used to provide the automatic indication of an IUA event to the IUA peer. 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. [Parameter Length]. A variable-length parameter consists of the [Parameter Tag]. 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.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. and [Parameter Value] fields. 02 TEI Status Request It is interchanged between peers of IUA layer to request the status of a specific TEI. including the header. z Parameter Tag The [Parameter Tag] field is a 16-bit identifier of the type of parameter. or a parameter value might be invalid. 03 TEI Status Confirm It is interchanged between peers of IUA layer to confirm the status of a specific TEI. 5-131 . The variable-length parameters contained in a message are defined in a tag-length-value format. this message header consists of the tag.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Parameter Length z The [Parameter Length] field must be a multiple of four bytes. IV. Table 5-60 Correspondence between tag values and interface identifier types Tag value Interface identifier type 0x0001 Integer 0x0003 Text 5-132 . length. The [Parameter Length] must not be padded with all zero bytes. and data link connection identifier (DLCI). A sender must not pad with more than three bytes. the sender pads with all zero bytes after the Parameter Value field. The receiver must ignore the padding bytes. Format of IUA Message Header In addition to the common message header. It contains the actual information to be transferred in the parameter. The IUA message header will immediately follow the common header in these messages. there will be a specific message header for QPTM and the TEI Status MGMT messages. As shown in Figure 5-100. If it is not a multiple of four bytes. 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. interface identifier. Parameter Value z The [Parameter Value] has a variable length. Table 5-60 shows the correspondence between the tag values of the IUA message header and the types of the interface identifier. The interface identifiers are assigned according to network operator policy. The [Length] value is variable if the type of the interface identifier is text. The text formatted Interface Identifier MAY optionally be supported. Q.921/Q. The protocol data contains the upper layer Q. The interface identifier of the character string type is not supported at present.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Note: The integer formatted interface identifier MUST be supported. z Length The [Parameter Length] values of the IUA message header vary with different types of interface identifiers. z Interface Identifier The interface identifier identifies the physical interface at the SG for which the signaling messages are sent/received. the Data message contains a mandatory protocol data. The [Length] value is 8 if the type of the interface identifier is integer. As shown in Figure 5-102 the Unit Data Request message contains a mandatory protocol data.931 message. The format of the [Interface Identifier] parameter can be text or integer. The protocol data contains the upper layer Q. 5-133 . As shown in Figure 5-101. V. coordinated between the SG and ASP. The length is equal to the length of the interface identifier plus four bytes (the tag and length fields). The maximum length does not exceed 255 octets. The integer values used are of local significance only.931 Boundary Primitives Transport (QPTM) Messages 1) Data Request message The Data Request message contains the common message header followed by IUA message header. 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.931 message. Table 5-61 Valid values for the [Reason] parameter Value Define Description 0x00 RELEASE_MGMT Management layer generated release.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 15 Parameter tag=0x00e 31 Parameter length Protocol data(32) Figure 5-102 Structure of Data Acknowledge message 3) Establish messages (Request. Indication) The Establish messages contain the common message header followed by IUA message header. if SABME is received. 0x01 RELEASE_PHYS Physical layer alarm generated release. 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. Indicates Layer 2 SHOULD release and deny all requests from far end to establish a data link on the signaling channel (that is. Indication. Confirmation) The Release messages contain the common message header followed by IUA message header. 0x02 RELEASE_DM Specific to a request. Confirm. The Release Confirm message does not contain any additional parameters. 4) Release messages (Request. It does not contain any additional parameters. 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 . the ASP Up message contains an optional [INFO String] parameter. the ASP Up Ack message contains an optional [INFO String] parameter. 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 state maintenance messages only use the common message header. 2) ASP Up Ack As shown in Figure 5-105. 1) ASP Up As shown in Figure 5-104. Length of the [INFO String] parameter is from 0 to 255 characters. 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. the ASP Down message contains the mandatory [Reason] parameter and the optional [INFO string] parameter. No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes.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 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=0x0a Parameter length Reason Parameter tag=0x4 Parameter length INFO string Figure 5-106 Structure of ASP Down message 5-135 . The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The value of this parameter is fixed set to “0x01”. The format and description of the [Heartbeat Data] parameter in the Heartbeat Ack message are the same as for the Heartbeat message. The Heartbeat Data could include. 5) Heartbeat As shown in Figure 5-107. according to the text and integer formatted interface identifiers. the Heartbeat message contains an optional [Heartbeat Data] parameter. VII. indicating that ASP is under management inhibition.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 ASP Active message contains the mandatory [Traffic Mode Type]. a Heartbeat Sequence Number and. z INFO string The format and description of the [INFO String] parameter are the same as for the ASP Up message. 6) Heartbeat Ack The Heartbeat Ack message contains an optional [Heartbeat Data] parameter. optional [Interface Identifier]. The receiver MUST respond with a Heartbeat Ack message. 4) ASP Down Ack The ASP Down Ack message contains the mandatory [Reason] parameter and the optional [INFO String] parameter. or Timestamp. IUA application server process traffic maintenance (ASPTM) messages ASP traffic maintenance messages use the common and IUA message headers. If an ASP is removed from Management Inhibit. The format and description of the [Reason] and [INFO String] parameters are the same as for the ASP Down message. 1) ASP Active (ASPAC) As shown in Figure 5-108 and Figure 5-109. and optional [INFO String] parameters. for example. 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 ASP will send an ASP Up message. 5-136 . 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 0 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) 0 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 integer formatted Interface Identifier must be supported. the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned.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. the ASP is noted as Active for all the Interface Identifiers provisioned for that AS. overriding any currently active ASPs in the AS. and optional [INFO String] parameters. 5-138 . The format and description of the optional [INFO String] parameter are the same as for the ASP Up message. 0x02 Load-share The ASP will share in the traffic distribution with any other currently active ASPs. the ASP can also send ranges of Interface Identifiers (Type 0x8). Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types. 2) ASP Active Ack (ASPAC ACK) The ASP Active Ack message contains the mandatory [Traffic Mode Type]. while the text formatted Interface Identifier may be supported. The format and description of the [Traffic Mode Type] and [Interface Identifier] parameters are the same as for the ASP Active (ASPAC) message. Caution: If the optional [Interface Identifier] parameter is present. If only a subset of Interface Identifiers for an AS are included. If no Interface Identifiers are included. z INFO String (optional) The format and description of the [INFO String] parameter are the same as for the ASP Up message. z 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. optional [Interface Identifier]. If integer formatted Interface Identifiers are being used.Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. primary/backup operation). 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. The Error message contains the mandatory [Error Code] and optional [Diagnostic Information] parameters. 5-139 .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]. and optional [INFO String] parameters. optional [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 Identifier] parameter is the same as for the ASP Active message. The format and description of the [Traffic Mode Type] and [Interface Identifier] parameters are the same as for the ASP Active (ASPAC) message. Table 5-63 lists the defined IUA error codes. Figure 5-110 shows the structure of the Error message. 4) ASP Inactive Ack The ASP Inactive Ack message contains the optional [Interface Identifier] and [INFO String] parameters. Layer Management (MGMT) Messages 1) Error The Error message will only have the common message header. VIII. The format and description of the optional [INFO String] parameter are the same as for the ASP Up message. it will need to resend its message with an integer formatted Interface Identifier. a bogus message). 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. For example. When the ASP receives this error. 0x04 Unsupported Message Type The "Unsupported Message Type" error would be sent if a message with an unexpected or unsupported Message Type is received. an MGMT message was received on a stream other than "0". The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream. 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. 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.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. The Error message could optionally provide the supported version in the Diagnostic Information area. 0x0b Unrecognized SAPI The "Unrecognized SAPI" error would handle the case of using a SAPI that is not recognized by the SG. 5-140 . The "Invalid Interface Identifier" error would be sent by a SG if an ASP sends a message with an invalid (unconfigured) [Interface Identifier] value. 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. 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). 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. 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. if the MGC receives an IUA Establish Request message). The "Protocol Error" error would be sent for any protocol anomaly (that is. To enhance debugging. but the combination is not valid for the interface (for example. optional [ASP Identifier]. 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 . Diagnostic Information z The optional Diagnostic information can be any information germane to the error condition. optional [Interface Identifiers]. combination Description SAPI The "Invalid TEI. on a BRI the MGC tries to send Q. mandatory [Status Information].Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Value 0x0c Chapter 5 SIGTRAN Definition Invalid TEI. and optional [INFO String] parameters. 2) Notify (NTFY) As shown in Figure 5-111 and Figure 5-112. to assist in the identification of the error condition.921 Management messages through IUA when Layer Management at the SG SHOULD be performing this function). the Notify message contains the mandatory [Status Type]. the Diagnostic information could contain the first 40 bytes of the offending message. SAPI combination" error identifies errors where the TEI is assigned and the SAPI is recognized. 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 . If the Status Type is AS_State_Change.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 0 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. based on the value of the Status Type. Table 5-64 lists the defined status types. 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-64 Status types Value z Definition 0x010x01 Application server state change (AS_State_Change) 0x020x02 Other Status Information The [Status Information] parameter contains more detailed information for the notification. 0x01 UNASSIGNED TEI is considered unassigned by Q. 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. As shown in Figure 5-113. Confirm and Indication) The TEI Status messages contain the common message header followed by IUA message header.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN If the Status Type is Other. These notifications are not based on the SG reporting the state change of an ASP or AS. ASP Interface Identifiers z The format of the [Interface Identifiers] parameter in the Notify message is the same as for the ASP Active message. the Status Information values shown in Table 5-66 are defined.921. INFO String z The format of the [INFO String] parameter in the Notify message is the same as for the ASP Up message. 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. Table 5-67 Status in TEI Confirm and TEI Indication messages Value Definition Description 0x00 ASSIGNED TEI is considered assigned by Q. and Confirm messages contain the mandatory [Status] parameter. 3) TEI Status Messages (Request. the TEI Status Indication. The TEI Status Request message does not contain any additional parameters. 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).921. 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. 5-143 . or cold standby depending on the extent to which ASP1 and ASP2 share call state or can communicate call state under failure/withdrawal events. 5-144 . where only one ASP is configured within an AS (no backup). See Figure 5-116. warm. ASP2 MAY act as a hot. where ASP1 is configured to be Active and ASP2 a standby in the event of communication failure or the withdrawal from service of ASP1. In this case. 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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN 5. 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. 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.5. load-sharing case) The two ASPs are brought to active and load-share the traffic load.9 Basic Signaling Procedures I. one ASP is sufficient to handle the total traffic load. It is assumed that the SCTP association is already set up. 5-145 .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. ASP Traffic Fail-over Examples z (1+1 Sparing. Back-up Over-ride) Figure 5-118shows a case in which an ASP withdraws from service. where two of the ASPs are brought to active and share the load. 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. In this case. a minimum of two ASPs are required to handle the total traffic load (2+1 sparing). withdrawal of ASP. for example. Load-sharing case. if the SG knows that n+k = 2+1 for a load-share AS and n currently equals 1. The SG could have also (optionally) sent a Notify message when the AS moved to the Pending state. 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. z (1+1 Sparing. 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. ASP1 withdraws from service. the initial SG-ASP1 ASP Inactive message exchange would not occur. the SG notifies ASP2 that the AS has moved to the Down state. the SG notifies ASP1 that an alternative ASP has overridden it. Caution: If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure). In this 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.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. 5-146 . the SG has knowledge of the minimum ASP resources required (implementation dependent). Step 5: Send the QPTM message to the remote IUA peer in the SG. Step 2: Find the SCTP association to the chosen SG. and common header. 5-147 . Step 5: Send the QPTM message to the remote IUA peer in the ASP. Step 1: Determine the AS for the Interface Identifier. IUA message header. Step 2: Determine the Active ASP (SCTP association) within the AS. the initial SG-ASP1 ASP Inactive message exchange would not occur. III. Table 5-68 Procedures of sending a QPTM message Direction Procedure Step 1: Determine the correct SG. SG->ASP Step 3: Determine the correct stream in the SCTP association based on the D channel. over the SCTP association. 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). Step 4: Fill in the QPTM message. IUA message header.921/Q.931 Primitives Backhaul Examples Table 5-68 shows the two procedures of sending a QPTM message in two directions. Step 4: Fill in the QPTM message.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System SG ASP Inactive Chapter 5 SIGTRAN ASP1 ASP3 ASP2 ASP Inactive ACK NTFY(Ins. over the SCTP association. and common header. Q. ASP->SG Step 3: Determine the correct stream in the SCTP association based on the D channel. 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. the gateway has a problem with its physical connection. Figure 5-122shows an example of the message flows for a failed attempt to establish a data link on the signaling channel. An active association between ASP and SG is established prior to the message flows. 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. 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.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. 5-148 . SG Establish Request( Establish START) ASP Establish Indication (RELEASE_PHYS) Figure 5-122 Failure of establishing a data link IV. passing PDUs. In this case. so it cannot establish a data link on the signaling channel. 6.2 Terminology I.2 LAPV5 V5.1 Introduction V5UA is defined by IETF Draft V5.2 interface provisioned to carry communication channels. either singly or in multiples. 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.6 V5UA 5.2 V5UA SG (NIF) LAPV5 MGC V5UA V5UA M2UA SCTP SCTP IP IP Figure 5-124 Location of V5UA in the system 5. It is a mechanism for backhauling of V5.2 messages over IP using SCTP or other applicable transmission protocols. Communication Channel (C-Channel) It refers to a 64 kbit/s time slot on a V5.2-User Adaptation Layer (V5UA). AN V5. II.6. See Figure 5-124. 5-149 . on demand.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. ranging from 0 to 8191 (decimal).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN III. but excluding the C-path for the protection protocol. 5-150 . Envelope Function Address (EFA) It refers to a 13-bit number. VI.2 protocols. Communication Path (C-Path) It refers to any one of the following information types: z The layer 2 data link carrying the control protocol z The layer 2 data link carrying the link control protocol z The layer 2 data link carrying the PSTN signaling z Each of the layer 2 data links carrying the protection protocol z The layer 2 data link carrying the BCC protocol z All the ISDN Ds-type data from one or more user ports z All the PSTN P-type data from one or more user ports z All the ISDN T-type data from one or more user ports IV. or an ISDN agent attached to an AN.2 interface.An EFA uniquely identifies one of the five V5. Table 5-69 Corresponding relations between EFA values and protocols Value Protocol 0–8175 ISDN_PROTOCOL 8176 PSTN_PROTOCOL 8177 CONTROL_PROTOCOL 8178 BCC_PROTOCOL 8179 PROT_PROTOCOL 8180 LINK_CONTROL_PROTOCOL 8181–8191 RESERVED V. Multi-Link It refers to a collection of more than one 2048 kbit/s link which together make up a V5. Table 5-69 contains the possible values for an EFA. all of different types. Logical Communication Channel (Logical C-Channel) It refers to a group of one or more C-paths. Normally. generally used together within an ISDN Primary Rate Access (ISDN-PRA) user port. XI. The L1 FSM is located on the SG. the SG is mandatorily set to server. 5-151 . the MGC (SoftX3000) is set to client.2 interface whose time slot 16 carries a C-path for the protection protocol. the SG is mandatorily set to client. link control protocol. and.2 interface which has been assigned for carrying logical C-channels.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN VII. 5. The SCTP registered User Port Number Assignment for V5UA is 5675. and the BCC protocol. 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.2 initialization. Physical Communication Channel (Physical C-Channel) It refers to a 64 kbit/s time slot on a V5.3 V5UA Functions I. A physical C-channel may not be used for carrying bearer channels. Primary Link It refers to a 2048 kbit/s (E1) link in a multi-link V5.2 initialization. also the C-path for the control protocol. When the MGC is set to server. and BCC protocol and any other C-paths initially carried in time slot 16 of the primary link. link control protocol. on V5.2 interface whose physical C-channel in time slot 16 carries a C-path for the protection protocol and. IX. Other C-paths may also be carried in the time slot 16. VIII. Secondary Link It refers to a 2048 kbit/s (E1) link in a multi-link V5.6. on V5. Multi-Slot It refers to a group of more than one 64 kbit/s channels providing 8 kHz and time slot sequence integrity. in order to supply a higher bit-rate service. X. acts as the standby C-channel for the control protocol. When the MGC is set to client. Client/Server Model An SG and MGC communicating through V5UA adopts the client/server peer mode. SCTP Stream Management It is recommended that one SCTP stream be used for BCC. 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. MDL RELEASE request It is used to request the outcome of the procedures for terminating multiple frame operation.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN II. It is recommended to use a separate SCTP stream for Protection protocol on a specific C-channel. Link Control. it is recommended that one separate SCTP stream be used for all MPH (link related) messages. 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.4 Structure of V5UA Protocol Stack Figure 5-125 shows the V5UA protocol stack. One single stream should not be used to carry data of more than one C-channel. Control and PSTN protocol on a specific C-channel. MDL ESTABLISH indication It is used to indicate the outcome of the procedures for establishing multiple frame operation. V5.5 Definition of V5UA Boundaries Table 5-70 lists the boundary primitives defined by V5UA. 5-152 .2 V5UA LM SCTP IP Figure 5-125 Structure of V5UA protocol stack 5. MDL ESTABLISH confirm It is used to confirm the outcome of the procedures for establishing multiple frame operation. In addition.6. 5. It is also recommended to use one SCTP stream for all ISDN user ports on a specific C-channel.6. 5-153 . indicating an overload condition of the C-channel on the SG.2. 5. On reception of this message L1 FSM on the SG shall also start reporting the status of the V5 link to the GWC.2. However. This primitive equals the MPH-AI and MPH-DI primitives in V5. It is used by V5 system management to request to take the link out of service for use on a V5 interface.2. 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 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. 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-Processed primitive defined by V5.6 Implementation of V5UA Figure 5-126 shows a typical implementation of V5UA in an NGN solution. MDL-ERROR Indication It is used to indicate an error condition to V5 System Management. 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.6. 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. However. 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.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. this primitive has more extended meanings than the MPH-Stop primitive. this primitive has more extended meanings than the MPH-Processed primitive. The only valid reason for this primitive is 'Overload'. The use of this primitive is similar to that of the MPH-Stop primitive defined by V5. a V5UA message header. Message Structure As shown in Figure 5-127.2 message flows to the SoftX3000 through V5UA for processing.6. and several variable-length V5UA messages. the V5UA message structure is composed of a common header. and transparently transmits V5. 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 SoftX3000 H. 5.7 V5UA Protocol Messages I.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. Message Class z 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. This field SHOULD be set to all '0's and ignored by the receiver. which means version 1. The currently supported version number is 0000 0001. [Spare]. Table 5-72 V5 boundary primitives transport messages (V5PTM) Value 00 Message type Reserved Description - 5-155 .0.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN II. [Message Class]. [Message Type]. Version z The version field contains the version of the V5UA adaptation layer. Spare z The length of the spare field is eight bits. The message header part applies to all signaling protocol adaptation layer messages. Table 5-74 and Table 5-75 are defined according to different message classes. Table 5-73.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 z The message types as listed in Table 5-72.921/Q. and [Message Length] fields. Common Message Header The common message header contains the [Version]. 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. 0F Sa-Bit Set Confirm SG sends a Sa-Bit Set Confirm message to return the status of Sa bits on the E1 links. it sends an Establish Request message. When MGC expects channel D to be in the service operation state. 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. 0E Sa-Bit Set Request SGC sends a Sa-Bit Set Request message. 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. 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. 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. MGC controls the status of channel D. 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. An PDU corresponds to an unconfirmed information transmission service. This is required regardless of whether or not the E1 link carries C-channels. 08 Release Request MGC sends a Release Request message to release the data link on the signaling channel. An PDU corresponds to a confirmed information transmission service.921 user protocol data unit (PDU). 0D Link Status Indication SG sends a Link Status Indication message. 02 Data Indication It is sent by the SG to indicate that the peer IUA has successfully processed a received Data Request message.921 user protocol data unit (PDU). 06 Establish Confirm SG sends an Establish Confirm message to confirm an Establish 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. 03 Unit Data Request It is sent by the MGC and contains an ISDN Q. 5-156 . 07 Establish Indication SG sends an Establish Indication message to indicate that a data link has been established in a signaling channel. which is used between V5 System Management on the MGC and the L1 FSM on the SG. 0C Link Status Stop Reporting MGC sends a Link Status Stop Reporting message. 0B Link Status Start Reporting MGC sends a Link Status Start Reporting 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. without any change. An V5UA peer must send a Heartbeat Ack message in response to a Heartbeat message. 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.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. 03 Heartbeat (BEAT) It is optionally used to ensure that the V5UA peers are still available to each other. 11 Sa-Bit Status Indication SG sends a Sa-Bit Status Indication message to return the status of Sa bits on the E1 links. 05 ASP Down Ack (DOWN ACK) It is used to acknowledge an ASP Down message received from a remote V5UA peer. 04 ASP Up Ack (UP ACK) It is used to acknowledge an ASP Up message received from a remote V5UA peer. The Heartbeat Ack message includes all the parameters of the received Heartbeat message. 12 Error Indication SG sends an Error Indication 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. 07-7F Reserved by the IETF - 80-FF Reserved IETF-defined extensions - for ASPSM 5-157 . 06 Heartbeat Ack (BEAT ACK) It is sent in response to a Heartbeat message. 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. 04 TEI Status Indication It is interchanged between peers of V5UA layer to indicate the status of a specific TEI.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. the message type might be unexpected given the current state. 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. 02 ASP (INACTIVE) Inactive It is sent by an ASP to indicate to an SG that it is no longer an active ASP. 03 TEI Status Confirm It is interchanged between peers of V5UA layer to confirm 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. 03 ASP Active (ACTIVE ACK) Ack It is used to respond to an ASP Active message received from a remote V5UA. 02 TEI Status Request It is interchanged between peers of V5UA layer to request the status of a specific TEI. or a parameter value might be invalid. 04 ASP Inactive (INACTIVE ACK) Ack It is used to acknowledge an ASP Inactive message received from a remote V5UA peer. including the header. 01 Notify (NTFY) It is used to provide the automatic indication of an V5UA event to the IUA peer. 5-158 . For example. it is used only in QPTM. It contains the actual information to be transferred in the parameter. Parameter Value z The [Parameter Value] has a variable length. A variable-length parameter consists of the [Parameter Tag]. However. and all MGMT messages containing Sa. The variable-length parameters contained in a message are defined in a tag-length-value format. Format of V5UA Message Header In addition to the common message header. as defined by the message type. 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. As shown in Figure 5-128. The [Parameter Length] must not be padded with all zero bytes.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN III. the [Envelope Function Address (EFA)] field is included in the [Spare] field in addition to the integer-formatted interface identifier and DLCI. and [Parameter Value] fields. there will be a specific message header for V5UA messages. Parameter Length z The [Parameter Length] field must be a multiple of four bytes. The receiver must ignore the padding bytes. A sender must not pad with more than three bytes. The V5UA message header will immediately follow the common header in these messages. z EFA 5-159 . Parameter Tag z The [Parameter Tag] field is a 16-bit identifier of the type of parameter. IV. Error Indication. Format of Variable-Length Parameter V5UA messages consist of a common header followed by zero or more variable-length parameters. the sender pads with all zero bytes after the [Parameter Value] field. for the V5 extension of the IUA Message Header.5.8 IV “Format of IUA Message Header". If it is not a multiple of four bytes. [Parameter Length]. written as a variable length string. Stop Reporting. Link Status Messages (Start Reporting.This is equal to the time slot number of the addressed time slot. For all link status messages.2 protocols. or an ISDN agent attached to an AN.2 standard. 16 and 31 representing the possible time slots for C-channels on a V5 interface. Possible values are 15. the Channel ID shall be set to '0' and shall be ignored by the receiver. It has to be unique for every V5 link on the SG. For all other messages.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN EFA is defined in the V5 standard. V. The text formatted interface identifier shall be coded as the hex representation of the integer formatted interface identifier. Indication) All Link Status Messages contain the V5UA Message Header. The EFA identifies a C-path. This Link Identifier MUST match the Link Identifier used in the Link Management Messages defined in this document. the Channel ID must be set to 0. For Link Management messages. coordinated between the SG and MGC. As shown in Table 5-68. which is a 13-bit number.It must be unique on the SG. an EFA uniquely identifies one of the five V5. The Link Identifier portion of the Interface Identifier identifies the physical link on the SG addressed by the message. 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). 5-160 . SAPI. Interface Identifier (Integer) z Figure 5-129 shows the integer-formatted interface identifier. Caution: For MPH messages for which DLCI and EFA are not used. Channel ID It refers to Channel Identifier (5 bits). The integer value used for the Link Identifier is of local significance only. ranging from 0 to 8191 (decimal). TEI and EFA shall be set to ZERO and shall be ignored by the receiver. the DLCI shall be set as defined in the V5. Sa-Bit Messages (Set Request.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. 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. Set Confirm. Table 5-76 Valid values of Link Status Value Definition Description 0x0000 Operational Link is in operation. VI. 0x0001 Non-Operational Link is not in operation. 5-161 . 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. 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. In addition it contains the parameter as shown in Figure 5-130. Table 5-77 Value of BIT ID Value 0x07 z Definition Description Sa7 Addresses the Sa7 bit BIT Value Table 5-78 shows the values of BIT Value. Status Request. 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). An active association between ASP and SG is established prior to the following message flow.8 Basic Signaling Procedures of V5UA I. 0x01 1 Bit is set to ONE. Error Indication Message The Error Indication message contains the V5UA message header. 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. 5. the BIT Value should be set to '0' by the sender and should be ignored by the receiver. Link Identification Procedure Initiated by the MGC Through V5UA Figure 5-133 shows a link identification procedure initiated by the MGC through V5UA.6. whose definition is Overload. Its additional parameter is shown in Figure 5-132. Note: For the Sa-Bit Status Request and Set Confirm messages. and the V5 interface is already activated. 0x01. 5-162 . VII. that is.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 5 SIGTRAN Table 5-78 Values of BIT Value Value Definition Description 0x00 0 Bit is set to ZERO. An active association between ASP and SG is established prior to the following messages flow.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. Link Identification Procedure Initiated by the AN Through V5UA Figure 5-134 shows a link identification procedure initiated by the AN through V5UA. ONE ) Sa-Bit Set Conf (Sa 7) Figure 5-134 Link identification procedure initiated by the AN through V5UA 5-163 . and the V5 interface is already activated.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. ZERO ) Sa-Bit Set Conf (Sa7) Data Request (LnkCtrl: FE-IDAck) Data Request (LnkCtrl Ack: FE-IDRel) Sa-Bit Set Req ( Sa7. SG ASP Data Indication (LnkCtrl: FE-IDReq) Data Request (LnkCtrl Ack: FE-IDReq) Sa-Bit Set Req ( Sa7. potentiality of providing a great number of signals. it can be seen that SS7 is divided into two parts: user part (UP) and message transfer part (MTP). flexibility and reliability. z Independent user part applicable to different users: It is a functional entity which makes use of the transmission capability of the MTP.1 Overview Signaling system No. Functional structure of the SS7 in the NGN is shown in Figure 6-1. SS7 is an international standard common channel signaling. and intelligent network (IN). 6-1 .7 (SS7) is made by International Telephone and Telegraph Consultative Committee (CCITT). which features high-speed transmission.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 Chapter 6 SS7 6. It can meet the signaling requirements of public switched telephone network (PSTN). including ISDN user part (ISUP) and IN application part (INAP). 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. powerful functions. global system for mobile communications (GSM). 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). Signaling link function can be divided into eight parts: z Demarcation of signal units. II. z Error correction. The MTP provides reliable signaling message transmission. Its design complies with the ITU-TQ. III. z Monitoring of signaling link error rate. It is applicable to transmission links of both lower rate (such as 4.2. which is to generate and receive signals over physical channels. z Initial alignment. DUP. I. electrical and functional features of a signaling data link and the means to access the data link. MTP2 The signaling link function is the Level 2 function (MTP2) of MTP. One signaling data link is composed of two data channels operating at the same data transmission rate and in two opposite directions. MTP1 The signaling data link function is the Level 1 function (MTP1) of MTP. It is equivalent to the third layer (network layer) of the OSI model.2 MTP 6. repetition. MTP1 defines the physical. signaling link (MTP2) and signaling network (MTP3). and out-of-sequence in case of the signaling network failure.1 Basic Concepts MTP is used to transmit signaling messages of various UPs (such as TUP. z Processor faults. z Location of signal units. MTP3 The network layer is the Level 3 (MTP3) of MTP. 6-2 . It is equivalent to the physical layer of open system interconnection (OSI)’s seven-layer model.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 6. The bit rate of digital message carrier is 64 kbit/s. z Error detection. The MTP includes the functional levels of signaling data link (MTP1).8 kbit/s) and higher rate (such as 2048 kbit/s). It provides reliable signaling links for transmitting signaling messages to signaling data links between two directly connected SPs together with Level 1. z Flow control in Level 2. It takes measures to avoid message loss.701-710 recommendations. and ISUP) in SS7 system. 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. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 IV. If the local SP is not the DSP and is capable of transferring. Therefore. z Message routing function determines the outgoing signaling links through which messages are transmitted to destinations from every SP. the message routing function will be enabled to transfer the message. z Message discrimination function is used to identify whether the DSP that receives a message is the local SP. 2) Signaling network management function 6-3 . 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. The signaling network function is divided into signaling message processing and signaling network management. The signaling message processing function is divided into three parts. 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. 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. as shown in Figure 6-2. z Message distribution function distributes received signaling messages to corresponding UPs by every SP. to activate those z links that are not arranged. the opposite activities and procedures are used to rebuild the normal configuration of the signaling network. Signaling route management: It distributes the status information of the signaling z network to block or unblock signaling routes. 6. the above three management functions can be activated under proper situations.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 When a signaling link or SP is faulty. When congestion occurs. The reconfiguration capability is to change the routing. signaling link management and signaling route management. The following describes specific contents. Signaling link management: It is to restore faulty signaling links. It can restart MTP of an SP or slow down signaling traffic temporarily in case of congestion. The signaling network management consists of signaling traffic management. signaling network management function provides the reconfiguration capability of the network. bypass faulty links or faulty SPs of the signaling service through proper procedures.2. Signaling traffic management: It is to transmit signaling traffic from one link or z route to multiple links or routes. route or SP is changed. 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 . you must activate and align new signaling links to restore signaling traffic required between two SPs.2 Singnaling Message I. In some cases. When the status of a signaling link. When faulty links or SPs are restored. and to deactivate arranged signaling links. it can control signaling traffic. 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. management messages. three basic signaling unit formats are stipulated: message signaling unit (MSU). 6-5 . z LSSU is to provide link status information so as to connect and restore signaling links. z MSU is to transmit messges of various UPs. Message Structure To meet the requirements of signaling message transmission through the MTP. link status signaling unit (LSSU) and fill-in signaling unit (FISU). and test and maintenance messges. some flags can be inserted between signaling units in case of overload of signaling links to reduce load. There is a flag at both the start and the end of every signaling unit. Message unit structure is shown in Figure 6-3. backward indicator bit (BIB). check bit (CK). One is the mantatory part of MTP part processing occupied by various signaling units.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 z no message signaling or link status signaling unit is transmitted. which consists of eight fixed-length fields. The pattern for a flag is 8-bit binary code 01111110. status field (SF) and service information octet (SIO). At the transmitting end. backward sequence number (BSN). forward sequence number (FSN). forward indicator bit (FIB). the FSNs in 6-6 . z Flag Flag is also called delimiter. z FSN FSN indicates the sequence number of the transmitted MSU and consists of 7 bits. MSU F CK SIF SIO 8 16 8N(N ≥ 2) 8 2 LI FIB FSN BIB BSN 6 1 7 1 7 F 8 Bit sent firstly Format of message signaling unit LSS U F CK SF 8 16 8 or 16 2 LI FIB FSN BIB BSN F 6 1 7 1 7 8 Bit sent firstly Format of link status signaling unit FISU F CK 8 16 2 LI FIB FSN BIB BSN F 6 1 7 1 7 8 Bit sent firstly Format of fill-in signaling unit Figure 6-3 Message unit format Structurally. FSNs are numbered in a cyclic sequence ranging from 0 to 127 At the receiving end. signaling unit is divided into two parts. every flag indicates the end of the last signaling unit and the start of the next one. Therefore. During the transimission of signaling units. a signaling unit is identified by two flags of the start and the end in the information flow. The other is the signaling message part of user part processing. every transmitted MSU is allocated with a FSN. 1) Mantatory Part of MTP Processing This part includes flag (F). length indicator (LI). In addition to the delimitation function. in the delimitation identification of signaling units. In the operation of a signaling network. the bit will be reversed (that is. z FIB It occupies one bit. 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. LI is a number in binary code in the range 0–63 (decimal numeral). its BIB value remains unchanged when a new signaling unit is sent. In the normal operation. requesting the opposite end to send a correct MSU. 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. the length indicator is set to 63. from "0" to "1" or from "1" to "0") and sent. If retransmission is requested. Upon retransmitting MSUs.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 the received MSUs are used to check the sequence of the MSUs. For transmitted and unconfirmed signaling units. 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. The CCITT 6-7 . the signaling terminal will also change the value of FIB (from "1" to "0" or from "0" to "1" ). if the signaling information field of an MSU is more than 62 octets. FIB is used in the retransmission process of MSUs. the limit value of FSN and BSN is 127. received correctly) MSUs being sent back to the transmitting end by the receiving end. When retransmission is necessary. so that it is consistent with BIB again until BIB changes its value again when there is another retransmission request. which is a part of the confirmation function. BSN indicates the sequence number of the unit to be retransmitted. The field of LI is 6 bits. FIB has the same state with that of the received BIB. If an MSU received is correct. it is also used to identify the signal units to be retransmitted. the transmitting end and receiving end set their FSN independently. If a wrong MSU is received. z BIB BIB is used to initiate a retransmission request for a wrong signaling unit received. instead of being assigned with new sequence numbers. The FSN of FISU or LSSU uses the FSN of the MSU transmitted last time. z BSN The BSN is the sequence number of the confirmed (that is. Retransmission is requested if the received BIB changes its value. if the LI is 63. the maximum length indicated must not exceed 272 octets. However. The length of SF can be an octect (8-bit) or two octects (16-bit). It consists of SI and SSF. The number of octets can be "0" (if only the flag is transmitted) or 5 (for FISU). it is regarded that there is a signaling unit error. which indicates the statuses of signaling links. It consists of 16 bits. SF z Status field is unique to each LSSU. SI and SSF occupy 4 bits respectively. 6-8 . The field has 8 bits. the lower 3 bits indicates link statuses. as shown in Figure 6-4. The meanings are shown in Table 6-2. When it is an octect. (Eight fields including end F have been discussed).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. CK z The field is used for error detection of signaling units. If the number is beyond the range. They are mandatory for every signaling unit. Table 6-2 Meanings of SF status indication CBA z 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. The seven fields above mentioned are available in all the three kinds of signaling units. The number can also be less than or equal to m+7 octets (m is equal to 272). coded 00. It consists of message addressing tag. are reserved presently. 6-9 . 4) Signaling Information Part Processed by User Part Signaling information part processed by user parts is the SIF in the format of MSU. SI is coded as Figure 6-4. SIF is unique to MSUs.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. user signaling information heading and user signaling information. to distinguish between an international signaling network message and a national signaling network message. the use of the reserved codes in SSF is determined by the domestic signaling network conditions in different countries. The network indicator serves to distinguish the network attribute of the transmitted message. of which the higher two bits act as the network indicator. In the MTP of a signaling network. This diagram only lists those that are frequently used. According to CCITT stipulations. and the lower two bits. The capacity of SI allows it to represent messages of16 kinds of UPs. that is. Figure 6-4 illustrates the codes and network allocation of SSF. the message processing function distributes a message to the user part indicated by SI. 3) SSF ISSF consists of 4 bits. and indicates the group and type of messages. Signaling point code is a digital address. If a user part regulary sends messages and distributes the SLS value cyclically. Equal traffic load can be shared among all available links. When the DPC in a message represents the receiving sigaling point. which identifies every signaling point in the No. Any two messages sent with the same SLS always arrive at the destination in the same sequence as that in which they are sent. which is at the beginning of SIF. H0=0001 and H1=0100 mean that the 6-10 . There are four types of tag structures. that is. The tag includes destination point code (DPC). Standard routing tag has 32 bits.7 singnaling network uniquely. originating point code (OPC) and SLS. 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. It is composed of H1 and H0. H0= 0001 and H1=0001 in a telephone user part (TUP) message mean that the transmitted message is an initial address message (IAM).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. type D. all the service levels to the destination should be equal. occupies 4 bits respectively. TCAP messages belong to the type of SCCP messages. as shown in Figure 6-5. For example. The SLS ensures the sequencing of messages. 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. the message is distributed to the correponding user part (such as ISUP or SCCP) in the SIO as indicated by the service indicator. 6-11 . the user part. if H0=0001 and H1=0100. The second function level may generate and transmit corresponding status signaling units according to instructions from the third level or its judgement. C and D structures. This part can be further divided into several sub-fields. that is. The third type consists of messages of type B. error detection and correction of signaling message units. FISU is mainly composed of those fields with transmission control function. signaling link level. Since both H1 and H0 occupy 4 bits. a certain user message can accommodate 256 messages. it reports such statuses as congestion and processor error to the third level. It has the function to "fill-in" in the signaling link. For signaling network management messages. They are generated and processed by Level 3. and MSU generated by the user part (MSU-UP). Level 3 analyzes its message tag. For specific format and codes of SIF. LI and CK in a signaling unit are mainly used for the sending and receiving sequence. and meanwhile they may be of fixed length or variable length so as to meet the needs of various functions and expansion. It is also generated and processed on the second function level. while the generation and processing of its service message part (SIF) are performed in Level 4.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 transmitted message is an address complete message (ACM). BIB. The most important message in the MTP layer is the signaling network management message. BSN. and therefore the signaling unit of this type is generated and processed by the second function level. or receive and process the signaling link status indication sent by the opposite end. These sub-fields may be mandatory or optional. The following introduces the general format of the signaling network management message. The first two types are of type A structure. so that these various user messages can be transmitted through common channels. which are transmitted between MTPs. These messages are transmitted through the MTP to a specific UP. These fields are analyzed and processed in the second function level of a signaling network. it means that the transmitted message is changeover order signaling (COO). FSN. Thus the SMU is adaptable to different user messages with different features. that is. If necessary. 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). if both H0=0001 and H1=0001. z MTP The fields F. FIB. and determines the message destination. it mean that it is a transmission forbidden message. MSU used for signaling network test and maintenance (MSN-SNT). z Signaling message Signaling message part is also called service message part. refer to the descriptions of codes and format of user messages. LSSU is used to transmit the status indication information of a signaling link. As one kind of message signaling unit. there can be 16 message groups. The standby four-bit code is “0000”. H0 identifies a management message group. That is. the SLC is “0000”. and H1_determines the messages in a message group. The SLC refers to the signaling link code that connects the DSP and the originating signaling point (OSP). The DPC and OPC are the same as those described above. the total message capacity is up to 256 types. At present only some of the message types are used. the signaling network management message is identified by the SI bit “S1=10000” of the SIO in the signaling unit. Currently a four-bit code is used. and each group has 16 types of messages. The Figure 6-6 shows the structure of the signaling management message. the signaling information of the signaling network management message is transferred by the SIF. Refer to Table 6-3. OPC. Since H0 and H1 both have four codes. Management H1 information 8n (n≥0) 4 H0 4 SLC 4 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. If transferred messages are not related to the signaling link or another special code is not specified. z Heading code The heading code comprises two four-code bits: H0 and H1. and SLC.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 In the signaling network. 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 . Each signaling point has routing information which determines the signaling link. A specific signaling link is selected through the SLS field.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 4 4 56 Bit sent firstly The heading code H1 contains a signaling code. Signaling Procedure 1) Message routing The message routing function is based on the information contained in the routing tag. that is. These message are not received by the remote end. z Load sharing among links not in the same link group. such as “0000” to these messages. the DPC is associated with more than one signaling links which are used to bear messages. as shown beblow: D C B A 0 1 0 1 TFA III. thus realizing load sharing. buffer updating and recovery are included in the switchover process. 6-1 . To implement this function. Typically. the information on DPC and SLC field. 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. Messages are sent in the siganaling link according to the DPC and SLS field. It also avoids message loss. Recovery includes forwarding relevant messages to the transfer buffer of the alternative link. Buffer updating includes identifying all the messages in the retransmission buffer of the available signaling link. The messages route according to the normal routing function. In this function. The process is started before the signaling link starts switching over the service. The other way is to allocate the default SLC. repetition and sequencing errors. Any SLC can be allocated to messages unrelated to the signaling link so that the messages can be load-shared. Two basic exmples of load sharing: z Load sharing among links in the same link group. the SLC is used as the SLS to realize load sharing. 3) Changback The changback program ensures that the signaling services are transferred from alternative signaling links to available signaling links as soon as possible. When a signaling link becomes available due to reconnection. 4) Activating the signaling link. z Stopping the transmitting of related services on the alternative signaling link. recovery or unlocking. z Running the content updating process of the re-buffer of the unavailable signaling link. z If the signaling link test succeeds. signaling link initial alignment will occur. 5) Recovering the signaling link. z Sending a changback notification through a related alternative signaling link to the remote signaling point of the signaling link that becomes available. When a signaling link fault is detected.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 When one signaling link is unavailable. z Sending LSSUs or FLSUs. Changback includes the basic program that uses opposite activities for switchover. repetition and sequencing errors. 6-2 . 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. and storing the services in the changback buffer. z If the signaling link test succeeds. z If the signaling link test fails. the link is recovered and can be used for signaling transmission. the signaling link becomes activated and the signaling link test starts. the link prepares to transmit signaling services. This message indicates that the message service on the alternative signaling link can be sent through the available signaling link. When it is decided to activate an inactive signaling link. z If initinal alignment fails. start link recovery until the signaling link is activated or conduct manual operations. Then the following is conducted: z Terminating the sending and receiving of MSUs on relevant signaling links. z Determining the alternative signaling link. z Transferring signaling services to the alternative signaling link. initial alignment starts: z If initial alignment succeeds. the signaling link test starts. It also avoids message loss. a new initial alignment process starts on the same signaling link after time-out for the timer. z When receiving the changback confirmation sent by the remote signaling point of the available signaling link. z If initial alignment succeeds. the relevant signaling point will restart the forwarded service on the available signaling link. switchover is implemented in the signaling point. ISUP information is carried to the MTP or from MTP to ISUP by primitives in the form of parameters. an active signaling link can turn inactive through the deactivating process. or intervene manually. 7) Signaling route management process The purpose of signaling route management is to ensure that information is reliably exchanged between signaling points. three letters are used to represent three kinds of signaling points: Y for OSP. the TFP transfer-prohibited message is sent to Z. If a signaling link is deactivated. The unavailability. a new initial alignment process may be started on the same signaling link. z When Y selects the signaling route from Z to X. and dedicated circuit-switched data network. telephony network. the transfer-prohibited message is sent to all reachable adjacent signaling points (by broadcasting). z If the signaling link test fails. In this case. 6. 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). the signaling terminals of the signaling link exit services. restriction. X for DSP. that is. 8) Transfer-prohibited procedure To facilitate description. If not bearing signaling services. 6-3 .1 Overview I. transfer-restricted. to ensure the signaling route is available. repeat the recovery process until the link is recovered. the transfer-prohibited message is sent to an adjacent signaling point and relevant messages are received at this point. ISUP is applied to the hybrid digital/analog network.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 6 SS7 If initial alignment fails.7 public channel signaling system. Basic Concepts ISUP is one kind of UPs of the No. and availabitity of the signaling route are implemented by the transfer-prohibited.3. Z is unavailable for Y. II. 6) Deactivating the signaling link. Figure 6-7 shows the protocol stack of the ISUP. ISUP meets the requirements of CCITT for international semi-automatic and automatic telephony services and circuit-switched data services. and Z for signaling transfer point (STP). and transfer-allowed procedures. z When Z receives a message sent to X and Z cannot forward the message. z When Z confirms that X is difficult to reach.3 ISUP 6. Protocol stack architecture The ISUP uses services provided by the MTP to transfer information between ISUPs. it means MTP cannot send messages to a specific destination as parameters. When MTP sends the MTP suspension primitive. it means that the signaling route to a specific destination is congested or that there is no ISUP on the destination. and status primitive. III. Application in NGN ISUP has three application modes in NGN solutions. 1) Application of ISUP in NGN (MTP-MTP) 6-4 . as shown in Figure 6-8. This may be because ISUP is not installed or ISUP cannot be accessed. recovery primitive. The MTP transfer primitive receives and sends ISUP singaling messages by encapsulating the messages. Figure 6-9 and Figure 6-10. Other unkown factors may cause this problem too. 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. suspension primitive. When MTP sends the MTP recovery primitive.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. 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 . thus realizing the interoperation of SS7 with a PSTN switch through an SS7 network. In the voice channel. 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. In the voice channel.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. the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN. the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN. and exchanges SS7 with a PSTN switch through the TMG8010. which has the function of an embedded signaling gateway. mandatory fixed part. the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN. as shown in Figure 6-11. circuit identification code (CIC).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 The SoftX3000 provides an M3UA link to connect with the SG7000. 6. For details of the routing tag and CIC. and optional part.2 Singnaling Message ISUP messages are transferred on the signaling link through the MSU. See Table 6-4.3. mandatory variable part. The following introduces other parts of the ISUP message. Message Type Code A message type code is an SIO field. and exchanges SS7 with a PSTN switch through the SG7000. In the voice channel. The message type code defines the function and format of each kind of ISUP message. F SIF CK Signaling message SIO CIC LI OPC SLC FIB FSN BIB BSN DPC F 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. which is required for all messages. 6-6 .2. An ISUP message consists of six parts: routing tag. The messages are encapsulated in the SIF of the MSU.2 Singnaling Message. refer to 6. message type code. The message will normally serve to bring an assistance operator into the circuit if the call is automatically set up at the switch. this message is used in conjunction with charging information. 00000010 SAM Subsequent address message: A message that may be sent in the forward direction following an initial address message. 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. after having been suspended. RLC Release complete message: A message sent in either direction in response to the receipt of a release message. 00001110 RES Resume message: A message sent in either direction indicating that the calling or called party. 00000100 INF Information: A message sent to convey information in association with a call. which may have been requested in an information request message. is reconnected. 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 redirection message will also carry the redirection number. In semi-automatic working. when the circuit concerned has been brought into the idle condition. 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.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. When the call is completed through an operator at the incoming international switch. to convey additional called number information. In automatic working. ANM Answer message: it indicates that the call has been answered. or if appropriate to a reset circuit message. 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. 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. this message has a supervisory function. 00001000 00001001 00010000 6-7 . When the call is redirected. 00000011 INR Information request: A message sent by a switch to request information in association with a call. the message should preferably cause this operator to be recalled. 00100001 FRJ Facility rejected: A message sent in response to a facility request message to indicate that the facility request has been rejected. 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. 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. When a circuit is used in the dual-circuit mode of operation. to the switch at the other end of the circuit. 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. 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. Under certain conditions. due to memory broken or other causes. 00100000 FAA Facility accepted: A message sent in response to a facility request message. a blocking message is also a proper response to a reset circuit message. indicating the specified circuit group has been blocked. 00101000 PAM Pass-along message 6-8 . 00010101 BLA Blocking acknowledgement: A message sent in response to a blocking message. 00011111 FAR Facility request: A message sent from a switch to another switch to request activation of a facility. indicating that the requested facility has been activated. indicating that the circuit 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. 00010111 GRS Circuit group reset: A message sent to release an identified group of circuits.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. requesting continuity checking equipment to be attached. 00011000 CGB Circuit group blocking message: A message sent to the switch at the other end. 00010010 RSC Reset circuit message: A message sent to release a circuit. 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. The message also indicates the maintenance blocking state of each circuit. 00110011 FAC Facility: A message sent in either direction at any phase of the call to request an action at another switch. 00100111 6-9 . The message is also used to carry the results. 00110000 OLM Overload message: A message sent in the backward direction. on non-priority calls in response to an IAM. 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. 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. The message is sent along an established path in any phase of the call. has occurred. 00110010 NRM Network resource management message: A message sent in order to modify network resources associated with a certain call. 00110001 CRG Charging information: Information sent in either direction for accounting and/or call charging purposes. 00101100 00101111 00011101 00011100 00011110 Reserved. error or rejection of a previously requested action. and should be relayed to the originating or terminating access. 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.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. to invoke temporary trunk blocking of the circuit concerned when the switch generating the message is subject to load control. 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. 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. the "optional parameter end" octet will be transmitted after all optional parameters are sent out. the length of which is one octet. Each parameter includes parameter LI and contents. If a message type specifies that there may be optional part. this pointer does not exist. IV. and each parameter has an LI. z The callee is controlled by MG2 and SG2. 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. Each parameter has a name that is coded by a single octet. a LI (one octet) and the parameter content. 6. II. All pointers are transmitted consecutively at the start of mandatory variable part. and it is coded based on a single octet. the media gateway is connected with subscribers through the circuit trunk of a circuit-switched network. This flow example is based on the following conventions: z The caller is controlled by MG1 and SG1. When an IP trunk media gateway originates a call. and call signaling enters the SoftX3000 through an SS7 gateway. lengths and order of them are defined by the message type. Mandatory Fixed Part For a specified message type.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. The length of a parameter can be fixed or variable. but this specific message does not include optional part. 6-10 . and optional parameters can be transmitted in any order. the message does not include the name and LI of its parameter. The parameter name and pointer transmitting order are implicit in the message type. Each optional parameter should contain a parameter name (one octet). If a message type specifies that the optional part is not allowed.3. and the octet is all 0. those mandatory parameters with fixed lengths are contained in the mandatory fixed part. "Optional parameter end" octet: If there are optional parameters. A pointer is used to indicate the start of each parameter. In this case.3 Basic Signaling Flow Figure 6-12 shows the call setup and release flow originated by an IP trunk media gateway. Optional Part Optional part is composed of parameters. Parameters may be of fixed or variable lengths. III. the pointer field is all 0. which may appear or not appear in any specific message type. The locations. Mandatory Variable Part Those mandatory parameters with variable lengths are contained in the mandatory variable part. [Mode] is set to “SendReceive”. TDM termination and RTP termination are added in the context. z MG1 and MG2 are controlled by the same SoftX3000. TDM termination and RTP termination are added in the context. [Mode] is set to “SendReceive”. MG2 returns its RTP port number and voice compression algorithm through the Reply command. The jitter buffer and voice compression algorithm are also set. The jitter buffer and voice compression algorithm are also set. MG1 returns its RTP port number and voice compression algorithm through the Reply command.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 z ISUP is taken as an example of SS7. 6-11 . an IAM is sent to the SoftX3000 through SG1. 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. 3) A context is created in MG2. 2) A context is created in MG1. and the third layer (network layer) of OSI layered model can be constructed. Basic Services SCCP provides the following 4 classes of services: z Class 0: basic connectionless service z Class 1: ordered connectionless service z Class 2: basic connection-oriented service z Class 3: flow control connection-oriented service Classes 0 and 1 services are connectionless. 6-12 . 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. non-circuit related information and other information can be transmitted between the switches and special centers of telecommunication network through SS7 network. The phone set of the callee rings. z Transferring signaling data units with logic signaling connection established or not established. It belongs to the fourth functional group. 6. In the layered architecture of SS7. The circuit-switched network returns an ACM. With SCCP function. II. 9) The callee hooks off. and classes 2 and 3 services are connection-oriented. The SoftX3000 sends an REL to SG1. 7) The callee hooks off.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. SG2 sends an ANM to the SoftX3000. SG2 sends an REL to the SoftX3000. 6) The SoftX3000 sends an ACM to SG1. providing additional functions for MTP at the same time so that circuit related information. 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. 10) The SoftX3000 sends the Subtract command to MG1 and MG2. 8) The SoftX3000 sends an ANM to SG1. Thus.1 Basic Concepts Signaling connection control part is abbreviated as SCCP. 5) The SoftX3000 sends the Modify command to MG1 and reports the remote RTP port number. connectionless or connection-oriented services can be created. SCCP is one of the UPs.4 SCCP 6.4. I. which is similar to a leased telephone line. The connection-oriented services mean that users exchange control information between SCCPs to reach a protocol before transmitting data. SCCP exists in SoftX3000 to serve as the intermediate layer for transferring messages.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. it is necessary to point out its position through the pointer. One code determines one SCCP message. the class of transferred services (whether it is basic connection-oriented class or flow control connection-oriented one). For optional parameters. which can provide the users with semi-permanent connection. SCCP messages are processed by the FCCU/FCSU in SoftX3000. If a parameter is mandatory with variable length. 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 message type employs 8-bit coding. Its message contents lie in the SIF of MSU. Any individual message may include optional parameters. The connection-oriented services of signaling can be divided into temporary signaling connection and permanent signaling connection. and so on. The connection-oriented connection described here refers to temporary signaling connection. Permanent signaling connection is established and controlled by local (or remote) O&M function or by the node management function. The route tag in Figure 6-13 has been described in MTP section. as shown in Figure 6-13. The optional parameters may be of fixed or variable lengths. it is necessary not only to point out their start bits but also to give their respective codes and lengths. which is similar to dialing telephone connection. even possibly the amount of the data transferred. As IANP needs SCCP and TCAP to transmit signaling. An MSU is identified to be an SCCP message by the SI being 0011 in the SIO of the MSU. The connectionless services of SCCP are equivalent to the data service of data network. Service users control the establishment of temporary signaling connection. 6-13 . while class 1 service can ensure that messages can be transferred to their destination in sequence by using SLS. III.2 Singnaling Message The SCCP message is a MSU of SS7. The protocol contains the route through which data are transferred.4. Application in SoftX3000 The SoftX3000 can interwork with SCP through IANP. The parameters that are mandatory but have variable lengths must be put in the mandatory variable part. 6. Class 0 service do not ensure that messages can be transferred in sequence. Table 6-5 SCCP messages Protocol class Message type 0 1 Connection request (CR) 2 X 6-14 3 X Code 00000001 . such as transmitting data signaling units with logic signaling connections established or not established. must be implemented by transmitting various kinds of SCCP messages. SCCP Message Type SCCP functions and programs. Table 6-5 lists SCCP messages and their corresponding protocol classes and codes.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. The SCCP messages are classified into connectionless service messages and connection-oriented service messages. while DT2 and ED are used for protocol class 3. In addition. z DT1. DT1 is used for protocol class 2. Among them. z RSR and RSC are in protocol class 3 to re-initialize the data sending sequence numbers in the data transmitting stage. 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. z RLSD and RLC are used to release the signaling connection after data transfer. The main message types are explained as follows: z CR and CC are used to establish signaling connection.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 Protocol class Message type 0 1 2 3 Code Connection confirm (CC) X X 00000010 Connection refusal (CREF) X X 00000011 Connection released (RLSD) X X 00000100 Release completed (RLC) X X 00000101 Data type 1 (DT1) X 00000110 Data type 2 (DT1) X 00000111 Data acknowledgement (AK) X 00001000 Unit data (UDT) X X 00001001 Unit data service (UDTS) X X 00001010 Expedited data (ED) X 00001011 Expedited data acknowledgement (EA) X 00001100 Reset request (RSR) X 00001101 Reset confirmation (RSC) X 00001110 Protocol data unit error (ERR) X X 00001111 Inactivity test (IT) X X 00010000 ×: means this message can be used in the corresponding protocol class. DT2 and ED are three kinds of messages used to transfer data after signaling connection is established successfully. DT2 and ED must be acknowledged by AK and EA. 6-15 . z During signaling connection establishment. it is called an optional parameter (O). and IF is used to check whether both ends of the signaling connection work. Table 6-6 lists the parameters of SCCP message.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 6 SS7 ERR is sent when any protocol error is detected. SCCP messages must have parameters to provide all kinds of information. and XUDTS are connectionless service messages. If a parameter is indispensable in a message. the CR message must have the parameter [Called Address] to access the called subscriber and implement signaling connection. 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 . UDTS. The ERR message must have the parameter [Error Cause] to show the causes of error. A parameter is mandatory in one message but may be optional in another message. z UDT. 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). For example. If a parameter is optional in a message. UDT and XUDT are used to transfer connectionless service data. 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. Parameters of SCCP Message To implement respective functions. When UDT and XUDT can not reach their destinations. Therefore. UDTS and XUDTS must be sent to the originating point to show the causes if it is specified in UDT and XUDT. II. XUDT. whether a parameter is mandatory or optional depends on the individual 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. including [Segmentation/re-assembly].] P (S) and [Receiving No. z [Called address] and [caller address] are used to identify originating/destination signaling point and/or SCCP service access point. z If the length of network service data unit (NSDU) is longer than the maximum length of message for data transmitting. III. z [Release cause]. 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. resetting and refusing the signaling connection. the [credit] in an AK message can modify this window. Examples of Parameter Format Coding 1) Subscriber address: called address/caller address Subscriber address is a parameter with variable length. z [Receiving No. Its structure is illustrated in Figure 6-14.] P(R) shows the expected next sequence number. The parameter [segmentation/reassemble] aims to implement this function.] P (R). z [Credit] appears in CR or CC messages. It is the window of the signaling connection. the NSDU must be divided into several segments to be transferred and then reassembled when they reach the destination.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. implementing flow control in protocol class 3. 6-17 . z [Protocol class] defines the four kinds of protocols of connectionless services and connection-oriented services. 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. z [Data] is the network service data (NSD) that the user would send to the destination. [Error cause] is used to show the causes of error in ERR message. [Reset cause] and [Refusal cause] are used respectively to show the causes for releasing. This parameter is only used for DT1. [Sending No. determining the number of messages contained in the signaling connection transmission part. z [Sorting/segmentation] is an integrated parameter. During the data transmission stage. Address The order for various units appearing in the address is DPC. as shown in Figure 6-15. and coding design. 0001 The global title (GT) includes only the nature of address indication. 0 The address does not contain the subsystem number. 6 7 z Meaning National reserved. as shown in Figure 6-16. number design. 1 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). and GT. 1 The address contains the signaling point code. 0100 The GT includes the translation type. 0010 The GT includes only the translation type. 0 Route selection should be based on the GT in the address.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 Address indication Address Figure 6-14 Subscriber address structure Address indication z Address indication indicates the type of the address contained. coding design. 6-18 . SSN. coding plan. 1 The address contains the subsystem number. 0000 The global tile is not included. 7 6 5 Reserved Addressing indication 4 3 2 Global title indication 1 0 bit Subsystem Signaling indication point indication Figure 6-15 Address indication Table 6-7 lists the meaning of the bits of the address indication. and nature of address indication. Table 6-7 Meanings of the bits of the address indication Bit 0 1 Bits 5–2 Value 0 The address doe not contain the signaling point code. GT format is illustrated in Figure 6-17. 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. as shown below: Bits: 76543210 00000000 Subsystem unknown 00000001 SCCP management 00000010 Reserved 00000011 ISUP 00000100 Operations. O/E Address feature indication Address information Figure 6-17 GT format when GT indicator is 0001 When GT indication is 0001. including four possibilities: GT indicator = 0001 When GT indicator is 0001. as shown below: 6-19 . It is an 8-bit code. bits 6–0 of the first octet in GT are address nature indications.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. the information after the second octet of the GT bits 7. 3. 4. 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 Bits 6–0: 0000000 Idle 0000001 User number 0000010 National reserved 0000011 National valid number 0000100 International number 00000101 ~ Idle 11111111 Bit 7 is odd/even indication. See Figure 6-18. which is encoded as follows: 0: even number of addresses 1: odd number of addresses If the GT indication is 0001. 0 indicates the address signaling. Format and Composition of SCCP Message Each SCCP message is made up of different parameters. The protocol class is a 4-bit code. 1000 Error returned 1001 to 1111 are idle. including mandatory part and optional part (if any). bits 4–7 are idle. Bits 3210 0000 Protocol class 0 0001 Protocol class 1 0010 Protocol class 2 0011 Protocol class 3 When bits 0–3 codes indicate that a protocol class is the connection-oriented class (protocol classes 2 and 3). 6-21 . Table 6-8 shows the corresponding parameters making up each message. 2) Protocol class and return selection The protocol class is used to define SCCP service classes. IV. and the protocol class should be negotiated by both ends of SCCP. When bits 0–3 codes indicate that a protocol class is the connectionless class (protocol classes 0 and 1). the filling code 0000 should be added at the end of address signaling.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 [Protocol class] field should be used at the stage of signaling connection establishment. bits 4–7 are encoded as follows: Bits: 7654 0000 Not specified 0001 to 0111 are idle. UDT M 0 Segmentation/re-assem bly User data IT M .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 M M Called address M 0 Caller address 0 Protocol class CREF M RLSD RLC M M M M DT1 M DT2 M AK M ED M EA M RSR RSC ERR M M M M M M M M Sorting/segmentation M Credit M M Release cause M M Return cause Reset cause M Error cause M 0 0 0 0 M M 6-1 M UDTS M M M M M M Receiving sequence No. 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 z Message type code z 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 F 3 Protocol class F 1 Called address V 3 (minimum) Credit 0 3 Caller address 0 4 (minimum) Data 0 3–130 Optional parameters end 0 1 2) UDT message A UDT message comprises: z Route tag z Message type code z 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 F 1 Called address V 3 (minimum) Caller address V 2 (minimum) Data V 2–X 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 z 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 F 1 Called address V 3 (minimum) Caller address V 2 (minimum) Data V 2–X X: (To be determined) 4) XUDT message A XUDT message comprises: z Route tag z Message type code z 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 F 1 Called address V 3 (minimum) Caller address V 2 (minimum) Data V 2–X Optional O 6 X: (To be determined) 5) XUDTS message A XUDTS message comprises: z Route tag z Message type code z 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 F 1 Called address V 3 (minimum) Caller address V 2 (minimum) Data V 2–X Optional O 6 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. z Class 2: Only failure is reported. z Class 3: Only success is reported. z 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. z ERROR: returned upon operation failure. z REJECT: indicating that the operation can not be performed. z 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). z The dialogue is acknowledged (TC_CONFIRM): The first backward continuity indicates that the dialogue is established and can be continued. z 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 z 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 7 6 5 Class 4 3 2 Format 1 0 Tag code Class code: See Table 6-16. z Table 6-16 Meanings of class codes Value Meaning 00 Universal 01 Application-wind 10 Context-specific 11 Private use z Element format: 0 stands for primitive and 1 for constructor. z 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 7 6 5 0 MSB Length of contents 4 3 2 1 0 LSB Table 6-18 Long format 7 6 5 4 3 2 1 MSB The length field is N-1 in length. 1 0 LSB MSB 1 2 Length of contents LSB N Table 6-19 Indefinite format 7 6 5 4 3 2 1 0 1 0 0 0 0 0 0 0 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 M Destination transaction ID Continue Abort M M Cause for abortion End M M O 6-7 Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Message Chapter 6 SS7 Parameter Unidirectio nal Dialogue portion O O O O Component portion M O O O Begin Continue End Abort O 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 After confirming service requirements. and traffic management. SRF. A. SCF. and then load them to SCP for system invocation. the standard interface protocol for intelligent network: intelligent network application protocol (INAP). the operation procedures that all functional entities should comply with after they receive information streams are also prescribed. SDF and call unrelated service function (CUSF.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 III. Generally. user data management. and it is closely related with TCAP.1228) recommendations. Meanwhile. adopt various standard graphic elements to design the IN service logics. SMS SMS is responsible for managing service data and user data. IP IP is the special resource to assist in the implementation of IN services. voice identification. SoftX3000 serves as SSP. Application in SoftX3000 SoftX3000 supports intelligent network application. IP can be a separate physical device or serve as part of SSP. It is controlled by SCP. and also can be transported over IP network through SIGTRAN. SSF. with its functions shared by other switches.12XY (Q. The INAP messages can be transported over narrowband TDM link through MTP. to define the information streams between the functional entities of the intelligent network. V. The functional entities (such as SCF. dual-tone multifrequency dialed number receiving. it has five functions: service logic management. and executes the operations designated by SCP service logics. INAP transmits standard information streams of the intelligent network by means of invoking TCAP primitives. service data management. 6-10 . It usually possesses voice functions. and it provides a friendly graphic editing interface for service designers. only in Q. you can use SCE to define the data related to the requirements. This interface protocol is put forward in ITU-T Q. In the intelligent network architecture. thus facilitating deployment of those services whose playing contents change frequently. INAP messages are processed by the FCCU/FCSU of SoftX3000. IV. and SRF) in the intelligent network nodes transmit messages to one another to mutually complete IN services. it can save investment and bring conveniences to managing voice resources. The intelligent network is a distributed system. such as voice synthesis. INAP is one of SS7 UPs. and so on. recorded announcement playing. VI. If IP is centralized in the network. ITU-T uses a kind of higher layer communication protocol. which communicates with SCP through IANP. in which the information streams among SSF. SCE SCE generates new service logics according to the requirements of customers.1228) are described in detail. service monitoring.1208. that is.1218 and Q. which are transmitted in SS7. and Q. 36 kinds of operations are adopted in CS-1 phase according to the requirement of services. The application protocol data unit (APDU) of ROSE serves as unit data (UDT). z Class 3: Only success is reported. Q. which is contained in the TCAP component sub-layer for transmission. Table 6-23 lists the operations in CS-1 phase and their corresponding information streams. In the INAP procedure.681. INAP Message Structure INAP is a kind of remote operation service element (ROSE) user procedure.682.690 recommendations.1) of ITU-T Q. z Class 4: Neither success nor failure is reported. z Class 2: Only failure is reported.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 6. For the INAP message structure. INAP Operations and Classes There are four classes of INAP operations: z Class 1: Both success and failure are reported.6. and class 0 service (basic connectionless service) of SCCP is adopted. INAP is described by Abstract Syntax Notation-1 (ASN. Table 6-23 INAP operations and classes Information stream Operation Class Activate Service Filtering Same 1 Activity Test Same 3 Activity Test Response Return Result from Activity Test 3 Apply Charging Same 2 Apply Charging Report Same 2 Assist Request Instruction Same 2 Call Gap Same 4 Call Information Report Same 4 Call Information Request Same 2 Cancel Status Report Request Same 2 Connect Information Same 2 Connect Same 2 Connect to Resource Same 2 6-11 . see the SCCP message structure.2 Singnaling Message I. II. 6-12 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 Information stream Operation Class Continue Same 4 Disconnect Forward Connection Same 2 Establish Temporary Connection Same 2 Event Notification Charging Same 4 Event Report BCSM Same 4 Furnish Charging Information Same 2 Initiate DP Same 2 Initiate Call Attempt Same 2 Release Call Same 4 Request Charging Event Notification Same 2 Request Report BCSM Event Same 2 Request Current Status Request First Status Match Report Request Status Report 1 Request Every Status Change Report Reset Timer Same 2 Select Facility Same 2 Send Charging Information Same 2 Service Filtering Response Same 4 Status Report Same 4 Assist Request Instruction from SRF Assist Request Instruction 2 Cancel Announcement Cancel 2 Collected User Information Return Result from Prompt and Collect User Information 1 Play Announcement Same 2 Prompt and Collect User Information Same 1 Specialized Resource Report Same 4 Note: In the "Operation" column. "same" indicates that the operation name is the same as the information stream name. 6. connect. continue with parameter. BCSM event report. status report. 6-13 . collect information. request UTSI report. 6. combine call segment. continue. and assist request instruction. request/cancel call information. release entity. terminal authentication. provide charging information. cancel status report request. disconnection forward connection with parameter. establish temporary connection. call information report. and specialized resource report. script information. reconnect. and send STUI. specialized resource report. There are eight operations between SCF and SRF: 5) 2 operations of class 1 Prompt and collect user information. 6) 4 operations of class 2 Close script. and UTSI report. assist request instruction. cut off LEG. initiate DP. manage triggering data. initiate call attempt.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 In the CS-2 phase. request status change. and detach LEG. among which are 47 operations between SCF and SSF: 1) 10 operations of class 1 Activate service filtering. 2) 25 operations of class 2 Request charging. The INAP message process between SoftX3000 (SSP) and SCP is related to specific services. request BCSM event report. send charging information. service filtering response. request charging report. play announcement. 8) 2 operations of class 4 Script event. and prompt and accept information. run script. move LEG. request current status. move call segment. release call. request the first status matching report. reset timer. the number of operations extends to 145. select facility. disconnect forward connection. connect to resource.3 Basic Signaling Flow SoftX3000 supports multiple IN services and generates other services as required. 7) Operations of class 3 None. charging event notification. generate call segment association. 3) 1 operation of class 3 Activity test 4) 11 operations of class 4 Call gap. Figure 6-23 shows the flow. and sends connection instruction (to connect with the real called number) and charging instruction (to charge the callee) to SSP. and completing connection between the caller and the callee as well as charging. z MG1 and MG2 are controlled by the same SoftX3000. Figure 6-22 shows the process of making an 800 call by an ordinary subscriber. SSP is responsible for notifying the callee to ring.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.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 6 SS7 I. translates the number into an ordinary phone number (real called number). This flow example is based on the following conventions: z The user MG originates a call. That is. An 800 number is allocated to each subscriber who applies for this service. 6-14 . 3) SCP queries the code translation table. Flow in Which User MG Originates IN Call The 800 service is taken to illustrate the flow. The callee corresponding to the translated 800 service number is conncected with MG2. 800 Service Process The 800 service is a freephone service. z The callee hooks on first. and the user originates a corresponding call. As the number 800××××××× serves as the access code of this service. II. and the caller who dials the number needs not to pay. 2) SSP collects the 800 number and reports it to SCP. the MG directly connects the user. and the caller dials the 800 service number. Database SCP No. z z The caller is connected with MG1. this service is usually called 800 service. 2) The caller hooks off. SGF sends the INAP/IP operation IDP to SCF to report triggering of the 800 service. MG1 sends the Notify command to SoftX3000 to report the off-hook event. The caller listens to the dialing tone. 4) MG1 sends the Notify command and the called number to SoftX3000. SoftX3000 waits for the off-hook event. that is.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. 5) SoftX3000 sends an INAP/IP operation IDP to SGF to report the triggering of the 800 service. it sets up a termination in the null context. SGF converts the two operations into an INAP/IP operation and sends it to SoftX3000. MG1 returns its RTP port number and voice compression algorithm through the Reply command. [Mode] is set to “ReceiveOnly”. TDM termination and RTP termination are added in the context.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. 7) A context is created in MG1. The jitter buffer and voice compression algorithm are also set. 6-15 . 6) SCF sends INAP/TC operations AC and CONNECT to SGF and asks SoftX3000 to charge and connect the call. After that. 3) SoftX3000 sends the Modify command to MG1 and waits for the user to enter the called number.CON IDP AC. z MG1 and MG2 are controlled by the same SoftX3000.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 8) Chapter 6 SS7 A context is created in MG2. 6-16 . [Mode] is set to “SendReceive”. 12) SoftX3000 sends the Modify command to MG1 and cuts off the ringback tone. and call signaling interworks with the SoftX3000 through a SS7 gateway. 11) SoftX3000 sends the Modify command to MG2 and cuts off the ringing tone. 14) The SoftX3000 sends the Subtract command to MG1 and MG2. TDM termination and RTP termination are added in the context. 9) SoftX3000 sends the Modify command to MG1 and notifies the remote address. 10) The callee hooks off. SGF sends the INAP operation ACR and report the charging resut to SCF. z ISUP is taken as an example of SS7. The mode is “SendReceive”. MG2 sends the Notify command to SoftX3000. z The callee is controlled by MG2 and SG2. MG2 sends the Notify command to SoftX3000. 15) SoftX3000 sends an INAP operation ACR to SGF. 13) The callee hooks on. This flow example is based on the following conventions: z The caller is controlled by MG1 and SG1. III. The jitter buffer and voice compression algorithm are also set. MG2 returns its RTP port number and voice compression algorithm through the Reply command. Flow in Which Trunk Gateway Originates IN Call When a trunk media gateway originates a call. Figure 6-24 shows the flow. the media gateway is connected with the user through the trunk of a circuit-switched network. SGF converts the two operations into an INAP/IP operation and sends it to SoftX3000. MG1 returns its RTP port number and voice compression algorithm through the Reply command. The jitter buffer and voice compression algorithm are also set. 7) SoftX3000 sends an ACM to SG1. 6-17 .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. The phone set of the callee rings. TDM termination and RTP termination are added in the context. MG2 returns its RTP port number and voice compression algorithm through the Reply command. 4) A context is created in MG1. The jitter buffer and voice compression algorithm are also set. 3) SCF sends INAP/TC operations AC and CONNECT to SGF and asks SoftX3000 to charge and connect the call. The circuit-switched network returns an ACM. SGF sends the INAP/IP operation IDP to SCF to report triggering of the 800 service. 5) A context is created in MG2. an IAM is sent to the SoftX3000 through SG1. 6) The SoftX3000 sends an IAM to the circuit-switched network through SG2. [Mode] is set to “ReceiveOnly”.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. 2) SoftX3000 sends an INAP/IP operation IDP to SGF to report the triggering of the 800 service. [Mode] is set to “SendReceive”. TDM termination and RTP termination are added in the context. 12) The callee hooks on. 10) SoftX3000 sends an ANM to SG1. tells the remote RTP port number. The mode is “SendReceive”. SG2 sends an ANM to the SoftX3000. SGF sends the INAP operation ACR and report the charging result to SCF. and notifies MG1 to send the ringback tone. 13) SoftX3000 sends an REL to SG1. 14) SoftX3000 sends an INAP operation ACR to SGF. 6-18 . 11) SoftX3000 sends the Modify command to MG1 and cuts off the ringback tone. SG2 sends an REL to the SoftX3000. 15) SoftX3000 sends the Subtract command to MG1 and MG2. 9) The callee hooks off.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 8) Chapter 6 SS7 SoftX3000 sends the Modify command to MG1. It is composed of line monitoring signals. and the types of line signaling are few. if the inter-office transmission system uses carrier. A register is a shared device. Line signaling is transmitted between line devices (repeaters). R2 signaling consists of line signaling and register signaling. Therefore.1 Line Signaling There are three forms of line signaling: DC line signaling.1 Basic Concepts As the telecom network is very large in scale. therefore DC line signaling actually is not used. Register signaling is transmitted between registers. the definition varies from country to country.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling Chapter 7 R2 Signaling 7. It is composed of selection signals and service signals. DC line signaling will not be introduced in this document. 7. DC line signaling DC line signaling is used for the real line trunks of electromechanical switches. No. Line signaling with in-band single frequency pulse In a toll automatic telephone network. long signal unit and continuous signal unit. A line device cannot be shared among trunks. Instead. the in-band single frequency pulse signal. 1 signaling is a subset of R2 signaling. Of these two kinds of signaling. line signaling with in-band single frequency pulse and digital line signaling. I. each trunk must have a line device. It is used for selecting route and callee and managing the telephone network. It is used for monitoring the status of connection of trunks and controlling the connection. The short signal unit is a short pulse 7-1 . In China. Few registers are needed in a signaling network. Therefore. the inter-office line signaling usually uses the audio signal. a register can be a complex device for matching more kinds of signaling. microwave or satellite circuits of frequency-division multiplexing. the channel associated signaling system is still widely used in the international telecom network and telecom networks of various countries. It consists of the short signal unit. it is hard to replace channel associated signaling completely with SS7 signaling in a short time span. namely.1. By far. The single frequency used by line signaling is 2600 Hz. II. local call networks are all stored program-controlled. line signaling is relatively simple to reduce costs. The structure of signaling signals is described in Table 7-2. Sending direction Connection status (signaling name) Forwa rd Signaling signal structure (ms) Backw ard 1 Occupation signal → Single pulse 150 2 Disconnection signal → Single pulse 600 3 Repeated disconnection signal 150 300 Used between toll offices and between toll/local offices 600 → 600 600 4 Answer signal ← Single pulse 150 5 Clear signal ← Single pulse 600 6 Release guard signal ← Single pulse 600 7 Blocking signal ← Continuous 7-2 Remarks 600 Used between local offices .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling signal with the nominal value of 150 milliseconds. The nominal interval of sending two signals is 300 milliseconds. 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. Backward signaling is sent from the terminating office to the originating office. Forward signaling is sent from the originating office to the terminating office. Table 7-1 lists the nominal values of pulse signals and intervals. The long signal unit is a long pulse signal with the nominal value of 600 milliseconds. Table 7-2 Signal structure of line signaling with in-band single frequency pulse Seria l No. It means that the switch can release the call in abnormal call disconnection in addition to normal disconnection. When the outgoing trunk of the originating office sends an occupation signal. The disconnection signal is sent in any of the following cases: z 1 The caller hangs up in call control recovery mode 2 The operator of original toll office in toll semi-automatic connection 3 The original office receives a backward register signaling such as connection busy. z The clear signal indicates that the callee hangs up. It is a backward signaling sent by the incoming trunk. 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. It is a backward signaling sent by the incoming trunk from the terminal office to the original office in relay. z Disconnection signal is a forward signaling sent by the outgoing trunk to the incoming trunk of the peer office. If the release control signal is still not received after sending the repeated disconnection signal. 7-3 . an alarm will be generated. 8 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 ← A → 9 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. 4 Callee not pickup after alerting timeout. an incoming trunk of the peer office will change its state from idle to occupied.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Seria l No. z The answer signal indicates that the callee picks up the phone. 0 means normal. and blocking state of the trunk lines. indicating that the trunk has been blocked. In a bi-directional trunk circuit. Y: Loss-of-synchronization report bit. and the trunk circuit is released. If no register signaling is received in 15 seconds.. sometimes it is occupied in both direction due to disturbances.. the operator will send the signal after receiving confirmation from the callee. the first four bits are used for synchronization in the multiframe.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. Table 7-3 describes the usage of TS16 in a PCM multiframe. a multiframe concept is introduces. release. A multiframe consists of 16 individual frames. if the callee hangs up and the operator need to call the callee. and is set to 1. III. and 1 means loss of synchronization. the operator can send the re-ringing signal. z The blocking signal is a backward signaling sent by the incoming trunk of the incoming office. When the toll office operator tries to connect the call. 7-4 . Table 7-3 Use of TS16 in a PCM multiframe Frame 0 Frame 1 abcd 00 00 XY XX z Voice channel 1 abcd Voice channel 16 Frame 2 abcd Voice channel 2 . and the other end will send a backward forced release signal (acting as a release control signal). z The ringback signal is a backward operator signaling. z The re-ringing signal is a forward operator signaling. and the TS16 of the other 15 frames are used to transmit the line signaling of the 30 voice channels. In the TS16 of the frame 0. After the toll office operator establish call connection with the callee and the callee answers. each of which is 125 µs and contains 32 timeslots. one end will send a forward forced release signal (acting as a release signal). and finds that the callee is engaged in a local call. To support transmission of 30 voice channel line signaling in the PCM system. the last four bits are used for loss-of-synchronization report. A multiframe has 16 TS16. It is sent by the operator back to the caller. abcd Voice channel 17 … TS16 of frame 0 X: Spare bit. z The forced release signal is used in the following case. Digital line signaling The line signaling monitors the occupation. It indicates that the caller of the originating office releases. z The forced disconnection signal is also a forward operator signal. Table 7-4 Meaning of forward signaling in digital lines Bit Meaning af=0 Caller picks up (occupied) af=1 Caller hangs up (released) bf=0 Not faulty bf=1 Faulty cf=0 Operator re-rings or forced releases cf=1 Operator does not re-ring or forced release Table 7-5 Meaning of backward signaling in digital lines Bit Meaning ab=0 Callee picks up ab=1 Caller hangs up (backward released) bb=0 Idle bb=1 Occupied or blocked cb=0 Operator rings back cb=1 Operator does not ring back Obviously. b. and the ab. and cb are for the backward signaling. c. Table 7-6 shows the differences between different digital line signaling in the three bits. bf. There are four bit—a. bb. Only the first three bits are used for both the forward signaling and the backward signaling. Table 7-6 Signaling bits in the automatic and semi-automatic connection of a toll office Connection state Forward signaling Backward signaling af bf cf ab bb Idle 1 0 1 1 0 Occupied 0 0 1 1 0 7-5 . Cf and Cb are not needed. Table 7-4 lists the meaning of the signaling.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling TS16 of other frames z A 30-voice-channel PCM system sends the line signaling by sampling and transmitting the TS16 in a multiframe. and the automatic connection between a local office and a toll office. and cf are for the forward signaling. and d—available in both transmission directions for each voice channel. no operator intervention is needed in the connection between local offices. The bit af. Therefore. while the backward signaling confirms and controls a call. Orginating office SND Send the first bit of forward signaling (Beat 1) Terminating office RCV SND RCV t1 Stop sending the first bit t2 of forward signaling (Beat 3) t3 Send the second bit of forwarding signaling t4 Figure 7-1 The transmission process of R2 register siganling 7-6 Send the first bit of backward signaling (Beat 2) Stop sending the first bit of backward signaling (Beat 3) . Similarly. When sending a digit. the sending party will not stop sending the forwarding signaling until having received a backward confirmation. Definition of Register Signaling The R2 register signaling is in multiple frequency control (MFC) mode. In the register signaling.1. the forward signaling and backward signaling are both consistent. 7.2 Register Signaling I. The forward signaling transmits addresses and controls indications.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling Forward signaling Connection state Backward signaling af bf cf ab bb Occupation confirmed 0 0 1 1 1 Answer 0 0 1 0 1 Hang up 0 0 1 1 1 Re-ring (forced release) 0 0 0 1 1 Release 1 0 1 0 1 Release control 1 0 1 1 0 Ring back 1 0 1 0 1 Blocked 1 0 1 1 1 Refer to the previous paragraphs on the definition of connection states. the receiving end will not stop sending backward signaling until having detected that the peer end stops sending forwarding signaling. It is divided into two types—forward signaling and backward signaling. the transmission of R2 register signaling is done in four beats. As shown in Figure 7-1. The terminating office thus replies that it has received the forwarding signaling. 4 The terminating office detects that the peer end stops sending the forward signaling. and 1980Hz. and 780 Hz. and stops sending the forward signaling. 3 The originating office receives and identifies the backward confirmation signaling. 1620 Hz. There are six backward signaling of MFC register signaling. 1860Hz. Six combinations of two from four low frequencies—1140 Hz. Coding Mode of MFC Register Signaling There are 15 types of forward signaling of MFC register signaling. II. 2 The terminating office (receiving end) receives and identifies the forwarding signaling. Table 7-7 Forward signaling Code 1 2 F0 (1380) √ √ F1 (1500) √ Frq (Hz) 3 4 5 √ 8 9 10 √ √ √ √ 11 12 13 √ √ √ √ √ 15 √ √ F7 (1860) 14 √ √ √ F4 (1740) 7 √ √ F2 (1620) 6 √ √ √ √ √ √ F11 (1980) √ √ √ √ Table 7-8 Backward signaling Code 1 2 F0 (1140) √ √ F1 (1020) √ Frq (Hz) F2 (900) 3 4 5 6 √ √ √ √ 7-7 √ √ . 1500 Hz. and returns the first bit of backward confirmation signaling. and stops sending the backward confirmation signaling. When the originating office detects that the peer end stops sending the backward confirmation signaling. 900 Hz. 1020 Hz. 1740 Hz. Fifteen combinations of two from the six high frequencies—1380 Hz. it starts the second control period by sending the next bit of forwarding signaling. Table 7-7 and Table 7-8 details the combination of frequencies.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling Beat Operations 1 The originating office sends the first bit of forwarding signaling. and informs what specific forwarding signaling the originating office shall next send. immediate. The high priority user in the table refers to those whose calls take precedence over others’ in the case of network blocking or overload. 7-8 . Table 7-9 lists the meanings of the four groups of signaling. Group A is the acknowledgement of group I. there are 10 user types. The combination of these two kinds of information is indicated with a KA code. free) and user level (ordinary. Table 7-9 Meanings of the four groups of signaling Forward signal Group I Name Meaning KA Caller type KC Toll connection type KE KD Capacity Group Name Meaning capacity Back control acknowledgement of the number receiving status and connection status 6 Callee status 6 10/15 5 Toll/local office and urban connection type 5 Digit 1–0 10 Digital signal II Backward signal Originating call service type A 6 B A Signal B signal Note: For a local office using the step-by-step system. Both forward signaling and backward signaling have two sub-types: group I and group II for the forward signaling. The purpose of this signaling is to provide the charging type (periodical. and group B the acknowledgement of group II. there are 15 user types. z Forward group I signaling Forward group I signaling consists of connection control signaling and digital signaling. high priority) information. Table 7-10 Forward group I signaling Type Meaning KA It refers to the caller type signaling sent from the originating local office to the originating toll office or originating international switching center in the forward direction. as shown in Table 7-11. refer to Table 7-10 and Table 7-12. Types and meanings MFC register signaling As described in the above. for a stored program control (SPC) local office using the crossbar system. the MFC register signaling falls into two types: forward and backward. and group A and group B for the backward signaling. For details.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Code 1 Frq (Hz) Chapter 7 R2 Signaling 2 3 F4 (780) 4 5 6 √ √ √ III. and backward group A from backward group B. The ten digits. A4. A3 signaling is the control signaling. and A5 an unallocated number. A4 indicates busy. refer to Table 7-10 and Table 7-11. For details. 1. KE It refers to the connection control signaling sent from the terminating toll office to the terminating local office and between local offices in the forward direction. ….Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 7 R2 Signaling Type Meaning KC It refers to the connection control signaling sent between toll offices in the forward direction. 0. 2. 3. A3 A3 is a conversion control signaling for differentiating forward group I from forward group II. are used to indicate the calling number. and connecting other specified calls (for example. Backward group A signaling Backward group A signaling is the MFC signaling of forward group I signaling. indicating the end of the calling number. called area code and called number. Digital signaling It is a selection signaling. completing specified calls. “15” is used to separate the calling number and called number. 7-9 . There are two types of KE signaling. Table 7-11 Backward group A signaling Type Meaning A1. In the toll incoming register at the local office end in the connection from the terminating toll office to the local office. A3 signaling is a pulse (150±30 ms) signaling. as shown in Table 7-11. A2. or in the multiple frequency incoming register of the local call connection. In other cases. A5 They are the cause analysis signaling when connection to the callee fails. This signaling has the functions of ensuring the communication quality of high-priority users. They control the code-sending sequence of forward digital signaling. It controls and acknowledges forward group I signaling. A6 These three kinds of signaling together are called code-sending sequence control signaling. test calls). periodical 9 (Have right for suburban automatic call. free Ordinary. free High priority. free Ordinary. immediate Printer. have right for toll automatic call Standby Standby 10 (Have no right for toll/suburban automatic call) High priority. free 7-10 . free 5 A5: unallocated number 6 Standby Standby Standby 6 A6: send KA and calling number 7 Standby Standby Standby 8 Standby High priority. immediate Printer.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling Table 7-12 Forward group I signaling and backward group A signaling Forward group I signaling Backward group A signaling Contents of KA signaling (including KOA) KA co de 1 2 3 Step-by-step local office O rd in ar y SPC local office using crossbar system (also including PAM office) KA KA Periodical Periodical User table. immediate 3 A3: shift to B signal 4 Standby Standby Standby 4 A4: telephone key blocking 5 Ordinary. immediate KC code Contents of KC signaling KA Ordi nary KE code Contents of KE signaling Digit al sign aling Contents of A signaling Periodical 1 A1: send next bit User table. immediate 2 A2: send starting from the first bit Printer. immediate Ordi nary User table. periodical High priority. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling 11 Standby 11* Voice mailbox notifies the user to leave a message 12 “Z” indicates a specified number call 12 Standby Test call 13 “T” indicates a test connection call 13 “T” indicates a test call Standby 14 High priority 14 Standby 15 Control the number of satellite circuit segments 15 Voice mailbox cancels notifying the user to leave a message 11 Standby 12 13 14 15 – – Note: Those types with brackets are not sent to the originating toll office. 7-11 . “*” indicates that the signal is needed for cooperating with old equipment. It indicates the status of the callee. Refer to Table 7-13 for the contents of backward group B signaling. 3 Urban call 4 Fax or user data communication of the urban user. high priority user 5 6 Used for toll call conne ction During toll call connection or test call connection (when KD=1. It is sent after the reception of KD signaling to acknowledge the control and connection of KD signaling.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling Forward group II z Forward group II signaling is also called KD signaling. based on KD. Table 7-14 describes the role of this signaling. 2 or 6) During local call connection (when KD=3 or 4) Callee idle. to judge whether the attendant can break in or forcefully release a local call. calling party release recovered Used for urban call conne ction Standby Table 7-14 Contents and role of KD signaling Role of KD signaling KD code Originating call service type Whether attendant can break in local call Yes 1 Semi-automatic breaking in of toll attendant 7-1 √ Whether toll attendant can break in No Yes – – No √ . first party release recovered 1 Callee idle 2 Callee local busy 3 Callee toll busy 4 Telephone key blocked Callee busy or telephone key blocked Automatically checking calling number 5 Called number is an unallocated number Called number is an unallocated number Test call 6 Standby Callee idle. It indicates the originating call service type. Backward group B signaling z Backward group B signaling is also called KB signaling. Table 7-13 Forward group II signaling and backward group B signaling Forward group II signaling (KD) Backward group B signaling (KB) Contents of KB signaling KD code KB code Contents of KD signaling 1 Semi-automatic call of a toll attendant 2 Automatic toll call. It is used. SoftX3000 IP MAN H.248/IUA UMG8900 UMG8900 R2 R2 PBX Exchange POTS POTS POTS POTS Figure 7-2 Typical application of R2 signaling in NGN The UMG8900 provides the interconnection between R2 trunks and the exchange and PBX. It packages the R2 message in the H.248/IUA H.2 Application of R2 Signaling Figure 7-2 illustrates the typical application of R2 signaling in NGN.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling Role of KD signaling Originating call service type KD code Whether attendant can break in local call Yes Whether toll attendant can break in No 2 Automatic toll call – √ 3 Urban call – √ 4 Urban fax or data – √ 5 Automatically checking calling number – 6 Test call – Yes – No √ √ – √ – – –√ – – – √ 7.248 message and sends the R2 7-2 . and ABCD is the user number.3 Basic Signaling Flow Figure 7-3 takes the connection process of a local call as an example to introduce the basic flow of R2 signaling.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling message to the Soft3000. Transit office Originating office Terminating office Occupy Occupation acknowledge P A1 Q A1 R A1 A A1 B A1 C A1 D Occupy Occupation acknowledge P A1 Q A1 R A1 A A1 B A1 C A1 D A3 A3 KD=3 KD=3 KB=1 KB=1 Answer Answer Talk Caller hooks on Callee hooks on Idle Caller hooks on Callee hooks on Idle Figure 7-3 Signaling process of a local call In Figure 7-3. thus implementing the interworking between NGN and the exchange and PBX in PSTN. the called number is PQRABCD. in which PRQ is the office directional number. After the transit office receives PQR 7-3 . 7. The figure shows that line signaling and register signaling are sent segment by segment. the originating office waits for the terminating office to send the A3 signal. 7-4 . This connection mode takes a long time. Therefore. After sending the full number. and then completes the signaling flow.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 7 R2 Signaling completely. it is used when the transmission line is of a poor quality. it starts routing to send register signaling of the originating office. and network layer . Intra-network higher layer (layers 4 to 7 of model OSI) functions required by some supplementary services can be implemented inside ISDN or provided by an independent service center. non-switching connection. data link layer. Circuit switching capacity TE User-network interface Packet switching capacity ISDN switch ISDN switch User-network interface TE Non-switching capacity Common channel signaling capacity Figure 8-1 Structure of ISDN 8.of the open systems interconnection (OSI) model.1. including circuit switching. The model is an abstract arrangement of the user-to-network interface standardized by CCITT (ITU) regulations. 8-1 .2 Basic Concepts I. It offers reference points to be standardized and functional groups related to the reference points. and common channel signaling. Normally. Reference Points and Functional Group The reference configuration (reference model) of the ISDN user-to-network interface is shown in Figure 8-2. The terminal equipment (TE) of ISDN is connected through the standard user-to-network interface. a network only provides functions of lower layers—physical layer. The basic structure of ISDN is shown in Figure 8-1. packet switching.1.1 DSS1 Signaling 8.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Chapter 8 DSS1 Signaling and V5 Protocol 8.1 Overview of DSS1 Signaling ISDN features multiple capabilities. There are three types of reference points: the U reference point. also called the U interface.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol S T U NT2 TE1 NT1 Transmission line R TE2 S TA Reference point Functional group Figure 8-2 Reference configuration for ISDN user-to-network interfaces Reference point In Figure 8-2. A cross is a conceptual reference point for dividing functional groups. Comparing the reference model to the actual application. crosses stand for physical interfaces between device units. The BRA U interface determines the transmission line code. z U reference point The U reference point. but not the line interface between the network and the primary rate access (PRA) user. In the user accessing. the U interface is the line interface between the network and the ISDN basic rate access (BRA) user. The U interface uses the original analog subscriber line (ASL). For the implementation of multiple functional groups combined in one device. This code indicates that the line transmission uses four levels. One way for reducing transmission attenuation is to reduce the line transmission rate. S/T reference point and R reference point. you need to reduce transmission attenuation. reference points between functional groups exist only conceptually. The physical interfaces cannot be observed. to transmit a 2-bit binary code with one level. is the line interface between the network and the user. that is. each level being a combination of two bits. we regard that the E1 line in the PRA application as the U interface in Figure 8-2. Correlation between binary codes and line levels: Binary code Line level 00 –3V 01 –1V 10 +3V 11 +1V 8-2 . The transmission line code adopted by the U interface in China is 2B1Q. crosses stands for reference points. According to the regulations of ITU. To transmit digital signals through twisted pairs. binary bit “0“ is converted to level 0. If the NT2 device does not exist. The line code is a pseudo-AMI (alternate mark inversion) code. binary bit “1” is converted to positive pulse or negative pulse. When the 2B1Q line code is used. thus reducing the transmission attenuation. also called S/T interface. is the line interface between network terminal type 1 (NT1) and network terminal type 2 (NT2). The bandwidth allocation is described in Table 8-1. also called S interface. The S/T interface uses a four-line transmission mode. is the line interface between the ISDN terminal (terminal equipment type 1 (TE1) or terminal adaptor (TA)) and the network terminal (NT).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol In this way. two lines for sending and two lines for receiving. Figure 8-3 illustrates the correlation between a binary code and an AMI code. the line element rate (baud rate) is 80 kbit/s. The T reference point. the line rate is reduced by half compared with the binary code rate. In AMI code. In the ITU regulation. also called T interface. the specifications of the S interface is the same as that of the T interface. Binary code 1 0 0 1 1 1 0 1 0 1 AMI code Sending direction Figure 8-3 Correlation between a binary code and an AMI code z R reference point 8-3 . Table 8-1 Bandwidth allocation in the 2B1Q line code mode Channel z Rate (bit/s) Function 2B channel 128 k Traffic channel D channel 16 k Signaling channel M channel 40 k Transmitting the maintenance information between the network and the terminal Used for U interface synchronization 12 k Transmitting clock information S reference point and T reference point The S reference point. which alternate forward and backward. S and T together form S/T reference point. and the corresponding bandwidth is 160 kbit/s. Functional group In Figure 8-2. z NT1 NT1 provides U interfaces and S/T interfaces for connecting ISDN terminals and devices of the ISDN exchange. is a non-standard ISDN terminal interface. for example. In application. Note: If the NT1 includes the function of the TA. the 2B1Q/AMI code conversion in the Chinese standard.but it has the line maintenance and performance monitoring functions. z Terminal equipment type 2 (TE2) TE2 is a non-standard ISDN terminal without S interfaces. IEEE-488 interface. with standard S interfaces. A functional group is the combination and arrangement of functions required on ISDN user interfaces. The role of the TA is for rate adaptation and protocol conversion. and video phones. and a LAN router. The non-standard ISDN terminal (TE2) does not have the 8-4 . also called R interface. ordinary telephone sets. NT1 is purely a physical layer device without software intelligence.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol The R reference point. It can be connected directly with the NT1 or NT2 through S interfaces. X 25 packet terminals and G3 fax machines. An S interface can be connected to the TE2 through a terminal adapter (TA). and an interface for connecting a non-standard ISDN terminal on the other end. z TE1 The TE1 is a standard ISDN terminal. a number of functional groups may be implemented in one device. it is called NT1+. It cannot be directly connected with the NT1 or NT2. The function of NT1 is the code conversion between the U interface and S/T interface. G4 fax machines. RS-232 interface. A common NT2 device can be a terminal control device such as a private automatic branch exchange (PABX) that has the functions of ISDN. z TA There is an S or U interface on one end of the TA. and analog telephone interface. It ensures the clock synchronization of the ISDN terminal and network. for example. z NT2 NT2 is an intelligent terminal device. blocks stand for functional groups. Common TE2 devices include PCs. Common TE1 devices include ISDN digital telephone sets. the AT command is converted to D channel signaling. packet switching and semi-permanent connection (SPC). In other words. 8-5 . It can be connected with the S or U interface only after the rate adaptation and protocol conversion with the TA. Some TAs contain the built-in AT command set. demand channel (D channel) and H channel. PRA (30B+D) and ISUP. III. It includes bearer channel (B channel). The AT command set is a general command format for operating on the Modem on a computer. The B channel protocol of the TA is V.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol function of the common channel signaling (D channel). ISDN Interface The ISDN interface falls into three types: BRA (2B+D).110. According to the number of B channels supported by D channels. z BRA interface BRA is short for the basic rate interface/access (BRI/BRA). It is specified when the ordinary subscriber line in PSTN is used as the ISDN subscriber line. ISDN Channel The ISDN channel type refers to the channel path type of the user-to-network interface. It converts the low-speed serial port data to the data with the speed of 64 kbit/s to enter the B channel. It supports two 64 kbit/s user channels (B channel) and one 16 kbit/s signaling channel (D channel). II. images and data) at a rate over 384 kbit/s. data and images) at the rate of 64 kbit/s. It can implement circuit switching. It enables the non-standard ISDN terminal to communicate with the network through a standard ISDN interface. It supports call originating and answering on a computer. Table 8-2 Bandwidth allocation in the 2B1Q line code mode Channel z Rate (bit/s) Function D16 16k D channel in 2B+D D64 64k D channel in 30B+D H channel The H channel is for transmitting user information (including stereo programs. the user can make calls and transmit data simultaneously through a computer. D channel z The D channel transmits signaling messages and packet messages for circuit switching. With a TA. D channels are divided into 2B+D and 30B+D. It has a rate of 144 kbit/s. B channel z The B channel is used for transmitting user information (including voice. Only the authorities for sub-address numbers need to be registered. The physical channel of the PRA interface is provided by the digital trunk module (DTM). Each DSL can provide eight BRA interfaces. When the ISDN-PC communicates with the network. The subscriber line is a coaxial cable that can meet the requirement of users with heavy traffic. T1=24TS) divided by the PCM system. the primary rate interfaces/accesses (PRI/PRA) are classified into the 30B+D interfaces (China and Europe) and the 23B+D interfaces (North America and Japan). The board type must be set to “PRA” during hardware data configuration. It supports thirty 64 kbit/s user channels (B channels) and a 64 kbit/s signaling channel (D channel). it can occupy two B channels at the maximum rate of 128 kbit/s. The 30B+D interface is the PRA interface in China with a rate of 2048 kbit/s. SUB1=1 SUB1=2 N1=6600000 SUB1=3 S/T¿Ú 2B+D subscriber line SUB1=4 NT1 N1=6600000 N2=6600001 SUB1=1 SUB1=2 SUB1=3 N2=6600001 SUB1=4 Figure 8-4 ISDN subscriber number and sub-address z PRA interface According to different gaping (E1=32TS. Sub-addresses are set on terminals. The PRA interface can be connected to the PABX that has the functions of ISDN. It can also provide channels for video conference users to transmit high quality pictures. the eight ISDN terminals attached to the 2B+D interface can call another terminal in the “subscriber number + sub-address” mode. On the network side. z ISUP interface 8-6 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol The BRA interface is provided by the digital subscriber line board (DSL) of the optical network unit (ONU) or remote subscriber processor (RSP) under the UMG8900. Two subscriber numbers must be allocated to a BRA interface on the network side and set on the terminal. As shown in Figure 1-6. Each PRA board provides two 30B+D PRA interfaces. sub-address numbers need not be set. or Internet interim inter-switch signalling protocol (ISP) system. One BRA interface can be connected with eight ISDN terminals at most. Each subscriber number can have four sub-addresses (1–4 digits) at most. It allows two telephones (each occupying a B channel) and a packet terminal (occupying the D channel) to communicate with the network simultaneously. a LAN. For the DSS1 signaling system. SoftX3000 IP MAN H. this document introduces only the PRI.3 Application of DSS1 Figure 8-5 is a typical application of DSS1 signaling in NGN.248/IUA H. It transparently transmits Q.248/IUA UMG8900 UMG8900 PRI PBX RSP BRI ISDN PRI NAS BRI POTS ISDN POTS PBX and NAS devices ISDN 2B+D access Figure 8-5 Typical application of DSS1 in NGN The UMG8900 provides the BRIs and PRIs specified in ISDN User to Network Interface Specifications. 8-7 .Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol The ISDN user part (ISUP) interface is needed for enabling the ISUP circuit between two exchanges. 8.931 signaling to the SoftX3000 through ISDN Q. For the BRI.921 messages.921-User Adaptation Layer (IUA) to implement the following ISDN services: z Providing BRIs for the accessing of ordinary ISDN users (2B+D). refer to relevant standards. for processing Q. z Providing PRIs for accessing PABXs and network access servers (NAS).1. 4 Protocol Structure of DSS1 DSS1 signaling has three layers: physical layer. Router) Functional group TA: Terminal adaptor Figure 8-7 Reference configuration of ISDN user-to-network interfaces The meanings of the B channel and D channel supported by the PRI: B channel: bearer channel of the user information with the rate of 64 kbit/s. network planning and acceptance test of the user-to-network interface. operation and maintenance. packet switching and SPC. Figure 8-6 illustrates the correlation between DSS1 signaling and the OSI reference model. used for carrying voice and data for circuit switching. data link layer and call control layer. It provides the technical basis for the interconnection. For example. PBX. It has the same rate as the PCM primary 8-8 . LAN. R TE1 R TE2 T U NT1 NT2 Transmission media S TA TE1: Standard ISDN terminal Reference point TE2: Non-standard ISDN terminal NT1: Network terminal type 1 NT2: Network terminal type 2 (For example.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol 8. equipment design. The PRI physical channel is in the PCM structure. Layers 4-7 Call control layer Layer 3 Data link layer Layer 2 Physical layer Layer 1 DSS1 signaling OSI reference model Figure 8-6 Correlation between DSS1 signaling and the OSI reference model I.1. the reference configuration of the PRI is shown in Figure 8-7. D channel: bearer channel of the signaling information with the rate of 64 kbit/s. used to transmit the signaling information and packet data information of circuit switching. Physical Layer The physical layer specifies the procedure and electrical and functional features of the ISDN user-to-network interface. Delimitation. Error recovery after the transmission. Management of the activation of the physical layer. These functions support the basic call control program and the call control program related to supplementary features provided by the network. These functions include: 8-9 . the call control layer provides functions for establishing and operating on network connections to users. With the functions and services provided by the data link layer. Discrimination of data link connections depending on the data link connection identifier (DLCI) contained in each frame. III. The LAPD protocol defines rules for the layer 2 entity on the user-to-network interface to exchange information through the D channel.3-1997). and TS16 for signaling transmission. and the frame structure. TS0 is used for frame synchronization and error control. each frame is divided into 32 basic time slots. II. Data Link Layer The data link layer specifies the specification attributes of the data link layer of the ISDN user-to-network interface (PRI). procedure. The PRI can use twisted pairs as the transmission media. It also specifies the process of message exchange on the D channel. between the NT2 and an exchange. namely. Therefore. LAN and a router). In the 30/32 channels of PCM. or between the TE and an exchange. keeping and removing network connections on the ISDN user-to-network interface. Performing flow control. The layer 2 entity may exchange information between the TE and the NT2 (such as PABX. Sequence control for keeping the sequence of frames connected through data links. Checking of the transmission and format of and operation onto data link connections. format and operation check. LAPD is to provide means of information transmission between combinations of data link connection ends. Functions of LAPD are as follows: Providing data link connections on one or more D channels. location and transparent transmission of frames. These specification attributes include the concept and terms of the data link layer protocol. procedure element and field format of the data link layer protocol under normal operation. 2048 kbit/s. hence allowing recognizing a string of bits sent on the D channel in the form of a frame. refer to ISDN User to Network Interface Specifications – Part 2: Technical Specifications on Data Link Layer (YDN 034. Call Control Layer The call control layer specifies the procedure for establishing. the data link layer protocol accesses the LAPD protocol through the link on the D channel. For details.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol rate. On the ISDN user-to-network interface. Notifying the management entity of unrecoverable errors. Generating and translating layer-3 messages for intra-layer communication. 8-10 . For details. Network connection control. Routing and trunks. Managing the timer and logical entity used in the call control program. The communication is realized by exchanging messages on the D channel. Error recovery.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Processing the primitive used for the communication with the data link layer. and the logical path of the packet layer (for example. Error checking. Managing accessing resources.932 is illustrated in Figure 8-8.3-1997. 8. Each message has a common part. Multiplexing of network connections. It is produced and processed by the call control layer. and the compatibility between the lower layers and the higher layers). X. Restart.1. The call control layer message consists of a number (an integer) of bytes. including the B channel. Transmitting information between the network and the user. address.5 Call Control Message The Layer 3 (call control layer) entity of the user side needs to communicate with the Layer 3 entity of the network side for call control.931/Q. the bearer capacity. and carried and transmitted by the data link layer. and optional or mandatory information elements. Blocking control and user data stream control.25 recommendations). The format of the call control layer message specified by the recommendations of ITU-T Q. Ensuring the consistency between the provided services and the services required by the user (for example. Sequencing. The call control layer message is composed of data blocks of different lengths. refer to ISDN User to Network Interface Specifications – Part 3: Technical Specifications on Basic Call Control of Layer 3 YDN 034. The value of the Q.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System 8 7 6 5 Chapter 8 DSS1 Signaling and V5 Protocol 4 3 2 1 1 byte Protocol discriminator Common part 0 0 0 0 Length of call reference value 2 bytes at most FLAG Call reference value 0 Optional or mandatory information elements 1 byte Message type 1 byte Other information elements Other information elements Figure 8-8 Format of ITU-T Q. and that on the terminating side is always set to 1. The eighth byte of the second eight-byte set is the call reference flag. The call reference flag identifies the end of the layer 2 logical link to send the call reference value. The value of the flag is 0 or 1. call reference values are unique on the originating side. two calls of different directions can have the same call reference value. The call reference value is allocated by the call originating interface. the call reference value can be re-allocated to a new call. II. They are allocated at the start of calls and kept till the end of these calls (except in the cases of call suspension). The sole purpose of the call reference flag is to solve the problem of two ends attempting to allocate the same call reference value at the same time. The call reference flag is also applied when using the global call reference (for example. Protocol Discriminator The protocol discriminator separates the call control message from other messages on the user-to-network interface. After the end or successful suspension of a call. to restart a program). Call reference value does not have the meaning of overriding ISDN from end to end. Call Reference Value The reference identifies calls involved by messages or facility registration/un-registration requests on the local user-to-network interface. 8-11 .931 call control layer message fixedly is 00001000. The length of the protocol discriminator is one byte. On layer 2 logical links of a same D channel.931 messages The common part consists of three sub-parts with the format identical with that of all messages. I. Inside the layer-2 logical link connection of a specific D channel. The call reference flag on the originating side is always set to 0. The message part is the third part of a message. The coding of different types of messages is described in Table 8-3. Call control layer messages of Q. Table 8-3 Types of call control layer messages of Q.931 are classified into four types: messages for call setup.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol III. and other messages. and its length is one byte. messages used at the call information stage. Message Type Message types identifies messages that are being sent. They include different information elements. messages for call clearing. Bit 8 is reserved for future expansion.931 Message code Message type 0000 0001 ALERTING 0000 0010 CALL PROCEEDING 0000 0111 CONNECT 0000 1111 Messages for call setup CONNECT ACKNOWLEDGE 0000 0011 PROGRESS 0000 0101 SETUP 0000 1101 SETUP ACKNOWLEDGE 0010 0110 RESUME 0010 1110 RESUME ACKNOWLEDGE 0010 0010 0010 0101 Messages used at the call information stage RESUME REJECT SUSPEND 0010 1101 SUSPEND ACKNOWLEDGE 0010 0001 SUSPEND REJECT 0100 0101 DISCONNECT 0100 1101 RELEASE 0101 1010 Messages for call clearing RELEASE COMPLETE 0100 0110 RESTART 0100 1110 RESTART ACKNOWLEDGE 0111 1011 INFORMATION 0110 1110 0111 1101 NOTIFY Other messages STATUS 0111 0101 STATUS ENQUIRY 8-12 . 6 Basic Signaling Process The following takes the process of the simplest call control with circuit switching as an example to describe the basic signaling process of DSS1. If ISUP is used as the signaling protocol between the originating and terminating offices. The message is transmitted on an established data link. Suppose both the calling end and the called end use ISDN terminal devices. the process of a typical call is illustrated in Figure 8-9. the network entity of layer 3 checks whether the called address is complete. Call Setup Process A call request is sent in the form of the SETUP message. If it is complete. Calling terminal Originating ISUP office Terminating office TEx Called terminal TEy SETUP SETUP ACK INFO INFO IAM SETUP CALL PROC ALERT ALERT ACM ALERT CONN ANM CONN CONN ACK CONN ACK REL REL COMP Conversation or data Caller hooks on first DISC(cause value=16) REL REL COMP REL DISC(cause value=16) RLC REL REL COMP DISC(cause value=16) REL DISC(cause value=16) REL REL RLC REL COMP Caller hooks on first REL COMP Figure 8-9 Basic signaling process of DSS1 (circuit switching) I.1. When the SETUP message reaches the network side of the originating office.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol 8. the originating office returns the CALL PROCEEDING message to hold the caller 8-13 . Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol waiting. These terminals will check whether they meet the content requirements of the SETUP message. When the originating office sends the REL message to the terminating office. indicating the completion of call release. whether the lower layer and higher layer protocols are consistent. The caller sends the INFORMATION message to provide the remaining information. and at the same time sends the CONNECT ACK message to the responding called terminal. including the bearer service capacity. The caller sends the DISCONNECT message (cause value = 16) to the originating office. The terminating office returns the RLC message. Therefore. the B channels selected by both exchanges are connected. there are several terminals having the information compatible with the SETUP message. The following case is possible. In this example. The terminating office sends the first ALARTING message to the originating office. If the called address is incomplete. II. it sends the SETUP message to the callee. the SETUP message is transmitted on the broadcast data link (TEI = 127). the call must go through another exchange before being connected to the callee. the originating office returns the SETUP ACK message to request subsequent information. It also contains the subscriber information channel selected by the terminating office. the originating office exchange must send a message containing the call-related information to the terminating office exchange through SS7 signaling (ISUP). On the basic interface of the callee. whether their terminal types match that of the calling terminal. Call Release Process The call release process with the caller hooking on first is as follows. and whether the sub-address (if there is one) is conformant. and end-to-end information. it immediately sends the CONNECT message to the network. these terminals simultaneously return the ALERTING message to the network and send the ringing tone to the callee. After the originating office receives the message. When the originating office network side receives the complete address information. the calling terminal sends the ringback tone (or displays the ALARTING information) to the caller. it also responds to the calling terminal with the RELEASE message to disconnect the 8-14 . it notifies the exchange for routing and resource allocation. Then. all the terminals connected to the passive bus receive the SETUP message. For example. When the terminating office receives this message. whether they have the same bearer service features as the message. When a called terminal responds to the call. The circuit connection is set up between the caller and the callee and the circuit is ready for transmitting subscriber information. The SETUP message contains all the information sent by the originating office. Therefore. The exchange of the terminating office transfers the CONNECT message to the caller side. it sends the REL message to the terminating office to disconnect the inter-office circuit. terminal lower layer and higher layer attributes. For a call. Then. When the ALARTING message finally arrives at the calling terminal. It is used for connecting the local exchange (LE) and the access network (AN). European Telecommunications Standards Institute (ETSI) issued V5 interface standards to perfect the interface and make it widely applicable.2. DSS1 call control messages on the user-to-network interface are the same as the above.2. high equipment cost and the development need of digital services that were characteristic of analog connection. In view of the importance of the V5 interface and the development urgency of the access network. the V5 interface standards have been reviewed and revised for times.1 (G. The terminating office returns the RELEASE COMPLETE message to the callee. In China. the following two documents are implemented: z Technical Specifications on V5. ITU-T adopted V5 interface specifications by using an expedited program. Now. V5. z Technical Specifications on V5. It supports analog telephone accessing and 64 kbit/s–based ISDN basic accessing. In the 1990s. These specifications include V5. These types of access have the assigned bearer channel allocation capacity. Basic Contents of V5 Interface The V5 interface is one between the access network and an exchange. indicating the completion of disconnection. including V5.1 Interface between Local Digital Exchange and Access Network (YDN 020-1996).1 Basic Concepts I. User ports correspond to bearer channels one by one. For the call release process with the callee hooking on first. Therefore. that is. The calling terminal returns the RELEASE COMPETE message.1 consists of a 2048 kbit/s link. In 1993. This is to solve the problems of poor transmission performance.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol inter-office circuit.2 V5 Protocol The V5 interface comes into being with the development of the access network. Refer to Figure 8-9 for an analysis. Bell Labs changed the analog interface connection between an exchange and devices to the standard digital interface connection (TR303 interface). it sends the DISCONNECT message (cause value =16) to the called terminal. The called terminal responds with the RELEASE message to disconnect the circuit between the caller and the terminating office. the call is completely released.964) and V5. It is a service node interface (SNI). After the terminating office receives the REL message from the originating office. the correlation between user ports and bearer channels is fixed.2 Interface between Local Digital Exchange and Access Network (YDN 021-1996). Now.1 and V5. 8.965).2 (G. indicating the completion of disconnection. 8. there is 8-15 . 2 interface Only one E1 link One to sixteen E1 links available No Bearer Connection Control (BCC) and user line concentration. z The layer 2 data link carrying the link control protocol.2 interface.1 and V5. They may be used in multiples of 64 kbit/s channels in order to facilitate certain ISDN services.1 interface V5. Communication path (C path): any one of the following information types: z The layer 2 data link carrying the control protocol.2 have the flexible and call-based dynamic bearer channel allocation capacity. E1 time slots directly correspond to user terminals. V5. on demand. managing only a single link Having link control protocol. Table 8-4 Differences between V5. and fault link switching protection No link control protocol. Not supporting ISDN-PRA Supporting ISDN-PRA No protection protocol. V5.2 is widely used between the access network and the exchange. line concentration capacity exists within the AN and on the V5. Table 8-4 lists the differences between V5. II. ISDN-PRA user ports. Therefore.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol no line concentration capacity within the AN. BCC protocol: a protocol which allows the LE to instruct the AN to allocate bearer channels.2 consists of one to sixteen 2048 kbit/s links. Instead. no fault link switching protection Having protection protocol.1 uses one time slot (TS16) to transmit signaling.2 interface reserved for it. In other words.1 and V5. It can support ISDN PRA besides those access types supported by V5. Having BCC and user line concentration. V5. Pre-connection bearer channel: any bearer channel or multiples thereof. user ports correspond to bearer channels dynamically. or PCM encoded 64 kbit/s channels from PSTN user ports. leaving the other time slots (except TS0) to transmit the voice signal. Connections between E1 bearer channels and user terminals are dynamically allocated.1. p.and f-type data). The access types supported by V5.2. either singly or in multiples. managing multiple links Due to its limitation. 8-16 . Common Terms Bearer channel: used to provide the bi-directional transmission capability for allocated B channels from ISDN-BRA user ports. The following is an introduction to V5.2 V5. ISDN D channel information: ISDN D channel information is defined as the D channel information from basic or primary rate access user ports (including Ds-.1 is rarely used now.2. V5. set up using the BCC protocol in order to provide switched services within the AN over bandwidth reserved on the V5. Multi-link: a collection of more than one 2048 kbit/s link which together make up a V5. Once it is used to carry a logical C channel. also the C path for the control protocol. z All the ISDN packet data (p-type) from one or more user ports. and the BCC protocol. Communication channel (C channel): a 64 kbit/s time slot on a V5. but is used for the protection of logical C channels.2 interface which has been assigned for carrying logical C channels. Protection group: a group of (N + K) physical C channels. in order to supply a higher bit-rate service. An active C channel becomes a standby C channel when it is not carrying a logical C channel. each allocated to a different logical C channel. Multi-slot: a group of more than one 64 kbit/s channels providing 8 kHz and time slot sequence integrity. Active C channel: a physical C channel which is currently carrying a logical C channel. z All the ISDN D channel signaling data (Ds-type) from one or more user ports. where K is the number of physical C channels which act as standby C channels for the N logical C channels. on V5. z The layer 2 data link carrying the BCC protocol. 8-17 . all of different types. acts as the standby C channel for the control protocol. link control protocol. z All the ISDN frame relay data (f-type) from one or more user ports. Standby C channel: a physical C channel which is not carrying a logical C channel.2 interface whose physical C channel in time slot 16 carries a C path for the protection protocol and. on V5.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol z The layer 2 data link carrying the PSTN signaling.2 initialization. link control protocol. a standby C channel becomes an active C channel. but excluding the C path for the protection protocol.2 interface whose time slot 16 carries a C path for the protection protocol and.2 initialization. It should be noted that this definition includes the possibility that there is more than one C path of the same information type. Primary link: the 2048 kbit/s link on a multi-link V5. A physical C channel may not be used for carrying bearer channels.2 interface. and BCC protocol and any other C paths initially carried in TS16 of the primary link. Time slots 16 of the primary and secondary links (only on a V5.2 interface provisioned to carry communication paths. Physical communications channel (physical C channel): a 64 kbit/s time slot on a V5. Logical communications path (logical C channel): a group of one or more C paths.2 interface with more than one 2048 kbit/s link) are always physical C channels. Other C paths can also be carried in TS16. Secondary link: the 2048 kbit/s link on a multi-link V5. z The layer 2 data link carrying the protection protocol. generally used together within an ISDN-PRA user port. or PCM encoded 64 kbit/s channels from PSTN user ports. BCC protocol: used to allocate bearer channels under the LE control. Control of the 2048 kbit/s link: managing the framing. Service-required multi-slot connection: provided on a 2048 kbit/s link in the V5.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol III. multi-frame locating. always with 8 kHz and time slot sequence integrity. p. Control for supporting common functions: providing the capability of the synchronous application and restart of assigned data. Control of layer 2 links: providing the bi-directional transmission capability for control and PSTN information. Link control protocol: defining the management function that supports 2048 kbit/s links on the V5.2 interface.2 interface. Functions of V5. User port control: providing the bi-directional transmission capability for the status and control information of each user port.and f-type data) of the ISDN-BRA and ISDN-PRA use ports. This timing information can also be used to synchronize the LE and AN in the work state.2 interface. ISDN D channel information: providing the bi-directional transmission capability for the D channel information (including Ds-. PSTN signaling information: providing the bi-directional transmission capability for the signaling information of PSTN user ports.2 Interface Figure 8-10 illustrates the functions of the V5. alarm indication and cyclic redundancy check (CRC) information of the 2048 kbit/s link. 8-18 . Bearer channel ISDN D-channel information PSTN signaling information Control information AN Link control information LE Protection information BCC information Timing Figure 8-10 Functions of the V5 interface Functional requirements of the V5 interface: Bearer channel: used to provide the bi-directional transmission capability for allocated B channels from ISDN-BRA and ISDN-PRA user ports. Timing: providing timing information necessary for bit transmission. byte identification and frame synchronization. SoftX3000 IP MAN H.921 messages. provides the V5 interface for accessing the standard V5 access network. 8.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Protection protocol: defining logical C channels that support switching between applicable physical C channels. 8. and transparently transmits Q.248/V5UA UMG8900 V5 ONU BRI POTS ISDN V5 access network Figure 8-11 Typical application of the V5 protocol in NGN The UMG8900 processes Q.931 messages to the SoftX3000 through V5UA.2 Interface Figure 8-12 illustrates the protocol structure of the V5.2.2.2 interface. 8-19 .2 Application of V5 Protocol Figure 8-11 illustrates the typical application of the V5 protocol in NGN.3 Protocol Structure of V5. 703 recommendations.and f-type date L2 Map function Q.2 interface is mentioned in terms of the logical C channel.2 interface (LAPV5) is based on that of the Link Access Procedure on the D channel (LAPD) protocol specified in Q. II. z Delimitation.931 layer LAPV5-DL PSTN ProtectionLink Q. Data Link Layer The data link layer (layer 2) of the V5. z Sequence control for keeping the sequence of frames connected through data links. For example: z Bit rate: 2048 kbit/s ± 50 ppm. location and transparent transmission of a frame. The V5. thus implementing the physical connection between the AN and LE. frequency offset of the AN ≤50 ppm. maximum offset against the nominal frequency ≤ 1 ppm. 8-20 . z Synchronization: pull-in range of the AN clock ≥ 1 ppm.931 BCC Control protocolprotocol control protocol LAPV5-DL Q. The specifications and procedure of the layer 2 protocol of the V5.921 recommendations.2 interface is composed of one to sixteen 2048 kbit/s links.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol AN LE PSTN Protection Link Control BCC protocol protocol protocol control Network Q. In the free work mode. The electrical and physical attributes of all 2048 kbit/s links must conform to relevant regulations of G. The functions of LAPV5 are as follows. z Impedance: 75-ohm coaxial (out of balance) or 120-ohm twisted pair (balanced).2 interface can provide bi-directional bearer channels for transmitting all kinds of service information and control information. in the work mode.921 Physical D16/64 layer Map function PSTN ET/L2 AN frame relay LAPV5-EF LAPV5-EF TE LC D16/64 C64 C64 Note: excluding the function of the AN terminating at AN_FR Figure 8-12 Protocol structure of the V5.2 interface I.921 (Note) Data link layer p. z Code: HDB3 code. LAPV5 allows flexible multiplexing of different information streams to C channels to support different service types. Physical Layer The physical layer of the V5. and the congestion control on the V5.2 interface is composed of multiple links. The user port control protocol defines the status indication and control (blocking control and activation control) of user ports. It does not control the call flow of the AN. z Notifying the network layer of unrecoverable errors. used to support the ISDN D channel information. z Congestion control. used to identify the protocol type of data frames. Instead. 8-21 . Call control is still a role of the LE. LAPV5 is used for the transmission of information between the AN and LE. Control protocol (common control and user port control) There are two types of control protocol: common control protocols and user port controls. The common control protocol defines the implementation of the V5 interface re-assignment and restart. and translates part of the analog status signals to be reported to the LE through the V5 interface.2 interface. including the control of ISDN-BRA user ports. there must be link identification and link blocking functions. and frame relay sub-layer (AN-FR). Network Layer The network layer (layer 3) of the V5.2 interface is application-oriented. format and operation check. z Error recovery after the transmission. III. It can implement different protocol functions with the services provided by layer 2. such as end-to-end flow control. used to describe the protocol information of data frames. These functions are realized through the link control protocol. z Managing the blocking of layer-1 links and assisting in link unblocking. and fulfills the functions such as the verification of variables and interface IDs and the unblocking of user ports. while the AN transparently transfers the address signals of analog user ports and most line signals. These protocols include: PSTN protocol The PSTN protocol is an excitation protocol. it transmits relating analog line information between AN user ports and national protocol entities of the LE. ISDN-PRA user ports and PSTN user ports. The functions include: z The status indication of the first 2048 kbit/s link and the identification of related links. The communication between sub-layers is achieved through the mapping function. data link sub-layer (LAPV5-DL). The LE provides services. Link control protocol Because the V5. It has three sub-layers: encapsulation function sub-layer (LAPV5-EF).Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 8 DSS1 Signaling and V5 Protocol Checking of the transmission and format of and operation onto data link connections. by using the link identification program. one communication path can transmit information related to multiple 2048 kbit/s links. z Layer 3 address (two bytes).2 interface. protection group 2. According to the structure of the V5.2 interface can have sixteen 2048 kbit/s links at most. each message having the following information elements: z Protocol discriminator (one byte).2 protocol. to check whether the two ends of a link are matched (consistent). Each V5. z The link control for the communication between the AN and LE during the coordination of functions on both sides. consisting of more than one 2048 kbit/s link. The system management requires that protection group 1 be switched through the protection started by the management interface. The protection protocol is used only when the V5. the program switches to another. When a communication path is found faulty during fault detection or after link blocking. The BCC protocol also has an auditing function for checking the allocation and connection of bearer channels within the AN. if a communication path is faulty. the protocol notifies the LE. the BCC protocol is capable of reporting inside-AN faults. z Coordination among link control functions. The V5. For the BCC protocol. In other words. Therefore. it can affect the service of a large number of subscribers. This process is specified by the LE and executed by the AN. If one communication path is faulty. the system management of the LE or AN triggers the protection program.1 interface does not support the BCC protocol. must have protection group 1 and. The program can also be triggered by the operator through the management interface. Protection protocol A V5.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System z Chapter 8 DSS1 Signaling and V5 Protocol Allow the requesting side. 8-22 . it has no line concentration function. 8. control protocol and link control protocol. Therefore.2 interface provides a protection program to enhance the reliability. z Message type (one byte).2 interface bearer channels and user ports.2. BCC protocol The BCC protocol of the V5. If there is a fault affecting the bearer channel connection inside the AN.2 interface is composed of multiple 2048 kbit/s links.4 Layer 3 Protocol Message Layer 3 protocols are message-oriented protocols. it helps realize line concentration. thus realizing the dynamic connection between V5. In addition. if provisioned. The V5. when the communication path concerned is faulty.2 interface is used to assign the bearer channels on certain links to user ports. all user ports are affected. For the PSTN protocol. different protocol discriminators can be used to support different protocols. Layer 3 Address Information Element The layer 3 address information element is used to identify layer 3 entities within the V5. II. The purpose of defining a protocol discriminator is to discriminate it from other protocols that may be transmitted on a same V5 data link. to which the transmitted or received message applies. the last one is to be determined by message type. as shown in Figure 8-13. Layer 3 address (high bit) 1 Layer 3 address (low bit) Figure 8-14 Layer 3 address information element identifying the PSTN port For the control protocol. The protocol discriminator used by the V5 protocol fixedly is 0x48. Protocol Discriminator Information Element The protocol discriminator is used to discriminate those other protocol messages that share the same data link connection with V5 protocol messages. the layer 3 address is used to identify PSTN user ports.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Other information elements determined by requirements (the length to be z determined by information elements).2 interface. but they may be used in the future. Its structure is protocol-dependent. It takes one byte. The protocol discriminator information element is the first part of a message. the layer 3 address information element is used to identify ISDN or PSTN user ports or to indicate the V5 common control function. It always takes two bytes. 8 7 6 5 4 3 2 1 Protocol discriminator Layer 3 address (high level) Layer 3 address (low level) 0 Message type Other information elements Figure 8-13 Format of layer 3 messages of the V5 interface I. The format of layer 3 address is illustrated in Figure 8-14. the first three are the common part. Of the above information elements. The layer 3 address information element is the second part of a message. appearing in every message. The layer 3 address ranges from 0 to 32767. In other words. These protocols are not defined. Figure 8-14 illustrates the format of layer 3 address information element when it identifies the PSTN 8-23 . In the RESET SN COM and RESET SN ACK messages. The source ID in the figure is a one-bit field used to indicate the entity (LE or AN) that builds the BCC reference number. Logical C-channel ID (high bit) Logical C-channel ID (low bit) Figure 8-18 Logical C-channel identification information element Table 8-5 lists the usages of the layer 3 address. this information element has been named the “BCC reference number” information element. 0 0 0 0 0 0 0 0 Layer 3 address (low bit) Figure 8-16 Layer 3 address information element identifying a 2048 kbit/s link For the BCC protocol. for a process created by the AN. Its format is shown in Figure 8-16. The figure shows that the layer 3 address ranges from 0 to 255 when it identifies a link. Figure 8-15 illustrates its format when it identifies the ISDN port or common control (8177) function. For a process created by the LE. the value of the logical C channel identification must be 0. this information element has been named the “logical C channel identification” information element. the field is coded 1.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol port. 8-24 . Its format is shown in Figure 8-18. Layer 3 address (high bit) 0 0 Layer 3 address (low bit) 1 Figure 8-15 Layer 3 address information element identifying the ISDN port or common control function For the link control protocol. this field is coded 0. The figure shows that the value of the BCC reference number ranges from 0 to 8191. The figure shows that the layer 3 address of the ISDN port ranges from 0 to 8175. this information element retains the name layer 3 address although it is used to refer to 2048 kbit/s links. Its format is shown in Figure 8-17. Source ID BCC 0 reference number value (high bit) 0 BCC reference number value (low bit) Figure 8-17 BCC reference number information element For the protection protocol. The figure shows that the value of the logical C channel identification ranges from 0 to 65535. and used for common control 0–32767 8177 BCC protocol BCC reference number BCC protocol process 0–8191 Control protocol Logical C channel ID Identifying logical C channels of the V5. The message type information element is the third part of a message. Message Type Information Element This information element is used to identify the protocol a message belongs to and the function for sending the message.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Table 8-5 Usages of the layer 3 address Protocol type Name PSTN protocol Control protocol Usage Digital value L3 address Identifying PSTN user ports 0–32767 0–8175 L3 address Identifying ISDN user ports and PSTN user ports. Table 8-6 is the allocation table of message type codes.2 interface 0–65535 Link protocol 2048 kbit/s link ID Identifying V5. Table 8-6 Allocation table of message type codes Protocol type Scope of message type codes PSTN protocol 0–15 Control protocol 16–23 BCC protocol 24–31 Protection protocol 32–47 Link control protocol 48–55 Table 8-7 lists the codes of the message type field.2 interface links 0–255 control III. It takes one byte fixedly. Table 8-7 Structure of V5 protocol message type codes Bit 8 7 6 5 4 3 2 1 Hexade cimal Protocol message type This bit is 0 fixedly 0 0 0 - - - - PSTN protocol message type 0 0 0 0 0 0 0 0x00 ESTABLISH 0 0 0 0 0 0 1 0x01 ESTABLISH ACK 0 0 0 0 0 1 0 0x02 SIGNAL 0 0 0 0 0 1 1 0x03 SIGNAL ACK 8-25 . Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Bit 8 7 6 5 4 3 2 1 Hexade cimal Protocol message type This bit is 0 fixedly 0 0 0 1 0 0 0 0x08 DISCONNECT 0 0 0 1 0 0 1 0x09 DISCONNECT COMPLETE 0 0 0 1 1 0 0 0x0C STATUS ENQUIRY 0 0 0 1 1 0 1 0x0D STATUS 0 0 0 1 1 1 0 0x0E PROTOCOL PARAMETER 0 0 1 0 - - - 0 0 1 0 0 0 0 0x10 PORT CONTROL 0 0 1 0 0 0 1 0x11 PORT CONTROL ACK 0 0 1 0 0 1 0 0x12 COMMON CONTROL 0 0 1 0 0 1 1 0x13 COMMON CONTROL ACK 0 0 1 1 - - - 0 0 1 1 0 0 0 0x18 SWITCH-OVER REQUEST 0 0 1 1 0 0 1 0x19 SWITCH-OVER COMMAND 0 0 1 1 0 1 0 0x1A OS SWITCH-OVER COMMAND 0 0 1 1 0 1 1 0x1B SWITCH-OVER ACK 0 0 1 1 1 0 0 0x1C SWITCH-OVER REJECT 0 0 1 1 1 0 1 0x1D PROTOCOL ERROR 0 0 1 1 1 1 0 0x1E RESET SN COMMAND 0 0 1 1 1 1 1 0x1F RESET SN ACK 0 1 0 - - - - 0 1 0 0 0 0 0 0x20 ALLOCATION 0 1 0 0 0 0 1 0x21 ALLOCATION COMPLETE 0 1 0 0 0 1 0 0x22 ALLOCATION REJECT 0 1 0 0 0 1 1 0x23 DE-ALLOCATION 0 1 0 0 1 0 0 0x24 DE-ALLOCATION COMPLETE 0 1 0 0 1 0 1 0x25 DE-ALLOCATION REJECT 0 1 0 0 1 1 0 0x26 AUDIT Control protocol message type Protection protocol message type BCC protocol message type 8-26 . these information elements are optional or mandatory.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Bit 8 7 6 5 4 3 2 1 Hexade cimal Protocol message type 0 1 0 0 1 1 1 0x27 AUDIT COMPLETE 0 1 0 1 0 0 0 0x28 AN FAULT 0 1 0 1 0 0 1 0x29 AN FAULT ACK 0 1 0 1 0 1 0 0x2A PROTOCOL ERROR 0 1 1 0 - - - 0 1 1 0 0 0 0 0x30 LINK CONTROL 0 1 1 0 0 0 1 0x31 LINK CONTROL ACK Link control protocol message type All other values are reserved. PSTN call flow started by the AN side user Suppose the PSTN user on the AN side is in the pulse dialing mode. PSTN protocol and national protocol. IV. the SIGNAL ACK message returned by the peer end is omitted.2 Interface I. 8. the caller hooks on first. After the completion of the call.2 interface requires the coordination between the BCC protocol. For the coding structure of these information elements. Other Information Elements These information elements can appear in different messages. In the figure. the DTMF signal is received by a dual tone number receiver on the LE side through the bearer channel. According to the grammatical meaning of this message and its application in the protocol.2. They are specific to different protocols.5 Call Control Flow of V5. If the user uses the DTMF dialing mode. 8-27 . PSTN protocol and national call entity. The call flow is illustrated in Figure 8-19. The following takes a PSTN call as an example to describe the flow of the message interaction between the BCC protocol.2 Interface between Local Digital Exchange and Access Network (YDN 021-1996). there is no SIGNAL message sent in the signal flow. Call Flow for the PSTN User Calls of the PSTN user through the V5. The symbol “-“ indicates 0 or 1. refer to Technical Specifications on V5. In this case. the call flow is similar to that when the AN side user is the caller. 8-28 . But the signal sequence and information elements in this call flow established at the call initiation differ from that in the call flow with the AN side user as the caller.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System PSTN user port AN side FE user occupation Hook off Chapter 8 DSS1 Signaling and V5 Protocol (Hook off) LE side ESTABLISH FE establishment Ss=hook-off ESTABLISH ACK ALLOCATION NAT (Hook off) FE establishment acknowledgement FE allocation request Ring ALLOCATION COMP FE allocation complete DT Dialing tone Digit 1 Digit n FE line signal SIGNAL (Line status signal) FE line signal SIGNAL (Line status signal) FE line signal Stop DT Ds=digit FE line signal Ds=digit Ring back tone (from terminal office) Start establishing the call Talk User answers Hook on FE line signal (Hook on) SIGNAL Ds=hook on DISCONNECT FE line signal (Hook on) FE disconnection request Ss=normal polarity DEALLOCATION DISCONNECT COMP Idle DEALLOCATION COMP FE deallocation request FE disconnection complete FE deallocation complete Figure 8-19 PSTN call flow started by the AN side user The PSTN call establishment flow started on the network side If the network side originates a call. the on the AN side is the callee. Figure 8-20 illustrates the signal flow at the call establishment stage for a call originated on the network side. ISDN user port AN side LE side NAT SETUP(B) ALLOCATION(TS1_B1) FE allocation request ALLOCATION COMP FE establishment complete SETUP-ACK or other messages (B1) CONNECT Hook on User answers DICONNECT Disconnect the call RELEASE DEALLOCATION FE deallocation request DEALLOCATION COMP FE deallocation complete Figure 8-21 ISDN call and release started by the AN side user 8-29 . Call Flow for the ISDN User PSTN call flow started by the AN side user Figure 8-21 illustrates the ISDN call flow started by the AN side user. the RELEASE COMP message replaces the SETUP ACK message to cancel the establishment of this call.Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System PSTN user port Chapter 8 DSS1 Signaling and V5 Protocol AN side LE side FE allocation request ALLOCATION Idle ALLOCATION COMP Ring FE establishment Ss=keep on ringing (Keep on ringing) ESTABLISH ACK FE line signal SIGNAL (Hoof off) Hook off FE allocation complete ESTABLISH FE line signal NAT Keep on ringing FE establishment acknowledgement FE line signal indication Ss=hook off Ring back tone Hook off Talk Figure 8-20 PSTN call establishment flow started on the network side II. the protocol-required synchronization procedure is: The allocation of the bearer channel must be completed before sending the SETUP ACK message (a DSS1 message). If the allocation of the bearer channel fails. During the establishment of an ISDN call. Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol Figure 8-21 shows that protocol synchronization is not required for the ISDN call release and the de-allocation of the bearer channel. ISDN user port AN side LE side NAT SETUP(CR1) ALLOCATION(TS1_B1) FE allocation request ALLOCATION(TS2_B2) FE allocation request SETUP(CR2) ALLOCATION COMP(TS1) FE establishment complete SETUP-ACK or other messages (CR1-B1) ALLOCATION COMP(TS2) FE establishment complete SETUP-ACK or other messages (CR2-B2) Figure 8-22 Two ISDN call setup flows simultaneously started at one ISDN user port 8-30 . the sending of the DEALLOCATION COMP message is independent of the order of receiving the RELEASE message. ISDN call setup flows simultaneously started Figure 8-22 illustrates two ISDN call setup flows simultaneously started at one ISDN user port. The figure shows the message interaction between the BCC protocol and the DSS1 protocol. Therefore.