1.3 Basic Control Procedures 1-23.......................................................................1.3.1 Gateway Registration Procedure 1-23...................................................1.3.2 Successful Termination Call Procedure (in the Same MG) 1-24...........1.3.3 Successful Termination Call Procedure (in Different MGs) 1-38...........
4.1 Overview of H.323 4-1..................................................................................4.1.1 What is H.323 4-1................................................................................4.1.2 Definition of Terms 4-1.........................................................................4.1.3 Structure of H.323 Protocol Stack 4-4..................................................4.1.4 H.323 Applications in SoftX3000 4-6...................................................
4.3 H.225.0 Call Signaling Protocols 4-18............................................................4.3.1 Overview of H.225.0 4-18......................................................................4.3.2 H.225.0 Messages 4-19.........................................................................4.3.3 Message Format 4-20............................................................................4.3.4 Information Elements 4-21.....................................................................4.3.5 A typical example of Q.931 message 4-24............................................4.3.6 Basic Procedures 4-27...........................................................................
7.1 Basic Concepts 7-1......................................................................................7.1.1 Line Signaling 7-1................................................................................7.1.2 Register Signaling 7-6..........................................................................
7.2 Application of R2 Signaling 7-15....................................................................7.3 Basic Signaling Flow 7-15..............................................................................
Chapter 8 DSS1 Signaling and V5 Protocol 8-1..................................................
8.1 DSS1 Signaling 8-1......................................................................................8.1.1 Overview of DSS1 Signaling 8-1..........................................................8.1.2 Basic Concepts 8-1..............................................................................8.1.3 Application of DSS1 8-7.......................................................................8.1.4 Protocol Structure of DSS1 8-8............................................................8.1.5 Call Control Message 8-10.....................................................................8.1.6 Basic Signaling Process 8-13................................................................
8.2 V5 Protocol 8-15.............................................................................................8.2.1 Basic Concepts 8-15..............................................................................8.2.2 Application of V5 Protocol 8-19..............................................................8.2.3 Protocol Structure of V5.2 Interface 8-19...............................................8.2.4 Layer 3 Protocol Message 8-22.............................................................8.2.5 Call Control Flow of V5.2 Interface 8-27................................................
Huawei Technologies Proprietary
HUAWEI
U-SYS SoftX3000 SoftSwitch System Technical Manual – Signaling & Protocols
V300R003
Huawei Technologies Proprietary
U-SYS SoftX3000 SoftSwitch System
Technical Manual
Volume Signaling & Protocols
Manual Version T2-010257-20050729-C-3.33
Product Version V300R003
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.
All other trademarks and trade names 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.
Huawei Technologies Proprietary
About This Manual
Release Notes
The manual applies to U-SYS SoftX3000 SoftSwitch System V300R003.
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
It guides the engineers how to configure various data in SoftX3000, including networking example, configuration script, key parameters
Huawei Technologies Proprietary
Manual Content Manual-Configuration Example and debugging guidance.
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.
Chapter 1 MGCP profiles the architecture, message specifications and call signaling procedures of MGCP.
Chapter 2 H.248 details the architecture, message specifications and call signaling procedures of H.248.
Chapter 3 SIP presents the architecture, message specifications and call signaling procedures of SIP.
Chapter 4 H.323 details the architecture, message specifications and call signaling procedures of H.323 protocol stack, including RAS, H.225.0, and H.245.
Chapter 5 SIGTRAN provides the architecture, message specifications and call signaling procedures of SIGTRAN protocol stack, including SCTP, M2UA, and M3UA.
Chapter 6 SS7 gives a detailed description of the architecture, message specifications and call signaling procedures of SS7.
Chapter 7 R2 Signaling elaborates the architecture, message specifications and call signaling procedures of the R2 signaling.
Chapter 8 DSS1 and V5 focuses on the architecture, message specifications and call signaling procedures of the DSS1 and V5 signaling.
Huawei Technologies Proprietary
Intended Audience
The manual is intended for the following readers:
NGN network planning experts NGN network administrators NGN system engineers
Conventions
The manual uses the following conventions:
I. General conventions
Convention Description
Arial Normal paragraphs are in Arial.
Boldface Headings are in Boldface.
Courier New Terminal Display is in Courier New.
II. Symbols
Eye-catching symbols are also used in the manual to highlight the points worthy of special attention during the operation. They are defined as follows:
Caution,: Means reader be extremely careful during the operation.
Note: Means a complementary description
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Table of Contents
4.1.1 What is H.323.......................................................................................................... 4-1 4.1.2 Definition of Terms .................................................................................................. 4-1 4.1.3 Structure of H.323 Protocol Stack........................................................................... 4-4 4.1.4 H.323 Applications in SoftX3000............................................................................. 4-6
RFC2705 document describes an application programming interface and a corresponding protocol (media gateway control protocol, MGCP) for controlling Voice over Internet Protocol (VoIP) gateways from external call control elements.
MGCP assumes a call control architecture where call control is independent of service bearer. As shown in Figure 1-1, the call control “intelligence” is outside the Media Gateways (MGs) and handled by external call control elements named Media Gateway Controller (MGC) or Call Agent (CA). MGCP is, in essence, a master/slave protocol, where the MGs are expected to execute commands sent by the MGCs.
MGC
MG
Control streams
Media streams
Figure 1-1 MGCP concept
1.1.2 Related Terms
I. Gateway
A gateway is a network element that provides interconnection and interworking between networks of various architectures. In NGN architecture, NGN interworks with other networks through certain gateways:
Trunk Media Gateways (TMG): that interface between the traditional telephone network (Public Switched Telephone Network, PSTN) and a VoIP network. Such gateways typically manage a large number of digital circuits.
Access Media Gateways (AMG): that convert media in one network to a suitable format required by another network. For example, AMGs can achieve the conversion between bearer channels of a circuit switched network and media streams of a packet switched network.
Universal Media Gateways (UMG): that provide functions to convert media streams and signaling, universally to implement Trunking Gateway (TG), built-in Signaling Gateway (SG) and Access Gateway (AG) functions. Such gateways
can connect to a variety of devices such as PSTN switches, Private Branch Exchanges (PBX), access networks, routers, and wireless base stations.
II. Media resource server
A Media Resource Server (MRS) is a type of gateway that supports a variety of endpoints such as announcement server access point, interactive voice response access point, and conference bridge access point.
SoftX3000 supports the controlling of an MGCP MRS to provide announcements and Interactive Voice Response (IVR) services. MRS can be used to provide announcements to all kinds of users in the system. SoftX3000 also supports digit collection through an MRS.
III. Call agent
A Call Agent provides signaling and call processing functions. It is an external call control element for controlling telephony gateways.
SoftX3000 provides MGCP call agent functionality. SoftX3000 can act as an access point for MGCP E-phones and Softphones in the network, compliant with the Internet Engineering Task Force (IETF) RFC2705 (MGCP). SoftX3000 supports Calls and Connections management procedure as specified in Section 2.1.3 of the RFC2705 (Version 1.0).
IV. Endpoint
Endpoints are sources or sinks of data and can be physical or virtual.
Examples of physical endpoints are an interface on a trunk gateway that terminates a trunk connected to a PSTN switch, and a port on an access gateway connected to E-phones. An example of a virtual endpoint is an audio source in an MRS. Creation of physical endpoints requires hardware installation, while creation of virtual endpoints can be done by software.
V. Endpoint identifier
Endpoints are identified by endpoint identifiers. Endpoint identifiers have two components that both are case insensitive: the domain name of the gateway that is managing the endpoint, and a local name within that gateway. Between the components, an “at” sign (@) is used as a delimiter. The syntax of the local name depends on the type of endpoint being named. However, the local name for each of these types is naturally hierarchical, beginning with a term that identifies the physical gateway containing the given endpoint and ending in a term that specifies the individual endpoint concerned. With this in mind, the following rules for construction and interpretation of endpoint identifiers must be supported:
The individual terms of the naming path must be separated by a single slash (“/").
The individual terms are character strings composed of letters, digits or other printable characters, with the exception of characters used as delimiters (”/”, “@”), and white spaces.
Characters used for wildcarding (“*”, “$”) can be used in local names. A term represented by an asterisk is to be interpreted as: “use ALL values of this term known within the scope of the Media Gateway”. A term represented by a dollar sign is to be interpreted as: “use ANY ONE value of this term known within the scope of the Media Gateway”.
In MGCP, the gateway is identified by a domain name, such as amg1.hauwei.com. The local name is structured with the name of the physical interface (for example aaln) and the terminal identifier (that is, the corresponding port number of the telephone number accessing the Media Gateway). The terminal identifier is separated from the name of the physical interface by a fraction bar (“/”).
An example is aaln/1 @ amg1.hauwei.com which is the name of an endpoint of an AMG.
That refers to the first port of the aaln interface of the AMG with the domain name amg1.hauwei.com.
Another example is X35V3+A4/[email protected] which is the name of an endpoint of a TG.
That refers to the thirteenth Time Division Multiplexing (TDM) circuit on the X35V3+A4 interface of the gateway numbered 23 in the example network.
VI. Calls and connections
Connections may be either point to point or multipoint. A point to point connection is an association between two endpoints with the purpose of transmitting data between these endpoints. Once this association is established for both endpoints, data transfer between these endpoints can take place. A multipoint connection is established by connecting the endpoint to a multipoint session. Connections can be established over several types of bearer networks.
Connections are grouped in calls. One or more connections can belong to one call. Connections and calls are set up at the initiative of one or several MGCs.
Figure 1-2 illustrates the concepts of endpoints, connections, calls and gateways, as well as their relations.
Figure 1-2 Relations between endpoints, connections, calls and gateways
When the two endpoints are located on gateways that are managed by the same call agent, the creation is done through three steps as follows:
2) The call agent asks the first gateway to “create a connection” on the first endpoint. The gateway allocates resources to that connection, and responds to the command by providing a “session description”. The session description contains the information necessary for a third party to send packets towards the newly created connection, such as IP address, User Datagram Protocol (UDP) port, and packetization parameters.
3) The call agent then asks the second gateway to “create a connection” on the second endpoint. The command carries the “session description” provided by the first gateway. The gateway allocates resources to that connection, and responds to the command by providing a “session description”.
4) The call agent uses a “modify connection” command to provide the second “session description” to the first endpoint. Once this is done, communication can proceed in both directions.
VII. Connection identifier
Connections managed at endpoints can be converged into calls. Connections are created by gateways. Gateways assign unique connection identifiers to local ends. Connection identifiers are character strings composed of hexadecimal numbers.
VIII. Call identifier
Calls are identified by unique identifiers which are created by the MGC. Call identifiers are treated in MGCP as unstructured octet strings. Call identifiers must be unique within the system. When an MGC builds several connections for the same call, the connections must pertain to the same call.
IX. Names of calls agents and other entities
In MGCP, Call Agents are identified by domain names. For enhanced network reliability, MGCP has been designed to allow the implementation of redundant Call Agents which share the same domain name but have different network addresses, for
example, IP addresses. A gateway identifies a Call Agent through its domain name. For lower-layer operations, the gateway fetches the list of network addresses of the Call Agent from the domain name server, and uses an appropriate network address for communication with the Call Agent according to specific situations. This redundancy mechanism is significant to improve the reliability of the system.
Other entities, such as gateways and information servers, are also identified by their domain names. Similarly, these entities can make full use of redundancy to enhance the reliability of the system. For Call Agents and gateways, they identify these entities through domain name.
Domain name prevents these entities from being identified directly through network addresses, because the domain name is relatively stable while network addresses can be easily changed. For example, if an entity is moved to a different Local Access Network (LAN), the IP address of the entity will be changed but the domain name can be retained. The domain name life ensures other entities can refresh the information about the domain name of that entity in time to obtain its latest IP address.
In MGCP, Call Agents and other entities are represented by e-mail address in essence, as in:
[email protected] indicating the busy signal in the information server numbered 12 in the example network
X. Event and signal
The concept of events and signals is central to MGCP. A Call Agent may ask to be notified about certain events occurring in an endpoint, such as off-hook events, on-hook events, flash-hook events, or dialing events. A Call Agent may request certain signals to be applied to an endpoint, such as dial tone, ringback tone, and busy tone.
Events and signals are grouped in packages. Each package is supported by a particular endpoint.
An event name is composed of two logical parts, a package name and an event name, separated by a slash (“/”). Event names and package names are case insensitive. The package name is in fact optional. Each endpoint type has a default package associated with it, and if the package name is excluded from the event name, the default package name for that endpoint type is assumed. When an event is applied on a connection, the name of the connection is added to the name of the event, using an “at” sign (“@”) as a delimiter. In addition, the range and wildcard notation of events can be used, instead of individual names. The asterisk sign (“*”), a wildcard character, can be used to denote “all connections”. The dollar sign (“$”), a wildcard character, can be used to denote “the current, any connection”.
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
G/ld Long duration connection event in the generic media packages. If a connection lasts for more than an hour, this event will be detected.
[0-9*#A-D] All digits and letters in the DTMF packages
T/$ All events in the trunk packages
R/qa@* Quality alert event in the RTP packages in all connections
R/rt@$ Ringback event in the RTP packages on current connection
XI. Digit map
The Call Agent can ask the gateway to collect digits dialed by the user. For example, a residential gateway collects the number that a user dials and the credit card number. An alternative procedure is for the gateway to notify the Call Agent of the dialed digits, as soon as they are dialed. However, such a procedure generates a large number of interactions and occupies a large number of network resources. It is preferable to accumulate the dialed numbers in a buffer, and to transmit them in a single message. The problem with this accumulation approach, however, is that it is hard for the gateway to predict how many numbers it needs to accumulate before transmission. The solution to this problem is to load the gateway with a digit map that corresponds to the dial plan.
This digit map is expressed using a strict syntax. It is composed of a list of digits and letters. If collected dial sequence matches one of the defined strings, it indicates necessary digits have been collected.
What are supported in the definition of digit strings include the digits from 0 to 9, the letters from “A” to “D”, the pound sign “#”, the asterisk sign “*”, the letters “T” and “x”, and the dot sign “.”. The digit strings separated by “|” are alternative number schemes. “[]” indicates “any of them”. “*” indicates the sign “*” used in DTMF. The letter “T” indicates the timer is detected time out. The letter “x” indicates any digit. The sign “.” indicates any number of letters, including zero number of letters, can appear before it. “#” indicates the sign “#” used in DTMF.
For example, using the phone on our disk, we can dial the following numbers:
Media Gateway Control Protocol is both a definition of commands and a definition of signaling. By MGCP commands, the MGC can control the MG; while the MG sends the responding signals back to the MGC. The commands and signals of MGCP are defined as IP packets, which allow it to be underlying bearer system independent.
The structure of MGCP protocol stack is shown in Figure 1-3.
MAC
IP
UDP
MGCP
Figure 1-3 MGCP protocol stack
MGCP messages are transmitted over UDP/IP. The transport layer protocol is UDP and the network layer protocol is IP.
1.1.4 Implementation in SoftX3000
Implementation of MGCP in SoftX3000 is illustrated in Figure 1-4.
SoftX3000 interworks with the PSTN through a Trunk Media Gateway (TMG) and built-in Signaling Gateway (SG). The TMG achieves the conversion of voice signals between a Circuit Switched (CS) network and a Packet Switched (PS) network, and the SG implements the conversion of signaling between a CS network and a PS network. The Call Agent is also known as MGC (SoftX3000), mainly used for signaling functions related to the call process, and it controls and manages the operating procedures of the MG and the SG. SoftX3000 controls the TMG through the H.248 protocol (H.248 is covered in a separate chapter) and controls the MRS, AG, IAD and Softphone through MGCP, to achieve functions such as signaling processing and call processing.
1.2 Protocol Messages
Nine types of MGCP messages in total are exchanged between MGC and MG, which are called commands when being sent to MG or MGC, while called responses when being returned from MG or MGC. Command and response are inseparable. After MG has registered successfully, upon receiving a command, MG (or MGC) will return a response immediately.
1.2.1 Message Types
I. Command
The names and meanings of MGCP commands are shown in Table 1-4. There are connection processing and endpoint processing commands. There are nine commands defined in this protocol.
MGC→MG, used to specify the encoding of the signals that will be received by the endpoint (A-law or µ-law). The Call Agent uses the command to transfer that information to the corresponding gateway.
NotificationRequest RQNT
Used to instruct the gateway to watch for specific events on a specified endpoint. If it happens, the Call Agent will be notified.
Notify NTFYMG→MGC, used by the gateway to notify the Call Agent that a specific event requested to watch for takes place.
CreateConnection CRCX
MGC→MG, used by the Call Agent to associate an endpoint with a specified IP address and UDP port. Apart from that, a CreateConnection command is also sent to the remote endpoint, which is required to create the connection between the two endpoints.
ModifyConnection MDCX
MGC→MG, used to change the parameters associated to a previously established connection. This command is used by the Call Agent to provide the first endpoint with the session description of the second endpoint, such as IP address, UDP port and packetization parameters. Once this process is completed, both parties can communicate in bi-directional ways.
DeleteConnection DLCX MGC→MG, used to delete an existing connection.
AuditEndpoints AUEP MGC→MG, used by the Call Agent to audit the status of an endpoint or a group of endpoints.
AuditConnection AUCX MGC→MG, used by the Call Agent to audit the status of a connection on an endpoint.
RestartInProgress RSIP
MG→MGC, used by the gateway to notify the Call Agent that the gateway, or a group of endpoints managed by the gateway, is being taken out of service or is being placed back in service.
II. Response
All MGCP commands are acknowledged. The acknowledgement carries a return code which is an integer, for which four ranges of values have been defined:
Values between 100 and 199 indicate a provisional response. Values between 200 and 299 indicate a successful completion. Values between 400 and 499 indicate a transient error. Values between 500 and 599 indicate a permanent error.
Whether to return response parameters depends on specific commands.
523 Unknown action or illegal combination of actions
524 Internal inconsistency in LocalConnectionOptions.
525 Unknown extension in LocalConnectionOptions.
526 Insufficient bandwidth.
527 Missing RemoteConnectionDescriptor.
528 Incompatible protocol version.
529 Internal hardware failure.
530 CAS signaling protocol error.
531 Failure of a grouping of trunks (for example, facility failure).
1.2.2 Message Structure
I. Command format
1) Command structure
Displayed in Figure 1-5 is the format of MGCP command, which consists of a command line and a group of parameter lines. A line feed character distinguishes the command line and each parameter line.
Command name Transaction ID Endpoint
Parameter name: parameter value
...
Protocol version Command line
Parameter line
Parameter name: parameter value
Figure 1-5 Structure of MGCP command
2) Command parameters ResponseAck (K)
The response acknowledgement attribute indicates the transaction identifiers which have received the response command. It contains a comma separated list of “confirmed transaction-id ranges”. For example:
It refers to bearer attributes. Currently only one attribute, “encoding”, is defined. The code of “encoding” attribute is “e”. Its values can be set to “A” which represents A-law and “µ” which represents µ-law. For example, a BearerInformation code is B: e:mu
CallId (C)
CallId is a globally unique parameter that identifies the call (or session) to which this connection belongs. Connections that belong to the same call share the same call-id. The call-id can be used to identify calls for reporting and accounting purposes. Call-id identifies calls, which is expressed as a hexadecimal character string, composed of a maximum of 32 characters.
ConnectionId (I) 3) The ConnectionId parameter is expressed as a hexadecimal character string
which is composed of a maximum of 32 characters. NotifiedEntity (N)
NotifiedEntity specifies where the notifications should be sent. When this parameter is absent, the notifications should be sent to the originator of the NotificationRequest.
RequestIdentifier (X)
RequestIdentifier is used to correlate this request with the notifications that it triggers. RequestIdentifier is expressed as a hexadecimal character string which is composed of a maximum of 32 characters.
LocalConnectionOptions (L)
The local connection options describe the operational parameters that the Call Agent suggests to the gateway. These parameters are: the packetization period in milliseconds (encoded as the keyword “p”), the preferred type of compression algorithm (encoded as the keyword “a”), the bandwidth in kilobits per second (encoded as the keyword “b”), the echo cancellation parameter (encoded as the keyword “e”), the gain control parameter (encoded as the keyword “gc”), the silence suppression parameter (encoded as the keyword “s”), the type of service parameter (encoded as the keyword “t”), the resource reservation parameter (encoded as the keyword “r”), the encryption key (encoded as the keyword “k”), and the type of network (encoded as the keyword “nt”). Each of the parameters is optional. When several parameters are present, the values are separated by commas. Examples of connection descriptors are:
L: p:10, a:PCMU
L: p:10, a:G726-32
L: p:10-20, b:64
L: b:32-64, e:off
Connection Mode (M)
The connection mode describes the mode of operation of the connection.
sendrecv The gateway should send and receive packets.
confrnce The gateway should place the connection in conference mode.
inactive The gateway should neither send nor receive packets.
loopback The gateway should place the circuit in loopback mode.
conttest The gateway should place the circuit in test mode.
netwloop The gateway should place the connection in network loopback mode.
netwtest The gateway should place the connection in network continuity test mode.
data The gateway should use the circuit for network access for data.
RequestedEvents (R)
The RequestedEvents parameter provides the list of events that have been requested. Each event can be qualified by a requested action, or by a list of actions. The actions, when specified, are encoded as a list of keywords, enclosed in parenthesis and separated by commas. Table 1-7 shows the codes for the various actions.
Table 1-7 Action codes
Code Action
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, the default action is to notify the event. This means that, for example, ft and ft(N) are equivalent. Events that are not listed are ignored.
The digit-map action can only be specified for the digits, letters and inter-digit timers in the MF and DTMF packets, or in other packages that would define the encoding of digits and timers.
The requested list is encoded on a single line, with event/action groups separated by commas. Examples of RequestedEvents encoding are:
R: hu(N), hf(S,N)
R: hu(N), [0-9#T](D)
SignalRequests (S)
The SignalRequests parameter provides the name of the signals that have been requested.
Several signals, for example announcement or Analogue Display Server Interface server (ADSI) display, can be qualified by additional parameters:
the name and parameters of the announcement,
the string that should be displayed.
These parameters will be encoded as a set of UTF8 character strings, separated by commas and enclosed within parenthesis, as in:
S: adsi("123456 Francois Gerard")
S: ann(no-such-number, 1234567)
When several signals are requested, their codes are separated by commas, as in:
S: asdi(123456 Your friend), rg
ObservedEvents (O)
The ObservedEvents parameter provides the list of events that have been observed.
Examples of observed actions are:
O: L/hu
O: 8295555T
O: 8,2,9,5,5,L/hf,5,5,T
O: L/hf, L/hf, L/hu
ConnectionParameters (P)
Connection parameters are encoded as a string of type and value pairs, where the type is either a letter identifier of the parameter or an extension type, and the value is decimal integer. Types are separated from value by an “=” sign. Parameters are encoded from each other by commas.
Table 1-8 shows the connection parameter types.
Table 1-8 Connection parameter types
Code Connection parameter name Connection parameter value
PS Packets sent The number of packets that were sent on the connection.
Reason codes are used by the gateway when deleting a connection to inform the Call Agent about the reason for deleting the connection. They may also be used in a RestartInProgress command, to inform the gateway of the Restart’s reason. The reason code is an integer number, and the values listed in Table 1-9 have been defined.
Table 1-9 Command reason codes
Reason code Description
000 Endpoint state is nominal. (This code is used only in response to audit requests.)
900 Endpoint malfunctioning
901 Endpoint taken out of service
902 Loss of lower layer connectivity
Reason codes are three-digit numeric values. The reason code is optionally followed by a white space and commentary, as in:
900 Endpoint malfuctioning
SpecificEndpointId (Z)
The endpoint identifier specified by the gateway is returned in a CreateConnection response. The SpecificEndpointId is an optional parameter that identifies the
responding endpoint. It can be used when the EndpointId parameter referred to a “any of” wildcard name. When a SpecificEndpointId is returned, the Call Agent should use it as the EndpointId value in successive commands referring to this call.
RequestedInfo (F)
When a non-wildcard EndpointId is specified, the (possibly empty) RequestedInfo parameter describes the information that is requested for the EndpointId specified. The following endpoint information can be audited with this command:
The RequestedInfo parameter contains a comma separated list of parameter codes.
For example, if one wants to audit the value of the NotifiedEntity, RequestIdentifier, RequestedEvents, SiganalRequests, DigitMap, QuarantineHandling, DetectEvents, and Capabilities parameters, the value of the RequestedInfo parameter will be:
F:N,X,R,S,D,Q,T,A
QuarantineHandling (Q)
The QuarantineHandling parameter specifies the handling of “quarantine” events, that is, events that have been detected by the gateway before the arrival of the NotificationRequest command, but have not yet been notified to the Call Agent. The parameter provides a set of handling options:
whether the quarantined events should be processed or discarded. (The default is to process them.)
whether the gateway is expected to generate at most one notification (step by step), or multiple notifications (loop), in response to the request. (The default is exactly one.)
For example:
Q:loop
Q:process
Q:discard,loop
DetectEvents (T)
The list of events that are currently detected in the quarantine mode. The DetectEvent parameter is encoded as a comma separated list of events.
For example:
T: hu,hd,hf,[0-9#*]
RestartMethod (RM)
The RestartMethod parameter specifies the type of restart, encoded as one of the following keywords:
A “graceful” restart method indicates that the specified endpoints will be taken out of service after the specified delay. The established connections are not yet affected, but
the Call Agent should refrain to establish new connections, and should try to gracefully tear down the existing connections.
A “forced” restart method indicates that the specified endpoints are taken abruptly out of service. The established connections, if any, are lost.
A “restart” method indicates that service will be restored on the endpoints after the specified “restart delay”. There are no connections that are currently established on the endpoints.
A “disconnected” method indicates that the endpoint has become disconnected and is now trying to establish connectivity. The “restart delay” specifies the number of seconds the endpoint has been disconnected. Established connections are not affected.
A “cancel-graceful” method indicates that a gateway is canceling a previously issued “graceful” restart command.
For example:
RM:restart
RestartDelay (RD)
The restart delay parameter is expressed as a number of seconds. If the number is absent, the delay value should be considered null.
In the case of the “graceful” method, a null delay indicates that the Call Agent should simply wait for the natural termination of the existing connections, without establishing new connections. The restart delay is always considered null in the case of the “forced” method. A restart delay of null for the “restart” method indicates that service has already been restored. This will typically occur after gateway startup/reboot.
EventStates (ES)
The EventStates parameter is encoded as a comma separated list of events.
For example:
E: hu
Capabilities (A)
Capabilities inform the Call Agent about endpoints’ capabilities when audited. The encoding of capabilities is based on the Local Connection Options encoding for the parameters that are common to both. The parameters used are Event Packages (v), Modes (m), a list of supported codecs (*), type of network (nt), and so on.
In addition, capabilities can also contain a list of supported packages and a list of supported modes.
RemoteConnectionDescriptor (RC)
The RemoteConnectionDescriptor includes the same fields as in the LocalConnectionDescriptor, such as IP address, UDP port and packetization parameters. For the CreateConnection command, this parameter may have a null
value when the information for the remote end is not known yet. This occurs because the entity that builds a connection starts by sending a CreateConnection to one of the two gateways involved in it. For the first CreateConnection issued, there is no information available about the other side of the connection. This information may be provided in SDP packets later through a ModifyConnection call.
LocalConnectionDescriptor (LC)
The LocalConnectionDescriptor is a session description that contains information about IP address and port number suitable for the local connection, as defined in SDP.
4) Command expressions
What are within the parenthesis preceded by the command name are input parameters. Those enclosed by […] are optional.
The 1st line: The CreateConnection command. The transaction identifier is 693585490, used to correlate this command with the responses that it triggers. It means to create a connection between SoftX3000 and the second port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The call identifier is a265.
The 3rd line: The local connection options. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.
The 4th line: The connection mode is “inactive”, that is, neither sending nor receiving packets. Only after the ModifyConnection command is executed, the connection mode is changed to “sendrecv”.
The 5th line: The encapsulated NotificationRequest in this CreateConnection command. The request identifier is 65000108, used to correlate this request with the notifications that it triggers.
The 6th line: SoftX3000 requests the gateway to monitor the following events that will happen in the endpoint: digit collection according to the rules specified by the digit map. “D/[0-9*#T]” indicates the digits and letters in the DTMF packages. What are involved are the digits from 0 to 9, the asterisk sign “*”, the pound sign “#”, and the timer identifier “T”. Those characters can be part of “digit strings”, representing the dial keys for user. “D/[0-9*#T](D)” indicates to process the “digit strings” dialed by user according to the digit map. If a digit string matches at least one of available dial plans defined in the digit map, the endpoint1 resident gateway will send the current digit
string to the Call Agent. “G/ld(N)” indicates if a long duration connection event in the generic media packages happens then it is requested to notify the Call Agent. (Long duration connection refers to a connection lasting for more than one hour.)
The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.
II. Response format
1) Response structure
Similar to the format of MGCP command, the response format is composed of a response line, usually followed by a group of optional parameter lines. The response line consists of the response code, transaction identifier, and an optional commentary, which are separated by white spaces. The response code is a three-digit numeric value, indicating the execution status of the command.
Response code Transaction ID Commentary (optional)
Parameter name: parameter value
...
Response line
Parameter line
Parameter name: parameter value
Figure 1-6 Structure of MGCP response
2) Response parameters
The optional response parameter lines depend on the corresponding commands. For more information, refer to the section “Command parameters”, earlier in this chapter.
3) Response expressions
What are within the parenthesis preceded by the command name are response parameter values. Those enclosed by […] are optional.
The 1st line: “200” indicates the successful receipt of the command. “693585490” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “CRCX OK” is a commentary.
The 2nd line: The connection identifier is “1607901”.
The 3rd line: Null, indicating what is preceded is an SDP session description.
The 4th line: The SDP protocol version is 0. It is the local connection descriptor at this time.
The 5th line: “c” in the response identifies the connection information. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” indicates the type of connection address is IP4. “191.169.4.165” represents the network address of the gateway that has a connection with the MGC.
The 6th line: Media description. “audio” indicates the type of media is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5012” is the transport layer port number to which media streams are transmitted. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. For audio and video signals, “8 0” represents the type of media payload defined in the RTP audio/video application document. It indicates all the formats may be used in the session but the first one is the default. At this time, the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. “0” corresponds to the media encoding format PCM3.
The 7th line: Attribute. Attribute is the basic method for SDP extension. It can be defined as session-level attribute or media-level attribute. There are two forms of attributes:
a=<flag>, as feature attribute. It is a binary attribute, indicating the session has this nature. For example, a=recvonly indicates the “receive only” feature.
a=<attribute>:<value>, as numeric value attribute. For example, a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.
1.3 Basic Control Procedures
1.3.1 Gateway Registration Procedure
The gateway must have registered to SoftX3000 before the subsequent procedures or connections are made. An application of gateway registration procedure is illustrated in Figure 1-7.
SoftX3000MG
RSIP
RSIP_RSP
Figure 1-7 Example of gateway registration procedure
1) Event 1: The MG originates an RSIP command to the MGC, reporting the MG has completed a load or restart and requesting to register to the MGC. The following is an RSIP encoding sample:
RSIP 836 aaln/*@iad-v2a-he.com MGCP 1.0 NSC 1.0
RM:restart
The 1st line: The RestartInProgress command. The transaction identifier is 836, used to correlate this command with the responses that it triggers. It can be found that a restart will take place on all endpoints of the access gateway whose domain name is iad-v2a-he.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The restart method is “restart”. A “restart” method indicates that service will be restored on the endpoints after the specified “restart delay”. There are no connections that are currently established on the endpoints of the gateway.
2) Event 2: The MGC sends a response to the MG registration request. The following are RestartInProgress response samples.
Sample 1:
200 836 OK
“200” indicates the successful receipt of the command. “836” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. If the MG receives this response, it indicates a successful registration.
Sample 2:
500 836 The endpoint is unknown
“500” indicates the transaction could not be executed because the endpoint is unknown. “836” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “The endpoint is unknown” is a commentary. If the MG receives this response, it indicates an unsuccessful registration.
1.3.2 Successful Termination Call Procedure (in the Same MG)
An application example for a successful call procedure between two endpoints in the same MG under the control of the same SoftX3000 is illustrated in Figure 1-8.
In the following example, it is assumed that
The endpoint identifier of the Endpoint1 is aaln/[email protected], which is connected to the UserA;
The endpoint identifier of the Endpoint2 is aaln/[email protected], which is connected to the UserB;
The UserA makes a call to the UserB, and the called party hooks on first; The IP address of the MG is 191.169.4.165.
Figure 1-8 MGCP call procedure between two endpoints in the same MG
1) Event 1: SoftX3000 sends a RQNT command to the Endpoint1, requesting it to detect the off-hook event on the endpoint. The MG acknowledges the command. The MG keeps monitoring such an event until the user at the Endpoint1 hooks off.
The 1st line: The NotificationRequest command. The transaction identifier is 59659850, used to correlate this command with the responses that it triggers. It indicates SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The request identifier is 6500010a, used to correlate this request with the notifications that it triggers.
The 3rd line: SoftX3000 requests the MG to detect the off-hook event in the endpoint.
The 4th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.
RQNT_RSP encoding 200 59659850 OK
“200” indicates the successful receipt of the command. “59659850” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates the MG has received and is executing the request.
2) Event 2: After the UserA hooks off, the Endpoint1 sends to SoftX3000 an NTFY command which carries the message of the off-hook event happening in the detected endpoint. SoftX3000 should acknowledge the information sent by the Endpoint1.
The 1st line: The Notify command. Upon detecting a specific event happening on its first port, the access gateway, whose domain name is zd0068.com and interface name is aaln, notifies SoftX3000.
The 2nd line: The request identifier is 6500010a. That value is the same as the value of the parameter contained in the RQNT command that triggers this notification. It is used to correlate the RQNT command with the NTFY command.
The 3rd line: The MG detects the off-hook event.
NTFY_RSP encoding 200 32008010 OK
“200” indicates the successful receipt of the command. “32008010” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates SoftX3000 has received that notification.
3) Event 3: SoftX3000 sends a RQNT command to the Endpoint1, requesting it to collect dialed digits according to the dial plan as well as sending the dial tone. The Endpoint1 acknowledges the command and sends dial tone to the UserA at the same time.
The 1st line: The NotificationRequest command. The transaction identifier is 59663957, used to correlate this command with the responses that it triggers. It indicates SoftX3000 sends requests to the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The request identifier is 65000102, used to correlate this request with the notifications that it triggers.
The 3rd line: SoftX3000 requests the MG to detect two events that will happen in the endpoint. One event is digit collection according to the dial plan specified by the digit map. “D/[0-9*#T]” indicates the digits and letters in the DTMF packages. What are involved are the digits from 0 to 9, the asterisk sign “*”, the pound sign “#”, and the timer identifier “T”. Those characters can be part of “digit strings”, representing the dial keys for user. “D/[0-9*#T](D)” indicates to process the “digit strings” dialed by user according to the digit map. If a digit string matches at least one of available dial plans defined in the digit map, the endpoint1 resident gateway will send the current digit string to the Call Agent. The other event: “G/ld(N)” indicates if a long duration connection event in the generic media packages happens then it is requested to notify the Call Agent. (Long duration connection refers to a connection lasting for more than one hour.)
The 4th line: Digit map. SoftX3000 delivers a dial plan to the Endpoint1 resident gateway: ([1-9]xxxxxxx|0xxxxxxxxxx|*|x.# |[0-9*#].T). “[1-9]xxxxxxx” indicates user can dial any 8-digit number started with an integer in the range of 1 to 9. “0xxxxxxxxxx” indicates any 11-digit number started with 0. “*” indicates each digit is reported as soon as it is dialed. “x.#” indicates any length of digits are reported whenever # is dialed. “[0-9*#].T” indicates any length of digits started with 0 ~ 9, * or # are reported after an expiration.
The 5th line: The request signal, requesting the MG to acknowledge this command and then send dial tone to the UserA.
RQNT_RSP encoding 200 59663957 OK
“200” indicates the successful receipt of the command. “59663957” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates the MG has received and is executing the request; meanwhile it is sending the dial tone to the Endpoint1.
4) Event 4: The Endpoint1 receives the digits according to the dial plan in the event 3. Upon receiving all necessary digits, the Endpoint1 sends an NTFY command to notify SoftX3000. The command carries the collected digits with the parameter ObservedEvents. SoftX3000 acknowledges the command.
The 1st line: The Notify command. Upon detecting a specific event happening on its first port, the access gateway, whose domain name is zd0068.com and interface name is aaln, notifies SoftX3000.
The 2nd line: The request identifier is 65000102. That value is the same as the value of the parameter contained in the RQNT command that triggers this notification. It is used to correlate the RQNT command with the NTFY command.
The 3rd line: The MG detects what the UserA dials is 66500008.
NTFY_RSP encoding 200 32008011 OK
“200” indicates the successful receipt of the command. “32008011” is a transaction identifier which is the same as the transaction identifier contained in the command that triggers this response. “OK” is a commentary. Here, it indicates SoftX3000 has received that notification.
5) Event 5: SoftX3000 creates a connection with the Endpoint1. The endpoint acknowledges the command and returns the information about the connection at the local endpoint.
The 1st line: The CreateConnection command. The transaction identifier is 59688530, used to correlate this command with the responses that it triggers. It means to create a connection between SoftX3000 and the first port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The call identifier is 4965. The protocol supports that several connections belonging to one call share the same call identifier. At present, Huawei design supports that several connections belonging to one call use different call identifiers. Call identifier is used for charging purposes.
The 3rd line: The local connection options. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.
The 4th line: The connection mode is “inactive”, that is, neither sending nor receiving packets. Only after the ModifyConnection command is executed, the connection mode is changed to “sendrecv”.
The 5th line: The encapsulated NotificationRequest in this CreateConnection command. The request identifier is 65000106, used to correlate this request with the notifications that it triggers.
The 6th line: SoftX3000 requests the MG to detect the following event that will happen in the endpoint: “G/ld(N)” indicates if a long duration connection event in the generic media packages happens then it is requested to notify the Call Agent. (Long duration connection refers to a connection lasting for more than one hour.)
The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.
CRCX_RSP encoding 200 59688530 CRCX OK
I:2008012
v=0
c=IN IP4 191.169.4.165
m=audio 5012 RTP/AVP 8 0
a=ptime:20
The 1st line: “200” indicates the successful receipt of the command. “59688530” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “CRCX OK” is a commentary.
The 2nd line: The connection identifier is “2008012”.
The 3rd line: Null, indicating what is preceded is an SDP session description.
The 4th line: The SDP protocol version is 0. Here, what is returned is the “session description” of the local endpoint (Endpoint1).
The 5th line: “c” in the response identifies the connection information. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” indicates the type of connection address is IP4. “191.169.4.165” represents the network address of the connection.
The 6th line: Media description. “audio” indicates the type of media is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5012” is the transport layer port number to which media streams are transmitted. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. For audio and video signals, “8 0” represents the type of media payload defined in the RTP audio/video application
document. It indicates all the formats may be used in the session but the first one is the default. At this time, the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. “0” corresponds to the media encoding format PCM3.
The 7th line: Attribute. Attribute is the basic method for SDP extension. It can be defined as session-level attribute or media-level attribute. There are two forms of attributes:
a=<flag>, as feature attribute. It is a binary attribute, indicating the session has this nature. For example, a=recvonly indicates the “receive only” feature.
a=<attribute>:<value>, as numeric value attribute. For example, a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.
6) Event 6: SoftX3000 creates a connection with the Endpoint2. The endpoint acknowledges the command and returns the information about the connection at the local endpoint.
The 1st line: The CreateConnection command. The transaction identifier is 59696722, used to correlate this command with the responses that it triggers. It means to create a connection between SoftX3000 and the second port of the access gateway whose domain name is zd0068.com and the interface name is aaln. The protocol version of MGCP is 1.0.
The 2nd line: The call identifier is 4a65. The protocol supports that several connections belonging to one call share the same call identifier. At present, Huawei design supports that several connections belonging to one call use different call identifiers. Call identifier is used for charging purposes.
The 3rd line: The local connection options. The Call Agent suggests to the gateway that the compression algorithm is PCMA and the encapsulation delay is 20 milliseconds.
The 4th line: The connection mode is “inactive”, that is, neither sending nor receiving packets. Only after the ModifyConnection command is executed, the connection mode is changed to “sendrecv”.
The 5th line: The encapsulated NotificationRequest in this CreateConnection command. The request identifier is 65000008, used to correlate this request with the notifications that it triggers.
The 6th line: SoftX3000 requests the MG to detect a specific event that will happen in the endpoint.
The 7th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.
CRCX_RSP encoding 200 59696722 CRCX OK
I:2008013
v=0
c=IN IP4 191.169.4.165
m=audio 5004 RTP/AVP 8 0
a=ptime:20
The 1st line: “200” indicates the successful receipt of the command. “59696722” is a transaction identifier which is the same as the transaction identifier contained in the CreateConnection command that triggers this response. “CRCX OK” is a commentary.
The 2nd line: The connection identifier is “2008013”.
The 3rd line: Null, indicating what is preceded is an SDP session description.
The 4th line: The SDP protocol version is 0. Here, what is returned is the “session description” of the local endpoint (Endpoint2).
The 5th line: “c” in the response identifies the connection information. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” indicates the type of connection address is IP4. “191.169.4.165” represents the network address of the connection.
The 6th line: Media description. “audio” indicates the type of media is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5004” is the transport layer port number to which media streams are transmitted. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. For audio and video signals, “8 0” represents the type of media payload defined in the RTP audio/video application document. It indicates all the formats may be used in the session but the first one is the default. At this time, the mapping relation from RTP payload type to encoding is that “8” corresponds to the media encoding format PCMA. “0” corresponds to the media encoding format PCM3.
The 7th line: Attribute. Attribute is the basic method for SDP extension. It can be defined as session-level attribute or media-level attribute. There are two forms of attributes:
a=<flag>, as feature attribute. It is a binary attribute, indicating the session has this nature. For example, a=recvonly indicates the “receive only” feature.
a=<attribute>:<value>, as numeric value attribute. For example, a=ptime:20 indicates the domain name of the media attribute is “ptime” and the value of the media attribute is “20”.
7) Event 7: SoftX3000 requests the MG to play the ringing tone to the UserB. The MG acknowledges the request and meanwhile plays the ringing tone to the UserB.
9) Event 9: The UserB hooks off. The MG notifies the Call Agent of that event. NTFY encoding NTFY 32008014 aaln/[email protected] MGCP 1.0
X:6500000a
O:hd
The 1st line: The Endpoint2 sends a notification to SoftX3000.
The 2nd line: The request identifier is 6500000a.
The 3rd line: The endpoint notifies SoftX3000 that the UserB hooked off.
NTFY_RSP encoding 200 32008014 OK
SoftX3000 acknowledges the receipt of the notification.
10) Event 10: SoftX3000 sends an MDCX command to the Endpoint2, requesting to modify the connection. The command carries some connection parameters of the Endpoint1. The Endpoint2 acknowledges the receipt of the command. Meanwhile, it will modify the connection and stop sending the ringback tone.
The 1st line: SoftX3000 sends a ModifyConnection command to the Endpoint2. The transaction identifier is 59721299.
The 2nd line: The call identifier is 4a65.
The 3rd line: The connection identifier is 2008013. The connection is created by the MG. The MG assigns a unique connection identifier to the local end.
The 4th line: The local connection options. The Call Agent suggests to the MG that the echo cancellation parameter is set to on, the compression algorithm is PCMA, and the encapsulation delay is 20 milliseconds.
The 6th line: The encapsulated NotificationRequest in this ModifyConnection command. The request identifier is 6500000e, used to correlate this request with the notifications that it triggers.
The 7th line: SoftX3000 requests the MG to detect the following events that will happen in the endpoint: “G/ft(N)” indicates if a fax tone detected event in the generic media packages happens then it is requested to notify the Call Agent; “G/mt(N)” indicates if a modem detected event in the generic media packages happens then it is requested to notify the Call Agent.
The 8th line: The signal is null, indicating the MGC requires the MG to stop any signal being sent currently.
The 9th line: Null, indicating what is preceded is an SDP session description.
The 10th line: The SDP protocol version is 0. The “session description” carries some connection parameters of the Endpoint1. Through the MDCX command, the connection parameters of the Endpoint1 are provided for the Endpoint2.
The 11th line: Here, “c” indicates the connection information of the Endpoint1. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” indicates the type of connection address is IP4. “191.169.4.165” represents the network address of the connection. In general, the Call Agent provides connection description parameters for the Endpoint2 through MGCP, such as the Endpoint1’s IP address, UDP port and RTP description.
The 12th line: Media description. “audio” indicates the type of media of the Endpoint1 is audio. ("audio” is used for audio connections, and “nas” used for data access.) “5012” is the port number for the media of the Endpoint1. “RTP/AVP” is the media protocol. “8” indicates PCMA is the encoding format for the media which is negotiated by the Endpoint1 and the Endpoint2.
MDCX_RSP encoding 200 59721299 MDCX OK
v:0
c:IN IP4 191.169.4.165
m:audio 5004 RTP/AVP 8
a:ptime:20
The 1st line: The Endpoint2 acknowledges the receipt of the MDCX command sent by SoftX3000.
The 2nd line: The SDP protocol version is 0. Here, what is returned is the “session description” of the local endpoint (Endpoint2).
The 3rd line: Compared with the “session description” returned in the CRCX_RSP, earlier in this chapter, it can be found that the encoding format for media, PCMA, is determined in the MDCX_RSP. The CRCX_RSP only provided two options: PCMA and PCM3.
11) Event 11: SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the connection. The command carries some connection parameters of the Endpoint2. The Endpoint1 acknowledges the command, and then the UserA and the UserB enjoy a conversation.
SoftX3000 sends an MDCX command to the Endpoint1, requesting to modify the connection mode to “sendrecv”. The “session description” of the Endpoint2 is also carried and provided for the Endpoint1.
MDCX_RSP encoding 200 59729491 MDCX OK
v:0
c:IN IP4 191.169.4.165
m:audio 5012 RTP/AVP 8
a:ptime:20
It indicates the Endpoint1 acknowledges the receipt of the MDCX command sent by SoftX3000 and returns the “session description” of the local endpoint. Compared with the “session description” returned in the CRCX_RSP, earlier in this chapter, it can be found that the encoding format for media, PCMA, is determined in the MDCX_RSP. The CRCX_RSP only provided two options: PCMA and PCM3.
12) Event 12: The UserB hooks on. The Endpoint2 sends an NTFY command to SoftX3000. SoftX3000 acknowledges the command.
The 1st line: The Endpoint2 detects a specified event that happened at the UserB, and notifies SoftX3000 of the event.
The 2nd line: The request identifier is 6500000e, which is the same as the request identifier carried in the encapsulated NotificationRequest command in the ModifyConnection command described in the event 10. It indicates the Notify
command is triggered by the encapsulated NotificationRequest command in the ModifyConnection command described in the event 10.
The 3rd line: The MG reports to SoftX3000 that the Endpoint2 detected an on-hook event happening at the UserB.
NTFY_RSP encoding 200 32008015 OK
13) Event 13: SoftX3000 sends an MDCX command to the Endpoint2. MDCX encoding MDCX 59754067 aaln/[email protected] MGCP 1.0
C:4a65
I:2008013
M:inactive
X:65000002
R:
S:
SoftX3000 sends an MDCX command to the Endpoint2, requesting to modify the mode of the connection between them to “inactive”. In the ModifyConnection command, there is an encapsulated NotificationRequest command with the request identifier as 65000002, indicating that the MGC requests the MG to detect the subsequent events happening in the Endpoint2 and stop any signal played currently.
MDCX_RSP encoding 200 59754067 MDCX OK
v:0
c:IN IP4 191.169.4.165
m:audio 5004 RTP/AVP 8
a:ptime:20
14) Event 14: SoftX3000 sends a DLCX command to the Endpoint2, requesting to delete the existing connection.
“250” indicates the connection is deleted. The transaction identifier is 59762260. “OK” is a commentary.
15) Event 15: SoftX3000 sends a DLCX command to the Endpoint1, requesting to delete the existing connection. The Endpoint1 acknowledges the command and sends busy tone to the UserA at the same time.
The 1st line: SoftX3000 sends a DLCX command to the Endpoint1, requesting to delete the existing connection.
The 2nd line: In the DeleteConnection command, there is an encapsulated NotificationRequest command with the request identifier as 65000106.
The 3rd line: SoftX3000 requests the MG to detect events that will happen in the Endpoint1.
The 4th line: SoftX3000 requests the MG to send the busy tone signal to the UserA.
DLCX_RSP encoding 250 59770452 OK
16) Event 16: SoftX3000 sends a RQNT command to the Endpoint2, requesting the MG to detect events and signals that will happen in the Endpoint2. The involved command encoding and response encoding are simple, and thus no more information is provided here.
17) Event 17: The UserA hooks on. The Endpoint1 sends an NTFY command to notify SoftX3000 of the event.
The 1st line: The Endpoint1 detects a specified event that happened at the UserA, and notifies SoftX3000 of the event.
The 2nd line: The request identifier is 65000106, which is the same as the request identifier carried in the encapsulated NotificationRequest command in the DeleteConnection command described in the event 15.
The 3rd line: The MG reports to the MGC that the Endpoint1 detected an on-hook event happening at the UserA.
18) Event 18: SoftX3000 sends a RQNT command to the Endpoint1, requesting the MG to detect events and signals that will happen in the Endpoint1. The involved command encoding and response encoding are simple, and thus no more information is provided here.
1.3.3 Successful Termination Call Procedure (in Different MGs)
An application example for a successful call procedure between two telephone users in different MGs under the control of the same SoftX3000 is illustrated in Figure 1-9. In the following example, it is assumed that
The IP address of the MG1 is 191.169.3.38; The UserA is connected to the MG1, and the corresponding endpoint identifier of
the UserA is aaln/[email protected]; The IP address of the MG2 is 191.169.1.25; The UserB is connected to the MG2, and the corresponding endpoint identifier of
the UserB is aaln/[email protected]; The UserA makes a call to the UserB, and the called party hooks on first.
SoftX3000MG1UserA MG2 UserB
RQNTRQNT_RSPOff-hook
NTFYNTFY_RSP
RQNTRQNT_RSPdial-tone
NTFYNTFY_RSP
dialing
CRCXCRCX_RSP
CRCXCRCX_RSP
RQNTRQNT_RSP RingingRQNT
RQNT_RSPRingback tone NTFY
NTFY_RSPMDCX
MDCX_RSPMDCXMDCX_RSP
Conversation
Off-hook
On-hookNTFY
NTFY_RSPMDCX
MDCX_RSP
DLCXDLCX_RSP
DLCXDLCX_RSPBusy-tone
On-hook NTFYNTFY_RSP
RQNTRQNT_RSP
RQNTRQNT_RSP
1
2
3
4
5
6
78
9
1011
15
12
13
14
1617
18
Figure 1-9 MGCP call procedure between two endpoints in different MGs
It can be found that the call procedures illustrated in Figure 1-9 and Figure 1-8 are basically same. As shown in Figure 1-9, the MGCP call procedure between two endpoints in different MGs helps us easily understand some commands and responses, such as CRCX and MDCX. Only the events involved those are described. For the remaining events, refer to the section 1.3.2, earlier in this chapter.
1) Event 5: SoftX3000 sends a CRCX command to the MG1, indicating it to create a connection. The MG creates a connection as requested, and then sends a CRCX_RSP as the response to SoftX3000. The response contains some connection parameters, such as IP address, port number, bearer parameter and connection identifier. The connection parameters describe the connection information of the local gateway MG1. Judging from the following CRCX_RSP encoding, the “IP address” refers to the IP address of the MG1: 191.169.3.38.
2) Event 6: SoftX3000 sends a CRCX command to the MG2, indicating it to create a connection. The MG creates a connection as requested, and then sends a CRCX_RSP as the response to SoftX3000. The response contains some connection parameters, such as IP address, port number, bearer parameter and connection identifier. The connection parameters describe the connection information of the local gateway MG2. Judging from the following CRCX_RSP encoding, the “IP address” refers to the IP address of the MG2: 191.169.1.25.
3) Event 10: SoftX3000 sends an MDCX command to the MG2, requesting to modify the connection. The command carries some connection parameters of the MG1, that is, the parameters contained in the CRCX_RSP from the MG1. Subsequently, the connection mode is changed to be “sendrecv”. Judging from the following MDCX encoding, the command carries the IP address of the MG1, that is, 191.169.3.38, and other connection information of the MG1. Through the MDCX command, some connection parameters of the MG1 are provided to the MG2.
The MG2 sends to SoftX3000 an MDCX_RSP carrying the connection information of the local gateway (MG2). After negotiation, the MG1 and the MG2 determine PCMA as the encoding mode.
4) Event 11: SoftX3000 sends an MDCX command to the MG1, requesting to modify the connection. The command carries some connection parameters of the MG2, that is, the parameters contained in the CRCX_RSP from the MG2. Subsequently, the connection mode is changed to be “sendrecv”. Judging from the following MDCX encoding, the command carries the IP address of the MG2,
that is, 191.169.1.25, and other connection information of the MG2. Through the MDCX command, some connection parameters of the MG2 are provided to the MG1.
The MG1 sends to SoftX3000 an MDCX_RSP carrying the connection information of the local gateway. After negotiation, the MG1 and the MG2 determine PCMA as the encoding mode.
At this time, both the MG1 and the MG2 know the connection information of the local end and the opposite end. Conversation conditions are satisfied.
H.248 is the same type of protocol as MeGaCo and completed by the International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) and IETF together, used as a media gateway control protocol between a Media Gateway Controller (MGC) and a Media Gateway (MG). The ITU-T, the IETF, the International Softswitch Consortium (ISC), and other standardization organizations are optimizing the H.248 protocol currently. Famous telecommunication equipment vendors are investing much in the development and application of the H.248 protocol. Compared with the MGCP protocol, the H.248 protocol can support more types of access technologies and support the mobility of terminations. In addition, the H.248 protocol is characterized by its support for network applications of much larger scale and also by its convenience in the aspect of protocol extension. Therefore, the H.248 protocol is more outstanding in flexibility, and thus is replacing MGCP gradually to grow to be the standard of media gateway control protocols.
2.1.2 Related Terms
I. Termination
A Termination is a logical entity on an MG that sources and/or sinks media and/or control streams. A Termination is described by a number of characterizing properties, which are grouped in a set of descriptors that are included in commands. The media stream parameters, as well as modem, and bearer parameters are encapsulated within the Termination. Terminations have unique identities (TerminationIDs), assigned by the MG at the time of their creation.
II. Type of Termination
There are two types of terminations: semi-permanent terminations and ephemeral terminations. Terminations representing physical entities have a semi-permanent existence. For example, a Termination representing a TDM channel might exist for as long as it is provisioned in the gateway. Terminations representing ephemeral information flows, such as RTP flows, would usually exist only for the duration of their use.
Ephemeral Terminations are created by means of an Add command. They are destroyed by means of a Subtract command. In contrast, when a physical Termination
is Added to or Subtracted from a Context, it is taken from or to the null Context, respectively.
III. Termination function
Terminations may have signals applied to them. Signals are MG generated media streams such as tones and announcements as well as line signals such as hookswitch.
Terminations may be programmed to detect Events, the occurrence of which can trigger notification messages to the MGC, or action by the MG.
Statistics may be accumulated on a Termination. Statistics are reported to the MGC upon request (by means of the AuditValue command) and when the Termination is taken out of the call it is in.
IV. TerminationID
Terminations are referenced by a TerminationID, which is chosen by the MG. A wildcarding mechanism using two types of wildcards can be used with TerminationIDs. The two wildcards are ALL and CHOOSE. ALL is used to address multiple Terminations at a time. When ALL is used in the TerminationID of a command, the effect is identical to repeating the command with each of the matching TerminationIDs. CHOOSE is used to indicate to a media gateway that it must select a Termination satisfying the partially specified Terminations. This allows, for instance, that an MGC instructs an MG to choose a circuit within a trunk group.
For example, if there are TerminationIDs of R13/3/1, R13/3/2 and R13/3/3 in a text encoding of the protocol, the TerminationID R13/3/* would match all of them. There are some circumstances where ALL Terminations must be referred to. The TerminationID “*” suffices, and is referred to as ALL. The CHOOSE TerminationID “$” may be used when it is required to refer to one TerminationID but it is uncertain that the Termination exists exactly. In this way, the TerminationID R13/3/$ would match one of them.
V. Descriptor
Descriptor is a syntactic element of the protocol that groups related properties. For instance, the properties of a media flow on the MG can be set by the MGC by including the appropriate descriptor in a command.
VI. Termination Property
Terminations have properties. The properties have unique PropertyIDs. A series of descriptors are composed of the properties.
There are a number of common properties for Terminations and properties specific to media streams. The common properties are not specific to media streams and also called the termination state properties. For each media stream, there are local properties and properties of the received and transmitted flows. Properties not included in the base protocol are defined in Packages. These properties are referred to by a
name consisting of the PackageName and a PropertyID. Properties may be read-only or read/write. For properties that are read/write, the MGC can set their values.
When a Termination is Added to a Context, the value of its read/write properties by including the appropriate descriptors as parameters to the Add command. Properties not mentioned in the Add command retain their prior values. Similarly, a property of a Termination in a Context may have its value changed by the Modify command. Properties not mentioned in the Modify command retain their prior values. Properties may also have their values changed when a Termination is moved from one Context to another as a result of a Move command.
VII. Root Termination
A special TerminationID, “Root”, refers to the entire MG. When “Root” is included in a command as a parameter, the command can take effect on the entire gateway rather than a Termination within it.
VIII. Context
A Context is an association between a number of Terminations. The Context describes the topology and the media mixing and/or switching parameters if more than two Terminations are involved in the association. There is a special Context called the null Context. It contains Terminations that are not associated to any other Termination. For instance, in a decomposed access gateway, all idle lines are represented by Terminations in the null Context.
Figure 2-1 gives several examples of Termination and Context and is not meant to be an all-inclusive illustration.
The maximum number of Terminations in a Context is an MG property. Media gateways that offer only point-to-point connectivity might allow at most two Terminations per Context. Media gateways that support multipoint conferences might allow three or more Terminations per Context.
IX. Context attribute
The attributes of Contexts are:
ContextID: Context identifier, which should be 32-bit integers specified by the MG, and be unique within the scope of the MG. The encodings of special Contexts are shown in Table 2-1.
Table 2-1 Encodings of special Contexts
Context Binary encoding Text encoding Meaning
Context NULL 0 "_" Refers to Terminations that are not associated to any other Termination in the MG.
Context CHOOSE
0xFFFFFFFE "$" Refers to requesting the MG
to create a new Context.
Context ALL 0xFFFFFFFF "*" Refers to all Contexts in the
MG.
Topology: The topology of a Context describes the flow of media between the Terminations within a Context. In contrast, the mode of a Termination (send/receive/_) describes the flow of the media at the ingress/egress of the media gateway. There are three connection values: oneway (indicating the oneway media stream between two Terminations), bothway (indicating the bothway media stream between two Terminations), and isolate (indicating no media stream between two Terminations). The topology structure can only be used to describe a Context, and can be used in the “Add” and ”Modify” commands.
Priority: The priority is used for a Context in order to provide the MG with information about a certain precedence handling for a Context. 0 represents the lowest priority and 15 represents the highest priority.
Indicator for emergency call: An indicator for an emergency call is used for a Context to provide the MG with information about emergency handling for a Context. The MG would preferentially handle a call using an emergency indicator.
X. Package
Different types of gateways may implement Terminations that have widely differing characteristics. Variations in Terminations are accommodated in the protocol by allowing Terminations to have optional Properties, Events, Signals and Statistics
implemented by MGs. To achieve MG/MGC interoperability, such options are grouped into Packages, and a Termination realizes a set of such Packages. An MGC can audit a Termination to determine which Packages it realizes.
Properties, Events, Signals and Statistics defined in Packages, as well as parameters to them, are referenced by identifiers (IDs).
Definition of a Package is composed of Properties, Events, Signals, Statistics, and Procedures. Table 2-2 lists some packages commonly used.
Table 2-2 Basic packages
Package Package ID Description
Generic G Generic package for commonly encountered items.
Base Root Package Root This package defines Gateway wide
properties.
Tone Generator Package Tonegen
This package defines signals to generate audio tones. This package does not specify parameter values. It is intended to be extendable. Generally, tones are defined as an individual signal with a parameter, ind, representing “interdigit” time delay, and a tone id to be used with playtones. A tone id should be kept consistent with any tone generation for the same tone. MGs are expected to be provisioned with the characteristics of appropriate tones for the country in which the MG is located.
Tone Detection Package Tonedet
This package defines events for audio tone detection. Tones are selected by name (tone id). MGs are expected to be provisioned with the characteristics of appropriate tones for the country in which the MG is located.
Basic DTMF Generator Package
Dg This package defines the basic DTMF tones as signals and extends the allowed values of parameter tl of playtone in tonegen.
DTMF detection Package dd
This package defines the basic DTMF tones detection. This package extends the possible values of tone id in the “start tone detected”, “end tone detected” and “long tone detected” events.
Call Progress Tones Generator Package
cg
This package defines the basic call process tones as signals and extends the allowed values of parameter tl of playtone in tonegen.
This package defines the basic all progress detection tones. This package extends the possible values of tone id in the “start tone detected”, “end tone detected” and “long tone detected” events.
Analog Line Supervision Package
al This package defines events and signals for an analog line.
Basic Continuity Package ct
This package defines events and signals for continuity test. The continuity test includes provision of either a loopback or transceiver functionality.
Network Package nt This package defines properties of network terminations independent of network type.
RTP Package rtp This package is used to support packet based multimedia data transfer by means of the Real-time Transport Protocol (RTP).
TDM Circuit Package tdmc This package is used to support TDM circuit
terminations.
Table 2-3 lists some Properties, Events, and Signals commonly used in Packages. The general formats are PackageID/PropertyID, PackageID/EventID, and PackageID/Signal.
Table 2-3 Examples of PropertyIDs, EventIDs and Signals
Event Meaning
al/fl Flashhook event in the Analog Line Supervision Packages
al/of Offhook event in the Analog Line Supervision Packages
al/on Onhook event in the Analog Line Supervision Packages
al/ri Ring signal in the Analog Line Supervision Packages
cg/bt Busy tone signal in the Call Progress Tones Generator Packages
cg/ct Congestion tone signal in the Call Progress Tones Generator Packages
cg/cw Call waiting tone signal in the Call Progress Tones Generator Packages
cg/dt Dial tone signal in the Call Progress Tones Generator Packages
cg/rt Ringing tone signal in the Call Progress Tones Generator Packages
dd/ce DigitMap Completion event in the DTMF detection Packages
nt/jit Maximum jitter buffer in milliseconds in the Network Packages
tdmc/ec Echo cancellation property in the TDM Circuit Packages
tdmc/gain Gain control property in the TDM Circuit Packages
2.1.3 Structure of Protocol Stack
H.248 messages are transported over UDP/IP. In addition, the messages can be transported over other transport protocols, such as Transmission Control Protocol (TCP), Stream Control Transmission Protocol (SCTP) and Signaling System No. 7 Message Transfer Part 3-User Adaptation Layer (M3UA) borne over the IP network, and Message Transfer Part Broadband (MTP3-B) borne over Asynchronous Transfer Mode (ATM).
The transport layer of the H.248 protocol in SoftX3000 may be UDP/TCP/SCTP borne over IP and MTP3-B borne over ATM, as shown in Figure 2-2.
H.248
UDP/TCP/SCTP
IP
MAC
Figure 2-2 H.248 protocol stack in SoftX3000
The H.248 protocol assumes that the transport network under it is not reliable, thus the state and reliability of a transaction is achieved by the protocol itself.
2.1.4 Implementation in SoftX3000
As shown in Figure 2-3, H.248 is implemented in SoftX3000 for communication between the SoftSwitch and Trunk Media Gateways (TMGs) as well as communication between the SoftSwitch and Access Media Gateways/Integrated Access Devices (AMGs/IADs).
SoftX3000 communicates with the trunk gateways through the H.248 protocol. SoftX3000 provides the H.248 MGC functionality to control Integrated Services Digital Network User Part (ISUP) trunks in the trunk gateways. H.248 MGC provides the following functions:
1) RTP capability negotiation for egress and ingress gateways
The receiving and transmitting RTP capabilities of each H.248 MG will be configured. SoftX3000 will ensure that a matching capability set between the two MGs will be used to establish the call.
2) Management of Public Switched Telephone Network (PSTN) ISUP trunks in TMG through the H.248 protocol
Supporting reservation of trunks on TMG Supporting release of trunks on TMG Supporting Hairpin connection of trunks on TMG Supporting modification of trunk parameters Applying tones to trunks Supporting a trunk (or a group of trunks) going out of service and being brought
back to service 3) Management of ephemeral RTP Terminations in TMG through the H.248 protocol
Supporting creation of ephemeral Terminations Supporting destruction of ephemeral Terminations Supporting modification of RTP parameters on ephemeral Terminations
The H.248 protocol defines eight commands for manipulating the logical entities of the protocol connection model, Contexts and Terminations. Commands provide for complete control of the properties of Contexts and Terminations.
Most commands are for the specific use of the MGC as command initiator in controlling MGs as command responders. The exceptions are the Notify and ServiceChange commands: Notify is sent from MG to MGC, and ServiceChange may be sent by either entity.
H.248 commands and meanings are shown in Table 2-4.
Table 2-4 H.248 commands
Command name
Command code Description
Add ADD
MGC→MG. The Add command adds a Termination to a Context. If no ContextID is specified, a Context will be first generated and then a Termination is added into it.
Modify MOD MGC→MG. The Modify command modifies the properties, events and signals of a Termination.
Subtract SUB
MGC→MG. The Subtract command disconnects a Termination from its Context and returns statistics on the Termination’s participation in the Context. The Subtract command on the last Termination in a Context deletes the Context.
Move MOV MGC→MG. The Move command atomically moves a Termination to another Context.
AuditValue AUD_VAL MGC→MG. The AuditValue command returns the current state of properties, events, signals and statistics of Terminations.
AuditCapabilities AUD_CAP MGC→MG. The AuditCapabilities command returns a collection of termination capabilities.
Notify NTFY MG→MGC. The Notify command allows the MG to inform the MGC of the occurrence of events in the MG.
MGC↔MG or MG→MGC. The ServiceChange command allows the MG to notify the MGC that a Termination or group of Terminations is about to be taken out of service or has just been returned to service. ServiceChange is also used by the MG to announce its availability to an MGC (registration), and to notify the MGC of impending or completed restart of the MG. The MGC may announce a handover to the MG by sending it a ServiceChange command.
II. Response
All H.248 commands are acknowledged. The structure of a response is basically the same as that of a command. TransactionID correlates a command with its response.
There are two types of responses, namely Reply and Pending. “Reply” indicates the execution of the command has been completed and returns information about the execution success or failure. “Pending" indicates the command is actively being processed but has not been completed. It is used to prevent the sender from assuming the TransactionRequest was lost where the command will take some time to complete.
2.2.2 Message Structure
I. Command format
1) Encapsulation format for command
A message is an information unit sent or received by the H.248 protocol. In the H.248 protocol, one ore more commands are encapsulated in a message.
A message may be encoded in a binary format or in a text format. In the case of binary codes, specifications defined in ITU-T X.680 (ASN.1) are used for description, and BER rules defined in X.690 for encoding; in the case of text format, RFC 2234 ABNF specifications are followed. MGCs should support both encoding formats. MGs may support one of or both formats. Any H.248 message shares the same structure as shown in Figure 2-4.
Messages start with a header which is followed by several transactions. The header contains a Message Identifier (MID) and a Version Number. The MID identifies the sender of the message which may be a domain address, domain name or device name. Domain name is a suggested default. The Version Number identifies the version of the protocol the message conforms to. Versions consist of one or two digits, beginning with version 1 for the present version of the protocol.
Transaction
A message contains one or more transactions. The transactions in a message are treated independently. There is no order implied.
Transactions include requests and responses, and responses are divided into two types: TransactionReply and TransactionPending. Commands are encapsulated in transaction requests which are described here. For the structure of transaction responses, refer to the description later in this chapter.
There is one Transaction per request invocation. A transaction contains one or more actions and each action includes one or more commands related to a single Context. The structure is as follows:
Actions are related to Contexts. Actions are identified by a ContextID. In an action, commands should be processed in order.
An action begins with the Context header (CtxHdr) in which ContextID is contained for identifying the Context this action corresponds to. ContextID is assigned by the MG and is unique within the scope of the MG. The MGC shall use the ContextID in all subsequent transactions relating to that Context.
CtxHdr is followed by several commands, and these commands are related to the Context identified by the ContextID.
Command
Commands are the major contents in an H.248 message. They control the Context and Termination attributes including specifying the topology structure of the Context and specifying the event reported by the Termination, for example, what signals and actions can be imposed on the Termination. A command is composed of the command header (CMDHdr) and command parameters. In the H.248 protocol, command parameters are grouped into “Descriptors”.
The H.248 message mechanism is shown in Figure 2-5.
Message
TransactionID1
TransactionIDn
ContextID1
ContextIDn
CMD1Command
CMDn
Des-nDes-1Descriptor
...
...
Figure 2-5 Message mechanism
2) Descriptor
The parameters to a command are termed Descriptors. A descriptor consists of a name and a list of items. Some items may have values. Many commands share common descriptors. Descriptors may be returned as output from a command. In any such return of descriptor contents, an empty descriptor is represented by its name unaccompanied by any list.
In general, the text format of descriptors is as follows:
DescriptorName=<someID> { parm = value, parm = value ...... }
The H.248 protocol defines 19 types of descriptors. Those commonly used descriptors are described below.
Modem (MD) descriptor
The Modem descriptor specifies the modem type and other parameters. The descriptor includes the following modem types: V.18, V.22, V.22bis, V.32, V32bis, V.34, V.90, V.91, Synchronous ISDN, and allows for extensions. By default, no Modem descriptor is present in a Termination.
Mux (MX) descriptor
In multimedia calls, a number of media streams are carried on a (possibly different) number of bearers. The multiplex (Mux) descriptor associates the media and the bearers. The descriptor includes the multiplex type: H.221, H.223, H.226, V.76, and possible extensions. Definition of the Mux descriptor is composed of the multiplex type and a set of TerminationIDs representing the multiplexed inputs. For example,
Mux=H.221{ MyT3/1/2,MyT3/2/3,MyT3/3/6,MyT3/21/22}
Media (M) descriptor
The Media descriptor specifies the parameters for all the media streams. These parameters are structured into two descriptors, a Termination State descriptor, which specifies the properties of a Termination that are not stream dependent, and one or more Stream descriptors each of which describes a single media stream.
A stream is identified by a StreamID. There are three types of Stream descriptors, namely LocalControl, Local, and Remote. As a convenience, a LocalControl, Local, or Remote descriptor may be included in the Media descriptor without an enclosing Stream descriptor. In this case, the StreamID is assumed to be 1. The relationship between these descriptors is like this:
Media Descriptor TerminationStateDescriptor Stream Descriptor LocalControl Descriptor Local Descriptor Remote Descriptor Termination State (TS) descriptor
The Termination State descriptor contains the ServiceStates property, the EventBufferControl property and properties of a Termination (defined in Packages) that are not stream specific. The ServiceStates (SI) property describes the overall state of the Termination. A Termination can be in one of the following states: “test” (TE), “out of service” (OS), or “in service” (IV). The “test” state indicates that the Termination is being tested. The state “out of service” indicates that the Termination cannot be used for traffic. The state “in service” indicates that a Termination can be used or is being used for normal traffic. “in service” is the default state.
The EventBufferControl (EB) property specifies whether events are buffered following detection of an event in the Events descriptor, or processed immediately.
Stream (ST) descriptor
A Stream descriptor specifies the parameters of a single bi-directional stream. There are three types of Stream descriptors, namely LocalControl, Local, and Remote. The Stream descriptor includes a StreamID which identifies the stream. Streams are created by specifying a new StreamID on one of the Terminations in a Context. A stream is deleted by setting empty Local and Remote descriptors for the stream with ReserveGroup and ReserveValue in LocalControl set to “false” on all Terminations in the Context that previously supported that stream.
StreamIDs are of local significance between the MGC and the MG, and they are assigned by the MGC. Within a Context, StreamID is a means by which to indicate which media flows are interconnected: streams with the same StreamID are connected.
LocalControl (O) descriptor
The LocalControl descriptor contains the Mode (MO) descriptor, the ReserveGroup (RG) and ReserveValue (RV) properties and properties of a Termination (defined in Packages) that are stream specific.
The allowed values for the Mode property are send-only (SO), receive-only (RC), send/receive (SR), inactive (IN) and loop-back (LB). “Send” and “receive” are with respect to the exterior of the Context, so that, for example, a stream set to mode=sendonly does not pass received media into the Context. Signals and Events are not affected by mode.
The Boolean-valued Reserve properties, ReserveValue and ReserveGroup, of a Termination indicate what the MG is expected to do when it receives a local and/or remote descriptor.
Local (L) and Remote (R) descriptors
The Local descriptor refers to the media received by the MG, and the Remote descriptor refers to the media sent by the MG.
The MGC uses Local and Remote descriptors to reserve and commit MG resources for media decoding and encoding for the given Stream(s) and Termination to which they apply. The MG includes these descriptors in its response to indicate what it is actually prepared to support. The MG shall include additional properties and their values in its response if these properties are mandatory yet not present in the requests made by the MGC.
When text encoding the protocol, the Local and Remote descriptors consist of session descriptions as defined in SDP (RFC 2327).
Events (E) descriptor
The Events descriptor contains a RequestIdentifier and a list of events that the MG is requested to detect and report. The RequestIdentifier is used to correlate the request
with the notifications that it may trigger. Requested events include, for example, fax tones, hookflash, and on-hook and off-hook transitions.
Each event in the descriptor contains the Event name, optional actions, and optional parameters. The Event name consists of a Package Name (where the event is defined) and an EventID in the format of PackageName/EventID. For example, al/on indicates the onhook event in the Analog Line Supervision Packages. Events can have parameters which are defined and named in the Package. The actions parameter indicates one or more possible actions to be taken at the occurrence of an event.
EventBuffer (EB) descriptor
The EventBuffer descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep.
Signals (SG) descriptor
A SignalsDescriptor is a parameter that contains the set of signals that the MG is asked to apply to a Termination. A SignalsDescriptor contains a number of signals and/or sequential signal lists. A SignalsDescriptor may contain zero signals and sequential signal lists. Signals shall be named with a Package name (in which the signal is defined) and a SignalID in the format of PackageName/SignalID.
For example, SG{SL=0{cg/dt}}.
In which, “SL” is the abbreviation of SignalList, and “cg/dt” indicates the dial tone signal in the Call Progress Tones Generator Packages.
There are three types of signals:
on/off: The signal lasts until it is turned off;
timeout: The signal lasts until it is turned off or a specific period of time elapses;
brief: The signal duration is so short that it will stop on its own unless a new signal is applied that causes it to stop; no timeout value is needed.
Audit (AT) descriptor
An Audit command (AuditValue and AuditCapabilities commands) specifies what information is to be audited. Possible items are:
The ServiceChange descriptor specifies the reason of a ServiceChange and contains the following parameters:
The ServiceChangeMethod (MT) parameter specifies the type of ServiceChange that will occur or has occurred. This parameter may be one of the six methods of ServiceChange:
Graceful: Indicates that the specified Terminations will be taken out of service after the specified ServiceChangeDelay; established connections are not yet affected, but the
MGC should refrain from establishing new connections and should attempt to gracefully tear down existing connections on the Termination(s) affected by the ServiceChange command.
Forced: Indicates that the specified Termination(s) were taken abruptly out of service and any established connections associated with them were lost.
Restart: Indicates that service will be restored on the specified Terminations after expiration of the ServiceChangeDelay.
Disconnected: Always applied with the Root TerminationID, indicates that the MG lost communication with the MGC, but it was subsequently restored. Since the MG state may have changed, the MGC may wish to use the Audit command to resynchronize its state with the MG’s.
Handoff: Sent from the MGC to the MG, this reason indicates that the MGC is going out of service and a new MGC association must be established. Sent from the MG to the MGC, this indicates that the MG is attempting to establish a new association in accordance with a Handoff received from the MGC with which it was previously associated.
Failover: Sent from the MG to the MGC to indicate the primary MG is out of service and a secondary MG is taking over.
The ServiceChangeReason (RE) parameter specifies the reason why the ServiceChange has occurred or will occur. It consists of an alphanumeric token (IANA registered) and, optionally, an explanatory string. The following parameter values in Table 2-5 are defined:
The optional ServiceChangeAddress parameter specifies the address, for example, IP port number for IP networks, to be used for subsequent communications.
The optional ServiceChangeDelay parameter is expressed in seconds.
The optional ServiceChangeProfile parameter specifies the profile, if any, of the protocol supported. The ServiceChangeProfile includes the version of the profile supported.
The optional ServiceChangeVersion parameter contains the protocol version and is used if protocol version negotiation occurs.
The ServiceChangeMGCId parameter can be returned by the MGC to the MG, describing the MGC that should preferably be contacted for further service by the MG. In this case, the MG shall reissue the ServiceChange command to the new MGC. The MGC specified in a ServiceChangeMgcId, if provided, shall be contacted before any further alternate MGCs. On a HandOff message from the MGC to the MG, the ServiceChangeMgcId is the new MGC that will take over form the current MGC.
The optional TimeStamp parameter specifies the actual time as kept by the sender. It can be used by the responder to determine how its notion of time differs from that of its correspondent.
The Extension parameter may contain any value whose meaning is mutually understood by the MG and the MGC.
DigitMap (DM) descriptor
A DigitMap is a dialing plan resident in the Media Gateway used for detecting and reporting digit events received on a Termination. The DigitMap descriptor contains a DigitMap name and the DigitMap to be assigned.
The collection of digits according to a DigitMap may be protected by three timers, that is, a start timer (T), short timer (S), and long timer (L). The timers are configurable parameters to a DigitMap. The start timer is started at the beginning of every digit map use, but can be overridden.
The start timer (T) is used prior to any digits having been dialed.
If the Media Gateway can determine that at least one more digit is needed for a digit string to match any of the allowed patterns in the digit map, then the interdigit timer value should be set to a long (L) duration, for example, 16 seconds.
If the digit string has matched one of the patterns in a digit map, but it is possible that more digits could be received which would cause a match with a different pattern, then instead of reporting the match immediately, the MG must apply the short timer (S), for example, 8 seconds, and wait for more digits.
For more information on digit map, refer to MGCP protocol, earlier in this manual.
Statistics (SA) descriptor
The Statistics descriptor provides information describing the status and usage of a Termination during its existence within a specific Context. The particular statistical properties that are reported for a given Termination are determined by the Packages realized by the Termination. By default, statistics are reported when the Termination is Subtracted from the Context. Statistics may also be returned from the AuditValue command, or any Add/Move/Modify command using the Audit descriptor.
Packages (PG) descriptor
Used only with the AuditValue command, the Packages descriptor returns a list of Packages realized by the Termination.
ObservedEvents (OE) descriptor
ObservedEvents is supplied with the Notify command to inform the MGC of which event(s) were detected. Used with the AuditValue command, the ObservedEvents descriptor returns events in the event buffer which have not been notified. ObservedEvents contains the RequestIdentifier of the EventsDescriptor that triggered the notification, the event(s) detected and the detection time(s). Detection times are reported with a precision of hundredths of a second.
Topology (TP) descriptor
A Topology descriptor is used to specify flow directions between Terminations in a Context. The Topology descriptor applies to a Context instead of a Termination. The default topology of a Context is that each Termination’s transmission is received by all other Terminations. The Topology descriptor is optional to implement.
A Topology descriptor consists of a sequence of triples of the form (T1, T2, association). T1 and T2 specify Terminations within the Context, possibly using the ALL or CHOOSE wildcard. The association specifies how media flows between these two Terminations are follows:
(T1, T2, isolate) means that the Terminations matching T2 do not receive media from the Terminations matching T1, nor vice versa.
(T1, T2, oneway) means that the Terminations that match T2 receive media from the Terminations matching T1, but not vice versa.
6 T1, T2, Bothway (T2, T3 bothway and T1, T3 bothway may be implied or explicit.) All Terminations have a bothway connection to all other Terminations.
Error (ER) descriptor
If a Transaction execution encounters an error, the reply of the command shall contain an Error descriptor. The Notify command may also contain an Error descriptor. Errors consist of an IANA registered error code and an explanatory string. Sending the explanatory string is optional.
Table 2-7 Identified error codes
Error code Meaning
400 Bad Request
401 Protocol Error
402 Unauthorized
403 Syntax Error in Transaction
406 Version Not Supported
410 Incorrect identifier
411 The transaction refers to an unknown ContextID
412 No ContextIDs available
421 Unknown action or illegal combination of actions
422 Syntax Error in Action
430 Unknown TerminationID
431 No TerminationID matched a wildcard
432 Out of TerminationIDs or No TerminationID available
433 TerminationID is already in a Context
434 Number of Terminations in a Context exceeds the maximum value
MOD (TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescriptor][,EventBufferDescriptor][,SignalsDescriptor][,DigitMapDescriptor][,AuditDescriptor])
The 1st line: The MeGaCo protocol version is 1. The MID is the identifier of the sender of this message. In this case, it is the IP address of and port [191.169.150.170]:2944.
The 2nd line: The TransactionID is 372794021, used to correlate the request with the responses that it will trigger.
The 3rd line: In this case, the encapsulated Context in this Transaction is null.
The 4th line: The Modify command, used to modify the properties, events and signals of the Termination A0.
The 5th line: The Events descriptor with the RequestIdentifier “369099784”. The RequestIdentifier is used to correlate the request with the notifications that it may trigger.
The 6th line: The MGC requests the MG to detect two events that will happen in the termination A0. One event is digit collection according to the dial plan (dmap1) specified by the digit map. The other event is detection of all events defined in the Analog Line Supervision Packages (al).
The 7th line: The Signals descriptor. It indicates that the MGC requests the MG to send the dial tone to the termination A0.
The 8th line: The DigitMap descriptor. The MGC delivers the dial plan (dmap1) to the termination A0.
The 9th line: The dial plan “dmap1”. In the dial plan, “[2-9]xxxxxx” indicates that user can dial any 7-digit number started with an integer in the range of 2 to 9. “13xxxxxxxxx” indicates any 11-digit number started with 13. “0xxxxxxxxx” indicates any 10-digit number started with 0. “9xxxx” indicates any 5-digit number started with 9. “1[0124-9]x” indicates any 3-digit number started with 1 which is followed by a decimal integer except 3. “E” is the letter “E”. “[0-9EF].L” indicates that any length of digits started with 0 ~ 9, E or F are reported after an expiration of the long timer.
II. Response format
1) Encapsulation format for response
The same as the encapsulation format for command. Here, we will detail two types of transactions of responses.
Transactions include requests and responses, and responses are divided into two types: TransactionReply and TransactionPending. For the encapsulation command of the Transaction Request, refer to the preceding section.
Transaction Reply
Transaction Reply is a response of the transaction receiver to the Transaction Request. Every transaction should have its Reply. A TransactionRequest stops being executed
either if all commands in the TransactionRequest have been carried out successfully or a failure is encountered during the execution of a non-optional command in the TransactionRequest.
The receiver invokes the Transaction Pending. A Transaction Pending indicates that the transaction is actively being processed, but has not been completed. It is used to prevent the sender from assuming the TransactionRequest was lost where the command will take some time to complete. The structure of Transaction Pending is as follows:
TransactionPending (TransactionID { } ) Transactions are presented as TransactionRequests. Corresponding response to a TransactionRequest is received in a single reply, possibly preceded by a number of TransactionPending messages.
2) Response descriptors
For response descriptors, refer to the description of command descriptors, earlier in this chapter.
3) Response expressions
What are within the parenthesis preceded by the command name are response parameter values. Those enclosed by […] are optional.
MOD (TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescriptor][,SignalsDescriptor][,DigitMapDescriptor][,ObservedEventsDescriptor][,EventBufferDescriptor][,StatisticsDescriptor][,PackagesDescriptor])
Subtract
SUB (TerminationID[,MediaDescriptor][,ModemDescriptor][,MuxDescriptor][,EventsDescript
The following is a text encoding sample of a transaction response.
MEGACO/1 [191.169.150.172]:2944
P=372794021{
C= - {
MF=A0}}
The 1st line: The MeGaCo protocol version is 1. The MID is the identifier of the sender of this message. In this case, it is the IP address of and port [191,169,150,172]:2944.
The 2nd line: TransactionID. The TransactionID of the response is 372794021, which is the same as the TransactionID described in the command sample, used to correlate the command with the response.
The 3rd line: Here the Context is null.
The 4th line: Acknowledgement that the Termination A0 has received the TransactionRequest from the MGC, indicating that the MG is executing it.
An H.248 MG must register with SoftX3000 before providing services. Currently, the supported protocol stack version is 1.0. If the protocol stack version implemented in the opposite end is later or earlier than that, the MG responds with Error 406 Version Not Supported, indicating a registration failure. The registration procedure is illustrated in Figure 2-7.
SoftX3000MG
SVC_CHG_REQ
SVC_CHG_REPLY
Figure 2-7 MG registration procedure
1) Event 1: The H.248 MG sends a SVC_CHG_REQ message to SoftX3000 for registration. The following is the text description of the SVC_CHG_REQ command.
MEGACO/1 [191.169.150.172]:2944
T=3{
C= - {
SC=ROOT{
SV{
MT=RS,RE=902}}}}
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent from the MG to the MGC. The IP address and port of the MG is [191.169.150.172]:2944.
The 2nd line: The TransactionID is “3”.
The 3rd line: Here the Context is null.
The 4th line: The ServiceChange command. The TerminationID is ROOT, indicating that the command refers to the entire gateway.
The 5th line: The encapsulated ServiceChange descriptor in the ServiceChange command.
The 6th line: The parameters contained in the ServiceChange descriptor, indicating the ServiceChange method is Restart and the reason is Warm Boot.
2) Event 2: On receipt of the registration message from the MG, the MGC sends a reply to the MG. The following is the text description of the SVC_CHG_REPLY.
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent from the MGC to the MG. The IP address and port of the MGC is [191.169.150.170]:2944.
The 2nd line: The TransactionID is “3”, and the Context is null. The ServiceChange command refers to the entire gateway, indicating that the MGC has received the registration transaction from the MG and responds to the MG that the registration is completed successfully.
2.3.2 Gateway Cancellation Procedure
To take out of service, an H.248 MG needs to cancel the registration to SoftX3000. The cancellation procedure is illustrated in Figure 2-8.
SoftX3000MG
SVC_CHG_REQ
SVC_CHG_REPLY
Figure 2-8 MG cancellation procedure
1) Event 1: The MG sends a SVC_CHG_REQ command to SoftX3000 for cancellation. The ServiceChangeMethod in the command is set to Graceful or Forced. The following is the text description of the SVC_CHG_REQ command.
MEGACO/1 191.169.150.172]:2944
T= 9998 {C= - {
SC = ROOT {
SV {
MT= FO, RE = 905}}}}
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent from the MG to the MGC. The IP address and port of the MG is [191.169.150.172]:2944.
The 2nd line: The TransactionID is “9998”, and the encapsulated Context in the Transaction is null.
The 3rd line: The ServiceChange command. The TerminationID is ROOT, indicating that the command refers to the entire gateway.
The 5th line: The parameters contained in the ServiceChange descriptor, indicating that the ServiceChange method is Forced and the reason is Termination taken out of service.
2) Event 2: SoftX3000 responds with a message. The following is the text description of the SVC_CHG_REPLY.
MEGACO/1 [191.169.150.170]:2944
P=9998{C= - {SC=ROOT{ER=505}}}
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent from the MGC to the MG. The IP address and port of the MGC is [191.169.150.170]:2944.
The 2nd line: The TransactionID is “9998”, and the Context is null. The ServiceChange command refers to the entire gateway, with the Error 505 Command Received Before Restart Response.
2.3.3 Gateway Initialization Procedure
After the MG completes a successful registration procedure, the MGC will modify the properties of all semi-permanent Terminations of the MG contained in the null Context and instruct the MG to detect off-hook events. At this time, the Termination can receive or originate calls.
It is assumed that three semi-permanent Terminations including A0, A1 and A3 are configured on the MG. The MGC will respectively send an MOD_REQ command to the three Terminations for initialization purposes. Here we illustrate the specific message interaction by using the Termination A0.
1) Event 1: After a successful registration, the MGC sends a modification command to modify the properties of the Terminations of the MG in the null Context. The following is the text description of the MOD_REQ command.
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent from the MGC to the MG. The IP address and port of the MGC is [191.169.150.170]:2944.
The 2nd line: The TransactionID is “372794419”, and a null Context is encapsulated in the Transaction.
The 3rd line: The Modify command, to modify the properties of the Termination A0.
The 4th line: The Events descriptor with the RequestIdentifier “369099777”. The MGC requests the MG to detect all events including off-hook events in the Analog Line Supervision Packages that will happen in the Termination A0.
The 5th line: The Signals descriptor. Here the signal is null, indicating the MGC requires the MG to stop any signal played currently.
2) Event 2: On receipt of the Modify command, the MG responds with a reply. The following is the text description of the MOD_REPLY.
MEGACO/1 [191.169.150.172]:2944
P=372794419{
C= - {MF=A0}}
2.3.4 Successful Termination Call Procedure
A call setup and release procedure between two Terminations in the same MG is illustrated in Figure 2-10. The call setup and release procedure between two Terminations in different MGs is basically the same and thus not detailed in this chapter.
In the procedure, it is assumed that
The physical TerminationID of the Termination1 is A0, which is connected to the UserA;
The physical TerminationID of the Termination2 is A1, which is connected to the UserB;
The UserA makes a call to the UserB, and the calling party hooks on first; The IP address and port of SoftX3000 is 191.169.200.61:2944; The IP address and port of the MG is 191.169.150.122:2944.
Figure 2-10 H.248 call procedure between two Terminations in the same MG
1) Event 1: Upon detecting that the UserA in the Termination A0 hooks off, the MG sends an NTFY_REQ command to notify SoftX3000 of the off-hook event. SoftX3000 acknowledges the receipt of the off-hook event in a reply message.
NTFY_REQ text description MEGACO/1 [191.169.150.122]:2944
T=883{C= - {
N=A0{
OE=369109250{al/of}}}}
The 1st line: The MeGaCo protocol. The protocol version is 1. The command is sent from the MG to the MGC. The IP address and port of the MG is [191.169.150.122]:2944.
The 2nd line: The TransactionID is “883”, and the encapsulated Context in the Transaction is null.
The 3rd line: The Notify command, which refers to the Termination A0.
The 4th line: The ObservedEvents descriptor. In this case, the TerminationA resident MG detects the off-hook event and reports the event to SoftX3000. The RequestIdentifier is 369109250, which is the same as the RequestIdentifier contained in the request that triggers NTFY_REQ.
NTFY_REPLY text description MEGACO/1 [191.169.200.61]:2944
P=883{C= - {
N=A0}}
2) Event 2: On receipt of the off-hook event, SoftX3000 sends an MOD_REQ command to instruct the MG to play the dial tone to the UserA at the Termination A0 and request the MG to detect on-hook events. In addition, SoftX3000 notifies the Termination A0 of the digit map (dmap1), based on which digits will be collected. The Termination A0 sends an MOD_REPLY to SoftX3000 as the response of the MOD_REQ and sends the dial tone to the UserA.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
For details of the parameters, refer to the command sample, earlier in this chapter.
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=372771555{
C= - {
MF=A0}}
For details of the parameters, refer to the response sample, earlier in this chapter.
3) Event 3: The UserA dials a number. The Termination A0 collects the dialed digits and tries to match the digit map. In the case of a successful match, the Termination A0 sends an NTFY_REQ command to SoftX3000. SoftX3000 acknowledges the receipt of the NTFY_REQ, sent by the A0, with an NTFY_REPLY.
NTFY_REQ text description MEGACO/1 [191.169.150.122]:2944
The 1st line: The command is sent by the MG to the MGC. The IP address and port of the MG is [191.169.150.122]:2944.
The 2nd line: The TransactionID is 884. In this case, the encapsulated Context in this Transaction is null. SoftX3000 is designed to create a Context after the calling party dials the called number, to avoid wasting resources in the event that the calling party hooks off but does not dial a number or, even dials a number, the dialed number is found inexistent or other reasons.
The 3rd line: The Notify command, which refers to the Termination A0.
The 4th line: The ObservedEvents descriptor. The RequestIdentifier is 369109251. It is the same as the RequestIdentifier of the preceding MOD_REQ, indicating this notification is triggered by that MOD_REQ command.
The 5th line: The TimeStamp for reporting the DigitMap event. “20030429T06132700” indicates 06:13:27 A.M. on April 29th 2003.
The 6th line: What is observed by the Termination A0 is a DigitMap Completion event in the DTMF detection package. This event has two parameters: Termination Method (Meth) and DigitString (ds).
The DigitMap Termination Method (Meth) has three possible values:
UM: Unambiguous match. If exactly one candidate alternative event sequence remains and it has been fully matched, a completion event is generated indicating an unambiguous match.
PM: Partial match. At each step, a timer is set to wait for the next event, based either on the default timing rules given above or on explicit timing specified in one or more alternative event sequences. If the timer expires and part or none of any candidate alternative event sequence is satisfied, a timeout completion with partial match is reported.
FM: Full match. If the timer expires and a member of the candidate set of alternative event sequences is fully satisfied, a timeout completion with full match is reported.
The DigitString (ds), in this case, indicates what the UserA dials is 6540100.
NTFY_REPLY text description MEGACO/1 [191.169.200.61]:2944
P=884{C= - {
N=A0}}
4) Event 4: The MGC creates a new Context in the MG and adds a TDM Termination and a RTP Termination in the Context. The MG responds with an ADD_REPLY with a new allocated connection descriptor and a new RTP termination descriptor.
The 1st line: The command is sent by the MGC to the MG. The IP address and port of the MGC is [191.169.200.61]:2944.
The 2nd line: The TransactionID is “369363687”.
The 3rd line: “$” indicates that the MG is requested to create a new Context. “$” is used because the Context is not determined currently.
The 4th line: The ADD command, used to add the Termination A0 to the new Context.
The 5th line: The Media descriptor. The LocalControl (O) descriptor, in this case, indicates that the Termination A0 has a “send/receive” mode property, “OFF” ReserveGroup property, and “OFF” ReserveValue property.
The 7th line: The Events descriptor. The RequestIdentifier is 369109253. The MGC requests the MG to detect all events in the Analog Line Supervision Packages that will happen, such as on-hook events.
The 7th line: The Signals descriptor. Here the signal is null, indicating the MGC requires the MG to stop any signal played currently.
The 8th line: The ADD command, used to add a RTP Termination to the new Context. The new RTP Termination is ephemeral. Because the descriptor for the RTP Termination is not determined yet, “$” is used.
The 9th line: The Media descriptor. The LocalControl (O) descriptor, in this case, indicates that the RTP Termination has an “inactive” mode property, “OFF” ReserveGroup property, and “OFF” ReserveValue property. “nt/jit=40” indicates that the maximum jitter buffer in the Network Packages is 40 milliseconds.
The 10th line: The MGC suggests a set of Local descriptor parameters for the new RTP Termination. “v=0” indicates that the SDP protocol version is 0. “c=IN IP4 $” indicates the Context information of the RTP Termination, that is, the network indicator of the Context is Internet, the type of address for the Context is IP4, and the local IP address is unknown currently. “m=audio $ RTP/AVP 8” indicates the media description of the new RTP Termination suggested by the MGC. “audio” indicates that the type of media for the RTP Termination is audio. “$” indicates that the media port number for the RTP Termination is unknown currently. “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media
service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP (audio/video application document, transported over UDP) and Udp (the UDP protocol). For audio and video signals, “8” represents the type of media payload defined in the RTP audio/video application document. It indicates that the MGC suggests G.711A as the media encoding format for the RTP Termination.
The mapping relationship from RTP payload type to encoding defined in the H.248 protocol is as follows:
The 1st line: The command is sent by the MG to the MGC. The IP address and port of the MG is [191.169.150.122]:2944.
The 2nd line: The TransactionID is “369363687”. “C=286” indicates that the requested Context is created and the MG assigns an identifier “286” to identify the created Context.
The 3rd line: It is confirmed that the physical Termination A0 and the ephemeral Termination A100000034 have been added in the Context 286.
The 4th line: The Media descriptor.
The 5th line: Requested by the MGC, the MG confirms G.711A as the media encoding format for the Termination A100000034, sets its RTP port number to be 18300, and fills the local IP address to be 191.169.150.122.
5) Event 5: The MGC conducts the analysis of the called number and determines the called UserB is connected to the physical Termination A1 in the MG. Therefore, the MGC sends an ADD_REQ, requesting the MG to add the physical Termination A1 and a certain RTP Termination to a new Context. The MG responds with an ADD_REPLY with a new allocated connection descriptor “287” and a new RTP termination descriptor “A100000035”. Requested by the MGC, the MG determines G.711A as the codec type for the Termination A100000035 of the MG, sets its RTP port number to be 18296, fills the local IP address to be 191.169.150.122, and sets the Termination A100000035 to be in the inactive mode.
ADD_REQ text description MEGACO/1 [191.169.200.61]:2944
For details of the parameters, refer to Event 4, earlier in this section.
6) Event 6: The MGC sends an MOD_REQ command to the Termination A1, to modify the properties of the Termination A1 and request the MG to play the ringing tone to the UserB. The MG acknowledges with an MOD_REPLY, and meanwhile the MG plays the ringing tone to the UserB.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372771561{C=287{
MF=A1{
E=369108999{al/*},
SG{al/ri}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=372771561{C=287{MF=A1}}
7) Event 7: The MGC sends an MOD_REQ command to the Termination A0, to modify the properties of the Termination A0 and request the MG to play the ringback tone to the UserA. The MG acknowledges with an MOD_REPLY, and meanwhile the MG plays the ringback tone to the UserA.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372771562{C=286{
MF=A0{
E=369109256{al/*},
SG{cg/rt}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
8) Event 8: The called UserB hooks off. The MG notifies the MGC of the off-hook event with an NTFY_REQ command. The MGC acknowledges with an NTFY_REPLY.
NTFY_REQ text description MEGACO/1 [191.169.150.122]:2944
T=885{C=287{
N=A1{
OE=369108999{al/of}}}}
NTFY_REPLY text description MEGACO/1 [191.169.200.61]:2944
P=885{C=287{N=A1}}
9) Event 9: Through an MOD_REQ command, the MGC sends the connection description of the RTP Termination A100000034 associated with the Termination A0 to the RTP Termination A100000035 associated with the Termination A1, and modifies the mode property of the RTP Termination A100000035 to be send/receive. The MG acknowledges with an MOD_REPLY.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
The 1st line: The command is sent by the MGC to the MG. The IP address and port of the MGC is [191.169.200.61]:2944.
The 2nd line: The TransactionID is 370281195, and the ContextID is 287, that is, the Context created for the MGC and the Termination2.
The 3rd line: The Modify command, to modify the properties of the Termination A1. “M” represents the Media descriptor. “O” represents the LocalControl descriptor. “MO=SR” indicates that the MGC modifies the mode property of the Termination A1 to be send/receive. “RV=OFF,RG=OFF” indicates that both the ReserveGroup property and the ReserveValue property are set to OFF. “tdmc/ec=ON” indicates that the MGC suggests ON to be the echo canceler in the TDM Circuit Packages.
The 4th line: The MGC requests the MG to detect events that will happen in the Termination A1, such as on-hook events.
The 5th line: The Signals descriptor. Here the signal is null, indicating the MGC requires the MG to stop any signal played currently.
The 6th line: The Modify command, to modify the properties of the RTP Termination A100000035. “M” represents the Media descriptor. “O” represents the LocalControl
descriptor. “MO=SR” indicates that the MGC modifies the mode property of the RTP Termination A100000035 to be send/receive. “RV=OFF,RG=OFF” indicates that both the ReserveGroup property and the ReserveValue property are set to OFF.
The 7th line: The Local descriptor, carrying the connection description of the local RTP (associated with the Termination A1) Termination A100000035.
The 8th line: The Remote descriptor, carrying the connection description of the remote RTP (associated with the Termination A0) Termination A100000034.
MOD_REPLY text description MEGACO/1 [191.165.15.122]:2944
10) Event 10: Through an MOD_REQ command, the MGC sends the connection description of the RTP Termination A100000035 associated with the Termination A1 to the RTP Termination A100000034 associated with the Termination A0, and modifies the mode property of the RTP Termination A100000034 to be send/receive. The MG acknowledges with an MOD_REPLY.
At this time, the Terminations A0 and A1 know the connection information of the local end and the opposite end. The conversation conditions are satisfied, and a conversation can start.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
11) Event 11: The calling party UserA hooks on. The MG sends an NTFY_REQ command to notify the MGC. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.
NTFY_REQ text description MEGACO/1 [191.169.150.122]:2944
NTFY_REPLY text description MEGACO/1 [191.169.200.61]:2944
P=886{N=A0}}
12) Event 12: On receipt of the on-hook event of the UserA, the MGC sends an MOD_REQ command to the MG to modify the properties of the Termination A0. The MGC also requests the MG to detect events that will happen in the Termination A0, such as off-hook events, and modify the mode property of the RTP Termination A100000034 to be inactive. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ and indicate the execution of the command.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
T=370281199{C=286{
MF=A0{E=369109259{al/*},SG{}},
MF=A100000034{M{O{MO=IN,RV=OFF,RG=OFF}}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=370281199{C=286{MF=A0,MF=A100000034}}
13) Event 13: On receipt of the on-hook event of the UserA, the MGC sends an SUB_REQ command to the MG to subtract all semi-permanent Terminations and ephemeral RTP Terminations from the Context 286 and thus to delete the Context and disconnect the call. The MG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
SUB_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372509424{C=286{O-S=*}}
The 1st line: The command is sent by the MGC to the MG. The IP address and port of the MGC is [191.169.200.61]:2944.
The 2nd line: The TransactionID is “372509424”, and the ContextID is “286”. In “O-S=*”, “O” represents Optional, “S” represents Subtract, and “*” represents All. Therefore, “O-S=*” indicates to subtract all Terminations from the Context 286.
SUB_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=372509424{C=286{
S=A0,S=A100000034}}
14) Event 14: The MGC sends an MOD_REQ command to the MG to modify the properties of the Termination A1. The MGC also requests the MG to detect events that will happen in the Termination A1, such as on-hook events, and requests the MG to send the busy tone to the Termination A1. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ, and meanwhile sends the busy tone to the UserB.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372771569{C=287{
MF=A1{E=369109004{al/*},SG{cg/bt}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=372771569{C=287{MF=A1}}
15) Event 15: After the call and the Context between the Termination A0, the RTP Termination and the MGC are cleared, the MGC sends an MOD_REQ command to the MG, requesting the MG to detect events that will happen in the Termination A0, such as off-hook events. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ command. At this time, the Context is null.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372771570{C= - {
MF=A0{E=369109261{al/*},SG{}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=372771570{C= - {MF=A0}}
16) Event 16: The called party UserB hooks on. The MG sends an NTFY_REQ command to notify the MGC. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.
NTFY_REQ text description MEGACO/1 [191.169.150.122]:2944
T=887{C=287{
N=A1{OE=369109004{al/on}}}}
The RequestIdentifier is 369109004, which is the same as the RequestIdentifier in the MOD_REQ command described in the event 14. It indicates that the NTFY_REQ is triggered by the MOD_REQ command in the event 14.
NTFY_REPLY text description MEGACO/1 [191.169.200.61]:2944
P=887{C=287{N=A1}}
17) Event 17: On receipt of the on-hook event of the UserB, the MGC sends an SUB_REQ command to the MG to subtract all semi-permanent Terminations and ephemeral RTP Terminations from the Context 287 and thus to delete the Context and disconnect the call. The MG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
SUB_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372509427{C=287{O-S=*}}
SUB_REPLY text description MEGACO/1 [191.169.150.122]:2944
18) Event 18: After the call and the Context between the Termination A1, the RTP Termination and the MGC are cleared, the MGC sends an MOD_REQ command to the MG, requesting the MG to detect events that will happen in the Termination A1, such as off-hook events. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ command. At this time, the Context is null.
MOD_REQ text description MEGACO/1 [191.169.200.61]:2944
T=372771572{C= - {
MF=A1{E=369109006{al/*},SG{}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.122]:2944
P=372771572{C= - {MF=A1}}
2.3.5 Successful Trunk Call Procedure
The following example illustrates a call procedure under the control of SoftX3000, where a PSTN user under a TMG makes a call through SoftX3000 to a user under an AMG5000. The networking diagram is shown in Figure 2-11.
PSTN
Core Network
SoftX3000
TMG8010+SGAMG5000
Voice
H.248
MTP3+M2UA+Trunk+H.248
Figure 2-11 Networking diagram for a successful trunk call example
The call procedure is illustrated in Figure 2-12. In the procedure, it is assumed that
The IP address of SoftX3000 is 191.169.150.170; The IP address of the TMG is 191.169.150.10; The IP address of the AMG is 191.169.150.172; The PSTN user is the calling party, and the associated PSTN switch is connected
to SoftX3000 through a TMG; The AMG user is the called party, and the called party hooks on first.
1) Event 1: The PSTN user hooks off and dials the called number. An Initial Address Message (IAM) is sent to the MGC through the Signaling Gateway (SG) built in the TMG.
On receipt of the IAM, the MGC sends an ADD_REQ, requesting the TMG to add the physical Termination A29 and a certain RTP Termination to a new Context. The TMG responds with an ADD_REPLY with a new allocated connection descriptor “15” and a new RTP termination descriptor “A2147489806”. Requested by the MGC, the TMG determines G.723 as the codec type for the Termination A2147489806 of the TMG, sets its RTP port number to be 13388, fills the local IP address to be 191.169.150.10, and sets the Termination A2147489806 to be in the send/receive mode.
ADD_REQ text description MEGACO/1 [191.169.150.170]:2944
2) Event 2: The MGC conducts the analysis of the called number and determines the called UserB is connected to the physical Termination A0 in the AMG. Therefore, the MGC sends an ADD_REQ, requesting the AMG to add the physical Termination A0 and a certain RTP Termination to a new Context. The AMG responds with an ADD_REPLY with a new allocated connection descriptor “218” and a new RTP termination descriptor “A100000379”. Requested by the MGC, the AMG determines G.723 as the codec type for the Termination A100000379 of the AMG, sets its RTP port number to be 18300, fills the local IP address to be 191.169.150.172, and sets the Termination A100000379 to be in the inactive mode.
ADD_REQ text description MEGACO/1 [191.169.150.170]:2944
3) Event 3: The MGC sends an MOD_REQ to the AMG to modify the properties of the Termination A0. The MGC also requests the AMG to detect events that will happen in the Termination A0, such as off-hook events, and plays the ringing tone to the UserB. The AMG acknowledges with an MOD_REPLY, and meanwhile the AMG plays the ringing tone to the UserB.
MOD_REQ text description MEGACO/1 [191.169.150.170]:2944
T=372787554{C=218{
MF=A0{E=369099790{al/*},SG{al/ri}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.172]:2944
P=372787554{C=218{MF=A0}}
4) Event 4: The MGC sends an MOD_REQ command to the TMG, requesting the TMG to play the ringback tone to the PSTN user. The TMG acknowledges with an MOD_REPLY.
Subsequently, SoftX3000 sends an Address Complete Message (ACM) to the SG. On receipt of the message, the SG transfers it to the PSTN switch through the M2UA protocol and requests the switch to send the ringback tone to the PSTN user.
MOD_REQ text description MEGACO/1 [191.169.150.170]:2944
ADD_REPLY text description MEGACO/1 [191.169.150.010]:2944
P=371870051{C=15{MF=A29}}
5) Event 5: The UserB hooks off. The AMG sends an NTFY_REQ command to notify the MGC. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.
NTFY_REQ text description MEGACO/1 [191.169.150.172]:2944
T=2470{C=218{
N=A0{OE=369099790{al/of}}}}
NTFY_REPLY text description MEGACO/1 [191.169.150.170]:2944
P=2470{C=218{N=A0}}
6) Event 6: Through an MOD_REQ command, the MGC sends the connection description of the RTP Termination A2147489806 associated with the Termination A29 of the TMG to the RTP Termination A100000379 associated with the Termination A0 of the AMG, and modifies the mode property of the RTP Termination A100000379 to be send/receive. The AMG acknowledges with an MOD_REPLY.
MOD_REQ text description MEGACO/1 [191.169.150.170]:2944
7) Event 7: Through an MOD_REQ command, the MGC sends the connection description of the RTP Termination A100000379 associated with the Termination A0 of the AMG to the RTP Termination A2147489806 associated with the Termination A29 of the TMG. The TMG acknowledges with an MOD_REPLY.
At this time, the Termination A29 of the TMG and the Termination A0 of the AMG know the connection information of the local end and the opposite end. Subsequently, SoftX3000 sends an Answer Message (ANM) to the SG. On receipt of the message, the SG transfers it to the PSTN switch through the M2UA protocol and requests the switch to stop sending the ringback tone to the PSTN user and set up a conversation.
MOD_REPLY text description MEGACO/1 [191.169.150.010]:2944
P=370297192{C=15{MF=A29,MF= A2147489806}}
8) Event 8: The called UserB hooks on. The AMG sends an NTFY_REQ command to notify the MGC. The MGC sends an NTFY_REPLY to acknowledge the receipt of the Notify command.
NTFY_REQ text description MEGACO/1 [191.169.150.172]:2944
T=2471{C=218{
N=A0{OE=369099791{al/on}}}}
NTFY_REPLY text description MEGACO/1 [191.169.150.170]:2944
P=2471{C=218{N=A0}}
9) Event 9: On receipt of the on-hook event of the UserB, the MGC sends an MOD_REQ command to the AMG to modify the properties of the Termination A0. The MGC also requests the gateway to detect events that will happen in the Termination A0, such as off-hook events, and modify the mode property of the RTP Termination A100000379 to be inactive. The MG sends an MOD_REPLY to acknowledge the receipt of the MOD_REQ and indicate the execution of the command.
MOD_REQ text description MEGACO/1 [191.169.150.170]:2944
T=370297199{C=218{
MF=A0{E=369099776{al/*},SG{}},
MF=A100000379{M{O{MO=IN,RV=OFF,RG=OFF}}}}}
MOD_REPLY text description MEGACO/1 [191.169.150.172]:2944
P=370297199{C=218{MF=A0,MF= A100000379}}
10) Event 10: On receipt of the on-hook event of the UserB, the MGC sends an SUB_REQ command to the AMG to subtract all semi-permanent Terminations and ephemeral RTP Terminations from the Context 218 and thus to delete the Context and disconnect the call. The MG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
SUB_REQ text description MEGACO/1 [191.169.150.170]:2944
SUB_REPLY text description MEGACO/1 [191.169.150.172]:2944
P=372525424{C=218{
S=A0,S= A100000379}}
11) Event 11: On receipt of the SUB_REQ command from the AMG, the MGC sends a Release (REL) message to the SG. On receipt of the message, the SG transfers it to the PSTN switch through the M2UA protocol and requests the switch to send the busy tone to the PSTN user and release the voice circuit.
On receipt of the REL message, the PSTN switch acknowledges with a Release Completed (RLC) message which triggers the release of the voice circuit. On receipt of the RLC message, the SG transfers it to the MGC through the M2UA protocol.
On receipt of the RLC message, the MGC sends an SUB_REQ command to the TMG to subtract all semi-permanent Terminations and ephemeral RTP Terminations from the Context 15 and thus to delete the Context and disconnect the call. The TMG sends an SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
SUB_REQ text description MEGACO/1 [191.169.150.170]:2944
T=372525425{C=15{O-S=A29, O-S=A2147489806}}
SUB_REPLY text description MEGACO/1 [191.169.150.010]:2944
Put forward and studied by the IETF, the Session Initiation Protocol (SIP) is an application-layer control protocol for multimedia communication over IP network, which can be used for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls, distance learning, telemedicine, and similar applications. That is, all interactive two-party or multiparty multimedia communication activities over the Internet are multimedia sessions. Members in a session can communicate through multicast or through a mesh of unicast relations, or a combination of these.
SIP is being developed and studied. On one hand, SIP learns from the design concepts of other Internet standards and protocols and follows Internet principles such as concision, openness, compatibility and expendability with security issues taken into account. On the other hand, SIP fully considers the support for traditional PSTN services including Intelligent Network (IN) services and Integrated Services Digital Network (ISDN) services.
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user’s current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the underlying transport protocol and can be extended with additional capabilities.
Being an application-layer multimedia session signaling protocol, SIP can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means. Sessions can be advertised using multicast protocols such as Session Announcement Protocol (SAP), electronic mail, web pages or Lightweight Directory Access Protocol (LDAP), among others. SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and IN telephony subscriber services. These facilities also enable personal mobility, that is, the ability of end users to request and access subscribed telecommunication services on any terminal in any location at any time. SIP supports five facets of establishing and terminating multimedia communications:
User location: determination of the end system to be used for communication. User capabilities: determination of the media and media parameters to be used. User availability: determination of the willingness of the called party to engage in
communications. Call setup: "ringing", establishment of call parameters at both called and calling
party. Call handling and control: including redirection, transfer and termination of calls.
SIP can initiate multiparty sessions using a multipoint control unit (MCU), unicast mesh, or multicast, supporting gateway functionality between PSTN and Internet calls.
SIP can be used in conjunction with other signaling systems or protocols for call setup. The IETF has included extensibility and compatibility of SIP with other protocols. For example, SIP could be used to determine that the party can be reached through H.323, obtain the H.245 gateway and user address and then use H.225.0 to establish the call. In another example, SIP might be used to determine that the callee is reachable through the PSTN and indicate the phone number to be called, possibly suggesting an Internet-to-PSTN gateway be used.
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols. SIP does not reserve resources, but can convey to the invited system the information necessary to do this.
3.1.2 Related Terms
I. Call
A call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call-ID.
For example, all participants in a conference invited by the same source comprise one call. A point-to-point Internet telephony conversation is a kind of simplest session and maps into a single SIP call.
In normal cases, a call is established by the calling party. More generally, a call can be established by a third party who does not participate in the media communication, where the calling party of the session is not the same as the inviter of the session. For multicast conferences, if a user is invited to the same multicast session by several people, each of these invitations will be a unique call. In an MCU-based, call-in conference, each participant uses a separate call to invite himself to the MCU.
SIP is a client/server protocol. A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client.
A normal call consists of three transactions. Call initiation consists of two operation requests, namely INVITE and ACK. The former requires a response. The latter is only an acknowledgement that the final response is received; it does not require a response. Call termination consists of one operation request, namely BYE.
III. SIP URL
To transfer protocol messages correctly, there are two significant problems in SIP to be solved. The first problem is addressing, that is, the form of address used to identify end users. The second problem is user location, which will be described later. SIP utilizes the WWW technology to solve those problems.
SIP Uniform Resource Locators (URLs) are used for addressing purposes. SIP URL syntax is defined according to the Uniform Resource Identifier (URI) guidelines specified in the RFC 2396. Especially, the user field could be a telephone number to support addressing of IP telephony gateway and achieve the interworking between IP calls and the PSTN.
A SIP URL has the syntax:
SIP: Username:password@host:port; transport parameter; user parameter; method parameter; time-to-live; server address parameter? header name=header value
SIP indicates that the SIP is used for the communication to the specified end system.
Username is composed of any characters in a form of e-mail address or telephone number. (SoftX3000 adopts telephone number as the username.)
Host is either a domain name or an IPv4 address.
Port refers to the port number to which request message is sent. The default port is 5060, the public SIP port number.
Password can be included in a SIP URL, which is not recommended for the sake of security.
Transport parameter indicates the used transport protocol, TCP or UDP. The default transport parameter is UDP.
For user parameter, a function of SIP URL is to allow the host to be an IP telephony gateway with a telephone number as the username. Because BNF syntax cannot distinguish telephone number from general username, “user parameter” is added to
follow the domain name. Two values are available for this field: IP and phone. When the field is set to “phone”, the username is a telephone number and the corresponding end system is an IP telephony gateway.
Method parameter refers to the method (operation) to be used.
Time-to-live (TTL) indicates the life of UDP multicast data packets. This parameter is valid only when the transport parameter is set to “UDP” and the server address parameter is set to “multicast address”.
Server address parameter indicates the address of the server communicating with the user. It, usually the multicast address, overwrites the address in the “host” field.
“Transport parameter”, “time-to-live”, “server address parameter”, and “method parameter” are URL parameters used only in a redirect address, that is the Contact field which will be mentioned later.
“55500200” is a username. “127.0.0.1” is the IP address of a host. “5061” is a port number of the host. The user parameter is “phone”, indicating the username is a telephone number.
“Alice” is a username. “registrar.com” is the domain name of a host. “Register” is a method to be used.
IV. User location
User location is based on registration. After a SIP user terminal is powered on, it starts to register to a registrar (SoftX3000). For that specific purpose, REGISTER request and registration procedure are defined in SIP.
V. Location service
A location service is used by a SIP redirect or proxy server to obtain information about a callee’s possible location(s). Location services are offered by location servers. Location servers may be co-located with a SIP server, but the manner in which a SIP server requests location services is beyond the scope of this document. In the U-SYS Solution proposed by Huawei, SoftX3000 acts as a location server.
A proxy, or proxy server, is a logical network entity that acts as both a server and a client for the purpose of forwarding requests or responses on behalf of other clients. A proxy server may be in one of the states: Stateless, Stateful and Call Stateful. A proxy server attempts to forward requests to multiple addresses with a branch or cycle method.
A proxy server implements the functions of routing, authentication, charging monitoring, call control and service provision. In the U-SYS Solution proposed by Huawei, SoftX3000 also acts as a proxy server.
VII. Redirect server
A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses, and returns these addresses to the client, so that the client can directly initiate requests to these new addresses again. A redirect server implements the routing function rather than receive or reject calls. The redirect server, in coordination with a registration process, can support personal mobility. In the U-SYS Solution proposed by Huawei, SoftX3000 also acts as a redirect server.
VIII. Registrar
A register is a server that accepts REGISTER requests. A registrar is typically combined with a proxy or redirect server into a single application. A registrar needs to store the address mapping relationship in REGISTER requests in a database for subsequent call processes. A registrar may offer location services. In the U-SYS Solution proposed by Huawei, SoftX3000 also acts as a registrar.
IX. User agent
A logical entity that can initiates or receive SIP requests.
X. User agent client
A user agent client (UAC) is a client application that initiates the SIP request. An example of UAC is SIP phone.
XI. User agent server
A user agent server (UAS) is a server application that receives the SIP request. An example of UAS is SoftX3000.
Note: The distinguishing of UAC and UAS is based on one transaction.
The structure of SIP protocol stack is shown in Figure 3-1.
H.323 SIP RTSP RSVP RTCPH.263 etc.
RTP
TCP UDP
IP
PPP
Sonet
AAL3/4 AAL5
ATM Ethernet
PPP
V.34
Figure 3-1 SIP protocol stack
SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as the resource reservation protocol (RSVP) for reserving network resources, the real-time transport protocol (RTP) for transporting real-time data and providing quality of service (QoS) feedback, the real-time streaming protocol (RTSP) for controlling delivery of streaming media, the session announcement protocol (SAP) for advertising multimedia sessions through multicast and the session description protocol (SDP) for describing multimedia sessions. However, the functionality and operation of SIP does not depend on any of these protocols.
Transport-layer support: SIP lies in the layer above the IP layer. The network layer protocol is IP and the transport layer protocol is TCP or UDP. UDP is preferred.
3.1.4 Implementation in SoftX3000
Through SIP or Session Initiation Protocol for Telephones (SIP-T), SoftX3000 interworks with other SoftSwitch systems and other SIP domain equipment such as SIP phone and UniPhone. The implementation of SIP in SoftX3000 is illustrated in Figure 3-2.
SIP messages are encoded in a text form. There are two types of messages: request messages and response messages.
I. Request messages
Request messages are SIP messages sent from a client to a server, for the purpose of invoking a particular operation. They are INVITE, ACK, OPTIONS, BYE, CANCEL and REGISTER messages. The functions of these messages are listed in Table 3-1.
Table 3-1 Request messages
Request message Function
INVITE
The INVITE message indicates that the user is being invited to participate in a session. The message body contains a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive as well as their parameters. A success response must indicate in its message body which media the callee wishes to receive and may indicate the media the callee is going to send.
A server may automatically respond to an invitation for a conference the user is already participating in, identified either by the SIP Call-ID or a globally unique identifier within the session description, with a 200 (OK) response.
ACK The ACK request confirms that the client has received a final response to an INVITE request. ACK is used only with INVITE messages.
BYE The user agent client uses BYE to indicate to the server that it wishes to release the call.
CANCEL The CANCEL request cancels a pending request, but does not affect a completed request. (A request is considered completed if the server has returned a final status response.)
REGISTER A client uses the REGISTER request to register an address with a SIP server.
OPTIONS The OPTIONS request is used to query servers about their capabilities.
II. Response messages
Response messages are used to respond to request messages, indicating the success or failure status of the call. The class of a response message is distinguished by a Status-Code. The Status-Code is a 3-digit integer. The first digit of the Status-Code defines the class of response. The last two digits indicate the response in detail. The classification of response messages and their meanings are shown in Table 3-2.
Table 3-2 Response messages
Serial No. Status-Code Message functions
1xx Informational (provisional) Request received, continuing to process the request.
100 Trying
180 Ringing
181 Call Is Being Forwarded
182 Queued
2xx Success The action was successfully received, understood, and accepted.
200 OK
3xx Redirection Further action needs to be taken in order to complete the request.
5xx Server error The server failed to fulfill an apparently valid request.
500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
6xx Global failure The request cannot be fulfilled at any server.
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
Both the request and the response messages contain SIP header fields and SIP message fields.
SDP message fields are added into SIP messages.
3.2.2 Message Structure
I. Request messages
1) Request format
Figure 3-3 illustrates the format for a SIP request that consists of a start line, a message header, and a message body. A line feed character distinguishes each parameter line in the message header. Some parameters are optional for different request messages.
The following section describes some frequently used parameter fields.
Call-ID
The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client.
A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. A user might also receive several INVITEs to the same conference or call with different Call-IDs. The user judges the repetition of the INVITEs by identifications in the session description, for example, session identifier and version number carried in the o (source) field in the SDP.
in which, “host” is a domain name defined globally or an IP address routable globally. The local ID is composed of unique URI characters in the scope of “host". Otherwise, the local ID must be a globally unique value to ensure the global uniqueness of Call-ID. Call-IDs are case-sensitive.
“191.169.150.101” is the IP address of a host. “call-973636852-4” is a globally unique local ID.
Form
All requests and responses must contain the From header field that indicates the initiator of the request. The server duplicates this field from the request message to response messages.
This field has a generic format:
From:Display-name<SIP-URL>;tag=xxxx
The “display-name” is meant to be rendered by a human user interface. A system should use the display name “Anonymous” if the identity of the client is to remain hidden. The “display-name” is optional. “tag” is a string of hexadecimal numbers in which the hyphen “-“ can be added. When two user instances sharing the same SIP address use the same Call-ID to initiate a call invitation, this tag should be used for distinguishing purposes. The tag value must be globally unique. A user should maintain the same Call-ID and tag value in the whole process of a call.
The To header field specifies the logical recipient of the request. The format of the To header field is the same as that of the From header field except that the first key is replaced by “To”. All requests and responses must contain this field.
The tag parameter in the field distinguishes different user instances that are identified by the same SIP URL. A proxy server can concurrently deliver several requests, and the same request might reach different instances (for example, home telephone) of the user. Because the instances might all respond to the request, it is required to use the tag to distinguish the responses from different instances. The tag in the To header field is put by each instance in the response message.
In SIP, Call-ID, From, and To header fields identify one call branch. When a proxy server concurrently delivers requests, a call might have several call branches.
CSeq
CSeq is command sequence. A CSeq header field in a request contains a command name and a single decimal sequence number. Request client defines the sequence number which is unique inside the Call-ID. The initial value of the sequence number is arbitrary. The subsequent values share the same Call-ID. For a request with a different command name and a different message body, the CSeq sequence number should be increased by one. A retransmitted request contains the same sequence number. The server duplicates the CSeq value from the request to the response message, used to correlate the request with the response it triggers.
The CSeq value (decimal sequence number) of an ACK or a CANCEL request is the same as that of the corresponding INVITE request. The CSeq sequence number of a BYE request should be higher than that of the corresponding INVITE request. The server must remember the highest sequence number of an INVITE request having the same Call-ID. Upon receipt of an INVITE request with a lower sequence number, the server sends a response and discards the INVITE request.
Several requests concurrently delivered by the agent server have the same CSeq value. Strictly speaking, CSeq is required for any request that is cancelled by a BYE or CANCEL and also for continuous requests with the same Call-ID sent by the client.
An example of the CSeq field:
Cseq: 1 INVITE
Via
The Via header field indicates the path taken by the request. The field can avoid loops during the transport of the request and ensure the same path taken by the responses, for example, in firewall occasions.
The client originating a request must add its host name or network address in the Via header field of the request. If the client does not use the default port, it must add the used port number in the field. At requesting for forward, the proxy server must add its address in a new Via header field that is put before the existing Via. If the proxy server receives a request containing its address in a Via header field, the proxy server returns a response indicating a loop detection.
When a request is passing a Network Address Translation (NAT) entity (for example, firewall), the requested source address and the port number might be changed and thus the Via cannot be the base for routing responses. To avoid that, the proxy server should check the top Via header field. If the value of the top Via is different from the previous hop’s address that is detected by the proxy server, the server add a “receive” parameter in the Via which is thus called “Via header field tagged by the receiver”. For example:
When the request from 10.0.0.1 passes a NAT point with the external address 191.169.12.30, the request reaches the proxy server—softx3000.bell-telephone.com. At noticing the mismatch between the previous hop’s address and the Via header field address, the proxy server adds the actual sending address, as a receiver’s tag, at the end of the top Via and then adds its own address in a new Via that is put at the topmost.
If the proxy server sends a request to multicast address, the proxy server must add a parameter “maddr” in the Via to indicate that.
The proxy server or the user agent client complies with the following rules to process the received Via:
Rule 1: The first Via header field should indicate the proxy server or the user agent client itself. If not, the proxy server or the user agent client discards the message; otherwise, the proxy server or the user agent client deletes the Via header field.
Rule 2: If there is no a second Via header field, the response should reach the destination. Otherwise, proceed as follows.
Rule 3: If the second Via header field contains a “maddr” parameter, the proxy server or the user agent client sends the response according to the multicast address indicated in the parameter. The used port number is specified in the “sent-by” parameter. If not specified, the proxy server or the user agent client uses a port number 5060. The lifetime of the response should be specified in the “ttl” parameter. If not specified, the proxy server or the user agent client sets it to “1”.
Rule 4: If the second Via header field does not contain a “maddr” parameter but has a field tagged by the receiver, the proxy server or the user agent client sends the response to the address specified in the “received” parameter.
Rule 5: If there is neither a “maddr” parameter nor a tag, the proxy server or the user agent client sends the response to the address specified in the “sent-by” parameter.
The “sent-protocol” is expressed in the form of “protocol-name/protocol-version/transport”, in which the default values for “protocol-name” and “transport” are SIP and UDP. The “sent-by” is usually the host and port number of the sender. The “hidden” parameter has a key word—hidden. If there is a hidden parameter, it indicates that the field has been encrypted by the previous proxy for privacy purposes. For the meanings of the “maddr” and “received” parameters, see earlier descriptions. The “ttl” and “maddr” parameters are coordinated with each other. The “branch” parameter is used by the proxy server concurrently delivering requests to
The Contact header field is present in INVITE, ACK, and REGISTER requests, success responses, call process responses, and redirection responses to provide an address for direct communication with the user.
The Contact header field in an INVITE or ACK request indicates the location from which the request is originated. With the field, the callee can directly send a request (for example, BYE) to that address, instead of asking a series of proxy servers to forward the request by using the Via header field.
A success response to INVITE might contain the Contact header field, which helps to send the subsequent SIP requests (for example, ACK) directly to that address specified in the field. That address usually indicates the host of the callee. If the host is behind a firewall, that address indicates the proxy server.
Call process response to an INVITE request contains a Contact header field that has the same meaning as the success response message. However, a CANCEL request cannot be directly sent to that address. Instead, the CANCEL must be forwarded through the same path of the original request.
The Contact header field in a REGISTER request indicates the reachable location of the user. The request also defines a wildcard Contact field “*” that can only be used with the “expires” field with a value of “0” to remove all registrations of a user. In the Contact field, the “expires” parameter (optional) can also be specified to indicate the expiration interval of the registration. If the parameter is not specified, the “expires” field value is taken as its default value. If neither case is adopted, it is considered that the expiration interval of the SIP URI is one hour.
The Contact header field in a success response to the REGISTER request returns all locations that are currently reachable for the user.
The Contact header field in a redirect response such as Moved Temporarily, Moved Permanently, or Address Ambiguous specifies other alternative addresses for retry, which can be used for a response to a BYE, INVITE or OPTIONS request.
The Contact header field has a generic format:
Contact: address; q; action; expires; extension
The “address” is expressed in the same form as To and From. The “q” parameter has a value range [0, 1] indicating the relative priority of the given location. The greater the
value is, the higher the priority becomes. The “action” parameter is only used in a REGISTER request, indicating the server is required to perform the proxy service or redirection service on the subsequent requests to the client. If the Contact header field does not contain an “action” parameter, the action to be performed depends on the configurations of the server. The “expires” parameter indicates how long the URI is valid either in seconds or by SIP date. The “extension” attribute is actually the extension name.
The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483 (Too Many Hops) error response.
The purpose of inserting this field is to avoid consuming proxy server resources in an event of loop. The initial field value is 70.
The Max-Forwards header field has a generic format:
Max-Forwards: decimal integer
Allow
The Allow header field gives a list of request types that can all be supported by the proxy server.
An example of the Allow field:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Content-Length
The Content-Length header field indicates the size of the message body, in decimal number of octets, sent to the recipient. Applications use this field to indicate the size of the message body to the transferred, regardless of the media type of the entity. If the used transport protocol is based on streams, for example, TCP, this header field must be used.
The size of the message body does not include the Carriage Return Line Feed (CRLF) that separates the message header from the message body. The Content-Length value must be greater than or equal to 0. If a message does not contain a message body, the value of the Content-Length header field must be set to “0”.
SDP serves to construct the message body of a request or 2xx response.
The Content-Length header field has a generic format:
That indicates the length of the message body is 349 bytes.
Content-Type
The Content-Type header field indicates the media type of the message body sent to the recipient. If the message body is not empty, the Content-Type header field must be present. If the body is empty and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file).
An example of the Content-Type header field:
Content-Type: application/sdp
Supported
Transportation of a 100 provisional response defined in SIP is not reliable. In other words, there is no guarantee that UAC can receive the provisional response sent by the UAS.
If the response is required to carry information about media, it must be guaranteed that the message can be reliably transported to the peer. “100rel” extension provides an appropriate mechanism for the reliable transportation of the 100 response. The acknowledgement request method for a provisional response in “100rel” is PRACK.
If the UAC supports the extension, the UAC adds a “Supported: 100rel” header field in the message transmitted. If the UAS supports the extension, the UAS adds a “Require: 100rel” header field in the 100 response transmitted. Upon receipt of the response, the UAC is required to send a PRACK request to the UAS, notifying the UAS of the receipt of the provisional response. The UAS sends a 2xx response to the UAC to terminate the acknowledgement process of the provisional response.
If a UA wants to send a provisional response carrying a SDP message body, the UAC and the UAS must support and use the “100rel” extension to guarantee the reliable transportation of the message.
For example:
Supported: 100rel
User-Agent
The User-Agent header field contains information about the UAC originating the request.
Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Therefore, the User-Agent header field should be set to be a configurable option.
The Expires header field gives the relative time after which the message (or content) expires.
For example:
Expires: 5
Accept-Language
The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server assumes all languages are acceptable to the client.
For example:
Accept-Language: en
Authorization
The Authorization header field contains authentication credentials of a UA.
The following introduces a general process for a UA to request an authorization from the server.
If the server requires authorizing the user when the UA originates a request, a nonce is generated at the local end for this authorization and all parameters necessary for the authorization request header field are returned to the UA to initiate a user authorization process.
Upon receipt of the authorization request, the UA generates an encrypted response using a particular algorithm according to the information returned from the server and the user configurations. The UA sends the response through a new request message to the server.
Upon receipt of the new request with the authorization response, the server firstly checks the correctness of the nonce. If the nonce is not generated locally, the server returns a failure message. If the nonce is generated locally but the authorization expires, the server re-generates a nonce and re-initiates a user authorization procedure. The earlier nonce is returned with the cnonce parameter.
If the nonce passes the verification, the server generates a response with the same algorithm as the UA according to the nonce, username, password (the server can obtain the password of the user from the local user information), and URI. In addition, the server compares the generated response with the response carried in the request message. If the responses match, the user successfully passes the authorization. Otherwise, the authorization fails.
The authorization methods include digest, basic, chap-password, and carddigest. Digest is an HTTP-digest method. Currently SoftX3000 supports only the HTTP-digest method. SoftX3000 will support the carddigest method to achieve Uniphone card number calls.
Username indicates the authenticated user.
Realm is used to identify the domain from which the authorization procedure is initiated.
Nonce is an encryption factor that is generated by the entity initiating the authorization procedure.
Response is a string of characters that the UA generates, by using a particular algorithm, according to the nonce, username, password, and URI from the server upon receipt of the authorization request. The string contains the encrypted password of the user. (During the authorization procedure, the UA and the server exchange other information, except password, in plain text in SIP messages.)
URI refers to the request-URI of the originated call request message. Upon receipt of an authorization request, the UA has to re-originate a request that carries the authorization response information to the server. In the request, some fields including request-URI might be changed at a passed network server. The URI parameter in the authorization header field serves to transfer the request-URI in the original message for authorization purposes when the UA originates the request. This is to ensure the correctness of the authorization procedure.
If the UA returns a new request message with the authorization response after expiration at the server, the server has to re-generate a nonce to authenticate the user. The nonce parameter carries the new nonce. The cnonce parameter carries the earlier nonce to the UA.
Algorithm is used to transfer the algorithm for generating the “response”.
o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.1.116
s: Sip Call
c: IN IP4 191.169.1.95
t: 0 0
m: audio 30000 RTP/AVP 8 0 4 18
a: rtpmap:8 PCMA/8000
a: rtpmap 0 PCMU/8000
a: rtpmap 4 G723/8000
a: rtpmap 18 G729/8000
The 1st line: This is the start line of the request. It indicates an INVITE request message for URI. The current address of the invited user is “sip:[email protected]”. The SIP protocol version is 2.0.
The 2nd line: This is a From header field. It indicates that the address of the request originator is “<sip:[email protected]>”. The tag is “1ccb6df3”. When several users sharing the same SIP address originate INVITEs with the same Call-ID, this is used to distinguish the users.
The 3rd line: This is a To header field. It indicates that the address of the request recipient is “<sip:[email protected]>”.
From the From and To header fields, we can find:
A terminal, 44510000, under the control of an MGC with the IP address “191.169.1.116” dials a terminal, 66500002, under the control of an MGC with the IP address “191.169.1.110”. The terminal type might be ESL connected to SIP, H.323, Integrated Access Device (IAD), or Access Gateway (AG).
The 4th line: This is a CSeq header field, used to correlate the INVITE request with the triggered responses and corresponding ACK and CANCEL requests.
The 5th line: This is a Call-ID header field. This header field identifies an INVITE that is globally unique. The Call-ID is “20973e49f7c52937fc6be224f9e52543@sx3000” in
which “sx3000” is the domain name of the SoftX3000 originating the call and “20973e49f7c52937fc6be224f9e52543” is the local identifier.
The 6th line: This is a Via header field. This header field indicates the path through which the request passes. “SIP/2.0/UDP” represents the protocol for the transmission, in which the protocol name is “SIP”, the protocol version is “2.0”, and the transport layer is “UDP”. “191.169.1.116:5061” indicates that the IP address of the SoftX3000, the sender, is “191.169.1.116” and the used port is “5061”. “branch=z9hG4bkbc427dad6” is the branch parameter. When concurrently delivering a request, SoftX3000 tags all the branches.
The 7th line: This is a Contact header field, indicating that the subsequent requests (for example, BYE) can be directly sent to <sip:[email protected]:5061> without the help of a Via header field.
The 8th line: This is a 100rel extension. This header field provides a reliable transmission mechanism for 100 response.
The 9th line: This is a Max-Forwards header field, indicating that the maximum number of hops the request can transit on the way to its destination is 70.
The 10th line: This is an Allow header field. This header field lists the types of request messages that are supported by the SoftX3000 with a given IP address “191.169.1.116”.
The 11th line: This is a Content-Type header field, indicating that the body carried in the message is a single message body based on the SDP.
The 12th line: This is a white space. An SDP session description follows the white space.
The 13th line: This is the SDP protocol version number. Currently it is the version 0.
The 14th line: This line contains the session owner/creator and the session identifier, used to give the originator (username and host address) of the session, the session identifier, and the session version number. “HuaweiSoftX3000” is the username that is used by the user to log into the originating host. If the host does not support user identifier, this field is tagged to be a sign “-“. The first “1073741831” is the session identifier. The session identifier in the form of a digit string helps the multiple tuples (username, session identifier, network type, address type, and address) to construct the session’s globally unique identifier. The second “1073741831” is the version number of the session announcement, which is provided for the proxy server to detect the latest one from the several announcements of the same session. The basic principle is to increment that version number once the session data is modified. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” refers to the address type in the form of a text string. Currently “IP4” and “IP6” are defined. “191.169.1.116” is the IP address of the host that creates the session.
If the address type is IP4, the IP address might be a full domain name or a dotted decimal IP4 address. If the address type is IP6, the IP address might be a full domain name or a compressed text IP6 address.
The 15th line: This line contains the session name. Each session description necessarily has one and only one session name.
The 16th line: This line contains the connection related data. Currently the network type and the address type are defined to be “IN” and “IP4”. “191.169.1.95” might be the IP address of a Media Gateway (MG) (the terminal type is ESL telephone connected to an IAD/AG) under the control of the SoftX3000 whose IP address is 191.169.1.116. “191.169.1.95” might also be the IP address of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone).
The 17th line: This line contains the time description. It provides a time segment when the session can be activated, allowing the session to periodically occur. “0” represents the start time. The format for the field is t:<start time><end time>. The values of “start time” and “end time” are expressed in the decimal form of Network Time Protocol (NTP) time values. The unit is second.
The 18th line: This line contains the media-level description. It provides information that is suitable only for the media stream. “audio” refers to the media type. Currently five types of media are defined: audio, video, application, data, and control. “30000” represents the transport-layer port to which the media stream is transmitted, that is, the UDP port number of the MG (the terminal type is ESL phone connected to an IAD/AG) or the UDP port number of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone). “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. “8 0 4 18” is, for audio and video, the media payload type that is defined in the RTP audio/video application document. It means that all the formats carried in the session might be used, but the first one is the default format for the session.
The whole line indicates that A-law PCM single-channel audio signal is used by default, its static payload type is numbered 8 in the RTP audio/video application document, and the signal is transmitted to a UDP port 30000.
The 19th to 22nd lines: These lines introduce rtpmap attributes, specifying the mapping correspondence from RTP payload type to encoding. The format of such a line is a: rtpmap:<payload type><encoding name>/<clock rate>[/<coding parameter>]. In the format, <coding parameter> refers to the number of audio channels. This parameter is unavailable to video signals.
Figure 3-4 illustrates the format for a SIP response that is composed of a start line, a message header, and a message body. A line feed character distinguishes each parameter line in the message header. Some parameters are optional for different response messages.
……
White space
Content-Type: Field value
Supported: Field value
User-Agent: Field value
SDP
Content-Length: Field value
Allow: Field value
Max-Forwards: Field value
Contact: Field value
Via: Field value
CSeq: Field value
To: Field value
Form: Field value
Call-ID: Field value
Descriptive phraseStatus codeSIP/protocol versionStart line
Message header
Message body
Figure 3-4 SIP response format
2) Response message parameters
Refer to the earlier section describing the request message parameters.
3) Example of response message
The following is an example of SIP response message.
o=HuaweisoftX3000 1073741824 1073741824 IN IP4 191.169.1.110
s=Sip Call
c=IN IP4 191.169.1.135
t=0 0
m=audio 30016 RTP/AVP 8
a=rtpmap:8 PCMA/8000
The 1st line: The SIP protocol. The protocol version is 2.0. The status code is 180. “Ringing” is a descriptive phrase, indicting to send the ringing tone to the callee.
The 2nd and 3rd lines: Refer to the example of SIP request.
The 4th line: This is a CSeq header field, used to correlate the INVITE request with the triggered responses and corresponding ACK and CANCLE requests. The CSeq header field in this response has the same meaning as that in the earlier described request. Both are “1 INVITE”, indicating the response is trigger by the previous request.
The 5th to 11th lines: Refer to the example of SIP request.
The 12th line: This is a white space. An SDP session description follows the white space.
The 13th line: This is the SDP protocol version number. Currently it is the version 0.
The 14th line: This line contains the session owner/creator and the session identifier, used to give the originator (username and host address) of the session, the session identifier, and the session version number. “HuaweiSoftX3000” is the username that is used by the user to log into the originating host. If the host does not support user identifier, this field is tagged to be a sign “-“. The first “1073741824” is the session identifier. The session identifier in the form of a digit string helps the multiple tuples (username, session identifier, network type, address type, and address) to construct the session’s globally unique identifier. The second “1073741824” is the version number of the session announcement, which is provided for the proxy server to detect the latest one from the several announcements of the same session. The basic principle is to increment that version number once the session data is modified. “IN” refers to network indicator in the form of a text string. The currently defined IN is
Internet. “IP4” refers to the address type in the form of a text string. Currently “IP4” and “IP6” are defined. “191.169.1.110” is the IP address of the host that creates the session.
The 15th line: This line contains the session name. Each session description necessarily has one and only one session name.
The 16th line: This line contains the connection related data. Currently the network type and the address type are defined to be “IN” and “IP4”. “191.169.1.135” might be the IP address of an MG (the terminal type is ESL telephone connected to an IAD/AG) under the control of the SoftX3000 whose IP address is 191.169.1.110. “191.169.1.135” might also be the IP address of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone).
The 17th line: This line contains the time description. It provides a time segment when the session can be activated, allowing the session to periodically occur.
The 18th line: This line contains the media-level description. It provides information that is suitable only for the media stream. “audio” refers to the media type. “30016” represents the transport-layer port to which the media stream is transmitted, that is, the UDP port number of the MG (the terminal type is ESL phone connected to an IAD/AG) or the UDP port number of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone). “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. “8” is the media payload type defined in the RTP audio/video application document.
The 19th line: This line introduces a rtpmap attribute, specifying the mapping correspondence from RTP payload type to encoding. The RTP payload type “8” represents PCMA.
3.3 Basic Message Procedures
3.3.1 SIP User Registration Procedure
When user powers on a SIP phone, the SIP phone must register itself to the associated server. When the address of a SIP client changes, the SIP phone must re-register itself to the associated server. The SIP must periodically update the registration information. The following scenario presents how a SIP phone registers itself to the SoftX3000 to illustrate the SIP user registration procedure.
In the following example, it is assumed that
The IP address of SoftX3000 is 191.169.150.30; The IP address of SIP Phone is 191.169.150.251;
SIP Phone requests to register itself to SoftX3000.
SoftX3000SIP Phone
Register
401 Unauthorized
Register
200 OK
Figure 3-5 Registration procedure between SIP entity and SIP server
1) Event 1: SIP Phone originates a Register request to SoftX3000, notifying SoftX3000 of an on-power event or a restart event and requesting to register to MGC. The following is an example of Register request.
The 1st line: This is the start line of the request. It indicates a Register request message. The terminal is originating to register itself to the MGC whose IP address is 191.169.150.30. The SIP protocol version is 2.0.
The 2nd line: This is a From header field. It indicates that the Register originator is a SIP Phone controlled by the MGC whose IP address is 191.169.150.30.
The 3rd line: This is a To header field. It indicates the address of the Register recipient. In this example, the address of the Register recipient, MGC, is 191.169.150.30.
The 4th line: This is a Call-ID header field, This header field identifies an INVITE that is globally unique. The Call-ID is “[email protected]” in which “191.169.150.251” is the IP address of SIP Phone originating the Register request and “1-reg” is the local identifier.
The 5th line: This is a CSeq header field, used to correlate the Register request with the responses it triggers.
The 6th line: This is a Contact header field. The Contact header field in the Register request indicates the reachable location of the user. It indicates that the current IP address of SIP Phone is “191.169.150.251” and the telephone number is “6540012”.
The 7th line: This line indicates that the lifetime of the Register is 100s.
The 8th line: This line indicates that the length of the message body of the request is null, that is, the message does not carry a session description.
The 9th line: This line indicates that English is the preferred language to mention the reason phrase, the session description, or the status answer contents carried in the answer message.
The 10th line: This line indicates that the message sender, a UA entity, supports sip-cc, sip-cc01, and timer extension protocols. “timer” represents that the terminal supports the session-timer extension protocol.
The 11th line: This line contains information of the user terminal that originates the request. In this example, the information includes the type and the version number of SIP Phone.
The 12th line: This is a Via header field. This header field indicates the path taken by the request. “SIP/2.0/UDP” represents the protocol used for the transmission, in which “SIP” is the protocol name, “2.0” is the protocol version number, and “UDP” is the transport layer. “191.169.150.251” represents the IP address of the request sender.
2) Event 2: SoftX3000 returns a 401 Unauthorized response, indicating that MGC requires authenticating the user. The WWW-Authenticate field carries the authorization method, “digest”, that is supported by MGC and the domain name of MGC, “huawei.com”. SoftX3000 generates a nonce required for this authorization. This response carries those parameters to the terminal to initiate an authorization procedure.
3) Event 3: SIP Phone re-originates a Register request to SoftX3000. The request carries an Authorization header field that contains an authorization method (“digest”), SIP Phone’s user identifier (a telephone number in this example), MGC’s domain name, nonce, URI, and response parameters. (The contained
response parameter contains a response that SIP Phone encrypts, upon receipt of the 401 Unauthorized response message, by using a particular algorithm according to the information returned from the server as well as the user configurations.) The following is an example of Register request.
4) Event 4: Upon receipt of the Register request from SIP Phone, MGC checks the correctness of the nonce. If the received nonce is the same as that carried in the 401 Unauthorized response message, SIP Phone passes the check. Otherwise, MGC will return a failure message. Subsequently, MGC collects the nonce, username, password (obtained from the local user information), and URI and uses the same algorithm as used at the terminal to generate a new response parameter. MGC compares the new response parameter with that carried in the request message. If they are consistent, the user successfully passes the authorization; otherwise, the authorization fails. MGC returns a 200 OK response message, indicating the success of the terminal authorization.
The IP address of SoftX3000 is 191.169.200.61; The IP address of SIP Phone A is 191.169.150.101; The IP address of SIP Phone B is 191.169.150.100; SIP Phone A originates a call to SIP Phone B, and the calling party hooks on first; The telephone number of SIP Phone A is 1000, and the telephone number of SIP
Phone B is 1001.
SoftX3000SIP Phone A SIP Phone B
INVITE
100 TryingINVITE
100 Trying
ACK
180 Ringing180 Ringing200 OK200 OK
ACK
Conversation
BYE487
BYE
56
789
1012 11
13
14
1516
17
INVITE
100 Trying
12
407ACK
34
Figure 3-6 SIP call procedure between two SIP entities
1) Event 1: SIP Phone A originates an INVITE request to MGC, requesting MGC to invite SIP Phone B to a session. The session description of the INVITE message carries SIP Phone A’s IP address (191.169.150.101), port number (8766), payload type, encoding information matching the payload type to MGC.
For interpretation of the lines, refer to the example of request message in the Request Messages section.
2) Event 2: MGC returns a 100 Trying response to SIP Phone A, notifying SIP Phone A of the receipt of the request and also that MGC is processing the request.
3) Event 3: MGC sends a 407 Proxy Authentication Required response to SIP Phone A, indicating that MGC requires authenticating the user. The Proxy-Authenticate field carries the authorization method, “digest”, that is supported by MGC and the domain name of MGC, “huawei.com”. MGC generates a nonce required for this authorization. This response message carries those parameters to the terminal to initiate an authorization procedure.
5) Event 5: SIP Phone A re-originates an INVITE request to SoftX3000. The request carries a Proxy-Authorization field that contains an authorization method (“digest”), SIP Phone’s user identifier (a telephone number in this example), MGC’s domain name, nonce, URI, and response parameters. (The contained response parameter contains a response that SIP Phone A encrypts, upon receipt of the 407 response message, by using a particular algorithm according to the information returned from the server as well as the user configurations.)
6) Event 6: MGC returns a 100 Trying response to SIP Phone A, notifying SIP Phone A of the receipt of the request and also that MGC is processing the request.
7) Event 7: MGC sends an INVITE message to SIP Phone B, requesting SIP Phone B to participate in the session. The INVITE message carries SIP Phone A’s session description to SIP Phone B.
o=HuaweiSoftX3000 1073741833 1073741833 IN IP4 191.169.200.61
s=Sip Call
c=IN IP4 191.169.150.101
t=0 0
m=audio 8766 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
8) Event 8: SIP Phone B returns a 100 Trying response to MGC, notifying MGC of the receipt of the request and also that SIP Phone B is processing the request.
11) Event 11: SIP Phone B sends a 200 OK response to MGC, notifying that SIP Phone B has successfully received and processed the INVITE request. The message carries its IP address (191.169.150.101), port number (8766), payload type, encoding information matching the payload type to MGC.
12) Event 12: MGC sends a 200 OK response to SIP Phone A, notifying that MGC has successfully received and processed the INVITE request, and MGC sends the session description of SIP Phone B to SIP Phone A.
17) Event 17: MGC receives the BYE from SIP Phone A and knows the on-hook event. MGC sends a BYE request to SIP Phone B, requesting to terminate the session.
Figure 3-7 illustrates an example of a successful SIP trunk call procedure where two SoftX3000s communicate with each other through SIP.
In the following example, it is assumed that
The IP address of SoftX3000 A is 191.169.1.112; The IP address of SoftX3000 B is 191.169.1.110; SIP Phone A controlled by SoftX3000 A has a telephone number 66600003; SIP Phone B controlled by SoftX3000 B has a telephone number 5550045; SIP Phone A originates a call to SIP Phone B, and the called party hooks on first.
SoftX3000 BSoftX3000 A
INVITE
100 Trying
180 Ringing
200 OK
ACK
BYE
487 Request Terminated
1
23
4
5
6
7
Figure 3-7 SIP trunk call procedure
1) Event 1: SIP Phone A controlled by SoftX3000 A hooks off and originates a call to SIP Phone B controlled by SoftX3000 B. SoftX3000 A sends an INVITE message to SoftX3000 B, inviting SoftX3000 to the session. The session description of the INVITE message carries SoftX3000 A’s IP address (191.169.200.61), SIP Phone
o=HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.200.61
s=Sip Call
c=IN IP4 191.169.200.101
t=0 0
m=audio 30014 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
2) Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A, notifying SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing the request.
4) Event 4: SoftX3000 B sends a 200 OK response to SoftX3000 A, notifying that SoftX3000 B has successfully received and processed the INVITE request. The message carries its IP address (191.169.100.50), SIP Phone B's IP address (191.169.100.71), port number (40000), supported payload type, encoding information matching the payload type to SoftX3000 A.
SIP-T is not a new protocol. Based on SIP, SIP-T provides an extension mechanism of how to achieve the interworking between SIP network and PSTN network. There are three application models: PSTN-IP, IP-PSTN, and PSTN-IP-PSTN.
SIP-T has the following characteristics:
Encapsulation: SIP message body carries ISUP messages. Mapping: mapping between ISUP signaling and SIP messages and mapping
between ISUP parameters and SIP header fields. The mapping between ISUP signaling and SIP messages can be simply described in the following way:
IAM = INVITE
ACM = 180 RINGING
ANM = 200 OK
RLS = BYE
RLC = 200 OK
The following takes the PSTN-IP-PSTN model as an example to illustrate the call procedure where PSTN messages are transparently transported through SIP-T messages. A successful SIP-T trunk call procedure is shown in Figure 3-8.
1) Event 1: The calling PSTN user hooks off and dials the called number. An Initial Address Message (IAM) is sent to MGC through Signaling Gateway (SG) A controlled by SoftX3000 A.
Upon receipt of the IAM from SG A, SoftX3000 A encapsulates the IAM into the message body (SDP) of an INVITE message and sends it to SoftX3000 B to invite SoftX3000 B to participate in a session. The session description of the INVITE message carries SG A’s IP address (191.169.200.188), port number (30014), supported payload type, encoding information matching the payload type to SoftX3000 B.
2) Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A, notifying SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing the request.
3) Event 3: The called PSTN user receives the ringing tone. Meanwhile, SG B sends an Address Complete Message (ACM) to SoftX3000 B. Upon receipt of the ACM, SoftX3000 B encapsulates the ACM in a 180 Ringing response message and sends it to SoftX3000 A. The session description of the 180 Ringing message carries SG B’s IP address (191.169.150.1), port number (13304), supported payload type, encoding information matching the payload type to SoftX3000 A.
Upon receipt of the 180 Ringing message, SoftX3000 A extracts the ACM from the 180 Ringing message and transfers the extracted ACM to SG A. SG A receives the ACM, and meanwhile the calling PSTN user receives the ringback tone.
4) Event 4: The called PSTN user hooks off. SG B sends an Answer Message (ANM) to SoftX3000 B. Upon receipt of the ANM, SoftX3000 B encapsulates the ANM to the message body (SDP) of a 200 OK response message and sends it to SoftX3000 A.
Upon receipt of the 200 OK message, SoftX3000 A extracts the ANM from the 200 OK message and transfers the extracted ANM to SG A.
5) Event 5: SoftX3000 A sends an ACK message to SoftX3000 B, acknowledging the receipt of the final response to the INVITE request from SoftX3000 B.
Now, a bi-directional signaling channel is set up between the calling and called parties for them to make a conversation.
6) Event 6: The calling PSTN user hooks on. SG A sends a Release (REL) message to SoftX3000 A. Upon receipt of the REL message, SoftX3000 A encapsulates the REL in the message body (SDP) of a BYE request message and sends it to SoftX3000 B.
Upon receipt of the BYE message, SoftX3000 B extracts the REL from the BYE message and transfers the extracted REL to SG B.
7) Event 7: Upon receipt of the REL message, SG B knows that the calling PSTN user has hooked on, and then transfers the REL to the associated PSTN switch. The PSTN switch receives the message and sends the busy tone to the called PSTN user. The called PSTN user hooks on. SG B sends a Release Complete Message (RLC) to SoftX3000 B. Upon receipt of the RLC, SoftX3000 B encapsulates the RLC to the message body (SDP) of a 200 OK response message and sends it to SoftX3000 A.
Upon receipt of the 200 OK response, SoftX3000 A extracts the RLC from the 200 OK response and transfers the extracted RLC to SG A.
H.323 is an ITU-T Recommendation which covers the technical requirements for multimedia communications systems in a packet based network (PBN). H.323 entities (call control for instance) might be used in point-to-point sessions and multipoint conferences. The latest version of H.323 is Version 4 (V4).
H.323 describes the components of an H.323 system, including gateway (GW) between switched circuit network (SCN) and PBN, gatekeeper (GK) for address translation and access control, multipoint controller (MC) for controlling participation of terminals in multipoint conferences, multipoint processor (MP) for the centralized processing of audio, video, and/or data streams in a multipoint conference, and multipoint control unit (MCU) for providing the capability for terminals and gateways to participate multipoint conferences.
4.1.2 Definition of Terms
I. AAA
AAA stands for authentication, authorization, and accounting. Authentication is the process of checking whether the user has certain permission. Authorization is the process of granting the permission to the user, and allowing the user to access certain network resources. Accounting is the process of recording information when the subscriber is using a certain service. Such information is used to generate bills.
II. H.323 entity
An H.323 entity is any H.323 component, including terminals, gateways, gatekeepers, MCs, MPs, and MCUs. Terminals, gateways and MCU are known as endpoints. An endpoint can generate and terminate calls. It can generate and terminates media streams.
III. H.323 terminal
An H.323 terminal is an endpoint on the network which provides real-time, two-way communications with another H.323 terminal, gateway, or MCU. It can be integrated
in a personal computer, or can be an independent device, such as Ethernet-phone or video phone.
An H.323 entity interacts with an end user directly. It can call and be called. It can also process media streams.
IV. Gatekeeper
The gatekeeper (GK) is an H.323 entity on the network that manages the H.323 terminals, gateways, and MCUs in a zone. A zone includes at least one terminal, and may or may not include GWs or MCUs. A zone has one and only one GK.
The GK provides the following services and features for the H.323 endpoints:
Access control: Permitting the use of network resources after identity check. Address translation: Translating between alias and network address. Bandwidth management: Applying for initial bandwidth; controlling bandwidth
variation. Charging management: Providing basic charging data to the billing center. Zone management: Managing terminals, GWs and MCUs in the zone. Call control: Providing supplementary services.
V. Gateway
An H.323 Gateway (GW) is an endpoint on the network which provides for real-time, two-way communications between H.323 terminals on PBN and other ITU Terminals on an SCN or to another H.323 gateway. Conceptually, a GW performs conversions of media streams and signaling. The latter means that the GW serves as a terminal to convert the between user signaling and H.323 control signaling. If the GW connects two different networks, PBN and SCN for instance, it needs to convert between H.323 control signaling and signaling of the other type of network.
An H.323 GW interconnects different types of network, converts the format and content of signaling messages, and also the communication protocol procedures and media stream format.
VI. Multipoint conference
The components of multipoint conference are MC, MP, and MCU. They all serve for conferencing purpose.
The multipoint controller (MC) provides for the control of three or more terminals participating in a multipoint conference. The MC provides for capability negotiation with all terminals to achieve common levels of communications. It may also control conference resources such as who is multicasting video. When a terminal joins or leaves the conference, the MC will adjust the capability set sent to all terminals.
The multipoint processor (MP) processes the audio, video, and data streams in a multipoint conference, and returns the processed streams to each terminal. Therefore, the MP can implement the codec algorithms of all types of media streams.
The MC and MP are functional entities rather than physical ones.
The multipoint control unit (MCU) is an endpoint on the network which provides the capability for three or more terminals and GW to participate in a multipoint conference. It controls and manages the multipoint conference and all attended terminals, and performs mixing or switching of audio, video and data. The MCU consists of two parts: a mandatory MC and optional MPs.
There are two types of multipoint conferences:
Centralized multipoint conference
A centralized multipoint conference is one in which all participating terminals communicate in a point-to-point fashion with an MCU. The terminals transmit their control, audio, video, and/or data streams to the MCU. The MC within the MCU centrally manages the conference. The MP within the MCU processes the audio, video, and/or data streams, and returns the processed streams to each terminal. Figure 4-1 shows a typical networking model of centralized multipoint conference.
Terminal ATerminal B
Terminal C
MCU
Figure 4-1 A networking model of centralized multipoint conference
Decentralized multipoint conference
A decentralized multipoint conference is one in which the participating terminals multicast or multi-unicast their audio and video to all other participating terminals without using an MCU. The MCU manages the control messages and data messages only. Figure 4-2 shows a typical networking model of decentralized multipoint conference.
Figure 4-2 A networking model of decentralized multipoint conference
Hybrid multipoint conference
A hybrid multipoint conference is a mixture of centralized and decentralized multipoint conference. Figure 4-3 shows a typical networking model of hybrid multipoint conference.
Terminal A Terminal B Terminal C
MCU
Terminal D
Terminal E
Terminal F
Figure 4-3 A networking model of hybrid multipoint conference
VII. Radius
Radius stands for Remote Authentication Dial-In User Service. It is an AAA protocol widely in use. Radius specifies the format of the authentication, authorization and accounting messages interacting at Radius server and client.
4.1.3 Structure of H.323 Protocol Stack
Figure 4-4 shows the structure of H.323 protocol stack. The three layers at the bottom of the stack are bottom-layer protocols of PBN. In LAN, the physical layer is MAC-IPX. In IP network, the network layer is IP. There are two types of transport-layer protocols. One is unreliable transmission protocol like User Data Protocol (UDP), which transmits audio-visual signals in real time, and sends registration messages to GK. The other is reliable transmission protocol like Transmission Control Protocol (TCP), which transmits data signals, call signaling and media control messages.
Reliable Transport (TCP)Unreliable Transport (UDP)
Network Layer (IP)
Link Layer
Physical Layer
T.125
T.124
T.123
RTP
Figure 4-4 H.323 protocol stack
The H.323 protocol processing software includes the following parts:
All H.323 terminals shall have an audio codec. All H.323 terminals shall be capable of encoding and decoding speech according to Recommendation G.711. G.711 for PCM is mandatory and other G series Recommendations are optional. The most frequently-used Recommendations in IP telephony are G.729A and G.723.1.
H.260 Recommendation series, such as H.261 and H.263 specify the video codec.
The real-time audio and video encoded signals are all encapsulated in Real-time Transport Protocol (RTP) packets to provide timing information and datagram serial number for the receiving end to re-organize the signal. RTCP (Real-time Transport Control Real-time Transport Control Protocol (RTCP) is a part of RTP, and provides QoS monitoring feature.
Recommendation T.120 is the default basis of data interoperability in multimedia conferences.
H.225.0 is the core of H.323 protocol stack. It defines call signaling protocols and media stream packetization for packet-based multimedia communication systems. H.225.0 serves for call control. The principal function of H.225 is to establish call connections and H.245 control channel between H.323 endpoints before starting a call. H.225.0 also covers two other features: specifying the use of RTP/RTCP for media stream packetization and synchronization; defining RAS.
RAS, which stands for Registration, Admission and Status, specifies a type of message used between endpoint and GK. The RAS signaling function uses
H.225.0 messages to perform registration, admissions, bandwidth changes, status, and disengage procedures between endpoints and GKs.
Recommendation H.225.0 is drafted based on Q.931 and Q.932. ITU-T Recommendation Q.931 is ISDN user-network interface layer-3 specification for basic call control.
Recommendation H.245 is the control protocol for multimedia communication. It is designed for conference communication. H.245 is the control protocol in H.323 stack, and controls the establishment, maintenance and release of channels.
RAS, H.225.0 and H.245 are used in SoftX3000. The network protocol is IP, and the transport protocol is UDP and TCP. RAS is borne over UDP; while H.225.0 and H.245 are borne over TCP.
RAS, H.225.0 and H.245 will be detailed in the following sections.
4.1.4 H.323 Applications in SoftX3000
SoftX3000 implements multimedia communication services in H.323. Figure 4-5 shows the H.323 applications in SoftX3000. SoftX3000 provides two H.323 interfaces.
1) One is called SoftX3000 H.323 domain, which is the interface of H.323 terminals under direct control of SoftX3000. SoftX3000 can serve as an H.323 GW and an H.323 GK at the same time.
2) The other is called H.323 domain, which interfaces the external H.323 network. SoftX3000 serves as an H.323 GW.
SoftX3000 services as an H.323 GK in the domain. All H.323 terminals in the domain must register at SoftX3000 before using any services provided by SoftX3000.
SoftX3000 serves as an H.323 GW, and provides SIP, ISUP and MGCP interfaces to other networks.
The H.323 interfaces support signaling and protocol of RAS, Q.931 and H.245. SoftX3000 verifies the username and password retrieved from the H.323
terminal.
II. H.323 domain
SoftX3000, as an H.323 GW, must register at an external H.323 GK before using the services provided in the H.323 domain.
The H.323 interfaces support signaling and protocol of RAS, Q.931 and H.245. SoftX3000 registers the addresses of all terminals connecting through itself to
the external GK, including all H.323 terminals in the domain.
4.2 RAS Protocol
4.2.1 Overview of RAS
RAS is a part of H.225.0, which is used between endpoint and GK, and implements management function. It includes the following seven categories of procedures:
I. GK discovery
An endpoint uses multicast mode to discover the homed GK. Afterwards, all RAS messages will be transmitted between the endpoint and its homed GK.
II. Terminal and GW registration
It is used by an endpoint to register its information with the GK, including alias and transmission layer address of call control channel. This procedure also includes deregistration procedure.
III. Location request
It is used by endpoint or GK to request from corresponding GK the transmission layer address of the call control channel of a certain endpoint.
INAK Information Negative Acknowledgement Response
Table 4-8 Terminal to gatekeeper requests for changes in bandwidth
Message name Message description Message type
BRQ Bandwidth Request Request
BCF Bandwidth Confirm Response
BRJ Bandwidth Reject Response
Table 4-9 GW resource availability messages
Message name Message description Message type
RAI Resource Availability Indication Request
RAC Resource Availability Confirmation Response
II. RAS message format
A RAS message is in text format, and consists of message name and some mandatory and optional parameters. These parameters vary in different messages. Figure 4-6 illustrates a generic architecture of RAS message.
This section describes ASN.1 structures that are used in more than one RAS messages.
1) RequestSeqNum
All RAS messages include requestSeqNum. It is assigned by the request party and increments by 1. Any associated response messages (success or failure) shall have the corresponding requestSeqNum returned with it. Retransmitted messages shall have the same requestSeqNum. For instance, GRQ message and the triggered GCF or GRJ share the same requestSeqNum.
2) ProtocolIdentifier
The protocolIdentifier “determines the vintage of the implementations involved”. It defines the version number of the H.225 Recommendation used.
3) NonStandardData
It carries the non-standard information such as proprietary data that is not defined in H.225 Recommendation.
4) RasAddress
This is the registration and status transport address for this endpoint. RAS messages are transmitted on top of UDP in well-known port 1719.
5) EndpointType
It specifies the type of the endpoint—terminal, GW or MCU. If the H.323 element has an MC, then the mc Boolean would be true.
6) GatekeeperIdentifier
For RAS request messages, it identifies the GK that will respond to the request. If it is not supplied, the request message is valid to all reachable GKs.
For RAS response messages, it identifies the GK that returns the response message.
7) CallServices
It provides information on support of optional Q-series protocols to GK and called terminal.
8) EndpointAlias
It is a list of alias addresses, by which other terminals may identify this terminal. An alias address can be an E.164 address or an H.323 identifier. An E.164 address contains access code and telephone number, the latter of which identifies the GW. An H.323 identifier is a string of subscriber name, E-mail name or other identifier name. One endpoint can have multiple alias addresses corresponding to PRQ messages. All these alias addresses are sent to GK in the PRQ messages, and are translated to the same transport-layer address.
When an endpoint calls another or an alias, GK returns a prioritized endpoint as called party. Alternatively, the GK can also return a sequence of prioritized endpoint alternatives for rasAddress, endpointType, or endpointAlias. This parameter is used to improve call connection rate.
10) DiscoveryComplete
It is included in RRQ message. Set to TRUE if the requesting endpoint has preceded this message with the gatekeeper discovery procedure; set to FALSE if registering only.
11) CallSignalAddress
This is the registration and status transport address for this endpoint. Q.931 messages are transmitted on top of TCP in well-known port 1720.
12) VendorIdentifier
The VendorIdentifier structure allows a vendor to identify a product. The vendor element allows identification in terms of country code, extension, and manufacturer code. productId and versionId are text strings that can provide product information.
For instance:
VendorIdentifier
Vendor
T35CountryCode:82
T35Extension:0
manufacturerCode:2290
productId:Cns H.323v2
versionId:2.0
13) TimeToLive
TimeToLive is a number seconds that a registration is to be considered valid. The parameter is included in PRQ and PCF messages.
14) KeepAlive
An endpoint can send a lightweight RRQ consisting of only rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE should ignore fields other than endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive.
15) EndpointIdentifier 16) WillRespondToIRR
When it is set to True, the Gatekeeper will send an IACK or INAK message in response to an unsolicited IRR message with its needsResponse field set to TRUE.
17) RejectReason
It is included in RRJ message, and identifies the reason for the rejection of the registration.
Using this value, called party's GK can attempt to determine 'real' bandwidth usage. The default value is pointToPoint for all calls.
19) CallModel
H.323 Recommendation defines two transmission models for end-to-end (E2E) call signaling. When the callModel is gatekeeperRouted, the endpoint is requesting the GK mediated model. Either end knows the address of the other end, thus protecting the privacy of subscribers. The GK participates in the call signaling procedure. When the callModel is direct, the endpoint is requesting the direct terminal to terminal call model. After GK provides the transport-layer address of the called party, it no longer involves in the call signaling procedure.
20) EndpointIdentifier
It is a GK-assigned terminal identity string, such as E.164 addresses or H323_IDs.
21) DestCallSignalAddress
It is the translated call signaling transport address of destination terminal or GK itself. It includes IP address and port number of Q.931 messages.
22) SrcInfo
It is a sequence of alias addresses for the source endpoint, such as E.164 addresses or H323_IDs.
23) SrcCallSignalAddress
It is the transport address used at the source for call signaling.
24) BandWidth
The parameter is used by GK to control the number of H.323 terminals accessing PBN at the same time. The GK can reject a call when there is not enough bandwidth to support the call.
In ARQ and ACF messages, BandWidth is the number of 100 bits requested for the bidirectional call. For example, a 128 kbit/s call would be signalled as a request for 256 kbit/s. The bandwidth defined by GK in ACF can be less than the one defined in ARQ.
25) CallReferenceValue (CRV)
It is the CRV cited from Q.931. The call reference value is chosen at the side originating the call and has to be locally unique. This is used by a GK to associate the ARQ with a particular call. For instance: The call model in gatekeeperRouted, CRV at the two signaling segment—source terminal-GK and GK-destination terminal—are different. GK establishes the association between two CRVs, and ensures accurate transmission of signaling messages. Nevertheless, in the same signaling segment, all H.225.0 messages of a particular call, such as call admission, call establishment, supplementary service, bandwidth change, and call termination share the same CRV.
It is the unique identification of the conference to which the call belongs. CID consists of three parts—endpoint network address, conference initiation time and protocol version. Each call of a particular conference has its own call ID. All calls shares the same conferenceID, which is adopted for all H.225.0 messages in the conference.
27) Call ID
It identifies a call. Unlike CRV, the call ID is a global parameter. In other words, from source endpoint to GK, from source endpoint to destination endpoint, and from destination endpoint to GK, all RAS messages and call signaling messages of a particular call share the same call ID. The call ID serves for E2E message transmission. It can be encapsulated and transmitted in the Q.931 user-to-user messages. It can be used in supplementary services. The call ID is assigned by the source endpoint.
28) ActiveMC
It defines whether the source endpoint has an active MC.
29) AnswerCall
If the answerCall flag is TRUE then the GK has pre-granted permission to the endpoint to answer calls without first sending an ARQ. If the answerCall flag is FALSE, the endpoint shall always send ARQ to get permission to answer a call.
30) WillSupplyUUIEs
If it is set to TRUE, it indicates that the endpoint will supply Q.931 message information in IRR messages if requested by the Gk.
Line 2 indicates that the request sequence number is 969. The requestSeqNum is the same as the ones in the response messages RCF and RRJ, and is used to associate RRQ, RCF and RRJ.
Line 3 is protocolIdentifier, which defines the version number of the H.225 Recommendation used.
Line 4 is discoveryComplete, which is included in RRQ only. It is set to TRUE, which indicates that the requesting endpoint has preceded this message with the GK discovery procedure;
Line 5 to line 9 list the information of the endpoint that is transmitting Q.931 messages. IP address: 191.169.200.31; port number: 1720.
Line 10 to line 14 list the information of the endpoint that is transmitting RAS messages. IP address: 191.169.200.31; port number: 1719.
Line 15 to line 18 specify the type of the endpoint that is registering. In this example, it is an H.323 terminal.
Line 19 to 23 are content of the terminalAlias. It can be an E.164 address or an H.323 identifier. Here, the E.164 address is a telephone number 666302, and the H.323 identifier is also 666302.
Line 24 to 30 specify information about the endpoint vendor. Here, the country code is 82, extension is 0 and manufacturer code is 2290. productId and versionId are text strings that can provide product information.
Line 31 indicates that the registration is valid for 3600 seconds.
Line 32 has the following implications. An endpoint can send a lightweight RRQ consisting of only rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE should ignore fields other than endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. Therefore, keepAlive is set to False in the first RRQ message, and True for all the subsequent ones.
Line 32 is endpointIdentifier.
4.2.3 Basic Procedures
I. Overview of basic procedures
This section introduces three procedures:
GK discovery Terminal registration and unregistration Terminal to GK admission and disengagement
Each procedure is explained with a generic example of several events. Each process step represents an individual event.
II. GK discovery
GKEndpoint
GRQ
GCF
GRJ
1
2
3
GKEndpoint
GRQ
GCF
GRJ
1
2
3
Figure 4-7 Message flow diagram of GK discovery procedure
Here is the generic process of a GK discovery procedure:
1) When the endpoint initiates, it sends a GRQ message, searching for GK.
The GRQ message includes parameters endpointType, rasAddress, and gatekeeperIdentifier.
2) GK analyzes the endpoint information, determines that it is a local endpoint, and returns a GCF message. Alternatively, GK rejects the registration request of the endpoint, and returns a GRJ message with cause of rejection.
III. Terminal registration and unregistration
An endpont must register itself in the GK discovery procedure before it can start and receive calls. The registration of endpoint to the GK includes the former under the control of the latter.
GK
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
GKEndpoint
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
GK
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
GKEndpoint
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
Figure 4-8 Message flow diagram of terminal registration and unregistration
Here is the generic process of a terminal registration and unregistration procedure:
1) The endpoint sends a RRQ message to the RAS address of GK. The RRQ message includes two important parameters: endpontAlias and callSignalAddress.
2) The GK analyzes the endpoint information, determines that it is a local endpoint, and returns a GCF message. The endpoint then informs the GK of its call signaling transport address. The GK will then record the endpointAlias and callSignalAddress in translation table. When the GK finds that the endpoint is not a locla one, it returns an RRJ message to reject the call.
3) When the endpoint is to end the service, or change the mapping relation between alias and address, it sends a URQ message to GK and requests for unregistration.
4) In normal cases, GK returns a URF message for confirmation. When GK finds no registration information of the endpoint, it returns a URJ message.
ARQ/ACF and DRQ/DCF are the first and last pair of messages in the whole call control procedure. The first pair indicates the start and the last pair indicates the end of the call.
GK
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
GKEndpoint
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
GK
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
GKEndpoint
ARQ
ACF
ARJ
DRQ
DCF
DRJ
1
2
3
4
5
6
Figure 4-9 Message flow diagram of terminal to GK admission and disengagement
1) When the endpoints initiates a call, it sends an ARQ message to GK for authentication and address resolution. In the ARQ message, the endpoint specifies the destination information and required bandwidth.
2) If the GK admits the call, it returns an ACF message. The ACF message includes two key parameters—bandWidth which specifies the allowed maximum bandwidth for the call, and destCallSignalAddress, which might be an endpoint or GK address depending on the call model in use. Alternatively, the GK rejects the call with an ARJ message.
3) When the call completes, the endpoint sends a DRQ message to the GK, requesting to disengage the call.
4) In normal cases, GK returns a DCF message for confirmation. If the GK refuses the request, it returns a DRJ message.
4.3 H.225.0 Call Signaling Protocols
4.3.1 Overview of H.225.0
Recommendation H.225.0 is drafted based on Q.931 and Q.932. Recommendation Q.931 is ISDN user-network interface layer-3 specification for basic call control. Recommendation Q.932 specifies the generic procedures for the control of ISDN supplementary services.
H.225.0 basic call control messages are borrowed from Q.931 and Q.932. The former provides a greater share. As H.225.0 call signaling messages contain no call connection information, many Q.931 and Q.932 messages are thereby simplified here. Here, we will focus on H.225.0 call signaling messages only.
II. Call establishment messages
Table 4-10 Description of call establishment messages
Message name Meaning
Setup To initiate call establishment.
Setup Acknowledge
To indicate that call establishment has been initiated, and request for subsequent address information.
Call Proceeding To respond to Setup message, and indicate that requested access connection establishment has been initiated, and called number is complete.
Alerting To indicate that the called subscriber alerting has been initiated.
Connect To indicate acceptance of the access connection.
Progress To indicate the progress of an access connection establishment in the event of interworking within a private network.
III. Call clearing messages
Table 4-11 Description of call clearing messages
Message name Meaning
Release Complete To indicate that the equipment sending the message has released the channel (if any) and call reference (CR).
IV. Miscellaneous messages
Table 4-12 Description of call miscellaneous messages
Message name Meaning
Information To provide additional information, such as subsequent called address.
When the length of call reference is set to zero, the CRV is a virtual call reference, meaning that it is irrelevant to any call, and is used for supplementary services.
IV. Call reference value
This parameter is used to identify a call, and it is only valid in part of the call segment. For instance: The call model in gatekeeperRouted, CRV at the two signaling segments—source terminal-GK and GK-destination terminal—are different. GK establishes the association between two CRVs, and ensures accurate transmission of signaling messages. The CRV is generally used to associate multiple calls in three-party service or multi-party service.
V. Message type
Its value is coded by Q.931, as described in Section 4.3.2.1.
4.3.4 Information Elements
I. Bearer capability
It is a mandatory information element (IE) in H.225.0, though less significant as specified in Q.931. If this information element is received in a call between two H.323 terminals, it may be ignored by the receiver. If this information element appears in a Setup message for a call-independent signaling connection as defined in Recommendation H.450.1, the coding shall follow 7.2/H.450.1, which will not be elaborated here. H.225.0 specifies bearer capability as follows:
Information transfer capability
For calls originating from an ISDN endpoint the information indicated to the gateway shall be forwarded. This is to allow some advance information about the nature of the connection to be forwarded to the H.323 endpoint, for example, voice only vs. data vs. video; this would have an impact on the bandwidth required as well as on the ability/willingness to accept the call or not.
Calls that originate from an H.323 endpoint shall use this field to indicate their wish to place an audiovisual call. For audiovisual call, the field shall be set either to 'unrestricted digital information'. If a speech only call is to be placed, the H.323
terminal shall set the information transfer capability to either 'speech' or to '3.1 kHz audio'.
Rate multiplier
The segment shall be present if information transfer rate is set to 'multirate'. For a call originating from an ISDN endpoint, the gateway shall simply pass on the information that it receives from the ISDN. For a call originated from an H.323 endpoint, this shall be used to indicate the bandwidth to be used for this call on the SCN side. If a gateway is involved, this value shall reflect the number of external connections to be set up.
Layer 1 protocol
It is set to G.711 to indicate a voice-only call and H.221 and H.242 to indicate an H.323 videophone call.
II. Display
The network will send American Standard Code for Information Interchange (ASCII) to subscriber to be displayed.
III. Called party number and calling party number
The calling party number is used for charging and caller number display.
The called party number is used for routing.
If the numbering plan identification is set to “Private Numbering Plan” in a PBN originated call, this indicates that the E.164 address is not present in Setup message; and the call will be routed by an alias address in the user-to-user information.
IV. Cause
It indicates the generation of the message for future diagnosis. The Cause is mandatory in Release Complete, but optional elsewhere. The Cause information element and the ReleaseCompleteReason (a part of the Release Complete message) are mutually exclusive. The Cause is borrowed from Q.931, while ReleaseCompleteReason is for PBN.
Gateways shall map from a ReleaseCompleteReason to the Cause IE when sending a Release Complete message to the SCN side from the PBN side. Table 4-1 shows the mapping between the Cause IE and ReleaseCompleteReason.
Table 4-13 Mapping between the Cause IE and ReleaseCompleteReason
ReleaseCompleteReason code Corresponding Q.931 cause value
The reverse mapping is not required as packet-based network entities are required to decode the Cause IE.
V. User-User Information Element
User-User Information Element (UUIE) is the most significant IE in H.225.0 call signaling. It shall be used by all H.323 entities to convey H.323-specific call control information in addition to normal E2E subscriber data. The call control information is the essence of H.323 call signaling system, and represents the call signaling capability of the entire H.323 system. UUIE is indispensable for messages such as Setup, Alerting, CallProceeding, Connect, Release Complete, Facility, and User Information.
The protocol discriminator is changed to ASN.1. It means that the user information is changed from IA5 of Q.932 to a generic ASN.1.
The user information contains two parts. The body part is h323-UU-pdu, containing the UUIE contents of related messages, that is, the signaling information of H323. The optional part is the user data transmitted between terminals, and the data is IA5 character string, whose maximum length is 131 bytes. It is equivalent to user-user information defined in Q.932, but it is encapsulated in UUIE data structure defined by ASN.1. As an element in the data sequence, it is called user data.
H.225.0 defines the contents of h323-UU-pdu in UUIE of each related message. For example, the UUIE of Connect message contains the following contents:
Protocol identifier It is set by the called endpoint as the version number of H.225 protocol supported by the endpoint.
H.245 address: It is the transmission layer address of H.245 control channel of called endpoint or GK. According to this address, the calling endpoint can establish the H.245 control channel to the called endpoint or GK, and then establish the required media channel. This is the major purpose of H.225.0 call. This parameter can also be transmitted by UUIE of Alerting message or Call Processing message.
Destination information: It is used to indicate the endpoint type, making the calling endpoint able to determine whether the call is related to gateway.
Conference identifier: It is the conference identifier carried in Setup message. Call identifier: It is set by calling endpoint.
4.3.5 A typical example of Q.931 message
This is an example of Setup message.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 6FD1
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Packet mode
Information transfer rate: Packet mode
User information layer 1 protocol: Recommendation H.221 and H.242
Line 1 indicates that the message is a Q.931 message.
Line 2 is protocol descriminator. Now, it is set to Q.931.
Line 3 defines the length of call reference value. It is set to 2 bytes.
Line 4 is call reference value. It is 6FD1.
Line 5 is message type. Now, it is Setup.
Line 6 to line 15 means that the caller is an H.323 endpoint, and the information transfer capability is “Unrestricted digital information”. It implies that the caller is about to make a video call. Layer 1 protocol is set to H.221/H.242, which means that the call is an H.323 video call.
Line 16 to line 19 The network will send American Standard Code for Information Interchange (ASCII) to subscriber to be displayed.
Line 20 to 25 The calling party number: used for charging and caller number display.
Line 26 to 31 The called party number: used for routing.
Line 32 to 33 indicates the following is UUIE.
Line 34 indicates that the UUIE length is 126 bytes.
Line 35 protocol discriminator.
Line 36 to end The UUIE contents in the Setup message. The UUIE contains the following contents:
sourceAddress (AliasAddress): It can be an E.164 address or an H.323 identifier. Here, the E.164 address is a telephone number 7670000, and the H.323 identifier is also 7670000.
sourceInfo (EndpointType): Here, the country code is 82, extension is 0 and manufacturer code is 2290. productId and versionId are text strings that can provide product information.
destinationAddress (AliasAddress): It can be an E.164 address or an H.323 identifier. Here, the E.164 address is a telephone number 7670001, and there is no H.323 identifier.
callType (pointToPoint): Using this value, called party's GK can attempt to determine 'real' bandwidth usage. Here, it is an end-to-end call.
sourceCallSignalAddress (ipAddress): It is the transmission layer address (IP address plus TCP port number) of cal signaling channel of local endpoint. Here, the IP address is 191.169.200.31, and the port number is 1074.
callIdentifier: the call identifier is 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4.
4.3.6 Basic Procedures
I. Overview of basic procedures
This section takes the example that two endpoints register with the same GK, and describes the signaling procedures in two message transmission modes, for the purpose of detailing the call control procedure of H.323 system.
II. Basic call setup procedure (direct routing mode)
Figure 4-12 shows the signaling procedure, and follows brief description.
Endpoint 1 Endpoint 2GK
ARQ
ACFSetup
Call proceeding
ARQACF
AlertingConnect
RAS message
Cal signaling message
1
23
456
78
Endpoint 1 Endpoint 2GK
ARQ
ACFSetup
Call proceeding
ARQACF
AlertingConnect
RAS message
Cal signaling message
1
23
456
78
Figure 4-12 Signaling procedure (direct routing) of public GK
1) Scenario 1: Endpoint 1 (calling party) sends ARQ message to its GK through RAS channel, to request the GK to originate a call to endpoint 2.
2) Scenario 2: The GK agrees to accept the call. It translates the transmission layer address (IP address plus TCP port number) of call signaling channel of endpoint 2, and the sends the address in ACF message to endpoint 1.
3) Scenario 3: Endpoint 1 establishes call signaling channel to endpoint 2, and sends Setup message through the channel. If the ARQ has CRV, the Setup message and following signaling messages have the same CRV.
4) Scenario 4: Endpoint 2 sends back Call Proceeding message, indicating that the call has been processed. For the call between two H.323 terminals, the messages except UUIE do not carry other information element. If the call is between H.323 terminal and ISDN terminal, that is, if endpoint 2 is a gateway, endpoint 2 will transparently transmit the information elements from SCN side, such as bearing capability and proceeding indicator, to endpoint 1. If endpoint 1 is an H.323 terminal, there is no explanation information. If endpoint 1 is also a gateway, such information elements will be transmitted to the calling party at SCN side.
5) Scenario 5: Endpoint 2 sends ARQ to the GK through RAS channel to accept the call.
6) Scenario 6: The GK agrees to accept and sends back ACF. 7) Scenario 7: Endpoint 2 sends back Alerting message to endpoint 1, and waits for
answer by subscriber. 8) Scenario 8: The subscriber answers the call. Endpoint 2 sends Connect
message to endpoint 1, and the message carries H.245 control channel TCP port number of endpoint 2. Now , the call is set up.
If the GK does not allow endpoint 2 to accept the call, it will send back ARJ. In this case, endpoint 2 will send Release Complete message to endpoint 1.
III. Basic call setup procedure (gatekeeper routed mode)
Endpoint 1 Endpoint 2GKARQ
ACF
ARQACF
Alerting
Connect
RAS message
Call signaling message
1
2
78
Setup3Setup
Call proceedingCall proceeding
Alerting
Connect
45
6
910
1112
Endpoint 1 Endpoint 2GKARQ
ACF
ARQACF
Alerting
Connect
RAS message
Call signaling message
1
2
78
Setup3Setup
Call proceedingCall proceeding
Alerting
Connect
45
6
910
1112
Figure 4-13 Signaling procedure (gatekeeper routed) of public GK
Figure 4-13 shows the signaling procedure. The differences from the signaling procedure in direct routing mode are as follows:
1) The ACF message sent by the GK to endpoint 1 does not carry transmission layer address of call signaling channel of endpoint 1. Instead, the ACF message carries the transmission layer address of call signaling channel of the GK. Meanwhile, the GK establishes the call signaling channel to endpoint 2.
2) Afterward, the call signaling messages from endpoint 1 can only be transmitted to the GK, which transfers the messages to endpoint 2. Because endpoint 2 establishes signaling channel only with the GK, it can only send signaling messages to the GK, which transfers the messages to endpoint 1.
3) After the call is set up, endpoint 2 tells the GK the H.245 control channel transmission layer address in Connect message, but the information in Connect message sent by the GK to endpoint 1 is up to the transmission mode of H.245 control message. If the GK uses direct routing mode to transmit media control messages, the messages contain the H.245 control channel address of endpoint 2; if the GK uses transfer mode, the messages contain the H.245 control channel address of the GK. In this case, the GK has MC functions.
When either calling party or called party hooks on, a Release Complete message is sent to the GK, which then sends a Release Complete message to the peer end. Then TCP connection is disconnected.
Recommendation H.245 is the control protocol for multimedia communication. It is designed for conference communication. H.245 is the control protocol in H.323 stack, and controls the establishment, maintenance and release of channels.
In H.245, there are two kinds of channels defined as follows:
1) Control channel: also called H.245 channel. Through this channel, two H.245 peer signaling entities in different H.323 entities transmit H.245 messages to control the establishment and release of media channel. Control channel is a reliable channel, which corresponds to a TCP connection in IP network, and the numbers of the connected ports are allocated dynamically. In the H.225.0 call setup procedure, the calling and called endpoints (or GK) use Setup and Connect messages to exchange the allocated H.245 port address. After the call is set up, H.245 control channel is established. Each call has only one H.245 control channel, which exists during the call and will be released after the call is over.
2) Communication channel: also called media channel. In H.245, it is defined as logical channel, used to transmit user communication information. Generally, there might be multiple logical channels between two entities, and they can be established or released when necessary. In H.245, establishment is called Open and release is called Close. Logical channels are opened or closed by H.245, and each logical channel is assigned with an identifier when opened. Control channel can be regarded as a special permanent logical channel, whose channel number is 0.
In H.323, most of logical channels are uni-directional channels, especially those in conference call. However, T.120 data communication protocol and ordinary point-to-point telephone communication require bi-directional channel, which is composed of a pair of uni-directional logical channels occupying two logical channel numbers. The H.245 OpenLogicalChannel procedure supports uni-directional channel establishment and bi-directional channel establishment. The logical channels used to transmit audio and video signals are unreliable channels (such as UDP channels), the logical channels used to transmit data are reliable channels (such as TCP channel). Their port numbers are allocated dynamically. Logical channel establishment is actually that both parties use OLC and OLCA messages to exchange their allocated port numbers.
Each logical channel use a specific coding algorithm and bandwidth to transmit a specific kind of media information. In this case, both parties must negotiate these parameters before a logical channel is established, to determine the acceptable
parameter ranges. This is the capability exchange procedure of H.245. H.245 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 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.
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.
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. 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:
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.
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
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.
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
Capability table
Capability descriptors
Capability descriptor……
……
Simultaneous capability……
……
Alternative capability……
……
Capability table entry number……
……
Multiplexcapability
Capability table entry number
Capability table entry number
Alternative capability
Alternative capability
Simultaneous capability
Simultaneous capability
Capability descriptor
Capability descriptor
Sequence number
Protocol identifier
Capability table
Capability descriptors
Capability descriptor……
……
Simultaneous capability……
……
Alternative capability……
……
Capability table entry number……
……
Multiplexcapability
Capability table entry number
Capability table entry number
Alternative capability
Alternative capability
Simultaneous capability
Simultaneous capability
Capability descriptor
Capability descriptor
Figure 4-15 Data structure of TerminalCapabilitySet message
Sequence number
It is used to label instances of TerminalCapabilitySet so that the corresponding response can be identified.
Protocol identifier
It is used to indicate the version of Recommendation H.245.
Multiplex capability
it is used to indicate capabilities relating to multiplexing and network adaptation.
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.
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.
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, ……}
The terminal’s total capabilities are described by a set of CapabilityDescriptor structures, each of which is a single simultaneousCapabilities structure and a 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.
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.
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.
Terminal type
TerminalType is a number that identifies different types of terminal
Entity contains MC with data and audio MP / 100 140 180
Entity contains MC with data, audio and video MP / 110 150 190
After the peer end receives the masterSlaveDetermination message, it starts the determination calculation procedure. The determination principle is: the endpoint with larger terminaltype value is "Master". If the terminaltype values are the same, the endpoint with larger StatusDeterminationNumber is “Master”. If the StatusDeterminationNumbers are still the same, “undetermined” will be resulted. Generally, the status can be determined. Then, the peer terminal sends back determination acknowledge message to tell the determination result. If the status cannot be determined, the peer terminal sends back determination reject message, with rejection reason as “same number”. Then, the local terminal regenerates a StatusDeterminationNumber, and starts master-slave determination procedure again.
Besides, in a conference call, if an MC becomes the active MC, its terminaltype value becomes 240. An MC that is already acting as an MC shall always remain the active MC. Therefore, once an MC has been selected as the active MC in a conference, it shall use the Active MC value for all subsequent connections to the conference.
3) Logical channel signaling procedure
Logical channel is opened by transmitter side. It sends a OpenLogicalChannel message to the receive terminal, and the message contains ForwardLogicalChannelNumber and channel parameters.
ForwardLogicalChannelNumber
ForwardLogicalChannelNumber must be assigned by the transmitter side, and the acknowledge message carries this value to match the request message.
Channel parameters
The parameters define whether data type and media information are transmitted surely, whether silence suppression is performed, and destination terminal tag.
If the channel is used to transmit RTP encapsulated real-time media information, such as audio or video, the channel parameters also include the following three parameters:
Session ID
RTP session ID. An RTP session is the communication of a group of participants through RTP. For each participant, the session is defined by a pair of transmission
layer addresses (network layer address plus RTP and RTCP ports numbers). In IP multicast mode, the transmission layer addresses of the participants might be the same. In unicast mode, the transmission layer addresses of the participants are different because their network addresses are different. In a multimedia session, each media signal is transmitted by an individual RTP session, and has its own RTCP group. The RTP sessions are distinguished by different port pair and/or different multicast addresses.
Media channel
Used to transmit the IP address and port number of RTP encapsulated real-time media messages, and other transmission QoS parameters.
Media control channel
Used to transmit the IP address and port number of QoS parameter messages of RTCP encapsulated real-time signal transmission.
For more information about the above parameters, see RTP related documents.
IV. Example of H.245 message
An example of OpenLogicalChannel message is shown as follows:
Line 1 indicates that the message is an H.245 message.
Line 2 indicates that the message is a request message.
Line 3 indicates that the message name is openLogicalChannel.
Line 4: Forward logical channel number. Here the value is 1. This parameter must be assigned by transmit party, and the acknowledge message returns this value to match the request message.
Lines 5 and 6: Forward logical channel parameters. The parameters define whether data type and media information are transmitted surely, whether silence suppression is performed, and destination terminal tag.
Lines 7 to 11: Data type. Here, the data type is G.723 audio data, without silence suppression.
Lines 12 to 13: H.225 logical channel parameter, which is mandatory because the channel is used to transmit RTP encapsulated real-time media information, such as audio or video.
Line 14: RTP session ID. Here the value is 1.
Lines 15 to 21: Media channel parameters. That is, the IP address and port number used by the endpoint to transmit RTP encapsulated real-time media information. Here, the IP address is 191,169,150,171, and the port number is 40000.
Lines 22 to s8: Media control channel parameters. That is, the IP address and port number used by the endpoint to transmit QoS parameter message of RTCP encapsulated real-time signal transmission. Here, the IP address is 191,169,150,171, and the port number is 40001.
H.323 call procedure can be established in normal start and fast start mode. A complete H.323 call needs RAS, Q.931 and H.245.
For endpoint registration procedure, see Section 4.2.3.
4.5.1 Successful H.323 User Call Procedure (Normal Start)
Figure 4-21 shows a successful call procedure (normal start) between two H.323 users in the same SoftX3000.
The following example complies with the conventions below:
SoftX3000 serves as the GK, and its IP address is 191.169.150.170. The IP address of H.323 PhoneA is 191.169.150.171. The IP address of H.323 PhoneB is 191.169.31.31. H.323 PhoneA is the calling party, H.323 PhoneB is the called party, and the
called party first hooks on. The phone number of H.323 PhoneA is 7670000, and the phone number of
Figure 4-21 Successful H.323 user call procedure (normal start)
1) Scenario 1: H.323 PhoneA hooks off, and it sends ARQ to the GK to request whether the call can be initiated. In the ARQ message, H.323 PhoneA gives the destination information, required bandwidth, and call ID. It should be noted that the CallModel is gatekeeperRouted, and the GK is involved in the call signaling procedure, while the peer endpoints do not know the addresses of each other.
2) Scenario 2: The GK agrees to accept the call, and sends ACF message to H.323 PhoneA. In the message, there is allowed bandwidth, and translated transmission layer address of call signaling of destination or the transmission layer address of call signaling of the GK. Because the CallModel is “gatekeeperRouted”, the call signaling transmission layer address after translation is the transmission layer address of call signaling of the GK (IP address plus TCP port number). The IP address is 191.169.150.170, and the port number is 1720. Meanwhile, the GK establishes call signaling channel to H.323 PhoneB.
3) Scenario 3: H.323 PhoneA sends Setup message to the GK, to request call establishment. In the UUIE field of the message, the transmission layer address of the source call signaling channel is given (IP address plus TCP port number). The IP address is 191.169.150.171, and the port number is 1074, used to receive the Q.931 messages from the GK.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 6FD1
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Packet mode
Information transfer rate: Packet mode
User information layer 1 protocol: Recommendation H.221 and H.242
4) Scenario 4: The GK sends back Call Proceeding message, indicating that the call has been processed. The VendorIdentifier in the UUIE field of the message indicates the vendor ID of the GK. Here, the country code is 28, extension is 21 and manufacturer code is 0. Besides, it is indicated that the GK is Huawei NGN SoftX3000 product, whose version is SoftX3000V3.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: EFD1
Message type: CALL PROCEEDING (0x02)
User-user
Information element: User-user
Length: 70
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (callProceeding)
callProceeding
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
guid: 3F503030-DCBC-9839-3FB9-D7A6F6B50BF4
h245Tunneling: False
5) Scenario 5: The GK receives the Setup message from H.323 PhoneA. If the GK agrees to establish the call, it will translate and get the transmission layer
address (IP address plus TCP port number) of call signaling channel of H.323 PhoneB. The IP address is 191.169.31.31, and the port number is 1720. Then, the GK transfers the Setup message to H.323 PhoneB to request call establishment. In the UUIE field of the message, the transmission layer address of the source call signaling channel is given (IP address plus TCP port number). The IP address is 191.169.150.170, and the port number is 5011, used to receive the Q.931 messages from H.323 PhoneB.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 0004
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 4
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Circuit mode
Information transfer rate: Multirate (64 kbit/s base rate)
Rate multiplier: 186
User information layer 1 protocol: Recommendation H.221 and H.242
6) Scenario 6: H.323 PhoneB agrees to accept the call, and sends ARQ message to the GK through RAS channel, to tell the GK it accepts the incoming call.
7) Scenario 7: The GK agrees to accept the call, and sends ACF message to H.323 PhoneB. In the message, the GK sends the transmission layer address (IP address plus TCP port number) of its call signaling channel to H.323 PhoneB..
10) Scenario 10: H.323 PhoneB sends Connect message to the GK, and the message carries the IP address and TCP port number of the H.245 control channel of PhoneB. The IP address is 191.169.31.31, and the port number is 2722. Besides, the message carries the vendor ID, product and version information of H.323 PhoneB.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8004
Message type: CONNECT (0x07)
User-user
Information element: User-user
Length: 81
Protocol discriminator: X.208 and X.209 coded user information
11) Scenario 11: The GK receives Connect message from H.323 PhoneB, and transfers the message to H.323 PhoneA. The message carries the IP address and TCP port number of the H.245 control channel of H.323 PhoneB. The IP address is 191.169.31.31, and the port number is 2722. Besides, the message carries the vendor ID, product and version information of the GK. Now , the call is set up.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: EFD1
Message type: CONNECT (0x07)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Unrestricted digital information
Transfer mode: Circuit mode
Information transfer rate: 64 kbit/s
User information layer 1 protocol: Recommendation H.221 and H.242
12) Scenario 12: After the call is set up, H.323 PhoneB sends H.245 request message TCS to H.323 PhoneA to start capability exchange procedure, so that H.323 PhoneA can know the receive and transmit capabilities of PhoneB.
13) Scenario 13: H.323 PhoneA receives the TCS message from H.323 PhoneB, and sends back TCSA message to confirm.
ITU-T Recommendation H.245
response
terminalCapabilitySetAck
sequenceNumber: 1
14) Scenario 14: H.323 PhoneA sends H.245 request message TCS to H.323 PhoneB to start capability exchange procedure, so that H.323 PhoneB can know the receive and transmit capabilities of PhoneA.
15) Scenario 15: H.323 PhoneB receives the TCS message from H.323 PhoneA, and sends back TCSA message to confirm. Now, the capability exchange procedure is over.
ITU-T Recommendation H.245
response
terminalCapabilitySetAck
sequenceNumber: 1
16) Scenario 16: H.323 PhoneB sends MSD message to H.323 PhoneA, to start master slave determination procedure.
17) Scenario 17: H.323 PhoneA receives the MSD message from H.323 PhoneB, and it compares the carried terminalType and statusDeterminationNumber with its corresponding values, to get the result that it is Slave. Then, H.323 PhoneA sends the result to H.323 PhoneB through MSDA message.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (slave)
slave: slave
18) Scenario 18: H.323 PhoneA sends MSD message to H.323 PhoneB, to start master slave determination procedure.
ITU-T Recommendation H.245
request
masterSlaveDetermination
terminalType: 50
statusDeterminationNumber: 4947
19) Scenario 19: H.323 PhoneB receives the MSD message from H.323 PhoneA, and it compares the carried terminalType and statusDeterminationNumber with its corresponding values, to get the result that it is Master. Then, H.323 PhoneB sends the result to H.323 PhoneA through MSDA message.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (master)
master: master
20) Scenario 20: H.323 PhoneA sends OLC message to H.323 PhoneB, to start OpenLogicalChannel procedure. This channel is used to transmit G.723 audio signals and RTP encapsulated real-time media information (audio). The message carries the IP address (191.169.150.171) and port number (40000) used by H.323 PhoneA to transmit RTP encapsulated real-time media information (audio signals), and the IP address (191.169.150.171) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
21) Scenario 21: H.323 PhoneB sends back OLCA message as response. The message carries the IP address (191.169.31.31) and port number (40000) used by H.323 PhoneB to transmit RTP encapsulated real-time media information (audio signals), and the IP address (191.169.31.31) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
22) Scenario 22: H.323 PhoneA sends OLC message to H.323 PhoneB, to start OpenLogicalChannel procedure. This channel is used to transmit H.263 video signals and RTP encapsulated real-time media information (video). The message carries the IP address (191.169.150.171) and port number (40002) used by H.323 PhoneA to transmit RTP encapsulated real-time media information (video signals), and the IP address (191.169.150.171) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
23) Scenario 23: H.323 PhoneB sends back OLCA message as response. The message carries the IP address (191.169.31.31) and port number (40002) used by H.323 PhoneB to transmit RTP encapsulated real-time media information (video signals), and the IP address (191.169.31.31) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 2
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 3
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40002
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.31.31 (191.169.31.31)
tsapIdentifier: 40003
flowControlToZero: False
24) Scenario 24: H.323 PhoneB sends OLC message to H.323 PhoneA, to start OpenLogicalChannel procedure. This channel is used to transmit G.723 audio signals and RTP encapsulated real-time media information (audio). The message carries the IP address (191.169.31.31) and port number (40000) used by H.323 PhoneA to transmit RTP encapsulated real-time media information (audio signals), and the IP address (191.169.31.31) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
25) Scenario 25: H.323 PhoneA sends back OLCA message as response. The message carries the IP address (191.169.150.171) and port number (40000) used by H.323 PhoneA to transmit RTP encapsulated real-time media information (audio signals), and the IP address (191.169.150.171) and port number (40001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
26) Scenario 26: H.323 PhoneB sends OLC message to H.323 PhoneA, to start OpenLogicalChannel procedure. This channel is used to transmit H.263 video signals and RTP encapsulated real-time media information (video). The message carries the IP address (191.169.31.31) and port number (40002) used by H.323 PhoneB to transmit RTP encapsulated real-time media information (video signals), and the IP address (191.169.31.31) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
27) Scenario 27: H.323 PhoneA sends back OLCA message as response. The message carries the IP address (191.169.150.171) and port number (40002) used by H.323 PhoneA to transmit RTP encapsulated real-time media information (video signals), and the IP address (191.169.150.171) and port number (40003) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission. Now, the audio and video logical channels at both ends are opened, that is the logical channel signaling procedure is over, and both parties begin converstation.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 2
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 3
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
tsapIdentifier: 40002
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.150.171 (191.169.150.171)
tsapIdentifier: 40003
flowControlToZero: False
28) Scenario 28: H.323 PhoneB hooks on, and sends Q.931 Release Complete message to the GK to close the channel.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8004
Message type: RELEASE COMPLETE (0x5a)
User-user
Information element: User-user
Length: 35
Protocol discriminator: X.208 and X.209 coded user information
33) Scenario 33: The GK sends DCF message to H.323 PhoneA, to confirm that it has received DRQ message and released corresponding bandwidth. Now, whole release procedure is over.
ITU-T Recommendation H.225.0
disengageConfirm
requestSeqNum: 1931
4.5.2 Successful H.323 User Call Procedure (Fast Start)
Figure 4-22 shows H.323 call procedure in fast start mode, in which SoftX3000 serves as the GK.
Figure 4-22 Successful H.323 user call procedure (fast start)
H.323 call procedure in fast start mode is similar to H.323 call procedure in normal start mode, but there is no H.245 negotiation procedure in fast start mode. It should be noted that the Setup message carries H.245 channel information in H.323 call procedure in fast start mode.
4.5.3 Successful H.323 Trunk Call Procedure
Different SoftX3000 equipment uses H.323 to communicate. Figure 4-23 shows a successful H.323 trunk call procedure.
The following example complies with the conventions below:
The IP address of SoftX3000A is 191.169.1.112. The IP address of SoftX3000B is 191.169.1.110. The phone number of PhoneA controlled by SoftX3000A is 55500011. The phone number of PhoneB controlled by SoftX3000B is 66500010. H.323 PhoneA is the calling party, H.323 PhoneB is the called party, and the
The H.323 trunk call connection can be implemented in fast start mode.
1) Scenario 1: SoftX3000A sends Setup message to SoftX3000B, to request call establishment. The message contains call ID, phone number of PhoneA, vendor identifier, and phone number of PhoneB, used for charging and routing. Besides, the UUIE field in the message carries the transmission layer address (IP address plus TCP port number) of destination call signaling channel (IP address is 191.169.1.110, and the port number is 1720), and the transmission layer address (IP address plus TCP port number) of source call signaling channel (IP
2) Scenerio 2: SoftX3000B sends back Call Proceeding message, indicating that the call has been processed. The VendorIdentifier in the UUIE field of the message indicates the vendor identifier of SoftX3000B. Here, the country code is 28, extension is 21, vendor identifier is 0. Besides, it is indicated that SoftX3000B is Huawei NGN SoftX3000 product, whose version is SoftX3000V3.
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (callProceeding)
callProceeding
protocolIdentifier: 0.0.8.2250.0.2
destinationInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 28
t35Extension: 21
manufacturerCode: 0
productId: Huawei NGN SoftX3000
versionId: SoftX3000V3
gatekeeper (GatekeeperInfo)
gateway (GatewayInfo)
mc: False
undefinedNode: False
callIdentifier (CallIdentifier)
guid: 908552FC-3018-E030-8449-AC14C86413C4
h245Tunneling: False
3) Scenario 3: SoftX3000B sends Alerting message to SoftX3000A, indicating that the call has arrived and asking PhoneB resident gateway to play ringing tone. After SoftX3000A receives the message, it asks PhoneA resident gateway to play ringback tone.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8157
Message type: ALERTING (0x01)
User-user
Information element: User-user
Length: 129
Protocol discriminator: X.208 and X.209 coded user information
5) Scenario 5: SoftX3000B sends Facility message to SoftX3000A. The UUIE in the message carries H.245 control channel transmission layer address (IP address plus TCP port number) of SoftX3000B, where the IP address is 191.169.1.110, and the port number is 5259. The "Reason” is “Start H.245”. Now, the call is set up.
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 8157
Message type: FACILITY (0x62)
User-user
Information element: User-user
Length: 38
Protocol discriminator: X.208 and X.209 coded user information
6) Scenario 6: After the call is set up, SoftX3000B sends H.245 request message TCS to SoftX3000A to start capability exchange procedure, so that SoftX3000A can know the receive and transmit capabilities of SoftX3000B.
7) Scenario 7: SoftX3000A receives TCS message from SoftX3000B, and sends back TCSA message to acknowledge.
ITU-T Recommendation H.245
response
terminalCapabilitySetAck
sequenceNumber: 2
8) Scenario 8: SoftX3000A sends H.245 request message TCS to SoftX3000B to start capability exchange procedure, so that SoftX3000B can know the receive and transmit capabilities of SoftX3000A.
9) Scenario 9: SoftX3000B receives TCS message from SoftX3000A, and sends back TCSA message to acknowledge. Now, the capability exchange procedure is over.
ITU-T Recommendation H.245
response
terminalCapabilitySetAck
sequenceNumber: 1
10) Scenario 10: SoftX3000A sends MSD message to SoftX3000B, to start master slave determination procedure.
ITU-T Recommendation H.245
request
masterSlaveDetermination
terminalType: 120
statusDeterminationNumber: 14134743
11) Scenario 11: SoftX3000B receives the MSD message from SoftX3000A, and it compares the carried terminalType and statusDeterminationNumber with its corresponding values, to get the result that it is Slave. Then, SoftX3000B sends the result to SoftX3000A through MSDA message.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (master)
master: slave
12) Scenario 12: SoftX3000B sends MSD message to SoftX3000A, to start master slave determination procedure.
13) Scenario 13: SoftX3000A receives the MSD message from SoftX3000B, and it compares the carried terminalType and statusDeterminationNumber with its corresponding values, to get the result that it is Master. Then, SoftX3000A sends the result to SoftX3000B through MSDA message.
ITU-T Recommendation H.245
response
masterSlaveDeterminationAck
decision (slave)
slave: master
14) Scenario 14: SoftX3000A sends OLC message to SoftX3000B, to start OpenLogicalChannel procedure. This channel is used to transmit G.711 audio signals and RTP encapsulated real-time media information (audio). The message carries the IP address (191.169.3.38) and port number (30001) used by PhoneA resident gateway to transmit quality parameter information of RTCP encapsulated real-time signal transmission.
15) Scenario 15: SoftX3000B sends back OLCA message as response. The message carries the IP address (191.169.1.135) and port number (30019) used by PhoneB resident gateway to transmit RTP encapsulated real-time media information (audio signals), and the IP address (191.169.1.135) and port number (30019) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission.
16) Scenario 16: SoftX3000B sends OLC message to SoftX3000A, to start OpenLogicalChannel procedure. This channel is used to transmit G.711 audio signals and RTP encapsulated real-time media information (audio). The message carries the IP address (191.169.1.135) and port number (30019) used by PhoneB resident gateway to transmit quality parameter information of RTCP encapsulated real-time signal transmission.
17) Scenario 17: SoftX3000A sends back OLCA message as response. The message carries the IP address (191.169.3.38) and port number (30000) used by PhoneA resident gateway to transmit RTP encapsulated real-time media information (audio signals), and the IP address (191.169.3.38) and port number (30001) used to transmit quality parameter message of RTCP encapsulated real-time signal transmission. Now, the audio logical channels at both ends are opened, that is the logical channel signaling procedure is over, and both parties begin converstation.
ITU-T Recommendation H.245
response
openLogicalChannelAck
forwardLogicalChannelNumber: 2
forwardMultiplexAckParameters
(h2250LogicalChannelAckParameters)
h2250LogicalChannelAckParameters
sessionID: 1
mediaChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
tsapIdentifier: 30000
mediaControlChannel (unicastAddress)
unicastAddress
iPAddress
network: 191.169.3.38 (191.169.3.38)
tsapIdentifier: 30001
18) Scenario 18: PhoneB hooks on. SoftX3000B sends ESD message to SoftX3000A to request converstation end.
ITU-T Recommendation H.245
command
endSessionCommand
disconnect: disconnect
19) Scenario 19: SoftX3000A sends Q.931 Release Complete message to SoftX3000B, to close the channel. Now, the call is released. Meanwhile, SoftX3000A asks PhoneA resident gateway to play busy tone.
Signaling Transport (SIGTRAN) protocol stack is defined by the SIGTRAN workgroup of the Internet Engineering Task Force (IETF) for interworking purposes between the Signaling System No. 7 (SS7) and the Internet Protocol (IP).This protocol stack supports transmission of switched circuit network (SCN) signaling across IP network. This protocol stack supports the inter-layer standard primitive interface defined in SCN signaling protocol hierarchy model so as to ensure utilization of the existing SCN signaling application without modification. It also uses the standard IP transport protocol as the transmission bottom layer, and satisfies the special transmission requirements of SCN signaling by adding its own functions.
Caution:
The SIGTRAN protocol stack only implements SCN signaling adaptation and transmission on IP network without processing user-layer signaling messages.
The SIGTRAN protocol stack is functionally composed of two classes of protocols as follows:
The first class includes universal signaling transport protocols that achieve the efficient and reliable transmission of SS7 signaling on IP network. Currently SoftX3000 uses Stream Control Transmission Protocol (SCTP) specified by the IETF.
The second class refers to SS7 adaptation protocols including SS7 MTP2-User Adaptation Layer (M2UA), SS7 MTP3-User Adaptation Layer (M3UA), ISDN Q.921-User Adaptation Layer (IUA), and V5.2-User Adaptation Layer (V5UA). The SS7 adaptation protocols are applicable to existing SCN signaling systems and protocols.
When media streams are transferred from the SCN to the packet-switching network, the MG terminates SCN media streams, puts them into data packets (if the media data is not in form of packets), and then transfers the data packets to the packet-switching network. When media steams are transmitted from the packet-switching network to the SCN, reverse processes are performed.
II. Media Gateway Controller (MGC)
MGC processes registration and management of MG resources. SoftX3000 has MGC functions.
MGC might have the following capabilities:
Authorizing resource usage according to the local strategies. Terminating and initiating SCN signaling protocols, such as SS7-ISUP and Q.931.
(ISUP is the acronym of ISDN User Part.)
III. Signaling Gateway (SG)
SG, a signaling agent, can receive or transmit internal SCN signaling at the edge of IP network. The SG in the SS7-Internet gateway can relay, translate or terminate SS7 signaling.
The SG functions might also be integrated into the MG functions.
5.1.3 Structure of Protocol Stack
Figure 5-1 illustrates the SIGTRAN protocol model.
Currently SoftX3000 does not support MTP2-User Peer-to-Peer Adaptation Layer (M2PA) or SCCP-User Adaptation Layer (SUA).
5.1.4 SIGTRAN Implementation in SoftX3000
The SIGTRAN is used in SoftX3000 connection with an SG, for transmission of narrowband circuit-switched signaling over IP network, for example, SS7 ISUP and Intelligent Network Application Part (INAP). The SIGTRAN implemented in the SoftX3000 is illustrated in Figure 5-2.
The SIGTRAN is implemented on the interface between the SG and the SoftX3000 to transmit narrowband SCN signaling over IP network. The working principle of the SIGTRAN is as follows:
SCN signaling is accessed by the SG, and media streams (such as trunk voice channel) are accessed by the trunk media gateway (TMG).The SG packs the inter-layer primitives (or narrowband signaling) and transmits them to the SoftX3000. The SoftX3000 processes the signaling and controls the bearer connection of the MG through a media gateway control protocol (H.248), thereby achieving the interworking between the circuit switched network and the packet switched network. In this model, the SIGTRAN stack is employed between the SG and the SoftX3000.
Depending on the location of the SG, SoftX3000 provides three modes to interwork with SCN signaling:
SG embedded in the SoftX3000
The SoftX3000 provides Time Division Multiplex (TDM) interface to the SCN and uses MTP, not SIGTRAN, for signaling transmission.
SG embedded in the TMG or universal media gateway (UMG)
The TMG or UMG with an embedded SG converts and adapts SCN signaling, encapsulates the signaling into IP packets, and transmits the packets to the SoftX3000 across the IP network. The signaling transmission is based on M2UA, IUA, or V5UA of the SIGTRAN.
Independent SG
The SG converts and adapts SCN signaling, encapsulates the signaling into IP packets, and transmits the packets to the SoftX3000 across the IP network. Signaling transmission is based on M3UAof the SIGTRAN.
5.2 SCTP
5.2.1 Introduction
Before the SCTP is stipulated, UDP and TCP carry SS7 signaling traffic over IP network. UDP is a connectionless transport protocol and cannot guarantee the quality of transmission required by SS7 signaling. TCP is a connection-oriented transport protocol and guarantees the reliable transmission of signaling. TCP, however, has some disadvantages such as line header block, poor real-time ability, difficult multi-homing implementation, and vulnerable to denial of service (DOS) attacks. To solve those problems, the IETF put forward a connection-oriented, packet-based, and transmission-reliable protocol—SCTP. The SCTP removes those problems existing in the TCP and thus provides a higher reliability of signaling transmission. The design of the SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. The SCTP has optimized real-time performance and supports the multi-homing function. Therefore, SCTP is chosen as the transport protocol in the SIGTRAN protocol stack.
The SCTP is a transport-layer protocol above which SCTP user applications are operating and below which a packet-based network is lying. In the SIGTRAN implementation, the upper-layer users of the SCTP are SCN signaling adaptation modules, for example, M2UA, M3UA, IUA, and V5UA. The underlying layer of the SCTP is the IP network. The position of the SCTP in the SIGTRAN protocol stack is shown in Figure 5-1.
5.2.2 Terminology
I. Transport Address
A transport address is defined by the combination of an IP address, a transport-layer protocol type, and a transport-layer port number. Because the SCTP is transmitted on
the IP, an SCTP transport address is the combination of an IP address and an SCTP port number. SCTP port number is used for the identification of the users at the same address, and it is identical to TCP port number in the concept. For example, the IP address 10.105.28.92 and SCTP port number 1024 indicate a transport address, while 10.105.28.93 and 1024 mean another transport address. Similarly 10.105.28.92 and 1023 indicate a different transport address.
II. Host and Endpoint
Host A host is configured with one or multiple IP addresses. It is a typical physical entity.
SCTP Endpoint
Endpoint is one of the basic concepts of SCTP. An endpoint is the logical sender/receiver of SCTP packets. It is a typical logical entity.
A transport address (the combination of an IP address and an SCTP port number) uniquely identifies an endpoint. An endpoint might be defined by several transport addresses. For the same destination endpoint, all transport addresses used by the SCTP endpoint must use the same port number, but can use multiple IP addresses.
Notes:
A host can have more than one endpoint.
III. Association and Stream
Association
An association is the logical relationship or said channel, established between two SCTP endpoints for data transmission, by using the four-way handshake mechanism prescribed in SCTP.
As prescribed in the SCTP, two SCTP endpoints must not have more than one SCTP association between them at any given time. Because an association depends on the transport addresses used by the endpoints in the association, an SCTP association can be uniquely identified by the combination of four parameters, namely local IP address, local SCTP port number, peer IP address, and peer SCTP port number. In SoftX3000, an association might be an M2UA link, an M3UA link, a V5UA link, or an IUA link.
The term Stream used in SCTP refers to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. Strictly speaking, stream, in an SCTP association, is a uni-directional logical channel established from one endpoint to the other associated endpoint. An association is composed of several uni-directional streams, any of which is independent of the others. Stream IDs identifies the streams. Each stream transmits data without influence from other streams.
Note:
Multiple streams might be in the same stream. The number of available streams depends on the negotiation of the endpoints when an association is established between them. A stream cannot belong to more than one association. The number of outgoing streams might be different from that of incoming streams.
The data to be delivered in sequence must be conveyed within a single stream.
IV. Path and Primary Path
Path A path is a route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths.
Primary path
A primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. If there is more than one destination address to an endpoint, the SCTP endpoint is multi-homed. The definition includes the source address since an implementation might wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed.
Both SCTP endpoints in an SCTP association can be configured with several IP addresses, and thus there are several paths between the associated endpoints. This is the multi-address feature of an SCTP association. This is also the greatest difference of SCTP from TCP.
An SCTP association might include several paths but has only one primary path. As shown in Figure 5-3, an endpoint on the MGC (for example, SoftX3000) has two transport addresses (10.11.23.14:2905 and 10.11.23.15:2905); an endpoint on the SG also has two transport addresses (10.11.23.16:2904 and 10.11.23.17:2904).
The two endpoints determine an association that includes four paths, namely Path 0, Path 1, Path 2, and Path 3. Selections of the paths depend on your data configurations. For example, you configure the four paths and set Path 0 as the primary path, as shown in Figure 5-4.
Path 0: The local transport address 1 (10.11.23.14:2905) transmits SCTP packets to the peer transport address 1 (10.11.23.16:2904).
Path 1: The local transport address 1 (10.11.23.14:2905) transmits SCTP packets to the peer transport address 2 (10.11.23.17:2904).
Path 2: The local transport address 2 (10.11.23.15:2905) transmits SCTP packets to the peer transport address 1 (10.11.23.16:2904).
Path 3: The local transport address 2 (10.11.23.15:2905) transmits SCTP packets to the peer transport address 2 (10.11.23.17:2904).
The SCTP working principles for data transmission from an endpoint are as follows:
By default, an endpoint should always transmit SCTP packets through the primary path from a local transport address A to the peer endpoint. When the primary path becomes faulty, the SCTP automatically switches over to one of the backup paths. The SCTP preferentially switches the transport addresses of the peer endpoint; furthermore, the SCTP switches the transport addresses of the local endpoint.
The SCTP defines heartbeat messages. When a path is idle, the local SCTP user requires the SCTP to generate a heartbeat message and sends the message through that path to the peer endpoint which must immediately return a heartbeat acknowledgement message. This mechanism serves to precisely measure the round-trip time (RTT) and helps to monitor the reachability of the association as well as holding the active state of the SCTP association.
Figure 5-4 Data configuration for determining path selections
1) TSN and SSN TSN
The SCTP uses a transmission sequence number (TSN) mechanism to acknowledge data transmission. An endpoint in an association assigns a 32-bit sequence number, which is based on an initial TSN, to each data chunk sent by the local end to permit the receiving SCTP endpoint to acknowledge its receipt.
TSN is maintained on the basis of association.
Note:
In the TCP, the TSN mechanism helps to achieve acknowledged transmission and sequenced-delivery of data. When it is found that TSNs are not continuous, the TCP retransmits the data that will not be delivered to an upper-layer user above the TCP layer until the TSNs are sequential. This mechanism results in the dissatisfaction of the TCP for low-delay transmission of SS7 signaling traffic.
The SCTP assigns a 16-bit stream sequence number (SSN) to each data chunk sent in a stream by the local end, to ensure sequenced transmission in the stream.
At the establishment of an association, the SSNs in all streams are numbered from 0. When an SSN reaches 65535, the subsequent SSN is numbered from 0 again.
The assignments of TSN and SSN are independent to each other.
2) CWND
SCTP is a sliding window protocol. Congestion window (CWND) is maintained on the basis of each destination address and will be adjusted according to the network condition. Once the length of the unacknowledged message sent from the destination address is greater than the CWND value, the endpoint will stop transmitting data to this address.
3) RWND
Receiver window (RWND) indicates the size of the receiver’s inbound buffer in an association. During the association establishment, both data sender and receiver will exchange their RWND value with each other. The two RWND values will vary with data transmission and acknowledgement. This is, in effect, restricting the amount of data it can transmit. If the RWND is equal to 0, the data sender can always have one packet in flight to the receiver, which allows the sender to probe for a change in buffer of the data receiver by means of the acknowledgement message.
4) TCB
Transmission control block (TCB) is an internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association.
5.2.3 SCTP Functions
As shown in Figure 5-5, the SCTP has the following functions:
Association startup and takedown Sequenced delivery within streams User data fragmentation Acknowledgement and congestion avoidance Chunk bundling Packet validation Path management
An association is initiated by a request from an SCTP user, for example, M2UA or M3UA. Compared with a TCP connection, the startup of an SCTP association is relatively complicated. The startup uses a four-way handshake and employs a cookie mechanism. Cookie is a data chunk containing the initialization information and encryption information about the endpoint, which is processed and exchanged between the communication parties during the startup of the association to enhance protocol security and provide protection against potential DoS or masquerade attacks.
SCTP provides graceful close (that is, shutdown) for an active association on request from the SCTP user. SCTP also allows ungraceful close (that is, abort) either on request from the user or as a result of an error condition detected within the SCTP layer.
SCTP does not support a half-open state wherein one side might continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting request primitives from its user.
2) Sequenced delivery within streams
SCTP can transport the datagrams in sequence. The datagrams sent in sequence must be put in one stream, and the stream is the basis for sequenced transmission.
With streams, SCTP provides two mechanisms respectively for data acknowledgement and sequenced delivery. SCTP uses the TSN mechanism to achieve acknowledged transmission of data, and uses stream number and SSN to achieve sequenced delivery of data. When the SSNs that SCTP receives are sequential, SCTP delivers the data to the SCTP user, without waiting for continuity of TSNs of the data.
When the stream is blocked, the next expected in-sequence SCTP user message can be delivered from other streams.
SCTP also provides non in-sequence delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received, without guarantee of in-sequence delivery.
3) User data fragmentation
SCTP detects the path maximum transmission unit (PMTU) on the transport path, based on which SCTP fragments and then packetizes large user data to avoid multiple fragmentations and reassemblies at the IP layer. The purpose is to reduce the data load on the IP layer.
Before transmission, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the PMTU.
On receipt, SCTP reassembles the fragments into complete messages before passing them to the SCTP user.
4) Acknowledgement and congestion avoidance
Acknowledgement and retransmission are measures taken by a protocol to guarantee transmission reliability. So does SCTP. The acknowledgement mechanism is the basis for SCTP to guarantee transmission reliability. Congestion avoidance follows the window mechanism implemented in TCP, used for appropriate flow control.
SCTP assigns, in sequence, a TSN to each user data fragment or un-fragmented message before delivering it to the lower layer.
The TSN is independent of any SSN assigned at the stream level. The TSN serves to ensure the reliability of the transmission. The SSN is used to guarantee sequenced delivery of messages within streams.
TSN and SSN functionally separate reliable transmission from sequenced delivery. The receiver acknowledges all TSNs received, even if there are gaps in the sequence.
Packet retransmission function is responsible for acknowledgement of TSNs as well as resistance to congestion.
5) Chunk bundling
If short-length user data is attached with a large SCTP message header, the transmission efficiency is very low. Therefore, SCTP bundles several pieces of user data into the same SCTP packet to improve the utilization ratio of the bandwidth.
An SCTP packet consists of a common header followed by one or more chunks. Each chunk might contain either user data or SCTP control information.
The SCTP user has the option to request bundling of more than one user messages into a single SCTP packet.
During a congestion or retransmission, an SCTP implementation might still perform bundling to improve the efficiency even though the user has requested that SCTP not bundle.
Packet validation is the basis for SCTP to provide errorless transmission. The common header of an SCTP packet includes a Verification Tag field and a 32-bit Checksum field.
The Verification Tag value is chosen by each end of the association during association startup. The receiver discards packets received without the expected Verification Tag value, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association.
The sender of each SCTP packet sets the checksum to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid checksum discards the packet.
7) Path management
The sending SCTP user can use a set of transport addresses as destinations for SCTP packets. The SCTP path management function chooses a destination transport address for each outgoing SCTP packet based on the SCTP user’s instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user.
At association startup, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets.
On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing.
5.2.4 SCTP Primitives
The upper layer protocols (ULP) requests for services by passing primitives to SCTP and receives notifications from SCTP for various events.
SCTP primitive description uses the following format:
There are 16 request primitives sent from the SCTP user to SCTP. The meanings of the request primitives are shown in Table 5-1.
Table 5-1 SCTP request primitives
Primitive Function
INITIALIZE
This primitive allows SCTP to initialize its internal data structures and allocate necessary resources for setting up its operation environment. Once SCTP is initialized, ULP can communication directly with other endpoints without re-invoking this primitive.
SCTP will return to the ULP an event number (instance) of the SCTP association to be processed locally.
ASSOCIATE
This primitive allows the upper layer to initiate an association to a specific peer endpoint. The peer endpoint shall be specified by one of the transport addresses which defines the endpoint. If the local SCTP instance has not been initialized, the ASSOCIATE is considered an error.
An association ID, which is a local handle to the SCTP association, will be returned on successful establishment of the association. If SCTP is not able to open an SCTP association with the peer endpoint, an error is returned. If an association is successful, other association parameters might be returned, including the complete destination transport addresses of the peer as well as the outbound stream count of the local endpoint. One transport address from the returned destination addresses will be selected by the local endpoint as default primary path for sending SCTP packets to this peer. The returned “destination transport address list” can be used by the SCTP user to change the default primary path or to force sending a packet to a specific transport address.
Returned result: Association ID
SHUTDOWN
This primitive is used to gracefully close an association. Any locally queued user data will be delivered to the peer. The association will be terminated only after the peer acknowledges all the SCTP packets sent.
Returned result indicates whether the association is successfully closed. A success code will be returned on successful termination of the association. If attempting to terminate the association results in a failure, an error code shall be returned.
ABORT
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.
Returned result indicates whether the association is successfully closed. A success code will be returned on successful abortion of the association. If the action of attempting to abort the association results in a failure, an error code shall be returned.
SEND This primitive allows the SCTP user to notify SCTP of sending data to a destination transport address in a specified stream ID.
Returned result indicates whether the data is successfully sent.
SET PRIMARY
This primitive allows the ULP to instruct the local SCTP to use the specified destination transport address as primary path for sending packets.
Returned result is a result code, indicating whether this operation is successfully performed. If the specified destination transport address is not present in the “destination transport address list” returned earlier in an ASSOCIATE command or COMMUNICATION UP notification, an error shall be returned.
RECEIVE
This primitive is used to read available user message in the SCTP queue into the buffer specified by the SCTP user.
The size of the message read, in bytes, will be returned. It might, depending on the specific implementation, also return other information such as the sender’s address, the stream ID on which it is received, and whether there are more messages available for retrieval. For ordered messages, their SSN might also be returned.
STATUS
This primitive is used to return a data block containing the following information:
Association connection state Destination transport address list Destination transport address reachability states Current receiver window size Current congestion window size Number of unacknowledged DATA chunks Number of received DATA chunks Primary path Most recent SRTT on primary path RTO on primary path
Returned result is the state of the information that is required to return.
CHANGE HEARTBEAT
This primitive allows the ULP to instruct the local endpoint to enable or disable heartbeat on a specified destination transport address.
Returned result indicates the performance of this operation. If the destination transport address is not idle, heartbeat will not take place.
REQUEST HERATBEAT
This primitive allows the ULP to instruct the local endpoint to perform a heartbeat on a specified destination address of a given association.
Returned result indicates whether the transmission of the HEARTBEAT chunk to the destination address is successful.
This primitive allows the ULP to instruct the local SCTP to report the current SRTT measurement on a specified destination transport address of a given association.
Returned result is an integer containing the most recent SRTT in milliseconds.
SET FRAILURE THRESHOLD
This primitive allows the local SCTP to customize the reachability failure detection threshold for a specified destination transport address.
Returned result indicates whether the operation is successful.
SET PROTOCOL PARAMETERS
This primitive allows the local SCTP to customize the protocol parameters.
Returned result indicates whether the operation is successful.
RECEIVE UNSENT MESSAGE
This primitive allows the ULP to instruct the local SCTP to store the received failure message in the ULP buffer.
Returned result is the number of bytes including the failure message.
RECEIVE UNACKNOWLEDGED MESSAGE
This primitive allows the ULP to instruct the local SCTP to store the received unacknowledged failure message in the ULP buffer.
Returned result is the number of bytes including the unacknowledged message.
DESTROY
This primitive indicates the SCTP event number (instance) to be destroyed. (The SCTP event number is generated in the INITIALIZE primitive.)
Returned result indicates whether it is successful.
II. Notification Primitives Sent from SCTP to SCTP User
There are eight notification primitives sent from SCTP to the SCTP user. The meanings of the notification primitives are shown in Table 5-2.
Table 5-2 SCTP notification primitives
Primitive Function
DATA ARRIVE
When a user message is successfully received and ready for delivery to the SCTP user, SCTP invokes this primitive to notify the upper-layer user.
The following information is passed with the notification:
Association ID: local handle to the SCTP association. Stream ID: indicates the stream on which the data is received.
If a message cannot be delivered, SCTP invokes this primitive to notify the SCTP user.
The following information is passed with the notification:
Association ID: local handle to the SCTP association. Data retrieval ID: an identification used to retrieve unsent and
unacknowledged data. Cause code: indicates the reason of the failure, for example,
too long size, and message lifetime expiration.
NETWORK STATUS CHANGE
When a destination transport address is marked inactive (for example, when SCTP detects a failure) or marked active (for example, when SCTP detects a recovery), SCTP invokes this primitive to notify the SCTP user.
The following information is passed with the notification:
Association ID: local handle to the SCTP association. Destination transport address: indicates the destination
transport address of the peer endpoint affected by the status change.
New-status: indicates the new status.
COMMUNCIATION UP
When the local SCTP becomes ready to send or receive SCTP packets or when a lost communication to an endpoint is restored, SCTP invokes this primitive to notify the SCTP user.
The following information is passed with the notification:
Association ID: local handle to the SCTP association. Status: indicates the type of the event that has occurred. Destination transport address list: the complete set of
transport addresses of the peer. Outbound stream count: the maximum number of streams
allowed to be used in this association by the SCTP user. Inbound stream count: the number of streams that the peer
endpoint has requested with this association. (This might not be the same number as “outbound stream count".)
COMMUNICATION LOST
When SCTP completely loses communication to an endpoint (through heartbeat) or detects that the endpoint has performed an abort operation, SCTP invokes this primitive to notify the SCTP user.
The following information is passed with the notification:
Association ID: local handle to the SCTP association. Status: indicates the type of the event that has occurred. The
status might indicate a failure or a normal termination event occurred in response to a SHUTDOWN or ABORT request.
Data retrieval ID: an identification used to retrieve unsent and unacknowledged data.
Last acknowledged TSN: the TSN last acknowledged by that peer endpoint.
Last sent TSN: the TSN last sent to that peer endpoint.
An SCTP packet is composed of a common header and several chunks. A chunk contains either control information or user data. Multiple chunks can be bundled into one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. These chunks must not be bundled with any other chunk in a packet. If a user message does not fit into one SCTP packet, it can be fragmented into multiple chunks.
1) Format of the common header
SCTP common header is composed of a Source Port Number, a Destination Port Number, a Verification Tag, and a Checksum.
Source Port Number: 16 bits
This is the SCTP sender’s port number. The receiver can use it in combination with the source IP address, the destination port number, and possibly the destination IP address to identify the association to which this packet belongs.
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint or application.
Verification Tag (32 bits)
When an association is established, the local endpoint generates a random identification to the association. During association startup, the endpoints exchange this Tag with each other. On data transmission, the sender must carry the Tag of the peer in the common header for verification purposes.
Checksum (32 bits)
SCTP uses the Adler-32 algorithm to calculate the user data and obtains a 32-bit checksum which will be carried in the datagram. The receiver performs the same operation and checks whether the new checksum is equal to the carried one to judge whether the user data is destroyed.
2) Format of chunk fields
Each chunk is formatted with a Chunk Type field, a Chunk Flags field, a Chunk Length field, and a Chunk Value field.
Chunk Type (8 bits)
This field identifies the type of information contained in the Chunk Value field. Table 5-3 lists the values of Chunk Types.
Table 5-3 SCTP chunk types
ID Chunk type Description
0 DATA (payload data) Transmitted user data.
1 INIT This chunk is used to initiate an SCTP association between two endpoints.
2 INIT ACK This chunk is used to acknowledge the initiation message (INIT) of an SCTP association.
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.
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.
5 HEARTBEAT ACK Response to a HEARTBEAT chunk.
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.
This chunk is used to acknowledge the receipt of the SHUTDOWN 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.
10 COOKIE ECHO
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process.
11 COOKIE ACK This chunk is used to acknowledge the receipt of a COOKIE ECHO chunk.
12 ECNE Reserved for explicit congestion notification echo
13 CWR Reserved for congestion window reduced
14 SHUTDOWN COMPLETE
This chunk is used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process.
15 to 62 Reserved by the IETF
63 IETF-defined Chunk Extensions
64 to 126 Reserved by the IETF
127 IETF-defined Chunk Extensions
128 to 190 Reserved by the IETF
191 IETF-defined Chunk Extensions
192 to 254 Reserved by the IETF
255 IETF-defined Chunk Extensions
Chunk Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type. Table 5-4 shows the meanings of the bit combinations.
Table 5-4 Meanings of the highest-order two bits of Chunk Type
Bits (highest-order two bits) Meaning
00 Stop processing this SCTP packet and discard it. Do not process any further chunks within it.
Stop processing this SCTP packet and discard it. Do not process any further chunks within it. Report to the initiating endpoint the unrecognized parameter either in an ERROR or in the INIT ACK.
10 Skip this chunk and continue processing.
11 Skip this chunk and continue processing. Report to the initiating endpoint the unrecognized parameter either in an ERROR or in the INIT ACK.
Chunk Flags (8 bits)
The usage of these bits depends on the chunk type as given by the Chunk Type. Unless otherwise specified, they are set to zero on transmit and are ignored on receipt.
Chunk Length (16 bits)
This value represents the size of the chunk including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. The length is expressed in a binary number.
Chunk Value (variable length)
The Chunk Value field contains the actual information to be transferred in the chunk. The contents depend on the Chunk Type. The length of the Chunk Value is variable.
Note:
The total length of a chunk (including Type, Length, and Value fields) must be a multiple of four bytes. If the length of the chunk is not a multiple of four bytes, the sender must pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than three bytes. The receiver must ignore the padding bytes.
3) Format of optional and variable-length parameters
Chunk values of SCTP control chunks (except DATA chunk) consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown in Figure 5-7.
Figure 5-7 Format of optional and variable-length parameters
Chunk Parameter Type (16 bits)
This field identifies the type of the parameter. It takes a value from 0 to 65534. The value of 65535 is reserved for IETF-defined extensions.
Chunk Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. Table 5-5 shows the meanings of the bit combinations.
Table 5-5 Meanings of the highest-order two bits of Chunk Parameter Type
Bits (highest-order two bits) Meaning
00 Stop processing this SCTP packet and discard it. Do not process any further chunks within it.
01
Stop processing this SCTP packet and discard it. Do not process any further chunks within it. Report the unrecognized parameter either in an ERROR or in the INIT ACK.
10 Skip this chunk and continue processing.
11 Skip this chunk and continue processing. Report to the initiating endpoint the unrecognized parameter either in an ERROR or in the INIT ACK.
Chunk Parameter Length (16 bits)
This field contains the size of the parameter, in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Therefore, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes.
Chunk Parameter Value (variable-length)
This field contains the actual information to be transferred in the parameter.
The total length of a parameter (including Type, Length, and Value fields) must be a multiple of four bytes. If the length of the parameter is not a multiple of four bytes, the sender pads the parameter at the end with all zero bytes. The length of the padding is not included in the parameter length field. A sender should not pad with more than three bytes. The receiver must ignore the padding bytes.
The Reserved bits are set to all zeros and ignored by the receiver.
U bit (1 bit)
The unordered bit, if set to “1”, indicates that this is an unordered DATA chunk, and there is no stream sequence number assigned to this DATA chunk. Therefore, the receiver must ignore the SSN field.
After re-assembly (if necessary), unordered DATA chunks are dispatched to the SCTP user by the receiver without any attempt to re-order.
If an unordered user message is fragmented, each fragment of the message must have its U bit set to “1”.
B bit
The beginning fragment bit, if set, indicates the first fragment of a user message.
E bit
The ending fragment bit, if set, indicates the last fragment of a user message.
An unfragmented user message shall have both the B and E bits set to “1”.
Setting both B and E bits to “0” indicates a middle fragment of a multi-fragment user message. When a user message is fragmented into multiple chunks, the receiver uses the TSNs to reassemble the message. This means that the TSNs for each fragment of a fragmented user message must be strictly sequential. Table 5-6 shows the meanings of the B and E bits.
Table 5-6 Meanings of the B and E bits
B 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. A DATA chunk with no user data field will have Length set to 16 (indicating 16 bytes).
TSN (32 bits)
This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (232 - 1). TSN wraps back to 0 after reaching 4294967295.
Stream ID
This field identifies the stream to which the following user data belongs.
SSN (16 bits)
This value represents the stream sequence number of the following user data within the stream. The valid range of this field is 0 to 65535. When a user message is fragmented by SCTP for transport, the same sequence number must be carried in each of the fragments of the message.
This value represents an application (or upper layer) specified protocol identifier. The upper layer (SCTP user) passes this value to SCTP and sends it to the peer. SCTP does not use this identifier. Certain network entities and the peer application use this identifier to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks to make sure it is available for agents in the middle of the network.
The value 0 indicates no application identifier is specified by the upper layer for this payload data.
User Data (variable length)
This is the payload user data. This field must be padded to be a multiple of four bytes. A sender should not pad with more than three bytes. The receiver must ignore the padding bytes.
2) Initiation (INIT)
This chunk is used to initiate an SCTP association between two endpoints. Figure 5-9 shows the format of the INIT chunk.
The Chunk Flags field in INIT is reserved and all bits in it should be set to “0”. The sequence of parameters within an INIT can be processed in any order.
Initiate Tag (32 bits)
The receiver of the INIT records the value of the Initiate Tag parameter. This value must be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association.
The Initiate Tag is allowed to take any value except 0. If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver must treat it as an error and close the association by transmitting an ABORT.
This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association this buffer space should not be lessened (that is, dedicated buffers taken away from this association); however, an endpoint might change the value of a_rwnd it sends in SACK chunks.
Number of Outbound Streams (OS)
This field defines the number of outbound streams the sender of this INIT chunk wishes to create in this association. The value of 0 must not be used. A receiver of an INIT with the OS value set to 0 will abort the association.
Number of Inbound Streams (MIS)
This defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association. The value of 0 must not be used. A receiver of an INIT with the MIS value of 0 will abort the association.
Initial TSN
This field defines the initial TSN that the sender will use. This field might be set to the value of the Initiate Tag field.
IPv4 Address
This field contains an IPv4 address of the sending endpoint. It is binary encoded. An INIT chunk might contain several IPv4 or IPv6 addresses or a combination of addresses.
IPv6 Address
This field contains an IPv6 address of the sending endpoint. It is binary encoded. An INIT chunk might contain several IPv4 or IPv6 addresses or a combination of addresses. A sender must not use an IPv4-mapped IPv6 address; instead, the sender can use an IPv4 Address Parameter for an IPv4 address.
Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address that the sender of the INIT will support for the association being initiated. That is, during the
lifetime of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT. When the INIT sender is multi-homed, more than one IP Address parameter can be included in an INIT chunk. Moreover, a multi-homed endpoint might have access to different types of network, and thus more than one address type can be present in one INIT chunk. That is, IPv4 and IPv6 addresses are allowed in the same INIT chunk.
If the INIT contains at least one IP Address parameter, the source address of the IP datagram containing the INIT chunk and any additional address provided within the INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address parameters, the endpoint receiving the INIT must use the source address associated with the received IP datagram as its sole destination address for the association.
Cookie Preservative
The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for a longer life-span of the State Cookie. This parameter should be added to the INIT chunk by the sender when it re-attempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver might choose to ignore the suggested cookie life-span increase for its own security reasons.
The Cookie Preservative parameter contains a 32-bit Suggested Cookie Life-span Increment parameter that indicates to the receiver how much increment in milliseconds the sender wishes the receiver to add to its default cookie life-span.
Host Name Address
The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a network address translation (NAT) box.
Host Name
This variable-length field contains a host name defined according to “host name syntax” in RFC1123. The method for resolving the host name is out of scope of SCTP.
At least one null terminator is included in the Host Name string and must be included in the length.
Supported Address Types
The sender of INIT uses this parameter to list all the address types it can support.
Address Type
This parameter is filled with the type value of the corresponding address (for example, IPv4 = 5, IPv6 = 6, Hostname = 11).
The INIT ACK chunk is used to acknowledge the initiation of an SCTP association.
Figure 5-10 shows the format of the INIT ACK chunk. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: State Cookie and Unrecognized Parameter.
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value must be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT ACK transmits within this association.
The Initiate Tag is allowed to take any value except 0. If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver must treat it as an error and close the association by transmitting an ABORT.
Advertised Receiver Window Credit (32 bits)
This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association this buffer space should not be lessened.
Number of Outbound Streams (OS, 16 bits)
This field defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 must not be used. A receiver of an INIT ACK with the OS value set to 0 will destroy the association discarding its TCB.
Number of Inbound Streams (MIS, 16 bits)
This defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value of 0 must not be used. A
receiver of an INIT ACK with the MIS value set to 0 will destroy the association discarding its TCB.
Initial TSN (32 bits)
This field defines the initial TSN that the INIT ACK sender will use. This field might be set to the value of the Initiate Tag field.
IPv4 Address and IPv6 Address
Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address that the sender of the INIT ACK will support for the association being initiated. That is, during the lifetime of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT ACK, and can be used as a destination address of an IP datagram sent from the receiver of the INIT ACK. When the INIT ACK sender is multi-homed, more than one IP Address parameter can be included in an INIT chunk. Moreover, a multi-homed endpoint might have access to different types of network, and thus more than one address type can be present in one INIT chunk. That is, IPv4 and IPv6 addresses are allowed in the same INIT chunk.
If the INIT ACK contains at least one IP Address parameter, the source address of the IP datagram containing the INIT ACK chunk and any additional address provided within the INIT ACK can be used as destinations by the endpoint receiving the INIT ACK. If the INIT ACK does not contain any IP Address parameters, the endpoint receiving the INIT ACK must use the source address associated with the received IP datagram as its sole destination address for the association.
State Cookie (variable length)
The parameter length depends on the size of cookie. The parameter value must contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code.
Unrecognized Parameters (variable length)
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter which has a value that indicates that it should be reported to the sender. This parameter value field contains unrecognized parameters copied form the INIT chunk complete with Parameter Type, Length, and Value fields.
4) Selective Acknowledgement (SACK)
This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their TSNs. “Gaps” refer to the cases in which the TSNs of the received DATA chunks are not sequential.
This parameter is set to all zeros on transmit and ignored on receipt.
Cumulative TSN Ack
This parameter contains the TSN of the last DATA chunk received in sequence before a gap. The subsequent TSN is not received by the endpoint sending the SACK chunk. This parameter acknowledges the receipt of all TSNs that are less than or equal to this value.
Advertised Receiver Window Credit (a_rwnd)
This field indicates the updated receive buffer space, in bytes, of the sender of this SACK.
Number of Gap Ack Blocks = N
This field indicates the number of Gap Ack Blocks included in this SACK. Each Gap Ack Block acknowledges the sequence of TSNs received after an insequential TSN. All TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
This field contains the number of duplicate TSNs the endpoint has received. Each duplicate TSN is listed following the Gap Ack Block list.
Gap Ack Blocks
These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to the sum of Cumulative TSN Ack plus Gap Ack Block Start and less than or equal to the sum of Cumulative TSN Ack plus Gap Ack Block End of each Gap Ack Block are assumed to have been received correctly.
Gap Ack Block Start
This field indicates the Start offset TSN for this Gap Ack Block. To calculate the actual TSN number, the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the first TSN, in this Gap Ack Block, that has been received.
Gap Ack Block End
This field indicates the End offset TSN for this Gap Ack Block. To calculate the actual TSN number, the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block.
Duplicate TSN
This field indicates the number of times a TSN was received in duplicate since the last SACK was sent. Every time a receiver gets a duplicate TSN (before sending the SACK), it adds this TSN to the list of duplicates. The duplicate count is re-initialized to zero after sending each SACK.
5) Heartbeat Request (HEARTBEAT)
An SCTP endpoint sends this chunk to its peer endpoint to probe the reachability of a particular destination transport address defined in the present association.
Figure 5-12 shows the format of the HEARTBEAT chunk.
This field is set to the size of the chunk, in bytes, including the chunk header and the Heartbeat Information field.
Heartbeat Information TLV
The heartbeat parameter field contains Heartbeat Information (Heartbeat Information TLV). The Heartbeat Information has a variable-length and untransparent data structure. It is acceptable that only the sender understands the information. Figure 5-13 shows the format of the Heartbeat Information.
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.
6) Heartbeat Acknowledgement (HEARTBEAT ACK)
An SCTP endpoint sends this chunk to its peer endpoint as a response to a HEARTBEAT chunk. A HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the HEARTBEAT chunk to which this ACK is responding.
Figure 5-14 shows the format of the HEARTBEAT ACK chunk.
This field is set to the size of the chunk, in bytes, including the chunk header and the Heartbeat Information field.
Heartbeat Information TLV
This variable-length field contains the Heartbeat Information parameter of the Heartbeat Request to which this Heartbeat Acknowledgement is responding. This parameter field has a variable-length and untransparent data structure.
7) Abort Association (ABORT)
An SCTP endpoint sends an Abort chunk to the peer of an association to close the association. The ABORT chunk might contain Cause Parameters to inform the receiver the reason of the abort. DATA chunks must not be bundled with ABORT. Control chunks (except for INIT, INIT ACK, and SHUTDOWN COMPLETE) might be bundled with an ABORT, but they must be placed before the ABORT in the SCTP packet; otherwise, they will be ignored by the receiver.
If an endpoint receives an ABORT with a format error or for an association that does not exist, it must silently discard it. Moreover, under any circumstances, an endpoint that receives an ABORT must not respond to that ABORT by sending an ABORT of its own.
The high-order seven bits are reserved. They are set to zero on transmit and ignored on receipt. The T bit is set to 0 if the sender had a TCB that it destroyed. The T bit is set to 1 if the sender did not have a TCB.
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.
Zero or more Error Causes
This field contains the information contents of the ABORT chunk.
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.
This field is set to zero on transmit and ignored on receipt.
Length
This field indicates the length of the SHUTDOWN chunk. It is set to 8.
Cumulative TSN Ack
This field contains the TSN of the last chunk received in sequence before any gaps. Because the SHUTDOWN message does not contain Gap Ack Blocks, it cannot be used to acknowledge TSNs received out of order.
9) Shutdown Acknowledgement (SHUTDOWN ACK)
At the completion of a shutdown process, this chunk must be used to acknowledge the receipt of the SHUTDOWN chunk. Figure 5-17 shows the format of the SHUTDOWN ACK chunk.
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
This field is set to zero on transmit and ignored on receipt.
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.
Table 5-7 Correspondence between cause-specific information and cause code
Cause code value
Cause code and meaning 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.
1
Invalid Stream Identifier:
This error cause indicates that an endpoint received a DATA chunk sent to a nonexistent stream.
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.
2
Missing Mandatory Parameter:
This error cause indicates that one or more mandatory parameters are missing in a received INIT or INIT ACK. 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.
3
Stale Cookie Error:
This error cause indicates the receipt of a valid State Cookie that has expired.
Cause Length = 8
4
Out of Resource:
This error cause indicates that the sender is out of resource. This is usually sent in combination with or within an ABORT.
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.
5
Unresolvable Address:
This error cause indicates that the sender is not able to resolve the specified address parameter (for example, type of address is not supported by the sender). This is usually sent in combination with or within an ABORT.
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. 6
Unrecognized Chunk Type:
This error cause is returned to the originator of the chunk if the receiver does not understand the chunk and the upper bits of the “Chunk Type” are set to 1.
The Cause Length field has a variable length.
7
Invalid Mandatory Parameter:
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.
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.
8
Unrecognized Parameters:
This error cause is returned to the originator of the INIT ACK chunk if the receiver does not recognize one or more optional parameters in the INIT ACK chunk. The Cause Length field has a variable
length.
The TSN Value field contains the TSN of the DATA chunk received with no user data field.
9
No User Data:
This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data.
Cause Length = 8
10
Cookie Received While Shutting Down:
This error cause is usually returned when a COOKIE ECHO is received while the endpoint is in SHUTDOWN-ACK-SENT state.
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.
This field is set to all zeros on transmit and ignored on receipt.
Length (16 bits)
This field is set to the size of the chunk, in bytes, including the four bytes of the chunk header and the size of the Cookie.
COOKIE (variable length)
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK. An implementation should make the cookie as small as possible to ensure interoperability.
12) Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk must precede any DATA or SACK chunk sent within the association, and can be bundled with one or more DATA chunks or SACK chunk in the same SCTP packet.
Figure 5-21 shows the format of the COOKIE ACK chunk.
The highest-order seven bits of the field are reserved. The reserved bits are set to zero on transmit and ignored on receipt.
T bit (1 bit)
The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB, it should set this bit to 1.
III. SCTP endpoint maintenance parameters and recommended values
1) Parameters necessary for each SCTP instance
Table 5-8 lists the parameters necessary for each SCTP instance.
Table 5-8 Parameters necessary for each SCTP instance
Parameter Meaning
Associations A list of current associations and mappings to the data consumers for each association.
Secret key
A secret key is used by the endpoint to compute the message authentication code (MAC). This should be a cryptographic quality random number with a sufficient length. The RFC1750 provides helpful information on selection of the key.
Address list The list of IP addresses that this instance has bound. This piece of information is passed to the peer in INIT and INIT ACK chunks.
SCTP port The local SCTP port number that the endpoint is bound to.
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.
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.
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.
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, that is, DOWN, UP, ALLOW-HEARTBEAT, or NO-HEARTBEAT.
PMTU The current known path MTU.
Per destination timer A timer used by each destination.
Last-time used The time when a packet is last sent to this destination. This can be used to determine whether a HEARTBEAT is needed.
4) General parameters necessary Out queue: A queue of outbound DATA chunks. In queue: A queue of inbound DATA chunks.
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 theses messages are not bundled or segmented.) Figure 5-23 illustrates the signaling procedure.
Endpoint A Endpoint B
(1) INIT
(2) INIT ACK
(3) COOKIE ECHO
(4) COOKIE ACK
(5) DATA
(6) SACK
(7) DATA
(8) DATA
(9) SACK
Figure 5-23 Message interaction during association establishment
1) Endpoint A creates a transmission control block (TCB) to describe the association to be initiated, including the basic information of the association. Endpoint A sends an INIT chunk to Endpoint B. The INIT chunk contains the following parameters:
Initiate Tag: It is used by the peer end for verification use. It can be set to Tag_A, for example. Tag_A is a random number in the range of 1 to 4294967295.
OS: It represents the maximum number of outband streams expected by the local endpoint.
MIS: It represents the maximum number of inbound streams allowed by the local endpoint.
Note:
For endpoint A and endpoint B, each performs the related checks on the stream information received from the peer endpoint. If the maximum number of inbound streams of the peer endpoint is smaller than the maximum number of outbound streams of the local endpoint, it indicates that the peer endpoint cannot support the number of outbound streams expected by the local endpoint. In this case, the local endpoint can either use the maximum number of inbound streams of the peer endpoint as the number of outbound streams of the local endpoint or abort the association and notify the SCTP user of resource shortage at the peer endpoint.
After sending the INIT, endpoint A starts the INIT timer and enters the COOKIE-WAIT state.
Note:
The INIT timer is used to wait for an INIT ACK chunk returned by the peer endpoint. If no INIT ACK chunk is received when the timer expires, the local endpoint retransmits an INIT chunk until the maximum number of retransmission reaches.
2) Upon receipt of the INIT message, endpoint B immediately responds with an INIT ACK chunk. The INIT ACK chunk must contain the following parameters:
Destination IP Address: It is set to the source IP address of the INIT chunk. Initiate Tag: It is set to Tag_B. State Cookie: A temporary TCB is created according to the basic information of
the association. After the TCB is created, the necessary information (including timestamp and lifespan of a cookie) contained in it and a local secret key are computed to generate a 32-bit abstract MAC according to the algorithm described in the RFC2401. This computation is not reversible. The necessary information and the MAC constitute the State Cookie parameter.
Local transport address Maximum number of inbound streams
Maximum number of outbound streams 3) Upon receipt of the INIT ACK, endpoint A stops the INIT timer to quit the
COOKIE-WAIT state, and sends a COOKIE ECHO chunk which echoes the State Cookie parameter contained in the INIT ACK chunk. Subsequently, endpoint A starts the COOKIE timer and enters the COOKIE-ECHOED state.
Caution:
The COOKIE ECHO chunk can be bundled with one or more DATA chunks in the same SCTP packet, but the COOKIE ECHO must be the first chunk in the packet. The sending endpoint cannot send other packets to the peer endpoint unless the returned COOKIE ACK chunk is received.
4) Upon receipt of the COOKIE ECHO chunk, endpoint B performs the following authentication on the cookie:a) Compute a MAC using the TCB data carried in the State Cookie and the local secret key according to the MAC algorithm presented in the RFC2401. b) Compare the computed MAC with the one carried in the State Cookie.c) If the MACs are not the same, the message is discarded. If the same, compare the timestamp in the TCB with the current time to check whether the time expires the lifespan carried in the cookie.d) If so, the message is discarded. Otherwise, create an association to endpoint A according to the information carried in the TCB. Endpoint B enters the ESTABLISHED state and sends a COOKIE ACK chunk. Endpoint B sends a SCOMMUNCIATION UP notification to the SCTP user.
Caution:
The COOKIE ACK chunk can be bundled with one or more DATA or SACK chunks in the same SCTP packet, but the COOKIE ACK must be the first chunk in the packet.
Upon receipt of the COOKIE ACK chunk, endpoint A moves from the COOKIE-ECHOED state to the ESTABLISHED state and stops the COOKIE timer. Endpoint A notifies the SCTP user of the successful establishment of the association with a COMMUNICATION UP notification.
An endpoint should terminate its association when it exits service. An association can be terminated by either abort (ungraceful close) or shutdown (graceful close).
Abort (ungraceful close) of an association can be performed at any incompletion time. Both ends of the association discard data without delivering it to the peer. This method does not take data security into consideration. The association abort procedure is simple. The initiating endpoint sends an ABORT chunk to its peer endpoint. The SCTP packet sent must contain the Verification Tag of the peer, and the ABORT chunk must not be bundled with any DATA chunk. Upon receipt of the ABORT chunk, the receiving endpoint performs checks on the tag. If the Verification Tag is the same as the local one, the receiving endpoint removes the association from its record and notifies the SCTP user of the termination of the association.
When either endpoint performs a shutdown procedure, both ends of the association stop receiving new data from the respective SCTP users. When sending or receiving a SHUTDOWN chunk, the endpoint delivers the data in the packet to its SCTP user. With a shutdown of an association, it can be ensured that all data that is not sent or is sent but not acknowledged will be sent or acknowledged before the termination of the association.
Endpoint A Endpoint B
(1) SHUTDOWN
(2) SHUTDOWN ACK
(3) SHUTDOWN COMPLETE
Figure 5-24 Message interaction during association shutdown
The shutdown procedure of an association is demonstrated as follows:
1) The SCTP user of endpoint A that initiates the shutdown procedure sends the cause of the requested shutdown to the SCTP. The SCTP association moves from the ESTABLISHED state to the SHUTDOWN-PENDING state. In this state, the SCTP does not accept any data sending request from the SCTP user on this association. Meanwhile, the SCTP waits for endpoint B’s acknowledgement to all sent but not acknowledged data of endpoint A. After all sent but not acknowledged data of endpoint A is acknowledged, endpoint A sends a SHUTDOWN chunk to endpoint B. Endpoint A starts the T2-shutdown timer and enters the SHUTDOWN-SENT state. The purpose of starting the T2-shutdown timer is to wait for a SHUTDOWN-ACK chunk returned by endpoint B. If the timer expires, endpoint A must retransmit the SHUTDOWN chunk.
2) Upon receipt of the SHUTDOWN message, endpoint B enters the SHOUTDOWN-RECEIVED state and no longer accepts new data sent from the SCTP user. In addition, endpoint B checks the Cumulative TSN Ack field of the chunk and verifies that all pending DATA chunks have been received by the SHUTDOWN sender. After endpoint B’s data that is not sent or is sent but not acknowledged is sent or acknowledged, endpoint B sends a SHUTDOWN ACK chunk, starts the local T2-SHUTDOWN timer, and enters the SHUTDOWN-ACK-SENT state. If the timer expires, endpoint B retransmits the SHUTDOWN ACK chunk.
3) Upon receipt of the SHUTDOWN ACK message, endpoint A stops the T2-shutdown timer, sends a SHUTDOWN COMPLETE chunk to endpoint B, and removes all records about the association. Upon receipt of the SHUTDOWN COMPLETE chunk, endpoint B checks whether it is in the SHUTDOWN-ACK-SENT state. If it is not in this state, the chunk is discarded. If the endpoint is in the SHUTDOWN-ACK-SENT state, endpoint B stops the T2-shutdown timer, removes all records about the association, and enters the CLOSED state.
5.3 M2UA
5.3.1 Introduction
SS7 MTP2-User Adaptation Layer Protocol (M2UA) is a protocol for the transport of SS7 MTP2 User signaling messages (MTP3 messages) over IP using the Stream Control Transmission Protocol (SCTP) or any other suitable transport protocol. This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). See Figure 5-25.
SEP MGC
ISUP
MTP3
MTP2
MTP1
ISUP
MTP3
M2UA
SCTP
IP
M2UA
SCTP
IP
MTP2
MTP1
SS7 SIGTRANSG
PSTN IP
Figure 5-25 Location of M2UA in the system
As illustrated above, narrowband signaling of signaling end point (SEP) uses SG to access MGC. In the SIGTRAN protocol stack, M2UA runs on top of SCTP and is the
SCTP user. The upper layer user of M2UA at the MGC side is MTP3, and is MTP2 at the SG side.
5.3.2 Terminology:
I. Application Server (AS)
AS is a logical entity, standing for a certain amount of resources and corresponding to a particular “routing context”. For M2UA, AS is a group of Interface IDs. Each AS contains a set of application server processes (ASPs), of which one or more are normally actively processing traffic.
II. Application Server Process (ASP)
ASP is a process instance of an AS. Each ASP contains an SCTP endpoint and can serve a number of ASs. In the M2UA application, ASPs work in the active/standby mode, and only the active ASP processes traffic.
III. Signaling Gateway Process (SGP)
SGP is a process instance that uses M2UA to communicate to and from a signaling link terminal (SLT).SGP serves as an active, backup, or load-sharing process of a signaling gateway.
IV. Backhaul
Backhaul refers to the transport of signaling from the point of interface for the associated data stream (that is, SG function in the MG) back to the point of call processing (that is, the MGC), if this is not local.
V. Interface ID
Interface ID is used in the communication between the two ends of M2UA. It can be text or integer. Each interface ID corresponds to one actual physical link. The interface ID is a logical ID of the MTP link used between SG and ASP.
VI. Link Key
Link key is a locally unique (between ASP and SG) value that identifies a registration request for a particular signaling data link and signaling terminal pair. Link key is used in a dynamic registration.
M2UA link is a logical connection established between SG and ASP of MGC (SoftX3000).A M2UA link consists of SG, ASP, and SCTP association between SG and ASP. Its state corresponds to ASP state and SCTP association state.
Figure 5-26 shows the network architecture of M2UA. After the concept of M2UA LINK is introduced, this architecture can be simplified as in Figure 5-27.
MG/SG0
MTP2 link 0MTP2link 1MTP2 link 2MTP2 link 3
ASP0
ASP1
ASP2
ASP3
SCTP assoc 0
SCTP assoc 1
SCTP assoc 2
SCTP assoc 3
AS0
AS1
AS0 includes MTP2 link0 and link 1
AS1 includes MTP2 link2 and link 3
MGC
Figure 5-26 Network architecture of M2UA
MG/SG0
MTP2 link 0MTP2 link 1MTP2 link 2
MTP2 link 3
M2UA LINK 0(servered for MTP2 link 0and link1)AS0
AS1M2UA LINK 1(servered for MTP2 link 2and link3)
MGC
Figure 5-27 Simplified network architecture of M2UA
M2UA link provides channels for one or more MTP2s to communicate with its user, MTP3.Each MTP link will be mapped to a particular M2UA link by the M2UA interface ID, where the correspondence should be configured by executing the related commands.Thus the data coming from an MTP link can be carried over the M2UA link transparently.
SG embedded in TMG terminates MTP2 layer messages. SoftX3000 terminates MTP3 and upper layer messages. In other words, SG transports MTP3 messages over the IP network to SoftX3000 for processing.
M2UA messages are encapsulated in the user data field of an SCTP message, including a common message header and an M2UA message header.
5.3.5 Protocol Messages
I. Message Structure
As shown in Figure 5-30, M2UA message structure is composed of a common message header, an M2UA message header, and several variable-length M2UA messages.
8 State Confirm It is sent by the SGP in response to a State Request from the MGC.
9 State Indication It is sent from an SGP to an ASP to indicate a condition on a link.
10 Retrieval Request
It is sent by the MGC during the MTP Level 3 changeover procedure to request the BSN, to retrieve PDUs from the transmit and retransmit queues or to flush PDUs from the retransmit queue.
11 Retrieval Confirm It is sent by the SG to the related queue.
12 Retrieval Indication It is sent by the SG with a PDU from the transmit or retransmit queue.
13 Retrieval Complete Indication
It is exactly the same as the Retrieval Request message except that it also contains the last PDU from the transmit or retransmit queue.
14 Congestion Indication It is sent from an SGP to an ASP to indicate the congestion status and discard status of a link.
15 Data Acknowledge It is used to acknowledge the Data message.
16–127 Reserved by the IETF /
128–255 Reserved for IETF-Defined extensions /
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.
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.
3 Heartbeat (BEAT) It is optionally used to ensure that the M2UA peers are still available to each other.
4 ASP Up Ack (UP ACK) Used to acknowledge an ASP Up message received from a remote M2UA peer.
5 ASP Down Ack (DOWN ACK)It is used to acknowledge an ASP Down message received from a remote M2UA peer.
6 Heartbeat Ack (BEAT ACK)
It is sent in response to a Heartbeat message. An M2UA peer must send a Heartbeat Ack in response to a Heartbeat message. It includes all the parameters of the received Heartbeat message, without any change.
7–127 Reserved by the IETF /
128–255 Reserved for IETF-Defined extensions /
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.
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.
3 ASP Active Ack (ACTIVE ACK)
It is used to acknowledge an ASP Active message received from a remote M2UA peer.
4 ASP Inactive Ack (INACTIVE ACK)
It is used to acknowledge an ASP Inactive message received from a remote M2UA peer.
It is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
1 Notify (NTFY) It is used to provide an autonomous indication of M2UA events to an M2UA peer.
It is sent by an ASP to indicate to a remote M2UA peer that it wishes to register one or more given Link Keys with the remote peer. Typically, an ASP would send this message to an SGP, and expect to receive a REG RSP in return with an associated Interface Identifier value.
2 Registration Response (REG RSP)
It is used as a response to the REG REQ message from a remote M2UA peer. The REG RSP contains indications of success/failure for registration requests and returns a unique Interface Identifier value for successful registration requests.
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. Typically, an ASP would send this message to an SGP, and expect to receive a DEREG RSP in return reflecting the Interface Identifier and containing a de-registration status.
4 Deregistration Response (DEREG RSP)
It is used as a response to the DEREG REQ message from a remote M2UA peer.
The Message Length field defines the length of the message in octets, including the header. The Message Length must include parameter padding bytes, if any. The Message Length must not be longer than an MTP3 message plus the length of the common and M2UA message headers.
III. Format for M2UA Message Header
The M2UA message header includes the Tag, Length, and Interface Identifier fields.
Tag
The 16-bit Tag field indicates the type of the interface identifier. Table 5-17 shows the correspondence between the tag values of the M2UA message header and the types of the interface identifier.
Table 5-17 Correspondence between tag values and interface identifier types
Tag value Interface identifier type
1 (0x01) Integer
3 (0x03) Text
Length
The Parameter Length values of the M2UA message header vary with different types of interface identifiers.
The Length value is 8 if the type of the interface identifier is integer.
The Length value is variable if the type of the interface identifier is text. The maximum length does not exceed 255 octets. The Length is equal to the length of the interface identifier plus four bytes (the tag and length fields).
Interface Identifier
The Interface Identifier identifies the physical interface at the SG for which the signaling messages are sent/received. The format of the interface identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are coordinated between the SG and the ASP.
The integer formatted interface identifier must be supported. The text formatted interface identifier may optionally be supported.
IV. Format for Variable-Length M2UA Message
The common and M2UA message headers are followed by variable-length M2UA messages. An M2UA message includes the Parameter Tag, Parameter Length, and Parameter Value fields. Different M2UA messages determine different parameter tags, parameter lengths, and parameter values.
Parameter Tag
The Parameter Tag field is a 16-bit identifier of the type of parameter.
The common parameters used by the adaptation layers are in the range of 0x00 to 0xff.The M2UA specific parameters have tags in the range 0x300 to 0x3ff.Table 5-18 shows the correspondence between values and parameters.
Table 5-18 Correspondence between M2UA message tag values and parameters
789 (0x030B) Signaling Data Terminal (SDT) Identifier
780 (0x030C) Signaling Data Link (SDL) Identifier
781 (0x030D) Registration Result
783 (0x030E) Registration Status
783 (0x030F) De-Registration Result
784 (0x0310) De-Registration Status
Parameter Length
The Parameter Length field must be a multiple of four bytes. If it is not a multiple of four bytes, the sender pads with all zero bytes after the Parameter Value field. The Parameter Length must not be padded with all zero bytes. A sender must not pad with more than three bytes. The receiver must ignore the padding bytes.
Parameter Value
The Parameter Value field contains the actual M2UA message contents that are sent or received.
As shown in Figure 5-31, the Data message contains the following parameters:
Protocol Data (mandatory): The Protocol Data field contains the MTP2-User application message in network byte order starting with the Signaling Information Octet (SIO).
Correlation ID (optional): The Correlation ID parameter permits the new active ASP to synchronize its processing of the traffic in each ordered stream with other ASPs in the broadcast group. The Correlation ID parameter is assigned by the sending M2UA, and uniquely identifies the MSU carried in the Protocol Data within an AS.
Parameter tag=0x300 Parameter length
Protocol data(32)
Parameter tag=0x13 Parameter length=8
Correlation ID
0 15 31
Figure 5-31 Structure of Data message
2) Data Acknowledge
As shown in Figure 5-32, the Data Acknowledge message contains the Correlation ID message.
Parameter tag=0x301 Parameter length=8
Correlation ID
0 15 31
Figure 5-32 Structure of Data Acknowledge message
3) State Request
As shown in Figure 5-33, the State Request message contains the State parameter.
Table 5-19 shows the valid values for the State parameter.
Table 5-19 Valid values for State parameter
Value Definition Meaning
0x0 STATUS_LPO_SET Request local processor outage
0x1 STATUS_LPO_CLEAR Request local processor outage recovered
0x2 STATUS_EMER_SET Request emergency alignment
0x3 STATUS_EMER_CLEAR Request normal alignment
0x4 STATUS_FLUSH_BUFFERS Flush or clear receive, transmit and retransmit queues
0x5 STATUS_CONTINUE Continue or resume
0x6 STATUS_CLEAR_RTB Clear the retransmit queue
0x7 STATUS_AUDIT Audit state of link
0x8 STATUS_CONG_CLEAR Congestion cleared
0x9 STATUS_CONG_ACCEPT Congestion accept
0x0a STATUS_CONG_DISCARD Congestion discard
4) State Confirm
As shown in Figure 5-34, the State Confirm message contains the State parameter. The content of the State parameter in the State Confirm message is the same as that in the State Request message.
Parameter tag=0x302 Parameter length=8
State
0 15 31
Figure 5-34 Structure of State Confirm message
5) State Event
As shown in Figure 5-35, the State Event message contains the Event parameter.
As shown in Figure 5-37, the Retrieval Request message contains the mandatory Action parameter and optional Sequence Number parameter.
Parameter tag=0x306 Parameter length=8
Action
0 15 31
Parameter tag=0x307 Parameter length=8
Sequence number
Figure 5-37 Structure of Retrieval Request message
Action
Table 5-22 shows the valid values for the Action parameter.
Table 5-22 Valid values for Action parameter
Value Definition Meaning
0x1 ACTION_RTRV_BSN Retrieve the backward sequence number (BSN)
0x2 ACTION_RTRV_MSGS Retrieve the PDUs from the transmit and retransmit queues
Sequence Number
In the Retrieval Request message, the Sequence Number field is not present if the Action field is 0x01 (ACTION_RTRV_BSN).The Sequence Number field contains the forward sequence number (FSN) of the far end if the Action is 0x2.
8) Retrieval Confirm
As shown in Figure 5-38, the Retrieval Confirm message contains the mandatory Action parameter, mandatory Result parameter, and optional Sequence Number parameter.
Figure 5-38 Structure of Retrieval Confirm message
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.
Result
Table 5-23 shows the valid values for the Result parameter.
Table 5-23 Valid values for Result parameter
Value Definition Meaning
0x0 RESULT_SUCCESS Action successful
0x2 RESULT_FAILURE Action failed
Sequence Number
When the SGP sends a Retrieval Confirm to a Retrieval Request, it echoes the Action field. If the Action was ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP will put the BSN in the Sequence Number field and will set Result_Success in the Result field.
If the BSN could not be retrieved, the Sequence Number field will not be included and Result_Failure will be contained in the Result field.
9) Retrieval Indication
As shown in Figure 5-39, the Retrieval Indication message contains the Protocol Data parameter.
Figure 5-39 Structure of Retrieval Indication message
VI. ASP State Maintenance Messages
The ASP state maintenance messages only use the common message header.
1) ASP Up
As shown in Figure 5-40, the ASP Up message contains the optional ASP Identifier parameter and optional INFO String parameter.
Parameter tag=0x11 Parameter length=8
ASP identifier
0 15 31
Parameter tag=0x4 Parameter length
INFO string
Figure 5-40 Structure of ASP Up message
ASP Identifier
The ASP Identifier must be used where the SGP cannot identify the ASP by pre-configured address/port number information. For example, an ASP is resident on a host using dynamic address/port number assignment.
The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message.
INFO string
The optional INFO String parameter can carry any meaningful UTF-8 [6] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. No procedures are presently identified for its use but the INFO String might be used for debugging purposes.
2) ASP Up Ack
As shown in Figure 5-41, the ASP Up Ack message contains an optional INFO String parameter. The format and description of the INFO String in the ASP Up Ack message are the same as those of the INFO String in the ASP Up message.
As shown in Figure 5-42, the ASP Down message contains an optional INFO String parameter. The format and description of the INFO String in the ASP Down message are the same as those of the INFO String in the ASP Up message.
0 15 31
Parameter tag=0x04 Parameter length
INFO string
Figure 5-42 Structure of ASP Down message
4) ASP Down Ack
As shown in Figure 5-43, the ASP Down Ack message contains an optional INFO String parameter. The format and description of the INFO String in the ASP Down Ack message are the same as those of the INFO String in the ASP Up message.
0 15 31
Parameter tag=0x04 Parameter length
INFO string
Figure 5-43 Structure of ASP Down Ack message
5) Heartbeat
As shown inFigure 5-44, the Heartbeat message contains an optional Heartbeat Data parameter.
0 15 31
Parameter tag=0x09 Parameter length
Heartbeat data
Figure 5-44 Structure of Heartbeat message
The sending node defines the contents of the Heartbeat Data parameter. It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details.
Because the Heartbeat Data parameter is only of significance to the sender, the receiver of the Heartbeat message does not process this field. The receiver echoes the contents of the Heartbeat Data in a Heartbeat Ack message.
6) Heartbeat Ack
As shown in Figure 5-45, the Heartbeat Ack message contains an optional Heartbeat Data parameter. The format and definition of the Heartbeat Data parameter in the Heartbeat Ack message are the same as those of the Heartbeat Data parameter in the Heartbeat message.
0 15 31
Parameter tag=0x09 Parameter length
Heartbeat data
Figure 5-45 Structure of Heartbeat Ack message
VII. ASP Traffic Maintenance Messages
ASP traffic maintenance messages use the common and M2UA message headers.
1) ASP Active
As shown in Figure 5-46 and Figure 5-47, the ASP Active message contains the optional Traffic Mode Type, Interface Identifier, Additional Interface Identifier, and INFO String parameters, according to the text and integer formatted interface identifiers.
Figure 5-46 Structure of ASP Active message (integer formatted interface identifier)
0 15 31
Parameter tag=0x0b Parameter length
Traffic mode type
Parameter tag=0x03(String) Parameter length
Interface Identifiers
Parameter tag=0x04 Parameter length
INFO string
Additional Interface Identifiers
Figure 5-47 Structure of ASP Active message (text formatted interface identifier)
Traffic Mode Type
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. Within a particular AS, only one Traffic Mode Type can be used. Table 5-24 shows the three traffic mode types defined.
The ASP takes over all traffic in an AS (that is, primary/backup operation), overriding any currently active ASPs in the AS.
0x02 Load-share The ASP shares in the traffic distribution with any other currently active ASPs.
0x03 Broadcast All of the active ASPs receive all message traffic in the AS.
Interface Identifiers (optional)
The optional Interface Identifiers parameter contains a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) indexing the Application Server traffic that the sending ASP is configured/registered to receive. If integer formatted Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers (Type 0x8).Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface Identifiers for an AS are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
Caution:
If the optional Interface Identifier parameter is present, the integer formatted Interface Identifier must be supported, while the text formatted Interface Identifier may be supported.
INFO String (optional)
The format and description of the INFO String parameter are the same as for the ASP Up message.
2) ASP Active Ack
As shown in Figure 5-48 and Figure 5-49, the ASP Active Ack message contains the optional Traffic Mode Type, Interface Identifier, Additional Interface Identifier, and INFO String parameters.
The format and description of the optional INFO String parameter are the same as for the ASP Up message.
VIII. Layer Management Messages
1) Error
As shown in Figure 5-52, the Error message contains mandatory Error Code, optional Interface Identifier, and optional Diagnostic Information parameters.
0 15 31Tag=0x0C Length=8
Error code
Tag=0x01,0x03,0x08 Length
Interface Identifier
Tag=0x07 Length
Diagnostic information
Figure 5-52 Structure of Error message
Error Code The Error Code parameter indicates the reason for the Error Message. Table 5-25 lists the defined M2UA error codes.
Table 5-25 Error codes
Value Definition Meaning
0x01 Invalid Version
The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version.
The Error message would contain the supported version in the Common header. The Error message could optionally provide the supported version in the Diagnostic Information area.
0x02 Invalid Interface Identifier
The "Invalid Interface Identifier" error would be sent by an SGP if an ASP sends a message (that is, an ASP Active message) with an invalid (not configured) Interface Identifier value.
One of the optional Interface Identifier parameters (integer-based, text-based, or integer range) must be used with this error code to identify the invalid Interface Identifier(s) received.
The "Unsupported Message Class" error would be sent if a message with an unexpected or unsupported Message Class is received.
0x04 Unsupported Message Type
The "Unsupported Message Type" error would be sent if a message with an unexpected or unsupported Message Type is received.
0x05 Unsupported Traffic Handling Mode
The "Unsupported Traffic Handling Mode" error would be sent by an SGP if an ASP sends an ASP Active with an unsupported Traffic Handling Mode. An example would be a case in which the ASP sent an ASP Active message with load-sharing traffic handling mode, but the SGP did not support load-sharing.
One of the optional Interface Identifier parameters (integer-based, text-based, or integer range) may be used with this error code to identify the Interface Identifier(s).
0x06 Unexpected Message
The "Unexpected Message" error would be sent by an ASP if it received an MAUP message from an SGP while it was in the Inactive state.
0x07 Protocol Error The "Protocol Error" error would be sent for any protocol anomaly (that is, a bogus message).
0x08 Unsupported Interface Identifier Type
The "Unsupported Interface Identifier Type" error would be sent by an SGP if an ASP sends a text formatted Interface Identifier and the SGP only supports integer formatted Interface Identifiers.
When the ASP receives this error, it will need to resend its message with an integer formatted Interface Identifier.
0x09 Invalid Stream Identifier
The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream (that is, an MGMT message was received on a stream other than "0").
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").
0x0e ASP Identifier Required
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.
The ASP should resend the ASP Up message with an ASP Identifier.
0x0f Invalid ASP Identifier
The "Invalid ASP Identifier" is sent by an SGP in response to an ASP Up message with an invalid (that is, non-unique) ASP Identifier.
0x10 ASP Active for Interface Identifier(s)
The "ASP Currently Active for Interface Identifier(s)" error is sent by an SGP when a Deregistration Request is received from an ASP that is active for Interface Identifier(s) specified in the Deregistration Request. One of the optional Interface Identifier parameters (integer-based, text-based, or integer range) may be used with this error code to identify the Interface Identifier(s).
0x11 Invalid Parameter Value
The "Invalid Parameter Value " error is sent if a message is received with an invalid parameter value (for example, a State Request with an undefined State).
0x12 Parameter Field Error The "Parameter Field Error" would be sent if a message with a parameter has a wrong length field.
0x13 Unexpected Parameter The "Unexpected Parameter" error would be sent if a message contains an invalid parameter.
0x14
0x15 Not Used in M2UA /
0x16 Missing Parameter The "Missing Parameter" error would be sent if a mandatory parameter was not included in a message.
Diagnostic Information
The optional Diagnostic information can be any information germane to the error condition, to assist in the identification of the error condition.
In the case of an Invalid Version Error Code, the Diagnostic information includes the supported Version parameter. In the other cases, the Diagnostic information should be the first 40 bytes of the offending message.
2) Notify
As shown in Figure 5-53and Figure 5-54, the Notify message contains mandatory Status Type, mandatory Status Information, optional ASP Identifier, optional Interface Identifiers, and optional INFO String parameters.
Figure 5-54 Structure of Notify message (text formatted interface identifier)
Status Type
The Status Type parameter identifies the type of the Notify message. The following table lists the defined status types.
Table 5-26 Status types
Value Definition
0x01 Application server state change (AS_State_Change)
0x02 Other
The Status Information parameter contains more detailed information for the notification, based on the value of the Status Type.
If the Status Type is AS_State_Change, the Status Information values shown in Table 5-27 are used: These notifications are sent from an SGP to an ASP upon a change in status of a particular AS. The value reflects the new state of the AS. The Interface Identifiers of the AS may be placed in the message if desired.
Table 5-27 Status Information values if Status Type is AS_State_Change
If the Status Type is Other, the Status Information values shown in Table 5-28 are defined:
Table 5-28 Status Information values if Status Type is Other
Value Definition Meaning
0x01 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).
0x02 Alternate ASP active
The formerly Active ASP is informed when an alternate ASP transitions to the ASP Active state in override mode.
The ASP Identifier (if available) of the Alternate ASP must be placed in the message.
0x03 ASP failure
The SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN.
The ASP Identifier (if available) of the failed ASP must be placed in the message.
Interface Identifier s
The format of the Interface Identifiers parameter in the Notify message is the same as for the ASP Active message.
INFO String
The format of the INFO String parameter in the Notify message is the same as for the ASP Up message.
5.3.6 Basic Signaling Procedures
I. Establishment Procedure of Service Environment
Establishment procedure of the M2UA service environment is illustrated in Figure 5-55.SCTP association must be established between SG and MGC before the establishment of M2UA service environment.
Figure 5-55 Establishment procedure of M2UA service environment
Here MGC is the client, which will first send the request to establish the environment. Once the environment is ready, the M2UA data, MGC maintenance messages, and layer management messages can be transmitted between the peers.
II. Data Transfer Procedure
When the M2UA layer on ASP has an MAUP message to send to SG, it will do the following:
Determine the correct SG Get the M2UA link number Find the SCTP association to the chosen SG Determine the correct stream in the SCTP association based on the SS7 link Fill in the MAUP message, fill in M2UA Message Header, fill in Common Header,
and generate the M2UA message unit Send the MAUP message to the remote M2UA peer in SG, over the SCTP
association
When the M2UA layer on SG has an MAUP message to send to ASP, it will do the following:
Get Interface Identifier Determine the M2UA link number, which supports that MTP link Get the SCTP association Determine the correct stream in the SCTP association based on the SS7 link Fill in the MAUP message, fill in M2UA Message Header, fill in Common Header,
and generate the M2UA message unit Send the MAUP message to the remote M2UA peer in ASP, over the SCTP
association
III. Release Procedure
Release procedure of the M2UA service environment is illustrated in Figure 5-56.
Figure 5-56 Release procedure of M2UA service environment
After SG receives the release primitive from MGC, it begins the release process of M2UA service environment, and closes SCTP connection.
5.4 M3UA
5.4.1 Introduction
As SS7 MTP3-User adaptation layer, M3UA provides primitive communication service for MTP3 users over IP network and MTP3 (in an SG) at the edge of a network, so as to implement interworking between TDM SS7 and IP.
M3UA supports the following functions:
SS7 signaling point code representation
Within an SS7 network, an SG might be charged with representing a set of nodes in the IP domain into the SS7 network for routing purposes. The SG itself, as a physical node in the SS7 network, must have an SS7 point code.
Routing function
The distribution of SS7 messages between the signaling gateway process (SGP) and the application servers (ASs) is determined by the routing keys and their associated routing contexts.
Possible SS7 address/routing information that comprises a routing key entry includes, for example, the originating point code (OPC), destination point code (DPC), SIO found in the MTP3 routing label, or MTP3-User specific fields such as the ISUP circuit identification code (CIC).
SS7 and M3UA interworking
In the case of SS7 and M3UA interworking, the M3UA adaptation layer is designed to provide an extension of the MTP3 defined user primitives.
The M3UA layer at an ASP or IP server process (IPSP) indicates local congestion to an M3UA peer with a signaling connection (SCON) message. When an SG receives a congestion message (SCON) from an ASP, and the SG determines that a signaling point management cluster (SPMC) is now encountering congestion, it might trigger SS7 MTP3 transfer controlled management messages to concerned SS7 destinations according to congestion procedure of the relevant MTP3 standard.
SCTP stream mapping
The M3UA layer at both the SGP and ASP also supports the assignment of signaling traffic to streams within an SCTP association. Traffic that requires sequencing must be assigned to the same stream. To accomplish this, MTP3-User traffic can be assigned to individual streams based on, for example, the signaling link selection (SLS) value in the MTP3 routing label, subject of course to the maximum number of streams supported by the underlying SCTP association.
Client/Server model
The SGP and ASP are able to support both client and server operation. The peer endpoints using M3UA should be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations. The default orientation would be for the SGP to take on the role of server while the ASP is the client. In this case, ASPs should initiate the SCTP association to the SGP.
M3UA is conveyed over SCTP. The user port number registered by SCTP is 2905 for M3UA.
The following introduces some related terms and their definitions.
IP server process (IPSP)
An IPSP is a process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion instead of using the services of a signaling gateway.
Signaling gateway process (SGP)
An SGP is a processing instance of a signaling gateway. It serves as an active, backup or load-sharing process of a signaling gateway.
Routing key
A routing key describes a set of SS7 parameters and parameter values (such as DPC, SIO + DPC, SIO + DPC + OPC, and SIO + DPC + OPC + CIC) that uniquely define the range of signaling traffic to be handled by a particular application server. Parameters within the routing key cannot extend across a single destination point code.
Figure 5-57 shows the architecture of the M3UA protocol.
MTP3-User
M3UA
SCTP
IP
LM
Figure 5-57 Architecture of the M3UA protocol
M3UA is the lower-layer protocol of MTP3-User. It provides a standard MTP3 interface for MTP3-User. SCTP is the lower-layer protocol of M3UA and provides an association to serve M3UA. M3UA has also unique layer management (LM) to provide management services.
II. M3UA Implementations
M3UA provides the following service functions:
Support for the transport of MTP3-user messages Native management functions Interworking with MTP3 network management functions Support for the management of SCTP associations between the SGP and ASPs Support for the management of connections to multiple SGPs
All M3UA protocol messages (including SSNM messages) contain a common message header and zero or more parameters defined by the message type. Table 5-29 lists the SSNM messages.
Table 5-29 SSNM messages
Message Description
Destination unavailable (DUNA)
The DUNA message is sent from all SGPs in an SG to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are unreachable. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. The MTP3-User at the ASP is expected to stop traffic to the affected destination in the DUNA message.
The DAVA message is sent from the SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now reachable, or in response to a DAUD message (refer to the following part). The ASP MTP3-User protocol should resume traffic to the affected destination in the DAVA message.
Destination state audit (DAUD)
The DAUD message is sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes to one or more affected destinations.
SS7 network congestion (SCON)
The SCON message is sent from the SGP to all concerned ASPs to indicate congestion in the SS7 network to one or more destinations, or to an ASP in response to a DATA or DAUD message as appropriate. The SCON message might also be sent from the M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer or the ASP is congested.
Destination user part unavailable (DUPU)
The DUPU message is used by an SGP to inform an ASP that a remote peer MTP3-User part at an SS7 node is unavailable.
2) ASP management (ASPM) messages
Table 5-30 lists the ASPM messages.
Table 5-30 ASPM messages
Message Description
ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any SSNM or ASPM messages for all routing keys that the ASP is configured to serve.
ASP Up Ack The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer.
ASP Down The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer that the adaptation layer is not ready to receive DATA, SSNM, RKM or ASPTM messages.
ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M3UA peer, or in response to an ASPM message received by the ASP and locked due to management reasons.
Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP. The BEAT message does not contain any parameter.
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.
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.
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.
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.
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
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.
The Version field contains the version of the M3UA adaptation layer. The supported version is Release 1.0 protocol with the value 00000001.
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.
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.
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.
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.
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.
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.
Figure 5-60 shows the parameter format of the DATA message.
It is a parameter in the message to supplement the network indicator (NI).
In a DATA message, the Network Appearance implicitly defines the SS7 point code format used, the SS7 network indicator value, and the MTP3/MTP3-User protocol type/variant/version.
For example, two areas belong to the same NI (national network), but their signaling point formats are different. One area employs the 24-bit signaling point encoding scheme, and the other employs the 14-bit signaling point encoding scheme. In such a case, the network appearance parameter in the message is required.
The Network Appearance parameter value is of local significance only, coordinated between the SGP and ASP. Therefore, in the case where an ASP is connected to more than one SGP, the same SS7 network context may be identified by different Network Appearance values depending on which SGP a message is being transmitted or received.
Where the Network Appearance parameter is present, it must be the first parameter in the message as it defines the format of the protocol data field.
The network appearance parameter is not used in the M3UA protocol specification temporarily.
Routing Context
The routing context is a 32-bit value. In a message, it represents the routing key.
The Routing Context parameter contains the Routing Context value associated with the DATA message. Where a Routing Key has not been coordinated between the SGP and ASP, sending of Routing Context is not required. Where multiple Routing Keys and Routing Contexts are used across a common association, the Routing Context must be sent to identify the traffic flow, assisting in the internal distribution of Data messages.
Protocol Data
The Protocol Data parameter contains the original SS7 MTP3 message, including the service information octet and routing label.
The Protocol Data Parameter contains the Service Indicator (SI), Network Indicator (NI), Destination Point Code (DPC), Originating Point Code (OPC), and Signaling Link Selection Code (SLS) fields.
User Protocol Data includes MTP-User protocol elements (for example, ISUP, SCCP, or TUP parameters).
Figure 5-61 shows the format of the protocol data parameter.
The Originating Point Code field contains a 32-bit value.
Destination Point Code
The Destination Point Code field contains a 32-bit value. The Originating and Destination Point Code fields contain the OPC and DPC from the routing label of the original SS7 message in network byte order, justified to the least significant bit. Unused bits are coded “0”.
Service Indicator
The 8-bit Service Indicator field contains the SI field from the original SS7 message justified to the least significant bit. Unused bits are coded “0”.
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”.
Signaling Link Selection
The 8-bit Signaling Link Selection field contains the SLS bits from the routing label of the original SS7 message justified to the least significant bit and in Network Byte Order. Unused bits are coded “0”.
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.
Correlation ID
The Correlation ID parameter uniquely identifies the MSU carried in the Protocol Data within an AS. This Correlation ID parameter is assigned by the sending M3UA.
V. SS7 Signaling Network Management (SSNM) Messages
1) Destination Unavailable (DUNA)
The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are unreachable. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. As an implementation option the SG may suppress the sending of subsequent "response" DUNA messages regarding a certain unreachable SS7 destination for a certain period to give the remote side time to react. If there is no alternate route through another SG, the MTP3-User at the ASP is expected to stop traffic to the affected destination through the SG in accordance with the defined MTP3-User procedures.
The DUNA message contains the optional Network Appearance, optional Routing Context, mandatory Affected Point Code, and optional INFO String parameters.
Figure 5-62 shows the structure of the DUNA message.
Refer to the description of the Network Appearance field in the DATA message.
Routing Context
The optional Routing Context parameter contains the Routing Context values associated with the DUNA message. Where a Routing Key has not been coordinated between the SGP and ASP, sending of Routing Context is not required. Where multiple Routing Keys and Routing Contexts are used across a common association, the Routing Context(s) must be sent to identify the concerned traffic flows for which the DUNA message applies, assisting in outgoing traffic management and internal distribution of MTP-PAUSE indications to MTP3-Users at the receiver.
Affected Point Code
The Affected Point Code parameter contains a list of Affected Destination Point Code fields, each three-octet parameter to allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected Point Codes that are less than 24 bits are padded on the left to the 24-bit boundary.
INFO String
The optional INFO String parameter can carry any meaningful UTF-8 [10] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. No procedures are presently identified for its use but the INFO String may be used for debugging purposes.
2) Destination Available (DAVA)
The DAVA message is sent from an SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now reachable (and not restricted), or in response to a DAUD message if appropriate. If the ASP M3UA layer previously had no routes to the affected destinations the ASP MTP3-User protocol is informed and may now resume traffic to the affected destination. The ASP M3UA layer now routes the MTP3-user traffic through the SG initiating the DAVA message.
The DAVA message contains the optional Network Appearance, optional Routing Context, mandatory Affected Point Code, and optional INFO String parameters.
Network Appearance
The format and description of the Network Appearance are the same as for the DUNA message.
Routing Context
The format and description of the Routing Context are the same as for the DUNA message.
Affected Point Code
The format and description of the Affected Point Code are the same as for the DUNA message.
The format and description of the INFO String are the same as for the DUNA message.
3) Destination State Audit (DAUD)
The DAUD message may be sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes from the SG to one or more affected destinations.
The DAUD message contains the optional Network Appearance, optional Routing Context, mandatory Affected Point Code, and optional INFO String parameters.
Network Appearance
The format and description of the Network Appearance are the same as for the DUNA message.
Routing Context
The format and description of the Routing Context are the same as for the DUNA message.
Affected Point Code
The format and description of the Affected Point Code are the same as for the DUNA message.
INFO String
The format and description of the INFO String are the same as for the DUNA message.
4) Signaling Congestion (SCON)
The SCON message can be sent from an SGP to all concerned ASPs to indicate that an SG has determined that there is congestion in the SS7 network to one or more destinations, or to an ASP in response to a DATA or DAUD message as appropriate. For some MTP protocol variants (for example, ANSI MTP) the SCON message may be sent when the SS7 congestion level changes. The SCON message may also be sent from the M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer or the ASP is congested.
The SCON message contains the optional Network Appearance, optional Routing Context, mandatory Affected Point Code, optional Concerned Destination, optional Congestion Indications, and optional INFO String parameters.
Figure 5-63 shows the structure of the SCON message.
The Affected Point Code parameter can be used to indicate congestion of multiple destinations or ranges of destinations.
Concerned Destination
The optional 32-bit Concerned Destination parameter is only used if the SCON message is sent from an ASP to the SGP. It contains the point code of the originator of the message that triggered the SCON message. The Concerned Destination parameter contains one Concerned Destination Point Code field, a three-octet parameter to allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. A Concerned Point Code that is less than 24 bits is padded on the left to the 24-bit boundary.
Congestion Indications
The optional 32-bit Congestion Indications parameter contains a Congestion Level field. This optional parameter is used to communicate congestion levels in national MTP networks with multiple congestion thresholds, such as in ANSI MTP3. For MTP congestion methods without multiple congestion levels (for example, the ITU international method) the parameter is not included.
Congestion Level
The 8-bit Congestion Level field, associated with all of the Affected DPC(s) in the Affected Destinations parameter, contains one of the values as shown in Table 5-44.
Table 5-44 Congestion level values
Value Meaning
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,8].
INFO String
The format and description of the INFO String are the same as for the DUNA message.
5) Destination User Part Unavailable (DUPU)
The DUPU message is used by an SGP to inform concerned ASPs that a remote peer MTP3-User Part (for example, ISUP or SCCP) at an SS7 node is unavailable.
The DUPU message contains the optional Network Appearance, optional Routing Context, mandatory Affected Point Code, mandatory User/Cause, and optional INFO String parameters.
Figure 5-64 shows the structure of the DUPU message.
The format and description of the Network Appearance are the same as for the DUNA message.
Routing Context
The format and description of the Routing Context are the same as for the DUNA message.
Affected Point Code
The format and description of the Affected Point Code parameter are the same as for the DUNA message except that the Mask field is not used and only a single Affected DPC is included. Ranges and lists of Affected DPCs cannot be signaled in a DUPU message, but this is consistent with UPU operation in the SS7 network. The Affected
Destinations parameter in an MTP3 User Part Unavailable message (UPU) received by an SGP from the SS7 network contains only one destination.
User/Cause
The Unavailability Cause and MTP3-User Identity fields, associated with the Affected PC in the Affected Point Code parameter, are encoded as follows.
Unavailability Cause field
The 16-bit Unavailability Cause parameter provides the reason for the unavailability of the MTP3-User. The valid values for the Unavailability Cause parameter are shown in Table 5-45.
Table 5-45 Unavailability cause values
Value Meaning
0 Unknown
1 Unequipped remote user
2 Inaccessible remote user
The values agree with those provided in the SS7 MTP3 User Part Unavailable message. Depending on the MTP3 protocol used in the Network Appearance, additional values may be used—the specification of the relevant MTP3 protocol variant/version recommendation is definitive.
MTP3-User Identity field
The 16-bit MTP3-User Identity describes the specific MTP3-User that is unavailable (for example, ISUP and SCCP). Some of the valid values for the MTP3-User Identity are shown in Table 5-46.
The values align with those provided in the SS7 MTP3 User Part Unavailable message and Service Indicator. Depending on the MTP3 protocol variant/version used in the network appearance, additional values may be used. The relevant MTP3 protocol variant/version recommendation is definitive.
INFO String
The format and description of the INFO String are the same as for the DUNA message.
6) Destination Restricted (DRST)
The DRST message is optionally sent from the SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now restricted from the point of view of the SG, or in response to a DAUD message if appropriate. The M3UA layer at the ASP is expected to send traffic to the affected destination through an alternate SG with route(s) of equal priority, but only if such an alternate route exists and is available. If the affected destination is currently considered unavailable by the ASP, The MTP3-User should be informed that traffic to the affected destination can be resumed. In this case, the M3UA layer should route the traffic through the SG initiating the DRST message.
The DRST message contains the optional Network Appearance, optional Routing Context, mandatory Affected Point Code, and optional INFO String parameters.
Network Appearance
The format and description of the Network Appearance are the same as for the DUNA message.
Routing Context
The format and description of the Routing Context are the same as for the DUNA message.
Affected Point Code
The format and description of the Affected Point Code are the same as for the DUNA message.
INFO String
The format and description of the INFO String are the same as for the DUNA message.
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any ASPSM/ASPTM messages for all Routing Keys that the ASP is configured to serve.
The ASP Up message contains the optional ASP Identifier and optional INFO String parameters.
Figure 5-65 shows the structure of the ASP Up message.
The 32-bit ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message.
INFO String
The format and description of the optional INFO String parameter are the same as for the DUNA message.
2) ASP Up Acknowledgement (ASP Up Ack)
The ASP UP Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer.
The ASP Up Ack message contains the optional INFO String parameter.
Figure 5-66 shows the structure of the ASP Up Ack message.
The format and description of the optional INFO String parameter are the same as for the DUNA message.
The INFO String in an ASP Up Ack message is independent from the INFO String in the ASP Up message (that is, it does not have to echo back the INFO String received).
3) ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that the adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM messages.
The ASP Down message contains the optional INFO String parameter.
Figure 5-67 shows the structure of the ASP Down message.
The format and description of the optional INFO String parameter are the same as for the DUNA message.
The INFO String in an ASP Down Ack message is independent from the INFO String in the ASP Down message (that is, it does not have to echo back the INFO String received).
5) Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP, which has its own heartbeat.
The BEAT message contains the optional Heartbeat Data parameter.
Figure 5-69 shows the structure of the BEAT message.
The Heartbeat Data parameter contents are defined by the sending node. The Heartbeat Data could include, for example, a Heartbeat Sequence Number and/or Timestamp. The receiver of a BEAT message does not process this field as it is only of significance to the sender. The receiver must respond with a BEAT Ack message.
The BEAT Ack message is sent in response to a received BEAT message. It includes all the parameters of the received BEAT message, without any change.
VII. Routing Key Management Messages
1) Registration Request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to register one or more given Routing Keys with the remote peer. Typically, an ASP would send this message to an SGP, and expects to receive a REG RSP message in return with an associated Routing Context value.
The REG REQ message contains one or more mandatory Routing Key parameter.
Figure 5-70 shows the structure of the REG REQ message.
The mandatory Routing Key parameter is a variable-length value. The sender of this message expects that the receiver of this message will create a Routing Key entry and assign a unique Routing Context value to it, if the Routing Key entry does not already exist.
The Routing Key parameter may be present multiple times in the same message. This is used to allow the registration of multiple Routing Keys in a single message.
Figure 5-71 shows the format of the Routing Key parameter.
The Destination Point Code, Service Indicators, Originating Point Code List, and Circuit Range List parameters may be repeated as a grouping within the Routing Key parameter, in the structure shown above.
Local-RK-Identifier
The 32-bit Local-RK-Identifier field is used to uniquely identify the registration request. The Identifier value is assigned by the ASP, and is used to correlate the response in an REG RSP message with the original registration request. The Identifier value must remain unique until the REG RSP message is received.
Figure 5-72 shows the format of the Local-RK-Identifier field.
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
The Destination Point Code parameter is mandatory, and identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. The format is the same as described for the Affected Destination parameter in the DUNA message.
Figure 5-74 shows the format of the Destination Point Code.
The optional Network Appearance parameter field identifies the SS7 network context for the Routing Key, and has the same format as in the DATA message. The absence
Figure 5-75 Format of Network Appearance parameter
Service Indicators
The optional SI field contains one or more Service Indicators from the values as described in the MTP3-User Identity field of the DUPU message. The absence of the SI parameter in the Routing Key indicates the use of any SI value, excluding of course MTP management. Where an SI parameter does not contain a multiple of four SIs, the parameter is padded out to 32-byte alignment.
Figure 5-76 shows the format of the Service Indicators parameter.
Figure 5-76 Format of Service Indicators parameter
Originating Point Code List
The Originating Point Code List parameter contains one or more SS7 OPC entries, and its format is the same as the Destination Point Code parameter. The absence of the OPC List parameter in the Routing Key indicates the use of any OPC value.
Figure 5-77 shows the format of the Originating Point Code List.
Figure 5-77 Format of the Originating Point Code List
Circuit Range
An ISUP controlled circuit is uniquely identified by the SS7 OPC, DPC, and CIC value. For the purposes of identifying Circuit Ranges in an M3UA Routing Key, the optional Circuit Range parameter includes one or more circuit ranges, each identified by an OPC and Upper/Lower CIC value. The DPC is implicit as it is mandatory and already included in the DPC parameter of the Routing Key. The absence of the Circuit Range parameter in the Routing Key indicates the use of any Circuit Range values, in the case of ISUP/TUP traffic. The Origination Point Code is encoded the same as the Destination Point Code parameter, while the CIC values are 16-bit integers.
Figure 5-78 shows the format of the Circuit Range.
The REG RSP message is used as a response to the REG REQ message from a remote M3UA peer. It contains indications of success/failure for registration requests and returns a unique Routing Context value for successful registration requests, to be used in subsequent M3UA Traffic Management protocol.
The REG RSP message contains one or more mandatory Registration Result parameters.
Figure 5-79 shows the structure of the REG RSP message.
The Registration Result parameter contains the registration result for a single Routing Key in an REG REQ message. The number of results in a single REG RSP message must be anywhere from one to the total number of Routing Key parameters found in the corresponding REG REQ message. Where multiple REG RSP messages are used in reply to REG REQ message, a specific result should be in only one REG RSP message.
Figure 5-80 shows the format of each Registration Result.
The 32-bit Routing Context field contains the Routing Context value for the associated Routing Key if the registration was successful. It is set to "0" if the registration was not successful.
3) Deregistration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to deregister a given Routing Key. Typically, an ASP would send this message to an SGP, and expects to receive a DEREG RSP message in return with the associated Routing Context value.
The DEREG REQ message contains the mandatory Routing Context parameter.
Figure 5-81 shows the structure of the DEREG REQ message.
The Routing Context parameter contains (a list of) integers indexing the AS traffic that the sending ASP is currently registered to receive from the SGP but now wishes to deregister.
4) Deregistration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message from a remote M3UA peer.
The DEREG RSP message contains one or more mandatory Deregistration Result parameters.
Figure 5-82 shows the structure of the DEREG RSP message.
The Deregistration Result parameter contains the deregistration status for a single Routing Context in a DEREG REQ message. The number of results in a single DEREG RSP message may be anywhere from one to the total number of Routing Context values found in the corresponding DEREG REQ message.
Where multiple DEREG RSP messages are used in reply to DEREG REQ message, a specific result should be in only one DEREG RSP message. Figure 5-83 shows the format of each Deregistration Result parameter.
The 32-bit Deregistration Result Status field indicates the success or the reason for failure of the deregistration.
Table 5-49 lists the values for the Deregistration Status.
Table 5-49 Values for Deregistration Status
Value Meaning
0 Successfully Deregistered
1 Error - Unknown
2 Error - Invalid Routing Context
3 Error - Permission Denied
4 Error - Not Registered
5 Error - ASP Currently Active for Routing Context
VIII. ASP Traffic Maintenance Messages
1) ASP Active
The ASP Active message is sent by an ASP to indicate to a remote M3UA peer that it is ready to process signaling traffic for a particular AS. The ASP Active message affects only the ASP state for the Routing Keys identified by the Routing Contexts, if present.
The ASP Active message contains the optional Traffic Mode Type, optional Routing Context, and optional INFO String parameters.
Figure 5-84 shows the structure of the ASP Active message.
The 32-bit Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS.
Table 5-50 lists he valid values for Traffic Mode Type.
Table 5-50 Valid values for Traffic Mode Type
Value Traffic mode type
1 Override
2 Loadshare
3 Broadcast
Within a particular Routing Context, Override, Loadshare and Broadcast should not be mixed. The Override value indicates that the ASP is operating in Override mode, and the ASP takes over all traffic in an AS (that is, primary/backup operation), overriding any currently active ASPs in the AS. In Loadshare mode, the ASP will share in the traffic distribution with any other currently active ASPs. In Broadcast mode, the ASP will receive the same messages as any other currently active ASP.
Routing Context
The optional Routing Context parameter contains (a list of) integers indexing the AS traffic that the sending ASP is configured/registered to receive.
There is one-to-one relationship between an index entry and an SGP Routing Key or AS Name. Because an AS can only appear in one Network Appearance, the Network Appearance parameter is not required in the ASP Active message.
An ASP may be configured to process traffic for more than one logical AS. From the perspective of an ASP, a Routing Context defines a range of signaling traffic that the ASP is currently configured to receive from the SGP. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signaling traffic, identified by separate SS7 DPC/OPC/CIC ranges.
INFO String
The format and description of the optional INFO String parameter are the same as for the DUNA message.
2) ASP Active Acknowledgement (ASP Active Ack)
The ASP Active Ack message is used to acknowledge an ASP Active message received from a remote M3UA peer.
The ASP Active Ack message contains the optional Traffic Mode Type, optional Routing Context, and optional INFO String parameters.
Figure 5-85 shows the structure of the ASP Active Ack message.
The format and description of the optional INFO String parameter are the same as for the DUNA message.
The INFO String in an ASP Active Ack message is independent from the INFO String in the ASP Active message (that is, it does not have to echo back the INFO String received).
3) ASP Inactive
The ASP Inactive message is sent by an ASP to indicate to a remote M3UA peer that it is no longer an active ASP to be used within a list of ASPs. The ASP Inactive message affects only the ASP state in the Routing Keys identified by the Routing Contexts, if present.
The ASP Inactive message contains the optional Routing Context and optional INFO String parameters.
Figure 5-86 shows the structure of the ASP Inactive message.
The format of the Routing Context parameter is the same as for the ASP Inactive message.
INFO String
The format and description of the optional INFO String parameter are the same as for the DUNA message.
The INFO String in an ASP Inactive Ack message is independent from the INFO String in the ASP Inactive message (that is, it does not have to echo back the INFO String received).
IX. Management Messages
1) Error
The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected in the current state, or a parameter value might be invalid.
The Error message contains the mandatory Error Code, mandatory Routing Context, mandatory Network Appearance, mandatory Affected Point Code, and optional Diagnostic Information parameters.
Notes:
The Routing Context, Network Appearance, and Affected Point Code parameters are only mandatory for specific Error Codes.
The 32-bit Error Code parameter indicates the reason for the Error message.
Values for Error parameter Diagnostic Information
When included, the variable-length Diagnostic Information can be any information germane to the error condition, to assist in identification of the error condition.
2) Notify
The Notify message is used to provide an autonomous indication of M3UA events to an M3UA peer.
The Notify message contains the mandatory Status, optional ASP Identifier, optional Routing Context, and optional INFO String parameters.
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. The value reflects the new state of the AS.
If the Status Type is Other, the Status Information values are defined in Table 5-53.
Table 5-53 Values for Status Information if Status Type is Other
Value Definition Meaning
1 Insufficient ASP Resources Active in AS
In the Insufficient ASP Resources case, the SGP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is required to handle the load of the AS (Loadsharing or Broadcast mode).
2 Alternate ASP Active
For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Override mode. The ASP Identifier (if available) of the Alternate ASP must be placed in the message.
3 ASP Failure
For the ASP Failure case, the SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP must be placed in the message.
These notifications are not based on the SGP reporting the state change of an ASP or AS.
ASP Identifier
The format and description of the optional ASP Identifier are the same as for the ASP Up message.
Routing Context
The format and description of the Routing Context parameter are the same as for the ASP Active message.
INFO String
The format and description of the INFO String parameter are the same as for the ASP Active message.
The following examples show M3UA message flows for the establishment of traffic between an SGP and an ASP. It is assumed that the SCTP association is already set up.
I. Establishment of Association and Traffic Between SGPs and ASPs
1) Single ASP in an application server
This scenario shows the example M3UA message flows for the establishment of traffic between an SGP and an ASP, where only one ASP is configured within an AS (no backup).
Single ASP in an application server (“1+0” sparing), no registration
In such conditions, the sending of M3UA messages is shown in Figure 5-90.
SGP/IPSP ASP1/IPSP1ASP Up
ASP Up Ack
ASP active (RCn)
ASP active Ack (RCn)RC: Routing Context (optional)
Figure 5-90 Procedure to set up an M3UA message (example 1)
Single ASP in an application server (“1+0” sparing), dynamic registration
This scenario is the same as the former one but with the optional exchange of registration information. In this case the registration is accepted by the SGP. In such conditions, the sending of M3UA messages is shown in Figure 5-91.
SGP ASP1ASP Up
ASP Up Ack
REG REQ (LRCn,RKn)
REG RSP (LRCn,RKn)
ASP active (RCn)
ASP active Ack (RCn)
LRC: Local Routing ContextRK: Routing KeyRC: Routing Context
Figure 5-91 Procedure to set up an M3UA message (example 2)
Single ASP in multiple application servers (each with “1+0” sparing), dynamic registration
In such conditions, the sending of M3UA messages is shown in Figure 5-92.
SGP ASP1ASP Up
ASP Up Ack
REG REQ( LRC1,RK1 )
REG RSP(LRC1,RC1 )
ASP active (RC1)
ASP active Ack (RC1)
LRC: Local Routing ContextRK: Routing KeyRC: Routing Context
REG REQ (LRCn,RKn)
REG RSP (LRCn,RCn)
ASP active (RCn)
ASP active Ack (RCn)
Figure 5-92 Procedure to set up an M3UA message (example 3)
II. ASP traffic fail-over examples
1) 1+1 sparing, withdrawal of ASP, back-up over-ride
Referring to Figure 5-93, ASP1 withdraws from service as shown in Figure 5-93.
SGPASP inactive
ASP inactive Ack
ASP active
ASP active Ack
NTFY (AS-Pending)
ASP2ASP1
Figure 5-93 ASP traffic fail-over (example 1)
Note: If the SGP M3UA layer detects the loss of the M3UA peer (M3UA heartbeat loss or detection of SCTP failure), the initial ASP inactive message exchange (that is, SGP to ASP1) would not occur.
Following on from the example in Figure 5-94, and ASP2 wishes to over-ride ASP1 and take over the traffic. See Figure 5-94.
SG ASP1
NTFY (alternate ASP-active)
ASP active
ASP2
ASP active Ack
Figure 5-94 ASP traffic fail-over (example 2)
III. Normal Withdrawal of an ASP from an Application Server and Teardown of an Association
An ASP which is now confirmed in the state ASP-INACTIVE (that is, the ASP has received an ASP inactive Ack message) may now proceed to the ASP-DOWN state, if it is to be removed from service.
See Figure 5-95.
SGP ASP1ASP inactive (RCn)
DEREG REQ (RCn)
DEREG RSP(LRCn,RCn)
ASP Down
ASP Down Ack
RC: Routing ContextASP inactive Ack (RCn)
Figure 5-95 Example of normal withdrawal of an ASP from an application server and teardown of an association
5.5 IUA
5.5.1 Introduction
This section describes the need for ISDN Q.921-User Adaptation (IUA) layer protocol as well as how this protocol shall be implemented. Defined by RFC 3057, IUA defines
a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP).IUA supports both ISDN Primary Rate Access (PRA) as well as Basic Rate Access (BRA) including the support for both point-to-point (P2P) and point-to-multipoint (M2MP) modes of communication. Figure 5-96 shows the details.
ISDN EP MGC
Q.931
Q.921
Q.931
IUA
SCTP
IP
IUASCTP
IP
DSS1 IUASG
PSTN IP(NIF)
Q.921
Figure 5-96 Location of IUA in the system
5.5.2 Terminology
I. Interface
An interface supports the relevant ISDN signaling channel. This signaling channel MAY be a 16 kbit/s D channel for an ISDN BRA as well as 64 kbit/s primary or backup D channel for an ISDN PRA.
II. Application Server (AS)
An AS is a logical entity serving a specific application instance. An example of an Application Server is a MGC handling the Q.931 and call processing for D channels terminated by the Signaling Gateways.
III. Application Server Process (ASP)
A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances.
IV. Layer Management
Layer management is a nodal function that handles the inputs and outputs between the IUA layer and a local management entity.
I. Support for Transport of Q.921/Q.931 Boundary Primitives
In DSS1, all Q.921/Q.931 boundary primitives are standard. IUA layer needs to support all of the primitives of this boundary to successfully backhaul Q.931.The primitives are DL-ESTABLISH, DL-RELEASE, DL-DATA, and DL-UNIT DATA.
II. Support for Communication Between Layer Management Modules on SG and MGC
The IUA layer needs to provide some services that will facilitate communication between Layer Management modules on the SG and MGC. The primitives are M-TEI STATUS and M-ERROR.
III. Support for Management of Active Associations Between SG and MGC
The IUA layer can be instructed by the layer management to establish an SCTP association to a peer IUA node. This procedure can be achieved using the M-SCTP ESTABLISH primitive. Nine primitives between the IUA layer and the layer management are defined below to help the layer management manage the SCTP association(s) between the SG and MGC:
M-SCTP ESTABLISH M-SCTP RELEASE M-SCTP STATUS M-ASP STATUS M-ASP-UP M-ASP-DOWN M-ASP-ACTIVE M-ASP-INACTIVE M-AS STATUS
5.5.4 Functions Implemented by the IUA Layer
I. Mapping
The IUA layer MUST maintain a map of the interface identifier to a physical interface on the SG.A physical interface would be a E1 interface or a timeslot on the interface. In addition, for a given interface the SG MUST be able to identify the associated signaling channel. IUA layers on both SG and MGC MAY maintain the status of TEIs and SAPIs. The SG maps an interface identifier to an SCTP association/stream only when an ASP sends an ASP Active message for a particular interface identifier. It MUST be noted, however, that this mapping is dynamic and could change at any time
due to a change of ASP state. Therefore, the SG MUST maintain the states of AS/ASP and reference them during the routing of a message to an AS/ASP.
II. Status of ASPs
The IUA layer on the SG MUST maintain the state of the ASPs it is supporting. The state of an ASP changes because of reception of peer-to-peer messages (such as ASPM messages) or reception of indications from the local SCTP association. At a SG, an application server list MAY contain active and inactive ASPs to support ASP load-sharing and fail-over procedures. When, for example, both a primary and a back-up ASP are available, IUA peer protocol is required to control which ASP is currently active. The ordered list of ASPs within a logical application server is kept updated in the SG to reflect the active application server process(es).
Also the IUA layer MAY need to inform the local management of the change in status of an ASP or AS. This can be achieved using the M-ASP STATUS or M-AS STATUS primitives.
III. SCTP Stream Management
SCTP allows a user specified number of streams to be opened during the initialization. It is the responsibility of the IUA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, an IUA layer is not aware of the stream number to interface identifier mapping of its peer IUA layer. Instead, the interface identifier is in the IUA message header. The use of SCTP streams within IUA is recommended in order to minimize transmission and buffering delay, therefore improving the overall performance and reliability of the signaling elements. It is recommended that a separate SCTP stream is used for each D channel.
IV. Seamless Network Management Interworking
The IUA layer on the SG SHOULD pass an indication of unavailability of the IUA-User (Q.931) to the local layer management, if the currently active ASP moves from the ACTIVE state. The layer management could instruct Q.921 to take some action, if it deems appropriate. Likewise, if an SCTP association fails, the IUA layer on both the SG and ASP sides MAY generate Release primitives to take the data links out-of-service.
V. Congestion Management
If the IUA layer becomes congested (implementation dependent), it MAY stop reading from the SCTP association to flow control from the peer IUA.
M-ASP_ACTIVE request LM -> IUA LM requests ASP to send an ASP ACTIVE message to the SG.
M-ASP_ACTIVE confirm IUA -> LM ASP reports that it has received an ASP ACTIVE Acknowledgement message from the SG.
M-ASP_INACTIVE request LM -> IUA LM requests ASP to send an ASP INACTIVE message to the SG.
M-ASP_INACTIVE confirm IUA -> LM ASP reports that it has received an ASP INACTIVE Acknowledgement message from the SG.
5.5.7 Implementation of IUA
Figure 5-98 shows a typical implementation of IUA in an NGN solution.
SoftX3000
UMG8900
IUA
RSP subscriber frame
ISDN terminal ISDN terminal
BRAPRA
PBX
Figure 5-98 Typical implementation of IUA
The UMG8900 interoperates with the PBX through PRA and accesses the ISDN terminals through the BRA interfaces provided by the RSP subscriber frame. The UMG8900 transparently transmits the Q.931 messages in BRA and PRA to the SoftX3000 through IUA. The SoftX3000 processes the Q.931 call control messages.
As shown in Figure 5-99, the IUA message structure is composed of a common message header, an IUA message header, and several variable-length IUA messages.
The common message header contains the Version, Spare, Message Class, Message Type, and Message Length fields. The message header part applies to all signaling protocol adaptation layer messages.
Version
The version field contains the version of the IUA adaptation layer. The currently supported version number is 0000 0001, which means version 1.0.
Spare
The length of the spare field is eight bits. This field SHOULD be set to all '0's and ignored by the receiver.
80-FF Reserved for IETF-defined message class extensions
Message Type
The message types as listed in Table 5-55, Table 5-56, Table 5-57 and Table 5-58 are defined according to different message classes.
Table 5-56 Q.921/Q.931 boundary primitives transport (QPTM) messages
Value Message type Meaning
00 Reserved -
01 Data Request A Data Request contains an ISDN Q.921 user protocol data unit (PDU). A PDU corresponds to a confirmed information transmission service.
02 Data Indication A Data Indication message indicates that the peer IUA has successfully processed a received Data Request message.
03 Unit Data Request A Unit Data Request message contains an ISDN Q.921 user PDU. A PDU corresponds to a unconfirmed information transmission service.
04 Unit Data IndicationA Unit Data Indication message indicates that the peer IUA has successfully processed a received Unit Data Request message.
05 Establish Request
An Establish Request message establishes a data link on a signaling channel or confirms that a data link has been established on a signaling channel. MGC controls the status of channel D. When MGC expects channel D to be in the service operation state, it sends an Establish Request message.
06 Establish Confirm SG sends an Establish Confirm message to confirm an Establish Request message.
07 Establish IndicationSG sends an Establish Indication message to indicate that a data link has been established in a signaling channel.
08 Release Request MGC sends a Release Request to release a data link on a signaling channel.
09 Release Confirm SG sends a Release Confirm message to respond to a Release Request message
0A Release Indication SG sends a Release Indication message to indicate that a data link has been released on a signaling channel.
0B-7F Reserved by the IETF -
80-FF Reserved for IETF-defined QPTM extensions
-
Table 5-57 IUA application server process state maintenance (ASPSM) messages
Value Message type Meaning
00 Reserved -
01 ASP Up (UP) ASP sends an ASP Up (UP) message to SG to indicate that ASP is ready to receive traffic or maintenance messages.
02 ASP Down (DOWN)
ASP sends an ASP Down (DOWN) message to SG to indicate that ASP is not ready to receive traffic or maintenance messages.
03 Heartbeat (BEAT) It is optionally used to ensure that the IUA peers are still available to each other.
04 ASP Up Ack (UP ACK)
It is used to acknowledge an ASP Up message received from a remote IUA peer.
05 ASP Down Ack (DOWN ACK)
It is used to acknowledge an ASP Down message received from a remote IUA peer.
06 Heartbeat Ack (BEAT ACK)
It is sent in response to a Heartbeat message. An IUA peer must send a Heartbeat Ack message in response to a Heartbeat message. The Heartbeat Ack message includes all the parameters of the received Heartbeat message, without any change.
Table 5-58 IUA application server process traffic maintenance (ASPTM) messages
Value Message type Meaning
00 Reserved -
01 ASP Active (ACTIVE) It is sent by an ASP to indicate to an SGP that it is active and ready to be used.
02 ASP Inactive (INACTIVE) It is sent by an ASP to indicate to an SG that it is no longer an active ASP.
03 ASP Active Ack (ACTIVE ACK) It is used to respond to an ASP Active message received from a remote IUA.
04 ASP Inactive Ack (INACTIVE ACK)
It is used to respond to an ASP Inactive message received from a remote IUA.
05-7F Reserved by the IETF -
80-FF Reserved for IETF-defined ASPTM extensions -
Table 5-59 IUA management (MGMT) messages
Value Message type Meaning
00 ERROR
It is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
01 Notify (NTFY) It is used to provide the automatic indication of an IUA event to the IUA peer.
02 TEI Status Request It is interchanged between peers of IUA layer to request the status of a specific TEI.
03 TEI Status Confirm It is interchanged between peers of IUA layer to confirm the status of a specific TEI.
04 TEI Status Indication
It is interchanged between peers of IUA layer to indicate the status of a specific TEI.
The message length field defines the length of the message in octets, including the header.
III. Variable-Length Parameter Format
IUA messages consist of a common header followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameters contained in a message are defined in a tag-length-value format.
A variable-length parameter consists of the [Parameter Tag], [Parameter Length], and [Parameter Value] fields.
Parameter Tag
The [Parameter Tag] field is a 16-bit identifier of the type of parameter.
Parameter Length
The [Parameter Length] field must be a multiple of four bytes. If it is not a multiple of four bytes, the sender pads with all zero bytes after the Parameter Value field. The [Parameter Length] must not be padded with all zero bytes. A sender must not pad with more than three bytes. The receiver must ignore the padding bytes.
Parameter Value
The [Parameter Value] has a variable length. It contains the actual information to be transferred in the parameter.
IV. Format of IUA Message Header
In addition to the common message header, there will be a specific message header for QPTM and the TEI Status MGMT messages. The IUA message header will immediately follow the common header in these messages.
As shown in Figure 5-100, this message header consists of the tag, length, interface identifier, and data link connection identifier (DLCI).
The 16-bit [Tag] field indicates the type of the interface identifier. Table 5-60 shows the correspondence between the tag values of the IUA message header and the types of the interface identifier.
Table 5-60 Correspondence between tag values and interface identifier types
Tag value Interface identifier type
0x0001 Integer
0x0003 Text
Note:
The integer formatted interface identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported. The interface identifier of the character string type is not supported at present.
Length
The [Parameter Length] values of the IUA message header vary with different types of interface identifiers.
The [Length] value is 8 if the type of the interface identifier is integer.
The [Length] value is variable if the type of the interface identifier is text. The maximum length does not exceed 255 octets. The length is equal to the length of the interface identifier plus four bytes (the tag and length fields).
Interface Identifier
The interface identifier identifies the physical interface at the SG for which the signaling messages are sent/received. The format of the [Interface Identifier] parameter can be text or integer. The interface identifiers are assigned according to
network operator policy. The integer values used are of local significance only, coordinated between the SG and ASP.
V. Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
1) Data Request message
The Data Request message contains the common message header followed by IUA message header. As shown in Figure 5-101, the Data message contains a mandatory protocol data. The protocol data contains the upper layer Q.931 message.
Parameter tag=0x00e Parameter length
Protocol data(32)
0 15 31
Figure 5-101 Structure of Data message
2) Unit Data Request message
The Data Request message contains the common message header followed by IUA message header. As shown in Figure 5-102 the Unit Data Request message contains a mandatory protocol data. The protocol data contains the upper layer Q.931 message.
Parameter tag=0x00e Parameter length
Protocol data(32)
0 15 31
Figure 5-102 Structure of Data Acknowledge message
The Release messages contain the common message header followed by IUA message header. The Release Confirm message does not contain any additional parameters. The Release Request and Indication messages contain the parameters as shown in Figure 5-103:
Specific to a request. Indicates Layer 2 SHOULD release and deny all requests from far end to establish a data link on the signaling channel (that is, if SABME is received, send a DM)
0x03 RELEASE_OTHER Other reasons
Caution:
Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid reason codes for a Release Request message.
VI. IUA application server process state maintenance (ASPSM) messages
The IUA ASPSM messages will only use the common message header.
The ASP state maintenance messages only use the common message header.
1) ASP Up
As shown in Figure 5-104, the ASP Up message contains an optional [INFO String] parameter.
The optional [INFO String] parameter can carry any meaningful 8-bit ASCII character string along with the message. Length of the [INFO String] parameter is from 0 to 255 characters. No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes.
2) ASP Up Ack
As shown in Figure 5-105, the ASP Up Ack message contains an optional [INFO String] parameter. The format and description of the INFO String in the ASP Up Ack message are the same as those of the INFO String in the ASP Up message.
0 15 31
Parameter tag=0x04 Parameter length
INFO string
Figure 5-105 Structure of ASP Up Ack message
3) ASP Down
As shown in Figure 5-106, the ASP Down message contains the mandatory [Reason] parameter and the optional [INFO string] parameter.
Parameter tag=0x0a Parameter length
Reason
0 15 31
Parameter tag=0x4 Parameter length
INFO string
Figure 5-106 Structure of ASP Down message
Reason
The [Reason] parameter indicates the reason that the remote IUA adaptation layer is unavailable. The value of this parameter is fixed set to “0x01”, indicating that ASP is under management inhibition. If an ASP is removed from Management Inhibit, the ASP will send an ASP Up message.
INFO string
The format and description of the [INFO String] parameter are the same as for the ASP Up message.
4) ASP Down Ack
The ASP Down Ack message contains the mandatory [Reason] parameter and the optional [INFO String] parameter. The format and description of the [Reason] and [INFO String] parameters are the same as for the ASP Down message.
As shown in Figure 5-107, the Heartbeat message contains an optional [Heartbeat Data] parameter.
0 15 31
Parameter tag=0x09 Parameter length
Heartbeat data
Figure 5-107 Structure of Heartbeat message
The [Heartbeat Data] parameter contents are defined by the sending node. The Heartbeat Data could include, for example, a Heartbeat Sequence Number and, or Timestamp. The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver MUST respond with a Heartbeat Ack message.
6) Heartbeat Ack
The Heartbeat Ack message contains an optional [Heartbeat Data] parameter. The format and description of the [Heartbeat Data] parameter in the Heartbeat Ack message are the same as for the Heartbeat message.
VII. IUA application server process traffic maintenance (ASPTM) messages
ASP traffic maintenance messages use the common and IUA message headers.
1) ASP Active (ASPAC)
As shown in Figure 5-108 and Figure 5-109, the ASP Active message contains the mandatory [Traffic Mode Type], optional [Interface Identifier], and optional [INFO String] parameters, according to the text and integer formatted interface identifiers.
Figure 5-108 Structure of ASP Active message (integer formatted interface identifier)
0 15 31
Parameter tag=0x0b Parameter length
Traffic mode type
Parameter tag=0x03(String) Parameter length
Interface Identifiers
Parameter tag=0x04 Parameter length
INFO string
Additional Interface Identifiers
Figure 5-109 Structure of ASP Active message (text formatted interface identifier)
Traffic Mode Type
The [Traffic Mode Type] parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for the parameter are shown in Table 5-62:
0x010x01 Override The ASP takes over all traffic in an AS (that is, primary/backup operation), overriding any currently active ASPs in the AS.
0x02 Load-share The ASP will share in the traffic distribution with any other currently active ASPs.
Interface Identifiers (optional)
The optional [Interface Identifiers] parameter contains a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) indexing the Application Server traffic that the sending ASP is configured/registered to receive. If integer formatted Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers (Type 0x8).Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface Identifiers for an AS are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
Caution:
If the optional [Interface Identifier] parameter is present, the integer formatted Interface Identifier must be supported, while the text formatted Interface Identifier may be supported.
INFO String (optional)
The format and description of the [INFO String] parameter are the same as for the ASP Up message.
2) ASP Active Ack (ASPAC ACK)
The ASP Active Ack message contains the mandatory [Traffic Mode Type], optional [Interface Identifier], and optional [INFO String] parameters.
The format and description of the [Traffic Mode Type] and [Interface Identifier] parameters are the same as for the ASP Active (ASPAC) message.
The format and description of the optional [INFO String] parameter are the same as for the ASP Up message.
3) ASP Inactive (ASPIA)
The ASPIA message contains the mandatory [Traffic Mode Type], optional [Interface Identifier], and optional [INFO String] parameters.
The format and description of the [Traffic Mode Type] and [Interface Identifier] parameters are the same as for the ASP Active (ASPAC) message.
The format and description of the optional [INFO String] parameter are the same as for the ASP Up message.
4) ASP Inactive Ack
The ASP Inactive Ack message contains the optional [Interface Identifier] and [INFO String] parameters.
The format of the optional [Interface Identifier] parameter is the same as for the ASP Active message.
The format and description of the optional [INFO String] parameter are the same as for the ASP Up message.
VIII. Layer Management (MGMT) Messages
1) Error
The Error message will only have the common message header. The Error message contains the mandatory [Error Code] and optional [Diagnostic Information] parameters. Figure 5-110 shows the structure of the Error message.
0 15 31Tag=0x0C Length=8
Error code
Tag=0x07 Length
Diagnostic information
Figure 5-110 Structure of Error message
Error Code
The [Error Code] parameter indicates the reason for the Error Message. Table 5-63 lists the defined IUA error codes.
The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version.
The Error message would contain the supported version in the common header. The Error message could optionally provide the supported version in the Diagnostic Information area.
0x02 Invalid Interface Identifier
The "Invalid Interface Identifier" error would be sent by a SG if an ASP sends a message with an invalid (unconfigured) [Interface Identifier] value.
0x03 Unsupported Message Class
The "Unsupported Message Class" error would be sent if a message with an unexpected or unsupported Message Class is received.
0x04 Unsupported Message Type
The "Unsupported Message Type" error would be sent if a message with an unexpected or unsupported Message Type is received.
0x05 Unsupported Traffic Handling Mode
The "Unsupported Traffic Handling Mode" error would be sent by a SG if an ASP sends an ASP Active with an unsupported Traffic Handling Mode. An example would be a case in which the SG did not support load-sharing.
0x06 Unexpected Message
The "Unexpected Message" error would be sent by an ASP if it received a QPTM message from an SG while it was in the Inactive state (the ASP could optionally drop the message and not send an Error).
It would also be sent by an ASP if it received a defined and recognized message that the SG is not expected to send (for example, if the MGC receives an IUA Establish Request message).
0x07 Protocol Error The "Protocol Error" error would be sent for any protocol anomaly (that is, a bogus message).
0x08 Unsupported Interface Identifier Type
The "Unsupported Interface Identifier Type" error would be sent by an SG if an ASP sends a text formatted Interface Identifier and the SG only supports integer formatted Interface Identifiers.
When the ASP receives this error, it will need to resend its message with an integer formatted Interface Identifier.
0x09 Invalid Stream Identifier
The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream. For example, an MGMT message was received on a stream other than "0".
The "Unassigned TEI" error may be used when the SG receives an IUA message that includes a TEI which has not been assigned or recognized for use on the indicated ISDN D-channel.
0x0b Unrecognized SAPI
The "Unrecognized SAPI" error would handle the case of using a SAPI that is not recognized by the SG.
0x0c Invalid TEI, SAPI combination
The "Invalid TEI, SAPI combination" error identifies errors where the TEI is assigned and the SAPI is recognized, but the combination is not valid for the interface (for example, on a BRI the MGC tries to send Q.921 Management messages through IUA when Layer Management at the SG SHOULD be performing this function).
Diagnostic Information
The optional Diagnostic information can be any information germane to the error condition, to assist in the identification of the error condition.
To enhance debugging, the Diagnostic information could contain the first 40 bytes of the offending message.
2) Notify (NTFY)
As shown in Figure 5-111 and Figure 5-112, the Notify message contains the mandatory [Status Type], mandatory [Status Information], optional [ASP Identifier], optional [Interface Identifiers], and optional [INFO String] parameters.
0x010x01 Application server state change (AS_State_Change)
0x020x02 Other
Status Information
The [Status Information] parameter contains more detailed information for the notification, based on the value of the Status Type.
If the Status Type is AS_State_Change, the Status Information values shown in Table 5-65 are used: These notifications are sent from an SG to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the AS.
Table 5-65 Status information whose Status Type is AS_State_Change
Value Definition
0x010x01 Application Server Down (AS-Down)
0x02 Application Server Inactive (AS_Inactive)
0x03 Application Server Active (AS_Active)
0x04 Application Server Pending (AS_Pending)
If the Status Type is Other, the Status Information values shown in Table 5-66 are defined. These notifications are not based on the SG reporting the state change of an ASP or AS.
Table 5-66 Status information whose Status Type is Other
Value Definition Description
0x01 Insufficient ASP resources active in AS
In the Insufficient ASP Resources case, the SG is indicating to an "Inactive" ASP(s) in the AS that another ASP is required in order to handle the load of the AS (Load-sharing mode).
0x02 Alternate ASP 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.
Interface Identifiers
The format of the [Interface Identifiers] parameter in the Notify message is the same as for the ASP Active message.
The format of the [INFO String] parameter in the Notify message is the same as for the ASP Up message.
3) TEI Status Messages (Request, Confirm and Indication)
The TEI Status messages contain the common message header followed by IUA message header. The TEI Status Request message does not contain any additional parameters. As shown in Figure 5-113, the TEI Status Indication, and Confirm messages contain the mandatory [Status] parameter.
Parameter tag=0x10 Parameter length
Status
0 15 31
Figure 5-113 Structure of TEI Confirm and TEI Indication messages
The valid values for Status are shown in Table 5-67.
Table 5-67 Status in TEI Confirm and TEI Indication messages
Value Definition Description
0x00 ASSIGNED TEI is considered assigned by Q.921.
0x01 UNASSIGNED TEI is considered unassigned by Q.921.
5.5.9 Basic Signaling Procedures
I. Establishment of Association and Traffic between SGs and ASPs
Single ASP in an Application Server (1+0 sparing)
Figure 5-114shows the example IUA message flows for the establishment of traffic between an SG and an ASP, where only one ASP is configured within an AS (no backup). It is assumed that the SCTP association is already set up.
Figure 5-114 Establishment of traffic when there is a single ASP in an AS
Two ASPs in Application Server (1+1 sparing)
Figure 5-115shows the example IUA message flows for the establishment of traffic between an SG and two ASPs in the same Application Server, where ASP1 is configured to be Active and ASP2 a standby in the event of communication failure or the withdrawal from service of ASP1. ASP2 MAY act as a hot, warm, or cold standby depending on the extent to which ASP1 and ASP2 share call state or can communicate call state under failure/withdrawal events.
SG ASP1ASP Up
ASPUP ACK
ASP Acitve
ASP2
ASP Up
ASPUP ACK
ASP Acitve ACK
Figure 5-115 Establishment of traffic when there are two ASPs in the same AS
Two ASPs in an Application Server (1+1 sparing, load-sharing case)
The two ASPs are brought to active and load-share the traffic load. In this case, one ASP is sufficient to handle the total traffic load. See Figure 5-116.
Figure 5-116 Establishment of traffic when there are two ASPs in the same AS (in the load-sharing case)
Three ASPs in an Application Server (n+k sparing, load-sharing case)
Figure 5-117shows the example IUA message flows for the establishment of traffic between an SG and three ASPs in the same Application Server, where two of the ASPs are brought to active and share the load. In this case, a minimum of two ASPs are required to handle the total traffic load (2+1 sparing).
SG ASP1ASP Up
ASPUP ACK
ASP Active (Load-sharing)
ASP Active ACK
ASP2
ASP Up
ASPUP ACK
ASP Active (Load-sharing)
ASP Active ACK
ASP3
ASP Up
ASPUP ACK
Figure 5-117 Establishment of traffic when there is are three ASPs in the same AS
II. ASP Traffic Fail-over Examples
(1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
Figure 5-118shows a case in which an ASP withdraws from service.
In this case, the SG notifies ASP2 that the AS has moved to the Down state. The SG could have also (optionally) sent a Notify message when the AS moved to the Pending state.
Caution:
If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange would not occur.
(1+1 Sparing, Back-up Over-ride)
Figure 5-119shows a case in which ASP2 wishes to over-ride ASP1 and take over the traffic. In this case, the SG notifies ASP1 that an alternative ASP has overridden it.
SG ASP1ASP Active
ASPUP Active ACK
ASP2
Notify (Alt ASP-ACT))
Figure 5-119 Overriding an active ASP by a backup ASP
(n+k Sparing, Load-sharing case, withdrawal of ASP)
Figure 5-120shows the example IUA message flows for the establishment of traffic between an SG and three ASPs in the same Application Server in the n+k backup and load-sharing mode. ASP1 withdraws from service. In this case, the SG has knowledge of the minimum ASP resources required (implementation dependent),for example, if the SG knows that n+k = 2+1 for a load-share AS and n currently equals 1.
Figure 5-120 Withdrawal of service by ASP in the load-sharing mode
Caution:
If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange would not occur.
III. Q.921/Q.931 Primitives Backhaul Examples
Table 5-68 shows the two procedures of sending a QPTM message in two directions.
Table 5-68 Procedures of sending a QPTM message
Direction Procedure
Step 1: Determine the correct SG.
Step 2: Find the SCTP association to the chosen SG.
Step 3: Determine the correct stream in the SCTP association based on the D channel.
Step 4: Fill in the QPTM message, IUA message header, and common header.
ASP->SG
Step 5: Send the QPTM message to the remote IUA peer in the SG, over the SCTP association.
Step 1: Determine the AS for the Interface Identifier.
Step 2: Determine the Active ASP (SCTP association) within the AS.
Step 3: Determine the correct stream in the SCTP association based on the D channel.
Step 4: Fill in the QPTM message, IUA message header, and common header.
SG->ASP
Step 5: Send the QPTM message to the remote IUA peer in the ASP, over the SCTP association.
An example of the message flows for establishing a data link on a signaling channel, passing PDUs, and releasing a data link on a signaling channel is shown in Figure 5-122. An active association between ASP and SG is established prior to the message flows.
SGEstablish Request
Establish Confirm
ASP
Release Request(Release_MGMT)
Data Request
Data Indication
Data Request
Data Indication
Data Request
Data Request
Data Indication
Release Confirm
Figure 5-121 Establishing and releasing a data link.
Figure 5-122shows an example of the message flows for a failed attempt to establish a data link on the signaling channel. In this case, the gateway has a problem with its physical connection, so it cannot establish a data link on the signaling channel.
SG Establish Request( Establish START) ASP
Establish Indication (RELEASE_PHYS)
Figure 5-122 Failure of establishing a data link
IV. Layer Management Communication Examples
An example of the message flows for communication between Layer Management modules between SG and ASP is shown in Figure 5-123. An active association between ASP and SG is established prior to the message flows.
Figure 5-123 Communication between Layer Management modules
5.6 V5UA
5.6.1 Introduction
V5UA is defined by IETF Draft V5.2-User Adaptation Layer (V5UA). It is a mechanism for backhauling of V5.2 messages over IP using SCTP or other applicable transmission protocols. See Figure 5-124.
AN MGC
LAPV5
V5UA
M2UA
SCTP
IP
V5UA
SCTP
IP
V5.2 V5UASG
(NIF)V5.2
LAPV5
Figure 5-124 Location of V5UA in the system
5.6.2 Terminology
I. Bearer Channel Connection (BCC) Protocol
It refers to a protocol which allows the local exchange (LE) to instruct the access network (AN) to allocate bearer channels, either singly or in multiples, on demand.
II. Communication Channel (C-Channel)
It refers to a 64 kbit/s time slot on a V5.2 interface provisioned to carry communication channels.
It refers to any one of the following information types:
The layer 2 data link carrying the control protocol The layer 2 data link carrying the link control protocol The layer 2 data link carrying the PSTN signaling Each of the layer 2 data links carrying the protection protocol The layer 2 data link carrying the BCC protocol All the ISDN Ds-type data from one or more user ports All the PSTN P-type data from one or more user ports All the ISDN T-type data from one or more user ports
IV. Envelope Function Address (EFA)
It refers to a 13-bit number, ranging from 0 to 8191 (decimal).An EFA uniquely identifies one of the five V5.2 protocols, or an ISDN agent attached to an AN. Table 5-69 contains the possible values for an EFA.
Table 5-69 Corresponding relations between EFA values and protocols
Value Protocol
0–8175 ISDN_PROTOCOL
8176 PSTN_PROTOCOL
8177 CONTROL_PROTOCOL
8178 BCC_PROTOCOL
8179 PROT_PROTOCOL
8180 LINK_CONTROL_PROTOCOL
8181–8191 RESERVED
V. Logical Communication Channel (Logical C-Channel)
It refers to a group of one or more C-paths, all of different types, but excluding the C-path for the protection protocol.
VI. Multi-Link
It refers to a collection of more than one 2048 kbit/s link which together make up a V5.2 interface.
It refers to a group of more than one 64 kbit/s channels providing 8 kHz and time slot sequence integrity, generally used together within an ISDN Primary Rate Access (ISDN-PRA) user port, in order to supply a higher bit-rate service.
VIII. Physical Communication Channel (Physical C-Channel)
It refers to a 64 kbit/s time slot on a V5.2 interface which has been assigned for carrying logical C-channels. A physical C-channel may not be used for carrying bearer channels.
IX. Primary Link
It refers to a 2048 kbit/s (E1) link in a multi-link V5.2 interface whose physical C-channel in time slot 16 carries a C-path for the protection protocol and, on V5.2 initialization, also the C-path for the control protocol, link control protocol, and the BCC protocol. Other C-paths may also be carried in the time slot 16.
X. Secondary Link
It refers to a 2048 kbit/s (E1) link in a multi-link V5.2 interface whose time slot 16 carries a C-path for the protection protocol, and, on V5.2 initialization, acts as the standby C-channel for the control protocol, link control protocol, and BCC protocol and any other C-paths initially carried in time slot 16 of the primary link.
XI. Layer 1 Functional State Machine (L1 FSM)
It refers to the Functional State Machine in V5 System Management that tracks and controls the states of the physical E1 links on the interface. The L1 FSM is located on the SG.
5.6.3 V5UA Functions
I. Client/Server Model
An SG and MGC communicating through V5UA adopts the client/server peer mode. When the MGC is set to server, the SG is mandatorily set to client. When the MGC is set to client, the SG is mandatorily set to server. Normally, the MGC (SoftX3000) is set to client.
The SCTP registered User Port Number Assignment for V5UA is 5675.
It is recommended that one SCTP stream be used for BCC, Link Control, Control and PSTN protocol on a specific C-channel. It is recommended to use a separate SCTP stream for Protection protocol on a specific C-channel. It is also recommended to use one SCTP stream for all ISDN user ports on a specific C-channel. One single stream should not be used to carry data of more than one C-channel. In addition, it is recommended that one separate SCTP stream be used for all MPH (link related) messages.
5.6.4 Structure of V5UA Protocol Stack
Figure 5-125 shows the V5UA protocol stack.
I P
SCTP
V5UA
V5.2
LM
Figure 5-125 Structure of V5UA protocol stack
5.6.5 Definition of V5UA Boundaries
Table 5-70 lists the boundary primitives defined by V5UA.
Table 5-70 V5UA boundary primitives
Boundary primitive Description
MDL ESTABLISH Request It is used to request the outcome of the procedures for establishing multiple frame operation.
MDL ESTABLISH confirm It is used to confirm the outcome of the procedures for establishing multiple frame operation.
MDL ESTABLISH indication It is used to indicate the outcome of the procedures for establishing multiple frame operation.
MDL RELEASE request It is used to request the outcome of the procedures for terminating multiple frame operation.
MDL RELEASE confirm It is used to confirm the outcome of the procedures for terminating multiple frame operation.
MDL RELEASE indication It is used to indicate the outcome of the procedures for terminating multiple frame operation.
It is used by V5 system management to request to take the link in service for use on a V5 interface. On reception of this message L1 FSM on the SG shall also start reporting the status of the V5 link to the GWC. The use of this primitive is similar to that of the MPH-Processed primitive defined by V5.2. However, this primitive has more extended meanings than the MPH-Processed primitive.
MPH-LINK Status Stop Reporting
It is used by V5 system management to request to take the link out of service for use on a V5 interface. On reception of this message L1 FSM on the SG shall also stop reporting the status of the V5 link to the GWC. The use of this primitive is similar to that of the MPH-Stop primitive defined by V5.2. However, this primitive has more extended meanings than the MPH-Stop primitive.
MPH-LINK Status Indication
It is used by L1 FSM on the Signaling Gateway to report the status (operational/non-operational) of a V5 link to V5 system management. This primitive equals the MPH-AI and MPH-DI primitives in V5.2.
MPH-SA-BIT SET
It is used by system management to request that the L1 FSM in the SG sets or resets the value of a specified Sa bit on the requested link, or to report the successful setting or resetting of this bit back to system management. For V5 this message will be used for the Link Identification procedure to set/reset the value of the Sa7 bit.
MPH-SA-BIT Status
They are used between system management in the MGC and L1 FSM in the SG to request reporting of the status of a specified Sa bit on the requested link, or to report (indicate) the status of this bit back to system management. For V5 these messages will be used for the Link identification procedure to request or report the status of the Sa7 bit.
MDL-ERROR Indication
It is used to indicate an error condition to V5 System Management. The only valid reason for this primitive is 'Overload', indicating an overload condition of the C-channel on the SG.
5.6.6 Implementation of V5UA
Figure 5-126 shows a typical implementation of V5UA in an NGN solution.
The common message header contains the [Version], [Spare], [Message Class], [Message Type], and [Message Length] fields. The message header part applies to all signaling protocol adaptation layer messages.
Version
The version field contains the version of the V5UA adaptation layer. The currently supported version number is 0000 0001, which means version 1.0.
Spare
The length of the spare field is eight bits. This field SHOULD be set to all '0's and ignored by the receiver.
Table 5-72 V5 boundary primitives transport messages (V5PTM)
Value Message type Description
00 Reserved -
01 Data Request
It is sent by the MGC and contains an ISDN Q.921 user protocol data unit (PDU). An PDU corresponds to a confirmed information transmission service.
02 Data Indication It is sent by the SG to indicate that the peer IUA has successfully processed a received Data Request message.
03 Unit Data Request
It is sent by the MGC and contains an ISDN Q.921 user protocol data unit (PDU). An PDU corresponds to an unconfirmed information transmission service.
04 Unit Data IndicationIt is sent by the SG to indicate that the peer IUA has successfully processed a received Unit Data Request message.
05 Establish Request
It is sent by the MGC to establish a data link on a signaling channel or confirms that a data link has been established on a signaling channel. MGC controls the status of channel D. When MGC expects channel D to be in the service operation state, it sends an Establish Request message.
06 Establish Confirm SG sends an Establish Confirm message to confirm an Establish Request message.
07 Establish IndicationSG sends an Establish Indication message to indicate that a data link has been established in a signaling channel.
08 Release Request MGC sends a Release Request message to release the data link on the signaling channel.
09 Release Confirm SG sends a Release Confirm message to respond to a Release Request message
0A Release Indication SG sends a Release Indication message to indicate that a data link has been released on a signaling channel.
0B Link Status Start Reporting
MGC sends a Link Status Start Reporting message, which is used between V5 System Management on the MGC and the L1 FSM on the SG to track the status of a particular E1 link. This is required regardless of whether or not the E1 link carries C-channels.
0C Link Status Stop Reporting
MGC sends a Link Status Stop Reporting message, which is used between V5 System Management on the MGC and the L1 FSM on the SG to stop tracking the status of a particular E1 link.
SG sends a Link Status Indication message, which is used between V5 System Management on the MGC and the L1 FSM on the SG.
0E Sa-Bit Set Request
SGC sends a Sa-Bit Set Request message, which is used between V5 System Management in the MGC and the L1 FSM in the SG to set the status of Sa bits on the E1 links.
0F Sa-Bit Set Confirm SG sends a Sa-Bit Set Confirm message to return the status of Sa bits on the E1 links.
10 Sa-Bit Status Request
SGC sends a Sa-Bit Status Request message, which is used between V5 System Management in the MGC and the L1 FSM in the SG to obtain and read the status of Sa bits on theE1 links.
11 Sa-Bit Status Indication
SG sends a Sa-Bit Status Indication message to return the status of Sa bits on the E1 links.
12 Error Indication
SG sends an Error Indication message, which is used between the V5 stack on the SG and the V5 System Management in the MGC to indicate an error condition of the SG.
0B-7F Reserved by the IETF -
80-FF Reserved for IETF-defined V5PTM extensions
-
Table 5-73 V5UA application server process state maintenance (ASPSM) messages
Value Message type Description
00 Reserved -
01 ASP Up (UP) ASP sends an ASP Up (UP) message to SG to indicate that ASP is ready to receive services or maintain messages.
02 ASP Down (DOWN)ASP sends an ASP Down (DOWN) message to SG to indicate that ASP is not ready to receive services or maintain messages.
03 Heartbeat (BEAT) It is optionally used to ensure that the V5UA peers are still available to each other.
04 ASP Up Ack (UP ACK)
It is used to acknowledge an ASP Up message received from a remote V5UA peer.
05 ASP Down Ack (DOWN ACK)
It is used to acknowledge an ASP Down message received from a remote V5UA peer.
It is sent in response to a Heartbeat message. An V5UA peer must send a Heartbeat Ack message in response to a Heartbeat message. The Heartbeat Ack message includes all the parameters of the received Heartbeat message, without any change.
07-7F Reserved by the IETF -
80-FF Reserved for IETF-defined ASPSM extensions
-
Table 5-74 V5UA application server process traffic maintenance (ASPTM) messages
Value Message type Description
00 Reserved -
01 ASP Active (ACTIVE) It is sent by an ASP to indicate to an SGP that it is active and ready to be used.
02 ASP Inactive (INACTIVE) It is sent by an ASP to indicate to an SG that it is no longer an active ASP.
03 ASP Active Ack (ACTIVE ACK)
It is used to respond to an ASP Active message received from a remote V5UA.
04 ASP Inactive Ack (INACTIVE ACK)
It is used to acknowledge an ASP Inactive message received from a remote V5UA peer.
05-7F Reserved by the IETF -
80-FF Reserved for IETF-defined ASPTM extensions -
Table 5-75 V5UA management (MGMT) messages
Value Message type Description
00 ERROR
It is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
01 Notify (NTFY) It is used to provide the automatic indication of an V5UA event to the IUA peer.
02 TEI Status Request It is interchanged between peers of V5UA layer to request the status of a specific TEI.
03 TEI Status Confirm It is interchanged between peers of V5UA layer to confirm the status of a specific TEI.
04 TEI Status Indication
It is interchanged between peers of V5UA layer to indicate the status of a specific TEI.
05-7F Reserved by the IETF -
80-FF Reserved for IETF-defined MGMT extensions
-
2) Message Length
The message length field defines the length of the message in octets, including the header.
III. Format of Variable-Length Parameter
V5UA messages consist of a common header followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameters contained in a message are defined in a tag-length-value format.
A variable-length parameter consists of the [Parameter Tag], [Parameter Length], and [Parameter Value] fields.
Parameter Tag
The [Parameter Tag] field is a 16-bit identifier of the type of parameter.
Parameter Length
The [Parameter Length] field must be a multiple of four bytes. If it is not a multiple of four bytes, the sender pads with all zero bytes after the [Parameter Value] field. The [Parameter Length] must not be padded with all zero bytes. A sender must not pad with more than three bytes. The receiver must ignore the padding bytes.
Parameter Value
The [Parameter Value] has a variable length. It contains the actual information to be transferred in the parameter.
IV. Format of V5UA Message Header
In addition to the common message header, there will be a specific message header for V5UA messages. The V5UA message header will immediately follow the common header in these messages. However, it is used only in QPTM, Error Indication, and all MGMT messages containing Sa.
As shown in Figure 5-128, for the V5 extension of the IUA Message Header, the [Envelope Function Address (EFA)] field is included in the [Spare] field in addition to the integer-formatted interface identifier and DLCI.
For details of DLCI, refer to 5.5.8 IV “Format of IUA Message Header".
EFA
EFA is defined in the V5 standard. The EFA identifies a C-path, which is a 13-bit number, ranging from 0 to 8191 (decimal). As shown in Table 5-68, an EFA uniquely identifies one of the five V5.2 protocols, or an ISDN agent attached to an AN.
Caution:
For MPH messages for which DLCI and EFA are not used, SAPI, TEI and EFA shall be set to ZERO and shall be ignored by the receiver. For all other messages, the DLCI shall be set as defined in the V5.2 standard.
Interface Identifier (Integer)
Figure 5-129 shows the integer-formatted interface identifier.
It refers to the identifier for an E1 link on the SG (27 bits).It must be unique on the SG. This Link Identifier MUST match the Link Identifier used in the Link Management Messages defined in this document.
Channel ID
It refers to Channel Identifier (5 bits).This is equal to the time slot number of the addressed time slot. Possible values are 15, 16 and 31 representing the possible time slots for C-channels on a V5 interface. For Link Management messages, the Channel ID must be set to 0.
The text formatted interface identifier shall be coded as the hex representation of the integer formatted interface identifier, written as a variable length string.
V. Link Status Messages (Start Reporting, Stop Reporting, Indication)
All Link Status Messages contain the V5UA Message Header. The Link Identifier portion of the Interface Identifier identifies the physical link on the SG addressed by the message. For all link status messages, the Channel ID shall be set to '0' and shall be ignored by the receiver.
The integer value used for the Link Identifier is of local significance only, coordinated between the SG and MGC. It has to be unique for every V5 link on the SG.
The Link Status Indication Message contains the common message header followed by the V5UA message header. In addition it contains the parameter as shown in Figure 5-130.
Parameter tag=0x11 Parameter length
Link Status
0 15 31
Figure 5-130 Parameter of Link Status Indication message
The valid values for Link Status are shown in the Table 5-76.
Figure 5-132 Additional parameter of Error Indication message
[Error Reason] has only one value, that is, 0x01, whose definition is Overload. It means that a C-channel is not able to process all Layer 3 messages on this C-channel in a timely manner (overload condition of the C-channel).
5.6.8 Basic Signaling Procedures of V5UA
I. Link Identification Procedure Initiated by the MGC Through V5UA
Figure 5-133 shows a link identification procedure initiated by the MGC through V5UA. An active association between ASP and SG is established prior to the following message flow, and the V5 interface is already activated.
ASP SGData Request (LnkCtrl:FE-IDReq)
Data Indication (LnkCtrl ACK:FE-IDReq)
Data Indication(LnkCtrl:FE-IDAck)
Data Request (LnkCtrl ACK:FE-IDAck)
Sa_BIT Status Request (Sa7)
Sa_BIT Status Indication(Sa7,ZERO)
Data Request (LnkCtrl:FE-IDRel)
Data Indication (LnkCtrl ACK:FE-IDRel)
Figure 5-133 Link identification procedure initiated by the MGC through V5UA
II. Link Identification Procedure Initiated by the AN Through V5UA
Figure 5-134 shows a link identification procedure initiated by the AN through V5UA. An active association between ASP and SG is established prior to the following messages flow, and the V5 interface is already activated.
Signaling system No.7 (SS7) is made by International Telephone and Telegraph Consultative Committee (CCITT). SS7 is an international standard common channel signaling, which features high-speed transmission, potentiality of providing a great number of signals, powerful functions, flexibility and reliability. It can meet the signaling requirements of public switched telephone network (PSTN), global system for mobile communications (GSM), and intelligent network (IN).
Functional structure of the SS7 in the NGN is shown in Figure 6-1.
MACMTP1
MTP2
MTP3
SCCP
TCAP
TUP
ISUP
M3UA
IP
INAP
User part
Message transfer part
M2UASCTP
Figure 6-1 Functional structure of the SS7 in the NGN application
From the above figure, it can be seen that SS7 is divided into two parts: user part (UP) and message transfer part (MTP).
Common MTP: It is to transfer signaling messages between various user functions reliably. The SS7 can be transmitted through TDM or IP network (The protocol is M2UA/M3UA).
Independent user part applicable to different users: It is a functional entity which makes use of the transmission capability of the MTP, including ISDN user part (ISUP) and IN application part (INAP).
MTP is used to transmit signaling messages of various UPs (such as TUP, DUP, and ISUP) in SS7 system. Its design complies with the ITU-TQ.701-710 recommendations.
The MTP provides reliable signaling message transmission. It takes measures to avoid message loss, repetition, and out-of-sequence in case of the signaling network failure. The MTP includes the functional levels of signaling data link (MTP1), signaling link (MTP2) and signaling network (MTP3).
I. MTP1
The signaling data link function is the Level 1 function (MTP1) of MTP. MTP1 defines the physical, electrical and functional features of a signaling data link and the means to access the data link. It is equivalent to the physical layer of open system interconnection (OSI)’s seven-layer model, which is to generate and receive signals over physical channels.
One signaling data link is composed of two data channels operating at the same data transmission rate and in two opposite directions. The bit rate of digital message carrier is 64 kbit/s. It is applicable to transmission links of both lower rate (such as 4.8 kbit/s) and higher rate (such as 2048 kbit/s).
II. MTP2
The signaling link function is the Level 2 function (MTP2) of MTP. It provides reliable signaling links for transmitting signaling messages to signaling data links between two directly connected SPs together with Level 1.
Signaling link function can be divided into eight parts:
Demarcation of signal units; Location of signal units; Error detection; Error correction; Initial alignment; Processor faults; Flow control in Level 2; Monitoring of signaling link error rate.
III. MTP3
The network layer is the Level 3 (MTP3) of MTP. It transmits management messages between two SPs to ensure the reliable transmission of various signaling messages in case of the failure of signaling links or STPs. It is equivalent to the third layer (network layer) of the OSI model.
The signaling network function provided by the MTP3 must ensure the reliable transmission of signaling messages between SPs in case of the failure of signaling links or STPs. Therefore, this function includes functions and procedures required in notifying the remote end of fault results and the configuration function and procedure required in message routing in the signaling network.
The signaling network function is divided into signaling message processing and signaling network management, as shown in Figure 6-2.
Message distribution
Signaling message processingMessage
discrimination
Message routing
Outgoing
Incoming
Signaling traffic management
Signaling network management
Signaling route management
Signaling link management
Signaling network functionLevel 4 Level 3 message transfer part Level 2
Test and maintenance
Signaling message stream---- Indication and control
Figure 6-2 Signaling network function
2) Signaling message processing
The signaling message processing function is to ensure the signaling messages initiated by a specific UP of a signaling point (SP) to be transmitted to the same UP of the DSP designated by this UP.
The signaling message processing function is divided into three parts.
Message routing function determines the outgoing signaling links through which messages are transmitted to destinations from every SP.
Message discrimination function is used to identify whether the DSP that receives a message is the local SP. If the local SP is not the DSP and is capable of transferring, the message routing function will be enabled to transfer the message.
Message distribution function distributes received signaling messages to corresponding UPs by every SP.
When a signaling link or SP is faulty, signaling network management function provides the reconfiguration capability of the network. When congestion occurs, it can control signaling traffic. The reconfiguration capability is to change the routing, bypass faulty links or faulty SPs of the signaling service through proper procedures. In some cases, you must activate and align new signaling links to restore signaling traffic required between two SPs. When faulty links or SPs are restored, the opposite activities and procedures are used to rebuild the normal configuration of the signaling network.
The signaling network management consists of signaling traffic management, signaling link management and signaling route management.
When the status of a signaling link, route or SP is changed, the above three management functions can be activated under proper situations. The following describes specific contents.
Signaling traffic management: It is to transmit signaling traffic from one link or route to multiple links or routes. It can restart MTP of an SP or slow down signaling traffic temporarily in case of congestion.
Signaling link management: It is to restore faulty signaling links, to activate those links that are not arranged, and to deactivate arranged signaling links.
Signaling route management: It distributes the status information of the signaling network to block or unblock signaling routes.
RST Signaling-route-set-test signal for prohibited destination
RSR Signaling-route-set-test signal for restricted destination (national option)
MIM Management inhibit messages
LIN Link inhibit signal
LUN Link uninhibited signal
LIA Link inhibit acknowledgement signal
LUA Link uninhibited acknowledgement signal
LID Link inhibit denied signal
LFU Link forced uninhibited signal
LLT Link local inhibit test signal
LRT Link remote inhibit test signal
TRM Traffic-restart-allowed message
TRA Traffic-restart-allowed signal
DLM Signaling-data-link-connection-order message
DLC Signaling-data-link-connection-order signal
CSS Connection-successful signal
CNS Connection-not-successful signal
CNP Connection-not-possible signal
UFC User part flow control messages
UPU User part unavailable signal
II. Message Structure
To meet the requirements of signaling message transmission through the MTP, three basic signaling unit formats are stipulated: message signaling unit (MSU), link status signaling unit (LSSU) and fill-in signaling unit (FISU).
MSU is to transmit messges of various UPs, management messages, and test and maintenance messges.
LSSU is to provide link status information so as to connect and restore signaling links.
FISU is to maintain the normal running of signaling links and play a fill-in part when no message signaling or link status signaling unit is transmitted.
Message unit structure is shown in Figure 6-3.
MSU F CK SIF SIO LI FIB FSN BIB BSN F
8 16 8N(N ≥2) 8 2 6 1 7 1 7 8
Format of message signaling unit
Bit sent firstly
LSS U F CK SF LI FIB FSN BIB BSN F
8 16 8 or 16 2 6 1 7 1 7 8
Format of link status signaling unit
Bit sent firstly
FISU F CK LI FIB FSN BIB BSN F
8 16 2 6 1 7 1 7 8
Format of fill-in signaling unit
Bit sent firstly
MSU F CK SIF SIO LI FIB FSN BIB BSN F
8 16 8N(N ≥2) 8 2 6 1 7 1 7 8
Format of message signaling unit
Bit sent firstly
LSS U F CK SF LI FIB FSN BIB BSN F
8 16 8 or 16 2 6 1 7 1 7 8
Format of link status signaling unit
Bit sent firstly
FISU F CK LI FIB FSN BIB BSN F
8 16 2 6 1 7 1 7 8
Format of fill-in signaling unit
Bit sent firstly
Figure 6-3 Message unit format
Structurally, signaling unit is divided into two parts. One is the mantatory part of MTP part processing occupied by various signaling units, which consists of eight fixed-length fields. The other is the signaling message part of user part processing.
2) Mantatory Part of MTP Processing
This part includes flag (F), forward sequence number (FSN), forward indicator bit (FIB), backward sequence number (BSN), backward indicator bit (BIB), length indicator (LI), check bit (CK), status field (SF) and service information octet (SIO).
Flag
Flag is also called delimiter. There is a flag at both the start and the end of every signaling unit. During the transimission of signaling units, every flag indicates the end of the last signaling unit and the start of the next one. Therefore, in the delimitation identification of signaling units, a signaling unit is identified by two flags of the start and the end in the information flow.
The pattern for a flag is 8-bit binary code 01111110.
In addition to the delimitation function, some flags can be inserted between signaling units in case of overload of signaling links to reduce load.
FSN
FSN indicates the sequence number of the transmitted MSU and consists of 7 bits. At the transmitting end, every transmitted MSU is allocated with a FSN. FSNs are numbered in a cyclic sequence ranging from 0 to 127 At the receiving end, the FSNs in
the received MSUs are used to check the sequence of the MSUs, which is a part of the confirmation function. When retransmission is necessary, it is also used to identify the signal units to be retransmitted. The FSN of FISU or LSSU uses the FSN of the MSU transmitted last time, instead of being assigned with new sequence numbers.
FIB
It occupies one bit. FIB is used in the retransmission process of MSUs. In the normal operation, FIB has the same state with that of the received BIB. Retransmission is requested if the received BIB changes its value. Upon retransmitting MSUs, the signaling terminal will also change the value of FIB (from "1" to "0" or from "0" to "1" ), so that it is consistent with BIB again until BIB changes its value again when there is another retransmission request.
BSN
The BSN is the sequence number of the confirmed (that is, received correctly) MSUs being sent back to the transmitting end by the receiving end.
If retransmission is requested, BSN indicates the sequence number of the unit to be retransmitted.
In the operation of a signaling network, the transmitting end and receiving end set their FSN independently.
For transmitted and unconfirmed signaling units, the limit value of FSN and BSN is 127.
BIB
BIB is used to initiate a retransmission request for a wrong signaling unit received. If an MSU received is correct, its BIB value remains unchanged when a new signaling unit is sent. If a wrong MSU is received, the bit will be reversed (that is, from "0" to "1" or from "1" to "0") and sent, requesting the opposite end to send a correct MSU.
LI
LI is used to indicate the number of octets following the length indicator octet and preceding the check bit (CK) so as to distinguish three types of signaling units.
LI is a number in binary code in the range 0–63 (decimal numeral). The field of LI is 6 bits.
The LIs of the three types of signaling units are as follows:
Length indicator LI=0 Fill-in signaling unit
Length indicator LI=1 or 2 Link status signaling unit
Length indicator LI> 2: Message signaling unit
In a signaling network, if the signaling information field of an MSU is more than 62 octets, the length indicator is set to 63. However, if the LI is 63, the maximum length indicated must not exceed 272 octets.
Note that the numbers of bits and octets between two flags of a signaling unit have to be calculated frequently in the receiving and processing of signaling units. The CCITT
regulates that the number of bits between two flags of a signaling unit must be an integral number of octets. The number of octets can be "0" (if only the flag is transmitted) or 5 (for FISU). The number can also be less than or equal to m+7 octets (m is equal to 272). If the number is beyond the range, it is regarded that there is a signaling unit error.
CK
The field is used for error detection of signaling units. It consists of 16 bits.
The seven fields above mentioned are available in all the three kinds of signaling units. (Eight fields including end F have been discussed). They are mandatory for every signaling unit.
SF
Status field is unique to each LSSU, which indicates the statuses of signaling links.
The length of SF can be an octect (8-bit) or two octects (16-bit).
When it is an octect, the lower 3 bits indicates link statuses. The meanings are shown in Table 6-2.
Table 6-2 Meanings of SF status indication
CBA Identifier Indication Meaning
000 SIO Status indication “O” Out of location
001 SIN Status indication “N” Normal location
010 SIE Status indication “E” Emergency location
011 SIOS Status indication “OS” Out of service
100 SIOP Status indication “OP” Processor outage
101 ISB Status indication “EB” Busy
SIO
The field of SIO is unique to MSUs. It consists of SI and SSF, as shown in Figure 6-4.
The field has 8 bits. SI and SSF occupy 4 bits respectively.
Signaling network management messageSignaling network test and maintenance messageReservedSignaling connection control partTelephone subscriber partISUP
Signaling network management messageSignaling network test and maintenance messageReservedSignaling connection control partTelephone subscriber partISUP
SI indicates to which user part the transmitted message belongs. In the MTP of a signaling network, the message processing function distributes a message to the user part indicated by SI.
SI is coded as Figure 6-4. The capacity of SI allows it to represent messages of16 kinds of UPs. This diagram only lists those that are frequently used.
4) SSF
ISSF consists of 4 bits, of which the higher two bits act as the network indicator, and the lower two bits, coded 00, are reserved presently.
The network indicator serves to distinguish the network attribute of the transmitted message, that is, to distinguish between an international signaling network message and a national signaling network message. Figure 6-4 illustrates the codes and network allocation of SSF.
According to CCITT stipulations, the use of the reserved codes in SSF is determined by the domestic signaling network conditions in different countries.
5) Signaling Information Part Processed by User Part
Signaling information part processed by user parts is the SIF in the format of MSU. SIF is unique to MSUs. It consists of message addressing tag, user signaling information heading and user signaling information.
Tag includes the information required in sending messages to the destination. Standard routing tag has 32 bits, which is at the beginning of SIF. The tag includes destination point code (DPC), originating point code (OPC) and SLS.
Signaling point code is a digital address, which identifies every signaling point in the No.7 singnaling network uniquely. When the DPC in a message represents the receiving sigaling point, the message is distributed to the correponding user part (such as ISUP or SCCP) in the SIO as indicated by the service indicator.
The SLS ensures the sequencing of messages. Any two messages sent with the same SLS always arrive at the destination in the same sequence as that in which they are sent. Equal traffic load can be shared among all available links. If a user part regulary sends messages and distributes the SLS value cyclically, all the service levels to the destination should be equal. There are four types of tag structures, as shown in Figure 6-5.
Type A MTP management message
Type B TUP message
Type C ISUP message
Type D SCCP message
Since TCAP messages must be sent through SCCP, TCAP messages belong to the type of SCCP messages, that is, type D.
F CK SIF FIBLI FSNSIO BIB BSN
Management message SLC OPC DPC Type A: MTP management message
Signaling messageCIC
OPC DPC Type B: TUP messageSLS
Signaling message OPC DPC Type C: ISUP messageCIC SLC
F
SCCP user data SLS OPC DPC Type D: SCCP message
F CK SIF FIBLI FSNSIO BIB BSN
Management message SLC OPC DPC Type A: MTP management message
Signaling messageCIC
OPC DPC Type B: TUP messageSLS
Signaling message OPC DPC Type C: ISUP messageCIC SLC
F
SCCP user data SLS OPC DPC Type D: SCCP message
Figure 6-5 Four types of tag structures
Label
It is the field immediately following the tag field. It is composed of H1 and H0, occupies 4 bits respectively, and indicates the group and type of messages. For example, H0= 0001 and H1=0001 in a telephone user part (TUP) message mean that the transmitted message is an initial address message (IAM); H0=0001 and H1=0100 mean that the transmitted message is an address complete message (ACM). For signaling network
management messages, if both H0=0001 and H1=0001, it means that the transmitted message is changeover order signaling (COO); if H0=0001 and H1=0100, it mean that it is a transmission forbidden message. Since both H1 and H0 occupy 4 bits, a certain user message can accommodate 256 messages.
Signaling message
Signaling message part is also called service message part. This part can be further divided into several sub-fields. These sub-fields may be mandatory or optional, and meanwhile they may be of fixed length or variable length so as to meet the needs of various functions and expansion. Thus the SMU is adaptable to different user messages with different features, so that these various user messages can be transmitted through common channels.
For specific format and codes of SIF, refer to the descriptions of codes and format of user messages.
MTP
The fields F, BSN, BIB, FSN, FIB, LI and CK in a signaling unit are mainly used for the sending and receiving sequence, error detection and correction of signaling message units. These fields are analyzed and processed in the second function level of a signaling network, that is, signaling link level. FISU is mainly composed of those fields with transmission control function. It has the function to "fill-in" in the signaling link, and therefore the signaling unit of this type is generated and processed by the second function level.
LSSU is used to transmit the status indication information of a signaling link. It is also generated and processed on the second function level. The second function level may generate and transmit corresponding status signaling units according to instructions from the third level or its judgement, or receive and process the signaling link status indication sent by the opposite end. If necessary, it reports such statuses as congestion and processor error to the third level.
The MSUs transmitted in a signaling network fall into three types according to their roles in the network: MSU used for signaling network management (MSU-SNM), MSU used for signaling network test and maintenance (MSN-SNT), and MSU generated by the user part (MSU-UP). The first two types are of type A structure, which are transmitted between MTPs. They are generated and processed by Level 3. The third type consists of messages of type B, C and D structures. These messages are transmitted through the MTP to a specific UP. Level 3 analyzes its message tag, and determines the message destination; while the generation and processing of its service message part (SIF) are performed in Level 4, that is, the user part.
The most important message in the MTP layer is the signaling network management message. The following introduces the general format of the signaling network management message.
In the signaling network, the signaling network management message is identified by the SI bit “S1=10000” of the SIO in the signaling unit.
As one kind of message signaling unit, the signaling information of the signaling network management message is transferred by the SIF. The Figure 6-6 shows the structure of the signaling management message.
Managementinformation H1
8n(n≥0)
4
H 0
4 4
SLC
4
OPC
24/14
DPC
24/14
Bit sent firstlyManagementinformation H1
8n(n≥0)
4
H 0
4 4
SLC
4
OPC
24/14
DPC
24/14
Bit sent firstly
Figure 6-6 General format of the signaling network management message
Tag
The tag comprises three parts: DPC, OPC, and SLC.
The DPC and OPC are the same as those described above.
The SLC refers to the signaling link code that connects the DSP and the originating signaling point (OSP). If transferred messages are not related to the signaling link or another special code is not specified, the SLC is “0000”. Currently a four-bit code is used. The standby four-bit code is “0000”.
Heading code
The heading code comprises two four-code bits: H0 and H1.
H0 identifies a management message group, and H1_determines the messages in a message group. Since H0 and H1 both have four codes, the total message capacity is up to 256 types. That is, there can be 16 message groups, and each group has 16 types of messages. At present only some of the message types are used. Refer to Table 6-3.
The heading code H1 contains a signaling code, as shown beblow:
D C B A
0 1 0 1 TFA
III. Signaling Procedure
1) Message routing
The message routing function is based on the information contained in the routing tag, that is, the information on DPC and SLC field.
Each signaling point has routing information which determines the signaling link. Messages are sent in the siganaling link according to the DPC and SLS field.
Typically, the DPC is associated with more than one signaling links which are used to bear messages. A specific signaling link is selected through the SLS field, thus realizing load sharing.
Two basic exmples of load sharing:
Load sharing among links in the same link group. Load sharing among links not in the same link group.
Any SLC can be allocated to messages unrelated to the signaling link so that the messages can be load-shared. The other way is to allocate the default SLC, such as “0000” to these messages. The messages route according to the normal routing function. In this function, the SLC is used as the SLS to realize load sharing.
2) Switchover
The switchover program ensures that the signaling services borne on unavailable links are switched over to alternative signaling links as soon as possible. It also avoids message loss, repetition and sequencing errors.
To implement this function, buffer updating and recovery are included in the switchover process. The process is started before the signaling link starts switching over the service. Buffer updating includes identifying all the messages in the retransmission buffer of the available signaling link. These message are not received by the remote end. Recovery includes forwarding relevant messages to the transfer buffer of the alternative link.
When one signaling link is unavailable, switchover is implemented in the signaling point. Then the following is conducted:
Terminating the sending and receiving of MSUs on relevant signaling links. Sending LSSUs or FLSUs. Determining the alternative signaling link. Running the content updating process of the re-buffer of the unavailable signaling
link. Transferring signaling services to the alternative signaling link.
3) Changback
The changback program ensures that the signaling services are transferred from alternative signaling links to available signaling links as soon as possible. It also avoids message loss, repetition and sequencing errors. Changback includes the basic program that uses opposite activities for switchover.
When a signaling link becomes available due to reconnection, recovery or unlocking, changback is implemented at the signaling point. Then the following is conducted:
Determining the alternative signaling link that forwarded normals servies in the past.
Stopping the transmitting of related services on the alternative signaling link, and storing the services in the changback buffer.
Sending a changback notification through a related alternative signaling link to the remote signaling point of the signaling link that becomes available. This message indicates that the message service on the alternative signaling link can be sent through the available signaling link.
When receiving the changback confirmation sent by the remote signaling point of the available signaling link, the relevant signaling point will restart the forwarded service on the available signaling link.
4) Activating the signaling link.
When it is decided to activate an inactive signaling link, initial alignment starts:
If initial alignment succeeds, the signaling link becomes activated and the signaling link test starts.
If the signaling link test succeeds, the link prepares to transmit signaling services. If initinal alignment fails, a new initial alignment process starts on the same
signaling link after time-out for the timer. If the signaling link test fails, start link recovery until the signaling link is activated
or conduct manual operations. 5) Recovering the signaling link.
When a signaling link fault is detected, signaling link initial alignment will occur.
If initial alignment succeeds, the signaling link test starts. If the signaling link test succeeds, the link is recovered and can be used for
If initial alignment fails, a new initial alignment process may be started on the same signaling link.
If the signaling link test fails, repeat the recovery process until the link is recovered, or intervene manually.
6) Deactivating the signaling link.
If not bearing signaling services, an active signaling link can turn inactive through the deactivating process. If a signaling link is deactivated, the signaling terminals of the signaling link exit services.
7) Signaling route management process
The purpose of signaling route management is to ensure that information is reliably exchanged between signaling points; that is, to ensure the signaling route is available.
The unavailability, restriction, and availabitity of the signaling route are implemented by the transfer-prohibited, transfer-restricted, and transfer-allowed procedures.
8) Transfer-prohibited procedure
To facilitate description, three letters are used to represent three kinds of signaling points: Y for OSP, X for DSP, and Z for signaling transfer point (STP).
When Y selects the signaling route from Z to X, Z is unavailable for Y. In this case, the TFP transfer-prohibited message is sent to Z.
When Z confirms that X is difficult to reach, the transfer-prohibited message is sent to all reachable adjacent signaling points (by broadcasting).
When Z receives a message sent to X and Z cannot forward the message, the transfer-prohibited message is sent to an adjacent signaling point and relevant messages are received at this point.
6.3 ISUP
6.3.1 Overview
I. Basic Concepts
ISUP is one kind of UPs of the No.7 public channel signaling system. It provides the signaling function required for supporting voice and non-vocie basic bearer services and supplementary services in the integrated services digital network (ISDN).
ISUP is applied to the hybrid digital/analog network, telephony network, and dedicated circuit-switched data network. ISUP meets the requirements of CCITT for international semi-automatic and automatic telephony services and circuit-switched data services.
II. Protocol stack architecture
The ISUP uses services provided by the MTP to transfer information between ISUPs. Figure 6-7 shows the protocol stack of the ISUP. ISUP information is carried to the MTP or from MTP to ISUP by primitives in the form of parameters.
Primitives used between MTP and ISUP include the transfer primitive, recovery primitive, suspension primitive, and status primitive.
The MTP transfer primitive receives and sends ISUP singaling messages by encapsulating the messages.
When MTP sends the MTP suspension primitive, it means MTP cannot send messages to a specific destination as parameters.
When MTP sends the MTP recovery primitive, it means MTP can be recovered to parameters and can send messages to a specific destination in an unrestricted manner.
When MTP sends the MTP status primitive, it means that the signaling route to a specific destination is congested or that there is no ISUP on the destination. This may be because ISUP is not installed or ISUP cannot be accessed. Other unkown factors may cause this problem too.
III. Application in NGN
ISUP has three application modes in NGN solutions, as shown in Figure 6-8, Figure 6-9 and Figure 6-10.
A MTP link goes directly from the SoftX3000 to connect a STP, thus realizing the interoperation of SS7 with a PSTN switch through an SS7 network. In the voice channel, the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN.
2) Application of ISUP in NGN (M2UA-MTP)
SoftX3000
IP MAN ISUP
TMG8010 / UMG8900
PSTN switch
M2UA
Figure 6-9 Application of ISUP in NGN (M2UA-MTP)
The SoftX3000 provides an M2UA link to connect with the TMG8010, and exchanges SS7 with a PSTN switch through the TMG8010, which has the function of an embedded signaling gateway. In the voice channel, the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN.
The SoftX3000 provides an M3UA link to connect with the SG7000, and exchanges SS7 with a PSTN switch through the SG7000. In the voice channel, the SoftX3000 controls the TMG8010 to implement the interconnection with the PSTN.
6.3.2 Singnaling Message
ISUP messages are transferred on the signaling link through the MSU. The messages are encapsulated in the SIF of the MSU. An ISUP message consists of six parts: routing tag, circuit identification code (CIC), message type code, mandatory fixed part, mandatory variable part, and optional part, as shown in Figure 6-11.
For details of the routing tag and CIC, refer to 6.2.2 Singnaling Message. The following introduces other parts of the ISUP message.
F CK SIF FIBLI FSNSIO BIB BSN
Signaling message OPC DPC ISUP messageCIC SLC
F MSU
Message typeMandatory parameter A with fixed length
Mandatory parameter F with fixed lengthPoint to parameter M
Point to parameter PPoint to star t bit of optional parameter
Length of parameter MParameter M
Length of parameter PParameter P
Code of parameter XLength of parameter X
Parameter X
Code of parameter ZLength of parameter Z
Parameter ZEnd tag of variable parameter
～～
～～
～～
～～
～～
～～
～～
～～
Mandatory parameter with fixed length
Mandatory parameter with variable length
Optional parameter
F CK SIF FIBLI FSNSIO BIB BSN
Signaling message OPC DPC ISUP messageCIC SLC
F MSU
Message typeMandatory parameter A with fixed length
Mandatory parameter F with fixed lengthPoint to parameter M
Point to parameter PPoint to star t bit of optional parameter
Length of parameter MParameter M
Length of parameter PParameter P
Code of parameter XLength of parameter X
Parameter X
Code of parameter ZLength of parameter Z
Parameter ZEnd tag of variable parameter
～～～～～～
～～～～～～
～～～～
～～～～
～～～～～～
～～～～～～
～～～～
～～～～
Mandatory parameter with fixed length
Mandatory parameter with variable length
Optional parameter
Figure 6-11 Structure of the ISUP message
I. Message Type Code
A message type code is an SIO field, which is required for all messages. The message type code defines the function and format of each kind of ISUP message. See Table 6-4.
Initial address message: A message sent in the forward direction to initiate occupancy of an outgoing circuit and to transmit number and other information relating to the routing and handling of a call.
00000010 SAM
Subsequent address message: A message that may be sent in the forward direction following an initial address message, to convey additional called number information.
00000011 INR Information request: A message sent by a switch to request information in association with a call.
00000100 INF Information: A message sent to convey information in association with a call, which may have been requested in an information request message.
00000101 COT
Continuity message: A message indicating whether or not there is continuity on the preceding circuit as well as of the selected circuit to the following switch, including verification of the communication path across the switch with the specified degree of reliability.
00000110 ACM Address complete message: A message indicating that all the address signals required for routing the call to the called party have been received.
00000111 CON
Connect message: A message indicating that all the address signals required for routing the call to the called party have been received and that the call has been answered.
00001000 FOT
Forward transfer message: A message sent in the forward direction on semi-automatic calls when the outgoing international switch operator wants the help of an operator at the incoming international switch. The message will normally serve to bring an assistance operator into the circuit if the call is automatically set up at the switch. When the call is completed through an operator at the incoming international switch, the message should preferably cause this operator to be recalled.
00001001 ANM
Answer message: it indicates that the call has been answered. In semi-automatic working, this message has a supervisory function. In automatic working, this message is used in conjunction with charging information.
00001100 REL
Release message: A message sent in either direction to indicate that the circuit is being released due to the cause supplied and is ready to be put into the idle state on receipt of the release complete message. When the call is redirected, the redirection message will also carry the redirection number.
00001110 RES Resume message: A message sent in either direction indicating that the calling or called party, after having been suspended, is reconnected.
00010000 RLC
Release complete message: A message sent in either direction in response to the receipt of a release message, or if appropriate to a reset circuit message, when the circuit concerned has been brought into the idle condition.
00010001 CCR
Continuity check request message: A message sent by a switch for a circuit on which a continuity check is to be performed, to the switch at the other end of the circuit, requesting continuity checking equipment to be attached.
00010010 RSC Reset circuit message: A message sent to release a circuit, due to memory broken or other causes.
0010011 BLO
Blocking: A message sent only for maintenance purposes to the switch at the other end of a circuit, to cause an engaged condition of that circuit for subsequent calls outgoing from that switch. When a circuit is used in the dual-circuit mode of operation, a switch receiving the blocking message must be capable of accepting incoming calls on the concerned circuit unless it has also sent a blocking message. Under certain conditions, a blocking message is also a proper response to a reset circuit message.
00010101 BLA Blocking acknowledgement: A message sent in response to a blocking message, indicating that the circuit has been blocked.
00010111 GRS Circuit group reset: A message sent to release an identified group of circuits.
00011000 CGB Circuit group blocking message: A message sent to the switch at the other end, indicating the specified circuit group has been blocked.
00011001 CGU
Circuit group unblocking: A message sent to the switch at the other end of an identified group of circuits to cause cancellation in that group of circuits of an engaged condition activated earlier by a blocking or circuit group blocking message.
00011010 CGBA
Circuit group blocking acknowledgement: A message sent in response to a circuit group blocking message to indicate that the requested group of circuits has been blocked.
00011011 CGUA
Circuit group unblocking acknowledgement: A message sent in response to a circuit group unblocking message to indicate that the requested group of circuits has been unblocked.
00011111 FAR Facility request: A message sent from a switch to another switch to request activation of a facility.
00100000 FAA Facility accepted: A message sent in response to a facility request message, indicating that the requested facility has been activated.
00100001 FRJ Facility rejected: A message sent in response to a facility request message to indicate that the facility request has been rejected.
00100100 LPA
Loop-back acknowledgement message: A message sent in the backward direction in response to a continuity check request message indicating that a loop (or transceiver in the case of a 2-wire circuit) has been connected.
00101000 PAM Pass-along message
00101001 GRA
Circuit group reset acknowledgement: A message sent in response to a circuit group reset message and indicating that the requested group of circuits has been reset. The message also indicates the maintenance blocking state of each circuit.
00101010 CQM Circuit group query message: A message sent on a routine or demand basis to request the far-end switch to give the states of all circuits in a particular range.
00101011 CQR Circuit group query response: A message sent in response to a circuit group query message to indicate the states of all circuits in a particular range.
00101100 CPG
Call progress: A message sent in either direction during the set-up or active phase of the call, indicating that an event, which is of significance, and should be relayed to the originating or terminating access, has occurred.
00101111 CFN
Confusion message: A message sent in response to any message (other than a confusion message) if the switch does not recognize the message or detects a part of the message as being unrecognized.
00110000 OLM
Overload message: A message sent in the backward direction, on non-priority calls in response to an IAM, to invoke temporary trunk blocking of the circuit concerned when the switch generating the message is subject to load control.
00110001 CRG Charging information: Information sent in either direction for accounting and/or call charging purposes.
00110010 NRM
Network resource management message: A message sent in order to modify network resources associated with a certain call. The message is sent along an established path in any phase of the call.
Facility: A message sent in either direction at any phase of the call to request an action at another switch. The message is also used to carry the results, error or rejection of a previously requested action.
00110110 IDR Identification request
00110111 IDS Identification response
00111000 SGM Segmentation message: A message that may be sent in either direction to convey an additional message segement of an extremely long message.
00011101
00011100
00011110
00100111
Reserved.
Each kind of message is composed of a message type code and several parameters. Each parameter has a name that is coded by a single octet. The length of a parameter can be fixed or variable, and each parameter has an LI, the length of which is one octet.
II. Mandatory Fixed Part
For a specified message type, those mandatory parameters with fixed lengths are contained in the mandatory fixed part. The locations, lengths and order of them are defined by the message type. In this case, the message does not include the name and LI of its parameter.
III. Mandatory Variable Part
Those mandatory parameters with variable lengths are contained in the mandatory variable part. A pointer is used to indicate the start of each parameter, and it is coded based on a single octet. The parameter name and pointer transmitting order are implicit in the message type, and the numbers of parameters and pointers are defined by the message type.
A pointer also can be used to indicate the start of an optional part. If a message type specifies that the optional part is not allowed, this pointer does not exist. If a message type specifies that there may be optional part, but this specific message does not include optional part, the pointer field is all 0.
All pointers are transmitted consecutively at the start of mandatory variable part. Each parameter includes parameter LI and contents.
Optional part is composed of parameters, which may appear or not appear in any specific message type. Parameters may be of fixed or variable lengths, and optional parameters can be transmitted in any order. Each optional parameter should contain a parameter name (one octet), a LI (one octet) and the parameter content.
"Optional parameter end" octet: If there are optional parameters, the "optional parameter end" octet will be transmitted after all optional parameters are sent out, and the octet is all 0.
6.3.3 Basic Signaling Flow
Figure 6-12 shows the call setup and release flow originated by an IP trunk media gateway. When an IP trunk media gateway originates a call, the media gateway is connected with subscribers through the circuit trunk of a circuit-switched network, and call signaling enters the SoftX3000 through an SS7 gateway.
This flow example is based on the following conventions:
The caller is controlled by MG1 and SG1. The callee is controlled by MG2 and SG2. ISUP is taken as an example of SS7. MG1 and MG2 are controlled by the same SoftX3000.
Figure 6-12 ISUP call setup and release flow originated by a trunk media gateway
1) After the caller dials the number of the callee, an IAM is sent to the SoftX3000 through SG1.
2) A context is created in MG1. TDM termination and RTP termination are added in the context. [Mode] is set to “SendReceive”. The jitter buffer and voice compression algorithm are also set. MG1 returns its RTP port number and voice compression algorithm through the Reply command.
3) A context is created in MG2. TDM termination and RTP termination are added in the context. [Mode] is set to “SendReceive”. The jitter buffer and voice compression algorithm are also set. MG2 returns its RTP port number and voice compression algorithm through the Reply command.
4) The SoftX3000 sends an IAM to the circuit-switched network through SG2. The circuit-switched network returns an ACM. The phone set of the callee rings.
5) The SoftX3000 sends the Modify command to MG1 and reports the remote RTP port number.
6) The SoftX3000 sends an ACM to SG1. 7) The callee hooks off. SG2 sends an ANM to the SoftX3000. 8) The SoftX3000 sends an ANM to SG1. 9) The callee hooks off. SG2 sends an REL to the SoftX3000. The SoftX3000 sends
an REL to SG1. 10) The SoftX3000 sends the Subtract command to MG1 and MG2.
6.4 SCCP
6.4.1 Basic Concepts
Signaling connection control part is abbreviated as SCCP. In the layered architecture of SS7, SCCP is one of the UPs. It belongs to the fourth functional group, providing additional functions for MTP at the same time so that circuit related information, non-circuit related information and other information can be transmitted between the switches and special centers of telecommunication network through SS7 network. Thus, connectionless or connection-oriented services can be created, and the third layer (network layer) of OSI layered model can be constructed.
I. Function
The purpose of SCCP is to provide the methods by which data information is transmitted in the following cases:
Connecting logic signaling in the common channel signaling network. Transferring signaling data units with logic signaling connection established or not
established.
With SCCP function, the circuit related and non circuit related signaling information of ISUP can be transmitted when peer-to-peer signaling connection is established or not established.
II. Basic Services
SCCP provides the following 4 classes of services:
Class 0: basic connectionless service Class 1: ordered connectionless service Class 2: basic connection-oriented service Class 3: flow control connection-oriented service
Classes 0 and 1 services are connectionless, and classes 2 and 3 services are connection-oriented.
The connectionless services mean that the user can transfer signaling information through signaling network without setting up signaling connections in advance. The connectionless services of SCCP are equivalent to the data service of data network.
Class 0 service do not ensure that messages can be transferred in sequence, while class 1 service can ensure that messages can be transferred to their destination in sequence by using SLS.
The connection-oriented services mean that users exchange control information between SCCPs to reach a protocol before transmitting data. The protocol contains the route through which data are transferred, the class of transferred services (whether it is basic connection-oriented class or flow control connection-oriented one), even possibly the amount of the data transferred, and so on.
The connection-oriented services of signaling can be divided into temporary signaling connection and permanent signaling connection.
Service users control the establishment of temporary signaling connection, which is similar to dialing telephone connection.
Permanent signaling connection is established and controlled by local (or remote) O&M function or by the node management function, which can provide the users with semi-permanent connection, which is similar to a leased telephone line. The connection-oriented connection described here refers to temporary signaling connection.
III. Application in SoftX3000
The SoftX3000 can interwork with SCP through IANP. As IANP needs SCCP and TCAP to transmit signaling, SCCP exists in SoftX3000 to serve as the intermediate layer for transferring messages.
SCCP messages are processed by the FCCU/FCSU in SoftX3000.
6.4.2 Singnaling Message
The SCCP message is a MSU of SS7. Its message contents lie in the SIF of MSU. An MSU is identified to be an SCCP message by the SI being 0011 in the SIO of the MSU, as shown in Figure 6-13.
The route tag in Figure 6-13 has been described in MTP section. The message type employs 8-bit coding. One code determines one SCCP message. The parameters of certain special message type that are described as mandatory and have fixed lengths must be put in the mandatory fixed part. The parameters that are mandatory but have variable lengths must be put in the mandatory variable part. Any individual message may include optional parameters. The optional parameters may be of fixed or variable lengths. If a parameter is mandatory with variable length, it is necessary to point out its position through the pointer. For optional parameters, it is necessary not only to point out their start bits but also to give their respective codes and lengths.
SCCP functions and programs, such as transmitting data signaling units with logic signaling connections established or not established, must be implemented by transmitting various kinds of SCCP messages. The SCCP messages are classified into connectionless service messages and connection-oriented service messages. Table 6-5 lists SCCP messages and their corresponding protocol classes and codes.
DT1, DT2 and ED are three kinds of messages used to transfer data after signaling connection is established successfully. Among them, DT1 is used for protocol class 2, while DT2 and ED are used for protocol class 3. In addition, DT2 and ED must be acknowledged by AK and EA.
RLSD and RLC are used to release the signaling connection after data transfer. RSR and RSC are in protocol class 3 to re-initialize the data sending sequence
numbers in the data transmitting stage. ERR is sent when any protocol error is detected, and IF is used to check whether
both ends of the signaling connection work. UDT, XUDT, UDTS, and XUDTS are connectionless service messages. UDT and
XUDT are used to transfer connectionless service data. When UDT and XUDT can not reach their destinations, UDTS and XUDTS must be sent to the originating point to show the causes if it is specified in UDT and XUDT.
II. Parameters of SCCP Message
To implement respective functions, SCCP messages must have parameters to provide all kinds of information. For example, the CR message must have the parameter [Called Address] to access the called subscriber and implement signaling connection. The ERR message must have the parameter [Error Cause] to show the causes of error. If a parameter is indispensable in a message, it is called mandatory (M) parameter for the message, and such messages include the mandatory parameter with fixed length (F) and the mandatory parameter with variable length (V). If a parameter is optional in a message, it is called an optional parameter (O). A parameter is mandatory in one message but may be optional in another message. Therefore, whether a parameter is mandatory or optional depends on the individual message.
The meanings of the parameters in Table 6-6 are as follows:
[Destination local reference] and [origin local reference] specify one signaling connection uniquely.
[Called address] and [caller address] are used to identify originating/destination signaling point and/or SCCP service access point.
[Protocol class] defines the four kinds of protocols of connectionless services and connection-oriented services.
If the length of network service data unit (NSDU) is longer than the maximum length of message for data transmitting, the NSDU must be divided into several segments to be transferred and then reassembled when they reach the destination. The parameter [segmentation/reassemble] aims to implement this function. This parameter is only used for DT1.
[Receiving No.] P(R) shows the expected next sequence number, which is used in DT2 and AK messages of protocol class 3 to confirm that the remote point has received all the messages prior to that numbered P (R) 1.
[Sorting/segmentation] is an integrated parameter, including [Segmentation/re-assembly], [Sending No.] P (S) and [Receiving No.] P (R). Here P(S) should be in the range of window value prescribed in the protocol in order to implement the flow control of protocol class 3.
[Credit] appears in CR or CC messages, determining the number of messages contained in the signaling connection transmission part. It is the window of the signaling connection, implementing flow control in protocol class 3. During the data transmission stage, the [credit] in an AK message can modify this window.
[Release cause], [Reset cause] and [Refusal cause] are used respectively to show the causes for releasing, resetting and refusing the signaling connection. [Error cause] is used to show the causes of error in ERR message. [Return cause] is used in UDTS or XUDTS message of connectionless services to point out why UDT or XUDT is unable to reach the destination.
[Data] is the network service data (NSD) that the user would send to the destination.
If the address comprises an odd number of address signaling, the filling code 0000 should be added at the end of address signaling.
2) Protocol class and return selection
The protocol class is used to define SCCP service classes. The [Protocol class] field should be used at the stage of signaling connection establishment, and the protocol class should be negotiated by both ends of SCCP.
The protocol class is a 4-bit code.
Bits 3210
0000 Protocol class 0
0001 Protocol class 1
0010 Protocol class 2
0011 Protocol class 3
When bits 0–3 codes indicate that a protocol class is the connection-oriented class (protocol classes 2 and 3), bits 4–7 are idle.
When bits 0–3 codes indicate that a protocol class is the connectionless class (protocol classes 0 and 1), bits 4–7 are encoded as follows:
Each SCCP message is made up of different parameters, including mandatory part and optional part (if any). Table 6-8 shows the corresponding parameters making up each message.
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
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.
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):
Class 1: Both success and failure are reported. Class 2: Only failure is reported. Class 3: Only success is reported. Class 4: Neither success nor failure is reported.
The operation class is decided by TC user and can be discriminated by TCAP. Each operation has only one response, which may be:
RESULT: returned upon operation success. ERROR: returned upon operation failure. REJECT: indicating that the operation can not be performed. CANCEL: indicating that operation invocation is time-out, which is meaningful only
locally.
The component part performs component processing between TC users, including temporary components. It manages components’ state machines according to different operation classes carried by the components.
2) Dialogue
The consecutive exchange of components between TC users makes up a dialogue. The components are carried to the corresponding remote TC user part through dialogue. The component sub-layer provides the dialogue function, allowing several dialogues to go simultaneously between two given TC users. Dialogues are divided into structured dialogue and unstructured dialogue. The unstructured dialogue (TC_UNI) carries components not expecting any response. The structured dialogue comprises the start process, continuing process and end process. Each dialogue is uniquely identified by its dialogue ID.
The basic process of a dialogue is as follows:
The dialogue begins (TC_BEGIN). The dialogue is acknowledged (TC_CONFIRM): The first backward continuity
indicates that the dialogue is established and can be continued. The dialogue continues (TC_CONTINUE): The TC user continues an established
dialogue, and components carried can be exchanged in the full-duplex mode.
The dialogue ends: The transmitting end neither transmits nor receives components. There are four types of dialogue ending, as shown in Table 6-14.
Table 6-14 Types of dialogue ending
Type of dialogue ending Meaning
Prearranged end (TC_END)TC users at both terminals know the ending time beforehand. The ending is only of local significance, and will not be sent to the remote terminal.
Basic end (TC_END)
The local TC user terminates the local dialogue, transmits pending components to the remote terminal, and informs the remote TC user to end the dialogue.
Abortion (TC_ABORT)
Abortion (TC_NOTICE)
The dialogue is ended immediately, all pending operations are aborted, and reasons for the abortion should be indicated.
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 4 3 2 1 0
Class Format Tag code
Class code: See Table 6-16.
Table 6-16 Meanings of class codes
Value Meaning
00 Universal
01 Application-wind
10 Context-specific
11 Private use
Element format: 0 stands for primitive and 1 for constructor.
Tag code: Its range is from 00000 to 11110. Code 11111 indicates extension. If the most significant bit (MSB) of the octet that follows is 1, it indicates that the 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.
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.
IV. 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 flagComponent portion length
Component type flagComponent length
Component portion message unit
Component
Message type flag
Message total length
Transaction portion message unit
Dialog portion message unit
Component portion flagComponent portion length
Component type flagComponent 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.
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.
SCESMS
Service control point
Database
No.7No.7
Signaling transfer pointSTPIP
SSP
Exchange PABX
Functional peripheral
No.7 No.7
User terminal
SCP
No.7
SCESMS
Service control point
Database
No.7No.7
Signaling transfer pointSTPIP
SSP
Exchange PABX
Functional peripheral
No.7 No.7
User terminal
SCP
No.7
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.
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.
III. IP
IP is the special resource to assist in the implementation of IN services. It usually possesses voice functions, such as voice synthesis, recorded announcement playing, dual-tone multifrequency dialed number receiving, voice identification, and so on. IP can be a separate physical device or serve as part of SSP. It is controlled by SCP, and executes the operations designated by SCP service logics. If IP is centralized in the network, with its functions shared by other switches, it can save investment and bring conveniences to managing voice resources, thus facilitating deployment of those services whose playing contents change frequently.
IV. SMS
SMS is responsible for managing service data and user data. Generally, it has five functions: service logic management, service data management, user data management, service monitoring, and traffic management.
V. SCE
SCE generates new service logics according to the requirements of customers, and it provides a friendly graphic editing interface for service designers. After confirming service requirements, you can use SCE to define the data related to the requirements, adopt various standard graphic elements to design the IN service logics, and then load them to SCP for system invocation.
The intelligent network is a distributed system. The functional entities (such as SCF, SSF, and SRF) in the intelligent network nodes transmit messages to one another to mutually complete IN services. ITU-T uses a kind of higher layer communication protocol, that is, the standard interface protocol for intelligent network: intelligent network application protocol (INAP), to define the information streams between the functional entities of the intelligent network. This interface protocol is put forward in ITU-T Q.12XY (Q.1208, A.1218 and Q.1228) recommendations, in which the information streams among SSF, SCF, SRF, SDF and call unrelated service function (CUSF, only in Q.1228) are described in detail. Meanwhile, the operation procedures that all functional entities should comply with after they receive information streams are also prescribed.
SoftX3000 supports intelligent network application. In the intelligent network architecture, SoftX3000 serves as SSP, which communicates with SCP through IANP.
INAP is one of SS7 UPs, and it is closely related with TCAP. INAP transmits standard information streams of the intelligent network by means of invoking TCAP primitives. The INAP messages can be transported over narrowband TDM link through MTP, and also can be transported over IP network through SIGTRAN.
INAP messages are processed by the FCCU/FCSU of SoftX3000.
6.6.2 Singnaling Message
I. INAP Message Structure
INAP is a kind of remote operation service element (ROSE) user procedure, which is contained in the TCAP component sub-layer for transmission. The application protocol data unit (APDU) of ROSE serves as unit data (UDT), which are transmitted in SS7, and class 0 service (basic connectionless service) of SCCP is adopted.
INAP is described by Abstract Syntax Notation-1 (ASN.1) of ITU-T Q.681, Q.682, and Q.690 recommendations.
For the INAP message structure, see the SCCP message structure.
II. INAP Operations and Classes
There are four classes of INAP operations:
Class 1: Both success and failure are reported. Class 2: Only failure is reported. Class 3: Only success is reported. Class 4: Neither success nor failure is reported.
In the INAP procedure, 36 kinds of operations are adopted in CS-1 phase according to the requirement of services. Table 6-23 lists the operations in CS-1 phase and their corresponding information streams.
Table 6-23 INAP operations and classes
Information stream Operation Class
Activate Service Filtering Same 1
Activity Test Same 3
Activity Test Response Return Result from Activity Test 3
SoftX3000 supports multiple IN services and generates other services as required. The INAP message process between SoftX3000 (SSP) and SCP is related to specific services.
I. 800 Service Process
The 800 service is a freephone service. As the number 800××××××× serves as the access code of this service, this service is usually called 800 service. An 800 number is allocated to each subscriber who applies for this service, and the caller who dials the number needs not to pay. Figure 6-22 shows the process of making an 800 call by an ordinary subscriber.
Ringing
SCP
SSP
0755-6540808
IP 0755-6540808
No.7
No.7
(1)
(2)(3)
(4)
8008101234
Database
Figure 6-22 800 service diagram
1) The caller dials the 800 service number. 2) SSP collects the 800 number and reports it to SCP. 3) SCP queries the code translation table, translates the number into an ordinary
phone number (real called number), and sends connection instruction (to connect with the real called number) and charging instruction (to charge the callee) to SSP. SSP is responsible for notifying the callee to ring, and completing connection between the caller and the callee as well as charging.
II. Flow in Which User MG Originates IN Call
The 800 service is taken to illustrate the flow.
This flow example is based on the following conventions:
The user MG originates a call. That is, the MG directly connects the user, and the user originates a corresponding call.
The caller is connected with MG1, and the caller dials the 800 service number. The callee corresponding to the translated 800 service number is conncected with
MG2. MG1 and MG2 are controlled by the same SoftX3000. The callee hooks on first.
Figure 6-23 shows the flow.
MG1 SoftX3000 MG2 SGF SCF
(1)
(2)
(3)
(4)
(7)
(9)
(12)
(14)
(6)
(5)
(8)
(10)
(11)
(13)
(15)
MODIFYRELPLYNOTIFYRELPLYMODIFYRELPLYNOTIFYRELPLY
RELPLYMODIFY
ADDRELPLY
MODIFY
RELPLY
MODIFYRELPLY
RELPLY
SUBSTRACT
IDP
AC,CON
IDP
AC,CON
ADDRELPLY
NOTIFY
RELPLYMODIFYRELPLY
NOTIFYRELPLY
SUBSTRACT
RELPLY ACR ACR
Figure 6-23 Flow in which the user MG originates an IN call
1) SoftX3000 sends the Modify command to MG1 and MG2; that is, it sets up a termination in the null context. After that, SoftX3000 waits for the off-hook event.
2) The caller hooks off. MG1 sends the Notify command to SoftX3000 to report the off-hook event.
3) SoftX3000 sends the Modify command to MG1 and waits for the user to enter the called number. The caller listens to the dialing tone.
4) MG1 sends the Notify command and the called number to SoftX3000.
5) SoftX3000 sends an INAP/IP operation IDP to SGF to report the triggering of the 800 service. SGF sends the INAP/IP operation IDP to SCF to report triggering of the 800 service.
6) SCF sends INAP/TC operations AC and CONNECT to SGF and asks SoftX3000 to charge and connect the call. SGF converts the two operations into an INAP/IP operation and sends it to SoftX3000.
7) A context is created in MG1. TDM termination and RTP termination are added in the context. [Mode] is set to “ReceiveOnly”. The jitter buffer and voice compression algorithm are also set. MG1 returns its RTP port number and voice compression algorithm through the Reply command.
8) A context is created in MG2. TDM termination and RTP termination are added in the context. [Mode] is set to “SendReceive”. The jitter buffer and voice compression algorithm are also set. MG2 returns its RTP port number and voice compression algorithm through the Reply command.
9) SoftX3000 sends the Modify command to MG1 and notifies the remote address. 10) The callee hooks off. MG2 sends the Notify command to SoftX3000. 11) SoftX3000 sends the Modify command to MG2 and cuts off the ringing tone. 12) SoftX3000 sends the Modify command to MG1 and cuts off the ringback tone.
The mode is “SendReceive”. 13) The callee hooks on. MG2 sends the Notify command to SoftX3000. 14) The SoftX3000 sends the Subtract command to MG1 and MG2. 15) SoftX3000 sends an INAP operation ACR to SGF. SGF sends the INAP operation
ACR and report the charging resut to SCF.
III. Flow in Which Trunk Gateway Originates IN Call
When a trunk media gateway originates a call, the media gateway is connected with the user through the trunk of a circuit-switched network, and call signaling interworks with the SoftX3000 through a SS7 gateway.
This flow example is based on the following conventions:
The caller is controlled by MG1 and SG1. The callee is controlled by MG2 and SG2. ISUP is taken as an example of SS7. MG1 and MG2 are controlled by the same SoftX3000.
Figure 6-24 Flow in which an IP trunk gateway originates an IN call
1) After the caller dials the number of the callee, an IAM is sent to the SoftX3000 through SG1.
2) SoftX3000 sends an INAP/IP operation IDP to SGF to report the triggering of the 800 service. SGF sends the INAP/IP operation IDP to SCF to report triggering of the 800 service.
3) SCF sends INAP/TC operations AC and CONNECT to SGF and asks SoftX3000 to charge and connect the call. SGF converts the two operations into an INAP/IP operation and sends it to SoftX3000.
4) A context is created in MG1. TDM termination and RTP termination are added in the context. [Mode] is set to “ReceiveOnly”. The jitter buffer and voice compression algorithm are also set. MG1 returns its RTP port number and voice compression algorithm through the Reply command.
5) A context is created in MG2. TDM termination and RTP termination are added in the context. [Mode] is set to “SendReceive”. The jitter buffer and voice compression algorithm are also set. MG2 returns its RTP port number and voice compression algorithm through the Reply command.
6) The SoftX3000 sends an IAM to the circuit-switched network through SG2. The circuit-switched network returns an ACM. The phone set of the callee rings.
8) SoftX3000 sends the Modify command to MG1, tells the remote RTP port number, and notifies MG1 to send the ringback tone.
9) The callee hooks off. SG2 sends an ANM to the SoftX3000. 10) SoftX3000 sends an ANM to SG1. 11) SoftX3000 sends the Modify command to MG1 and cuts off the ringback tone.
The mode is “SendReceive”. 12) The callee hooks on. SG2 sends an REL to the SoftX3000. 13) SoftX3000 sends an REL to SG1. 14) SoftX3000 sends an INAP operation ACR to SGF. SGF sends the INAP operation
ACR and report the charging result to SCF. 15) SoftX3000 sends the Subtract command to MG1 and MG2.
As the telecom network is very large in scale, it is hard to replace channel associated signaling completely with SS7 signaling in a short time span. By far, the channel associated signaling system is still widely used in the international telecom network and telecom networks of various countries. No. 1 signaling is a subset of R2 signaling.
R2 signaling consists of line signaling and register signaling. Of these two kinds of signaling, the definition varies from country to country.
Line signaling is transmitted between line devices (repeaters). It is composed of line monitoring signals. It is used for monitoring the status of connection of trunks and controlling the connection. A line device cannot be shared among trunks. Instead, each trunk must have a line device. Therefore, line signaling is relatively simple to reduce costs, and the types of line signaling are few.
Register signaling is transmitted between registers. It is composed of selection signals and service signals. It is used for selecting route and callee and managing the telephone network. A register is a shared device. Few registers are needed in a signaling network. Therefore, a register can be a complex device for matching more kinds of signaling.
7.1.1 Line Signaling
There are three forms of line signaling: DC line signaling, line signaling with in-band single frequency pulse and digital line signaling.
I. DC line signaling
DC line signaling is used for the real line trunks of electromechanical switches. In China, local call networks are all stored program-controlled; therefore DC line signaling actually is not used. DC line signaling will not be introduced in this document.
II. Line signaling with in-band single frequency pulse
In a toll automatic telephone network, if the inter-office transmission system uses carrier, microwave or satellite circuits of frequency-division multiplexing, the inter-office line signaling usually uses the audio signal, namely, the in-band single frequency pulse signal.
The single frequency used by line signaling is 2600 Hz. It consists of the short signal unit, long signal unit and continuous signal unit. The short signal unit is a short pulse signal with the nominal value of 150 milliseconds. The long signal unit is a long pulse
signal with the nominal value of 600 milliseconds. The nominal interval of sending two signals is 300 milliseconds. Table 7-1 lists the nominal values of pulse signals and intervals.
Table 7-1 Nominal values of the in-band single frequency pulses and their intervals
Nominal values of pulse signal or interval
Pulse Signal length (ms)
Interval (ms)
Sending time deviation at transmitting
end (ms)
Recognition time range at receiving end
(ms)
Short signal unit 150 150 ± 30 80 ± 20
Sending interval – 300 ± 60 –
Long signal unit 600 600 ± 120 375 ± 75
There are two kinds of line signaling: forward signaling and backward signaling. Forward signaling is sent from the originating office to the terminating office. Backward signaling is sent from the terminating office to the originating office. The structure of signaling signals is described in Table 7-2.
Table 7-2 Signal structure of line signaling with in-band single frequency pulse
Sending direction Seri
al No.
Connection status (signaling
name) Forward
Backward
Signaling signal structure (ms) Remarks
1 Occupation signal → Single pulse 150
2 Disconnection signal → Single pulse 600
150 300 600
Used between toll offices and between toll/local offices
The connection states in Table 7-2 are described as follows:
Occupation signal is a forward signaling. When the outgoing trunk of the originating office sends an occupation signal, an incoming trunk of the peer office will change its state from idle to occupied.
Disconnection signal is a forward signaling sent by the outgoing trunk to the incoming trunk of the peer office. It means that the switch can release the call in abnormal call disconnection in addition to normal disconnection. The disconnection signal is sent in any of the following cases:
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.
4 Callee not pickup after alerting timeout, or caller not hang up for more than 90 seconds after callee hangs up
The repeated disconnection signal is sent by the outgoing trunk of the original office when it does not receive the release control signal 3 to 5 seconds after its
sending the disconnection signal. If the release control signal is still not received after sending the repeated disconnection signal, an alarm will be generated.
The answer signal indicates that the callee picks up the phone. It is a backward signaling sent by the incoming trunk.
The clear signal indicates that the callee hangs up. It is a backward signaling sent by the incoming trunk from the terminal office to the original office in relay.
The release control signal is a backward confirmation signal of the disconnection signal. It indicates that the caller of the originating office releases.
The blocking signal is a backward signaling sent by the incoming trunk of the incoming office, indicating that the trunk has been blocked.
The re-ringing signal is a forward operator signaling. After the toll office operator establish call connection with the callee and the callee answers, if the callee hangs up and the operator need to call the callee, the operator can send the re-ringing signal.
The forced disconnection signal is also a forward operator signal. When the toll office operator tries to connect the call, and finds that the callee is engaged in a local call, the operator will send the signal after receiving confirmation from the callee.
The ringback signal is a backward operator signaling. It is sent by the operator back to the caller.
The forced release signal is used in the following case. In a bi-directional trunk circuit, sometimes it is occupied in both direction due to disturbances. If no register signaling is received in 15 seconds, one end will send a forward forced release signal (acting as a release signal), and the other end will send a backward forced release signal (acting as a release control signal), and the trunk circuit is released.
III. Digital line signaling
The line signaling monitors the occupation, release, and blocking state of the trunk lines. To support transmission of 30 voice channel line signaling in the PCM system, a multiframe concept is introduces. A multiframe consists of 16 individual frames, each of which is 125 µs and contains 32 timeslots. A multiframe has 16 TS16. In the TS16 of the frame 0, the first four bits are used for synchronization in the multiframe, the last four bits are used for loss-of-synchronization report, and the TS16 of the other 15 frames are used to transmit the line signaling of the 30 voice channels. Table 7-3 describes the usage of TS16 in a PCM multiframe.
Y: Loss-of-synchronization report bit. 0 means normal, and 1 means loss of synchronization.
TS16 of other frames
A 30-voice-channel PCM system sends the line signaling by sampling and transmitting the TS16 in a multiframe. There are four bit—a, b, c, and d—available in both transmission directions for each voice channel. Only the first three bits are used for both the forward signaling and the backward signaling.
The bit af, bf, and cf are for the forward signaling, and the ab, bb, and cb are for the backward signaling. Table 7-4 lists the meaning of the signaling.
Table 7-4 Meaning of forward signaling in digital lines
Bit Meaning
af=0 Caller picks up (occupied)
af=1 Caller hangs up (released)
bf=0 Not faulty
bf=1 Faulty
cf=0 Operator re-rings or forced releases
cf=1 Operator does not re-ring or forced release
Table 7-5 Meaning of backward signaling in digital lines
Bit Meaning
ab=0 Callee picks up
ab=1 Caller hangs up (backward released)
bb=0 Idle
bb=1 Occupied or blocked
cb=0 Operator rings back
cb=1 Operator does not ring back
Obviously, no operator intervention is needed in the connection between local offices, and the automatic connection between a local office and a toll office. Therefore, Cf and Cb are not needed. Table 7-6 shows the differences between different digital line signaling in the three bits.
Table 7-6 Signaling bits in the automatic and semi-automatic connection of a toll office
Forward signaling Backward signalingConnection state
af bf cf ab bb
Idle 1 0 1 1 0
Occupied 0 0 1 1 0
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.
7.1.2 Register Signaling
I. Definition of Register Signaling
The R2 register signaling is in multiple frequency control (MFC) mode. It is divided into two types—forward signaling and backward signaling. In the register signaling, the forward signaling and backward signaling are both consistent. The forward signaling transmits addresses and controls indications, while the backward signaling confirms and controls a call. When sending a digit, the sending party will not stop sending the forwarding signaling until having received a backward confirmation. Similarly, the receiving end will not stop sending backward signaling until having detected that the peer end stops sending forwarding signaling. As shown in Figure 7-1, the transmission of R2 register signaling is done in four beats.
Send the first bit of backward signaling (Beat 2)Stop sending the first bit
of forward signaling (Beat 3)
Stop sending the first bit of backward signaling (Beat 3)Send the second bit of
forwarding signaling
Figure 7-1 The transmission process of R2 register siganling
Beat Operations
1 The originating office sends the first bit of forwarding signaling.
2
The terminating office (receiving end) receives and identifies the forwarding signaling, and returns the first bit of backward confirmation signaling. The terminating office thus replies that it has received the forwarding signaling, and informs what specific forwarding signaling the originating office shall next send.
3 The originating office receives and identifies the backward confirmation signaling, and stops sending the forward signaling.
4
The terminating office detects that the peer end stops sending the forward signaling, and stops sending the backward confirmation signaling. When the originating office detects that the peer end stops sending the backward confirmation signaling, it starts the second control period by sending the next bit of forwarding signaling.
II. Coding Mode of MFC Register Signaling
There are 15 types of forward signaling of MFC register signaling. Fifteen combinations of two from the six high frequencies—1380 Hz, 1500 Hz, 1620 Hz, 1740 Hz, 1860Hz, and 1980Hz. There are six backward signaling of MFC register signaling. Six combinations of two from four low frequencies—1140 Hz, 1020 Hz, 900 Hz, and 780 Hz. Table 7-7 and Table 7-8 details the combination of frequencies.
As described in the above, the MFC register signaling falls into two types: forward and backward. Both forward signaling and backward signaling have two sub-types: group I and group II for the forward signaling, and group A and group B for the backward signaling. Group A is the acknowledgement of group I, and group B the acknowledgement of group II. Table 7-9 lists the meanings of the four groups of signaling.
Table 7-9 Meanings of the four groups of signaling
Forward signal Backward signal
Group Name Meaning Capacity Group Name Meaning capacity
KA Caller type 10/15
KC Toll connection type 5
I
KE Toll/local office and urban connection type
5
A A Signal
Back control acknowledgement of the number receiving status and
Group Name Meaning Capacity Group Name Meaning capacity
Digital signal Digit 1–0 10 connection
status
II KD Originating call service type 6 B B
signalCallee status 6
Note: For a local office using the step-by-step system, there are 10 user types; for a stored program control
(SPC) local office using the crossbar system, there are 15 user types.
Forward group I signaling
Forward group I signaling consists of connection control signaling and digital signaling. For details, refer to Table 7-10 and Table 7-12.
Table 7-10 Forward group I signaling
Type Meaning
KA
It refers to the caller type signaling sent from the originating local office to the originating toll office or originating international switching center in the forward direction. The purpose of this signaling is to provide the charging type (periodical, immediate, free) and user level (ordinary, high priority) information. The combination of these two kinds of information is indicated with a KA code, as shown in Table 7-11. The high priority user in the table refers to those whose calls take precedence over others’ in the case of network blocking or overload.
KC
It refers to the connection control signaling sent between toll offices in the forward direction. This signaling has the functions of ensuring the communication quality of high-priority users, completing specified calls, and connecting other specified calls (for example, test calls).
KE
It refers to the connection control signaling sent from the terminating toll office to the terminating local office and between local offices in the forward direction. There are two types of KE signaling, as shown in Table 7-11.
Digital signaling
It is a selection signaling. The ten digits, 1, 2, 3, …, 0, are used to indicate the calling number, called area code and called number; “15” is used to separate the calling number and called number, indicating the end of the calling number.
Backward group A signaling
Backward group A signaling is the MFC signaling of forward group I signaling. It controls and acknowledges forward group I signaling. For details, refer to Table 7-10 and Table 7-11.
A1, A2, A6 These three kinds of signaling together are called code-sending sequence control signaling. They control the code-sending sequence of forward digital signaling.
A3
A3 is a conversion control signaling for differentiating forward group I from forward group II, and backward group A from backward group B. In the toll incoming register at the local office end in the connection from the terminating toll office to the local office, or in the multiple frequency incoming register of the local call connection, A3 signaling is the control signaling. In other cases, A3 signaling is a pulse (150±30 ms) signaling.
A4, A5 They are the cause analysis signaling when connection to the callee fails. A4 indicates busy, and A5 an unallocated number.
Forward group I signaling Backward group A signaling
Contents of KA signaling (including KOA)
Step-by-step local office
SPC local office using crossbar system (also including PAM office)
KA code
KA KA KA
KC code
Contents of KC signalin
g
KE code
Contents of KE signalin
g
Digital signali
ng
Contents of A
signaling
15
– 15
Control the number of satellite circuit segments
15
Voice mailbox cancels notifying the user to leave a message
Note: Those types with brackets are not sent to the originating toll office; “*” indicates that the signal is needed for cooperating with old equipment.
Forward group II
Forward group II signaling is also called KD signaling. It indicates the originating call service type. It is used, based on KD, to judge whether the attendant can break in or forcefully release a local call. Table 7-14 describes the role of this signaling.
Backward group B signaling
Backward group B signaling is also called KB signaling. It indicates the status of the callee. It is sent after the reception of KD signaling to acknowledge the control and connection of KD signaling.
Refer to Table 7-13 for the contents of backward group B signaling.
Table 7-13 Forward group II signaling and backward group B signaling
Forward group II signaling (KD) Backward group B signaling (KB)
Contents of KB signaling
KD code Contents of KD signaling KB code
During toll call connection or test
call connection (when KD=1, 2 or 6)
During local call connection (when KD=3
or 4)
1 Semi-automatic call of a toll attendant
Used for toll call
1 Callee idle Callee idle, first party release recovered
Figure 7-2 illustrates the typical application of R2 signaling in NGN.
SoftX3000
IP MAN
Exchange
UMG8900
POTSPOTS POTS POTS
R2 R2
PBX
H.248/IUAH.248/IUA
UMG8900
SoftX3000
IP MAN
Exchange
UMG8900
POTSPOTS POTS POTS
R2 R2
PBX
H.248/IUAH.248/IUA
UMG8900
Figure 7-2 Typical application of R2 signaling in NGN
The UMG8900 provides the interconnection between R2 trunks and the exchange and PBX. It packages the R2 message in the H.248 message and sends the R2 message to the Soft3000, thus implementing the interworking between NGN and the exchange and PBX in PSTN.
7.3 Basic Signaling Flow
Figure 7-3 takes the connection process of a local call as an example to introduce the basic flow of R2 signaling.
In Figure 7-3, the called number is PQRABCD, in which PRQ is the office directional number, and ABCD is the user number. The figure shows that line signaling and register signaling are sent segment by segment. After the transit office receives PQR completely, it starts routing to send register signaling of the originating office. After sending the full number, the originating office waits for the terminating office to send the A3 signal, and then completes the signaling flow. This connection mode takes a long time. Therefore, it is used when the transmission line is of a poor quality.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-1
Chapter 8 DSS1 Signaling and V5 Protocol
8.1 DSS1 Signaling
8.1.1 Overview of DSS1 Signaling
ISDN features multiple capabilities, including circuit switching, packet switching, non-switching connection, and common channel signaling. Normally, a network only provides functions of lower layers—physical layer, data link layer, and network layer - of the open systems interconnection (OSI) model. Intra-network higher layer (layers 4 to 7 of model OSI) functions required by some supplementary services can be implemented inside ISDN or provided by an independent service center.
The basic structure of ISDN is shown in Figure 8-1. The terminal equipment (TE) of ISDN is connected through the standard user-to-network interface.
TE ISDNswitch
User-network interface
Circuit switching capacity
Packet switching capacity
Non-switching capacity
Common channel signaling capacity
TEISDNswitch
User-network interface
Figure 8-1 Structure of ISDN
8.1.2 Basic Concepts
I. Reference Points and Functional Group
The reference configuration (reference model) of the ISDN user-to-network interface is shown in Figure 8-2. The model is an abstract arrangement of the user-to-network interface standardized by CCITT (ITU) regulations. It offers reference points to be standardized and functional groups related to the reference points.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-2
TE1S
NT2T
NT1U
Transmission line
TAS
TE2R
Reference point Functional group
TE1S
NT2T
NT1U
Transmission line
TAS
TE2R
Reference point Functional group
TE1S
NT2T
NT1U
Transmission line
TAS
TE2R
Reference point Functional group
Figure 8-2 Reference configuration for ISDN user-to-network interfaces
Reference point
In Figure 8-2, crosses stands for reference points. A cross is a conceptual reference point for dividing functional groups. In the user accessing, crosses stand for physical interfaces between device units. For the implementation of multiple functional groups combined in one device, reference points between functional groups exist only conceptually. The physical interfaces cannot be observed.
There are three types of reference points: the U reference point, S/T reference point and R reference point.
U reference point
The U reference point, also called the U interface, is the line interface between the network and the user. According to the regulations of ITU, the U interface is the line interface between the network and the ISDN basic rate access (BRA) user, but not the line interface between the network and the primary rate access (PRA) user. Comparing the reference model to the actual application, we regard that the E1 line in the PRA application as the U interface in Figure 8-2.
The BRA U interface determines the transmission line code. The U interface uses the original analog subscriber line (ASL). To transmit digital signals through twisted pairs, you need to reduce transmission attenuation. One way for reducing transmission attenuation is to reduce the line transmission rate, that is, to transmit a 2-bit binary code with one level. The transmission line code adopted by the U interface in China is 2B1Q. This code indicates that the line transmission uses four levels, each level being a combination of two bits. Correlation between binary codes and line levels:
Binary code Line level
00 –3V
01 –1V
10 +3V
11 +1V
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-3
In this way, the line rate is reduced by half compared with the binary code rate, thus reducing the transmission attenuation.
When the 2B1Q line code is used, the line element rate (baud rate) is 80 kbit/s, and the corresponding bandwidth is 160 kbit/s. The bandwidth allocation is described in Table 8-1.
Table 8-1 Bandwidth allocation in the 2B1Q line code mode
Channel Rate (bit/s) Function
2B channel 128 k Traffic channel
D channel 16 k Signaling channel
M channel 40 k Transmitting the maintenance information between the network and the terminal
Used for U interface synchronization 12 k Transmitting clock information
S reference point and T reference point
The S reference point, also called S interface, is the line interface between the ISDN terminal (terminal equipment type 1 (TE1) or terminal adaptor (TA)) and the network terminal (NT). The T reference point, also called T interface, is the line interface between network terminal type 1 (NT1) and network terminal type 2 (NT2). In the ITU regulation, the specifications of the S interface is the same as that of the T interface.
If the NT2 device does not exist, S and T together form S/T reference point, also called S/T interface.
The S/T interface uses a four-line transmission mode, two lines for sending and two lines for receiving. The line code is a pseudo-AMI (alternate mark inversion) code. In AMI code, binary bit “1” is converted to positive pulse or negative pulse, which alternate forward and backward; binary bit “0“ is converted to level 0. Figure 8-3 illustrates the correlation between a binary code and an AMI code.
Binary code 1 0 0 1 1 1 0 1 0 1
AMI code
Sending direction
Binary code 1 0 0 1 1 1 0 1 0 1
AMI code
Sending direction
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
R reference point
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-4
The R reference point, also called R interface, is a non-standard ISDN terminal interface, for example, RS-232 interface, IEEE-488 interface, and analog telephone interface.
Functional group
In Figure 8-2, blocks stand for functional groups. A functional group is the combination and arrangement of functions required on ISDN user interfaces. In application, a number of functional groups may be implemented in one device.
NT1
NT1 provides U interfaces and S/T interfaces for connecting ISDN terminals and devices of the ISDN exchange. The function of NT1 is the code conversion between the U interface and S/T interface, for example, the 2B1Q/AMI code conversion in the Chinese standard.
NT1 is purely a physical layer device without software intelligence,but it has the line maintenance and performance monitoring functions. It ensures the clock synchronization of the ISDN terminal and network.
Note:
If the NT1 includes the function of the TA, it is called NT1+.
NT2
NT2 is an intelligent terminal device. A common NT2 device can be a terminal control device such as a private automatic branch exchange (PABX) that has the functions of ISDN, and a LAN router.
TE1
The TE1 is a standard ISDN terminal, with standard S interfaces. It can be connected directly with the NT1 or NT2 through S interfaces. Common TE1 devices include ISDN digital telephone sets, G4 fax machines, and video phones.
Terminal equipment type 2 (TE2)
TE2 is a non-standard ISDN terminal without S interfaces. It cannot be directly connected with the NT1 or NT2. An S interface can be connected to the TE2 through a terminal adapter (TA). Common TE2 devices include PCs, ordinary telephone sets, X 25 packet terminals and G3 fax machines.
TA
There is an S or U interface on one end of the TA, and an interface for connecting a non-standard ISDN terminal on the other end. The role of the TA is for rate adaptation and protocol conversion. The non-standard ISDN terminal (TE2) does not have the
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-5
function of the common channel signaling (D channel). It can be connected with the S or U interface only after the rate adaptation and protocol conversion with the TA.
Some TAs contain the built-in AT command set. The AT command set is a general command format for operating on the Modem on a computer. It supports call originating and answering on a computer. In other words, the AT command is converted to D channel signaling. With a TA, the user can make calls and transmit data simultaneously through a computer.
The B channel protocol of the TA is V.110. It converts the low-speed serial port data to the data with the speed of 64 kbit/s to enter the B channel. It enables the non-standard ISDN terminal to communicate with the network through a standard ISDN interface.
II. ISDN Channel
The ISDN channel type refers to the channel path type of the user-to-network interface. It includes bearer channel (B channel), demand channel (D channel) and H channel.
B channel
The B channel is used for transmitting user information (including voice, data and images) at the rate of 64 kbit/s. It can implement circuit switching, packet switching and semi-permanent connection (SPC).
D channel
The D channel transmits signaling messages and packet messages for circuit switching. According to the number of B channels supported by D channels, D channels are divided into 2B+D and 30B+D.
Table 8-2 Bandwidth allocation in the 2B1Q line code mode
Channel Rate (bit/s) Function
D16 16k D channel in 2B+D
D64 64k D channel in 30B+D
H channel
The H channel is for transmitting user information (including stereo programs, images and data) at a rate over 384 kbit/s.
III. ISDN Interface
The ISDN interface falls into three types: BRA (2B+D), PRA (30B+D) and ISUP.
BRA interface
BRA is short for the basic rate interface/access (BRI/BRA). It is specified when the ordinary subscriber line in PSTN is used as the ISDN subscriber line. It has a rate of
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-6
144 kbit/s. It supports two 64 kbit/s user channels (B channel) and one 16 kbit/s signaling channel (D channel).
The BRA interface is provided by the digital subscriber line board (DSL) of the optical network unit (ONU) or remote subscriber processor (RSP) under the UMG8900. Each DSL can provide eight BRA interfaces. One BRA interface can be connected with eight ISDN terminals at most. It allows two telephones (each occupying a B channel) and a packet terminal (occupying the D channel) to communicate with the network simultaneously. When the ISDN-PC communicates with the network, it can occupy two B channels at the maximum rate of 128 kbit/s.
As shown in Figure 1-6, the eight ISDN terminals attached to the 2B+D interface can call another terminal in the “subscriber number + sub-address” mode. Two subscriber numbers must be allocated to a BRA interface on the network side and set on the terminal. Each subscriber number can have four sub-addresses (1–4 digits) at most. On the network side, sub-address numbers need not be set. Only the authorities for sub-address numbers need to be registered. Sub-addresses are set on terminals.
2B+D subscriber line
N1=6600000N2=6600001
NT1
S/T¿Ú
SUB1=1
SUB1=2
SUB1=3
SUB1=4
N1=6600000
SUB1=1
SUB1=2
SUB1=3
SUB1=4
N2=6600001
2B+D subscriber line
N1=6600000N2=6600001
NT1
S/T¿Ú
SUB1=1
SUB1=2
SUB1=3
SUB1=4
N1=6600000
SUB1=1
SUB1=2
SUB1=3
SUB1=4
N2=6600001
2B+D subscriber line
N1=6600000N2=6600001
NT1
S/T¿Ú
SUB1=1
SUB1=2
SUB1=3
SUB1=4
N1=6600000
SUB1=1
SUB1=2
SUB1=3
SUB1=4
N2=6600001
Figure 8-4 ISDN subscriber number and sub-address
PRA interface
According to different gaping (E1=32TS, T1=24TS) divided by the PCM system, the primary rate interfaces/accesses (PRI/PRA) are classified into the 30B+D interfaces (China and Europe) and the 23B+D interfaces (North America and Japan).
The 30B+D interface is the PRA interface in China with a rate of 2048 kbit/s. It supports thirty 64 kbit/s user channels (B channels) and a 64 kbit/s signaling channel (D channel).
The physical channel of the PRA interface is provided by the digital trunk module (DTM). The board type must be set to “PRA” during hardware data configuration. Each PRA board provides two 30B+D PRA interfaces. The subscriber line is a coaxial cable that can meet the requirement of users with heavy traffic. The PRA interface can be connected to the PABX that has the functions of ISDN, a LAN, or Internet interim inter-switch signalling protocol (ISP) system. It can also provide channels for video conference users to transmit high quality pictures.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-7
ISUP interface
The ISDN user part (ISUP) interface is needed for enabling the ISUP circuit between two exchanges.
8.1.3 Application of DSS1
Figure 8-5 is a typical application of DSS1 signaling in NGN.
SoftX3000
IP MAN
UMG8900 UMG8900
POTS POTS
H.248/IUA
ISDN 2B+D access
RSP
PBX and NASdevices
PRI PRI
NASPBX
H.248/IUA
ISDNISDN
BRIBRI
Figure 8-5 Typical application of DSS1 in NGN
The UMG8900 provides the BRIs and PRIs specified in ISDN User to Network Interface Specifications, for processing Q.921 messages. It transparently transmits Q.931 signaling to the SoftX3000 through ISDN Q.921-User Adaptation Layer (IUA) to implement the following ISDN services:
Providing BRIs for the accessing of ordinary ISDN users (2B+D); Providing PRIs for accessing PABXs and network access servers (NAS).
For the DSS1 signaling system, this document introduces only the PRI. For the BRI, refer to relevant standards.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-8
8.1.4 Protocol Structure of DSS1
DSS1 signaling has three layers: physical layer, data link layer and call control layer. Figure 8-6 illustrates the correlation between DSS1 signaling and the OSI reference model.
Data link layer
Physical layer Layer 1
Layer 2
Layer 3
Layers 4-7
DSS1 signaling OSI reference model
Call control layer
Figure 8-6 Correlation between DSS1 signaling and the OSI reference model
I. Physical Layer
The physical layer specifies the procedure and electrical and functional features of the ISDN user-to-network interface. It provides the technical basis for the interconnection, operation and maintenance, equipment design, network planning and acceptance test of the user-to-network interface. For example, the reference configuration of the PRI is shown in Figure 8-7.
TE1
RNT2
TNT1
UTransmission media
TE2R S
Reference point
Functional group
TE1: Standard ISDN terminal TE2: Non-standard ISDN terminalNT1: Network terminal type 1NT2: Network terminal type 2 (For example, PBX, LAN, Router)TA: Terminal adaptor
TA
Figure 8-7 Reference configuration of ISDN user-to-network interfaces
The meanings of the B channel and D channel supported by the PRI:
B channel: bearer channel of the user information with the rate of 64 kbit/s, used for carrying voice and data for circuit switching, packet switching and SPC.
D channel: bearer channel of the signaling information with the rate of 64 kbit/s, used to transmit the signaling information and packet data information of circuit switching. The PRI physical channel is in the PCM structure. It has the same rate as the PCM
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-9
primary rate, namely, 2048 kbit/s. The PRI can use twisted pairs as the transmission media. In the 30/32 channels of PCM, each frame is divided into 32 basic time slots. TS0 is used for frame synchronization and error control, and TS16 for signaling transmission.
II. Data Link Layer
The data link layer specifies the specification attributes of the data link layer of the ISDN user-to-network interface (PRI). These specification attributes include the concept and terms of the data link layer protocol, and the frame structure, procedure, procedure element and field format of the data link layer protocol under normal operation.
On the ISDN user-to-network interface, the data link layer protocol accesses the LAPD protocol through the link on the D channel. The LAPD protocol defines rules for the layer 2 entity on the user-to-network interface to exchange information through the D channel. The layer 2 entity may exchange information between the TE and the NT2 (such as PABX, LAN and a router), between the NT2 and an exchange, or between the TE and an exchange.
Therefore, LAPD is to provide means of information transmission between combinations of data link connection ends. Functions of LAPD are as follows:
Providing data link connections on one or more D channels; Discrimination of data link connections depending on the data link connection identifier (DLCI) contained in each frame;
Delimitation, location and transparent transmission of frames, hence allowing recognizing a string of bits sent on the D channel in the form of a frame;
Sequence control for keeping the sequence of frames connected through data links;
Checking of the transmission and format of and operation onto data link connections;
Error recovery after the transmission, format and operation check;
Notifying the management entity of unrecoverable errors;
Performing flow control;
Management of the activation of the physical layer.
For details, refer to ISDN User to Network Interface Specifications – Part 2: Technical Specifications on Data Link Layer (YDN 034.3-1997).
III. Call Control Layer
The call control layer specifies the procedure for establishing, keeping and removing network connections on the ISDN user-to-network interface. It also specifies the process of message exchange on the D channel.
With the functions and services provided by the data link layer, the call control layer provides functions for establishing and operating on network connections to users.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-10
These functions support the basic call control program and the call control program related to supplementary features provided by the network. These functions include:
Processing the primitive used for the communication with the data link layer;
Generating and translating layer-3 messages for intra-layer communication;
Managing the timer and logical entity used in the call control program;
Managing accessing resources, including the B channel, and the logical path of the packet layer (for example, X.25 recommendations);
Ensuring the consistency between the provided services and the services required by the user (for example, the bearer capacity, address, and the compatibility between the lower layers and the higher layers);
Routing and trunks;
Network connection control;
Transmitting information between the network and the user;
Multiplexing of network connections;
Error checking;
Error recovery;
Sequencing;
Blocking control and user data stream control;
Restart.
For details, refer to ISDN User to Network Interface Specifications – Part 3: Technical Specifications on Basic Call Control of Layer 3 YDN 034.3-1997.
8.1.5 Call Control Message
The Layer 3 (call control layer) entity of the user side needs to communicate with the Layer 3 entity of the network side for call control. The communication is realized by exchanging messages on the D channel. The call control layer message is composed of data blocks of different lengths. It is produced and processed by the call control layer, and carried and transmitted by the data link layer.
The format of the call control layer message specified by the recommendations of ITU-T Q.931/Q.932 is illustrated in Figure 8-8. The call control layer message consists of a number (an integer) of bytes. Each message has a common part, and optional or mandatory information elements.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-11
8 7 6 5 4 3 2 1
Protocol discriminator
0 0 0 0Length of call reference value
Call reference value
0 Message type
Other information elements
1 byte
2 bytes at most
Common part
Optional or mandatory information elements
FLAG
1 byte
1 byte
Other information elements
Figure 8-8 Format of ITU-T Q.931 messages
The common part consists of three sub-parts with the format identical with that of all messages.
I. Protocol Discriminator
The protocol discriminator separates the call control message from other messages on the user-to-network interface. The length of the protocol discriminator is one byte. The value of the Q.931 call control layer message fixedly is 00001000.
II. Call Reference Value
The reference identifies calls involved by messages or facility registration/un-registration requests on the local user-to-network interface. Call reference value does not have the meaning of overriding ISDN from end to end.
The call reference value is allocated by the call originating interface. Inside the layer-2 logical link connection of a specific D channel, call reference values are unique on the originating side. They are allocated at the start of calls and kept till the end of these calls (except in the cases of call suspension). After the end or successful suspension of a call, the call reference value can be re-allocated to a new call. On layer 2 logical links of a same D channel, two calls of different directions can have the same call reference value.
The eighth byte of the second eight-byte set is the call reference flag. The value of the flag is 0 or 1. The call reference flag identifies the end of the layer 2 logical link to send the call reference value. The call reference flag on the originating side is always set to 0, and that on the terminating side is always set to 1. The sole purpose of the call reference flag is to solve the problem of two ends attempting to allocate the same call reference value at the same time. The call reference flag is also applied when using the global call reference (for example, to restart a program).
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-12
III. Message Type
Message types identifies messages that are being sent. They include different information elements. The message part is the third part of a message, and its length is one byte. Bit 8 is reserved for future expansion.
Call control layer messages of Q.931 are classified into four types: messages for call setup, messages used at the call information stage, messages for call clearing, and other messages. The coding of different types of messages is described in Table 8-3.
Table 8-3 Types of call control layer messages of Q.931
Message code Message type
0000 0001 ALERTING
0000 0010 CALL PROCEEDING
0000 0111 CONNECT
0000 1111 CONNECT ACKNOWLEDGE
0000 0011 PROGRESS
0000 0101 SETUP
0000 1101
Messages for call setup
SETUP ACKNOWLEDGE
0010 0110 RESUME
0010 1110 RESUME ACKNOWLEDGE
0010 0010 RESUME REJECT
0010 0101 SUSPEND
0010 1101 SUSPEND ACKNOWLEDGE
0010 0001
Messages used at the call information stage
SUSPEND REJECT
0100 0101 DISCONNECT
0100 1101 RELEASE
0101 1010 RELEASE COMPLETE
0100 0110 RESTART
0100 1110
Messages for call clearing
RESTART ACKNOWLEDGE
0111 1011 INFORMATION
0110 1110 NOTIFY
0111 1101 STATUS
0111 0101
Other messages
STATUS ENQUIRY
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-13
8.1.6 Basic Signaling Process
The following takes the process of the simplest call control with circuit switching as an example to describe the basic signaling process of DSS1. Suppose both the calling end and the called end use ISDN terminal devices. If ISUP is used as the signaling protocol between the originating and terminating offices, the process of a typical call is illustrated in Figure 8-9.
Originating office
Terminating office
IAM
Conversation or data
Caller hooks on first
Caller hooks on first
ISUPCalling terminal
Called terminal
SETUP
SETUP ACK
INFO
INFO
ACMALERT
CONN ANM
CONN ACK
SETUPCALL PROC
ALERT
CONN
CONN ACK
DISC(cause value=16)REL DISC(cause value=16)RLC
RELREL
REL COMPREL COMP
DISC(cause value=16)
REL
REL COMPRLC
RELDISC(cause value=16)
REL
REL COMP
TEx TEy
ALERT
REL COMP
REL
Figure 8-9 Basic signaling process of DSS1 (circuit switching)
I. Call Setup Process
A call request is sent in the form of the SETUP message. The message is transmitted on an established data link.
When the SETUP message reaches the network side of the originating office, the network entity of layer 3 checks whether the called address is complete. If it is complete, the originating office returns the CALL PROCEEDING message to hold the
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-14
caller waiting. If the called address is incomplete, the originating office returns the SETUP ACK message to request subsequent information. The caller sends the INFORMATION message to provide the remaining information.
When the originating office network side receives the complete address information, it notifies the exchange for routing and resource allocation. In this example, the call must go through another exchange before being connected to the callee. Therefore, the originating office exchange must send a message containing the call-related information to the terminating office exchange through SS7 signaling (ISUP). When the terminating office receives this message, it sends the SETUP message to the callee. The SETUP message contains all the information sent by the originating office, including the bearer service capacity, terminal lower layer and higher layer attributes, and end-to-end information. It also contains the subscriber information channel selected by the terminating office.
On the basic interface of the callee, the SETUP message is transmitted on the broadcast data link (TEI = 127). Therefore, all the terminals connected to the passive bus receive the SETUP message. These terminals will check whether they meet the content requirements of the SETUP message. For example, whether they have the same bearer service features as the message, whether the lower layer and higher layer protocols are consistent, whether their terminal types match that of the calling terminal, and whether the sub-address (if there is one) is conformant. The following case is possible. For a call, there are several terminals having the information compatible with the SETUP message. Then, these terminals simultaneously return the ALERTING message to the network and send the ringing tone to the callee. The terminating office sends the first ALARTING message to the originating office. When the ALARTING message finally arrives at the calling terminal, the calling terminal sends the ringback tone (or displays the ALARTING information) to the caller. When a called terminal responds to the call, it immediately sends the CONNECT message to the network. The exchange of the terminating office transfers the CONNECT message to the caller side, and at the same time sends the CONNECT ACK message to the responding called terminal. Then, the B channels selected by both exchanges are connected. The circuit connection is set up between the caller and the callee and the circuit is ready for transmitting subscriber information.
II. Call Release Process
The call release process with the caller hooking on first is as follows.
The caller sends the DISCONNECT message (cause value = 16) to the originating office. After the originating office receives the message, it sends the REL message to the terminating office to disconnect the inter-office circuit. The terminating office returns the RLC message, indicating the completion of call release.
When the originating office sends the REL message to the terminating office, it also responds to the calling terminal with the RELEASE message to disconnect the
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-15
inter-office circuit. The calling terminal returns the RELEASE COMPETE message, indicating the completion of disconnection.
After the terminating office receives the REL message from the originating office, it sends the DISCONNECT message (cause value =16) to the called terminal. The called terminal responds with the RELEASE message to disconnect the circuit between the caller and the terminating office. The terminating office returns the RELEASE COMPLETE message to the callee, indicating the completion of disconnection. Now, the call is completely released.
For the call release process with the callee hooking on first, DSS1 call control messages on the user-to-network interface are the same as the above. Refer to Figure 8-9 for an analysis.
8.2 V5 Protocol
The V5 interface comes into being with the development of the access network. It is used for connecting the local exchange (LE) and the access network (AN). In the 1990s, Bell Labs changed the analog interface connection between an exchange and devices to the standard digital interface connection (TR303 interface). This is to solve the problems of poor transmission performance, high equipment cost and the development need of digital services that were characteristic of analog connection. In 1993, European Telecommunications Standards Institute (ETSI) issued V5 interface standards to perfect the interface and make it widely applicable.
In view of the importance of the V5 interface and the development urgency of the access network, ITU-T adopted V5 interface specifications by using an expedited program. These specifications include V5.1 (G.964) and V5.2 (G.965). In China, the V5 interface standards have been reviewed and revised for times. Now, the following two documents are implemented:
Technical Specifications on V5.1 Interface between Local Digital Exchange and Access Network (YDN 020-1996);
Technical Specifications on V5.2 Interface between Local Digital Exchange and Access Network (YDN 021-1996);
8.2.1 Basic Concepts
I. Basic Contents of V5 Interface
The V5 interface is one between the access network and an exchange. It is a service node interface (SNI), including V5.1 and V5.2.
V5.1 consists of a 2048 kbit/s link. It supports analog telephone accessing and 64 kbit/s–based ISDN basic accessing. These types of access have the assigned bearer channel allocation capacity. User ports correspond to bearer channels one by one; that is, the correlation between user ports and bearer channels is fixed. Therefore,
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-16
there is no line concentration capacity within the AN. V5.1 uses one time slot (TS16) to transmit signaling, leaving the other time slots (except TS0) to transmit the voice signal.
V5.2 consists of one to sixteen 2048 kbit/s links. It can support ISDN PRA besides those access types supported by V5.1. The access types supported by V5.2 have the flexible and call-based dynamic bearer channel allocation capacity. In other words, user ports correspond to bearer channels dynamically. Therefore, line concentration capacity exists within the AN and on the V5.2 interface.
Table 8-4 lists the differences between V5.1 and V5.2.
Table 8-4 Differences between V5.1 and V5.2
V5.1 interface V5.2 interface
Only one E1 link One to sixteen E1 links available
No Bearer Connection Control (BCC) and user line concentration. E1 time slots directly correspond to user terminals.
Having BCC and user line concentration. Connections between E1 bearer channels and user terminals are dynamically allocated.
Not supporting ISDN-PRA Supporting ISDN-PRA
No protection protocol, no fault link switching protection
Having protection protocol, and fault link switching protection
No link control protocol; managing only a single link
Having link control protocol; managing multiple links
Due to its limitation, V5.1 is rarely used now. Instead, V5.2 is widely used between the access network and the exchange. The following is an introduction to V5.2.
II. Common Terms
Bearer channel: used to provide the bi-directional transmission capability for allocated B channels from ISDN-BRA user ports, ISDN-PRA user ports, or PCM encoded 64 kbit/s channels from PSTN user ports. They may be used in multiples of 64 kbit/s channels in order to facilitate certain ISDN services.
Pre-connection bearer channel: any bearer channel or multiples thereof, set up using the BCC protocol in order to provide switched services within the AN over bandwidth reserved on the V5.2 interface reserved for it.
BCC protocol: a protocol which allows the LE to instruct the AN to allocate bearer channels, either singly or in multiples, on demand.
ISDN D channel information: ISDN D channel information is defined as the D channel information from basic or primary rate access user ports (including Ds-, p- and f-type data).
Communication path (C path): any one of the following information types:
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-17
The layer 2 data link carrying the control protocol; The layer 2 data link carrying the link control protocol; The layer 2 data link carrying the PSTN signaling; The layer 2 data link carrying the protection protocol; The layer 2 data link carrying the BCC protocol; All the ISDN D channel signaling data (Ds-type) from one or more user ports; All the ISDN packet data (p-type) from one or more user ports; All the ISDN frame relay data (f-type) from one or more user ports.
It should be noted that this definition includes the possibility that there is more than one C path of the same information type, each allocated to a different logical C channel.
Communication channel (C channel): a 64 kbit/s time slot on a V5.2 interface provisioned to carry communication paths.
Logical communications path (logical C channel): a group of one or more C paths, all of different types, but excluding the C path for the protection protocol.
Physical communications channel (physical C channel): a 64 kbit/s time slot on a V5.2 interface which has been assigned for carrying logical C channels. A physical C channel may not be used for carrying bearer channels. Time slots 16 of the primary and secondary links (only on a V5.2 interface with more than one 2048 kbit/s link) are always physical C channels.
Multi-link: a collection of more than one 2048 kbit/s link which together make up a V5.2 interface.
Multi-slot: a group of more than one 64 kbit/s channels providing 8 kHz and time slot sequence integrity, generally used together within an ISDN-PRA user port, in order to supply a higher bit-rate service.
Primary link: the 2048 kbit/s link on a multi-link V5.2 interface whose physical C channel in time slot 16 carries a C path for the protection protocol and, on V5.2 initialization, also the C path for the control protocol, link control protocol, and the BCC protocol. Other C paths can also be carried in TS16.
Secondary link: the 2048 kbit/s link on a multi-link V5.2 interface whose time slot 16 carries a C path for the protection protocol and, on V5.2 initialization, acts as the standby C channel for the control protocol, link control protocol, and BCC protocol and any other C paths initially carried in TS16 of the primary link.
Active C channel: a physical C channel which is currently carrying a logical C channel. An active C channel becomes a standby C channel when it is not carrying a logical C channel.
Standby C channel: a physical C channel which is not carrying a logical C channel, but is used for the protection of logical C channels. Once it is used to carry a logical C channel, a standby C channel becomes an active C channel.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-18
Protection group: a group of (N + K) physical C channels, where K is the number of physical C channels which act as standby C channels for the N logical C channels.
III. Functions of V5.2 Interface
Figure 8-10 illustrates the functions of the V5.2 interface.
AN LE
Bearer channel
ISDN D-channel information
PSTN signaling information
Control information
Link control information
Protection information
BCC information
Timing
Figure 8-10 Functions of the V5 interface
Functional requirements of the V5 interface:
Bearer channel: used to provide the bi-directional transmission capability for allocated B channels from ISDN-BRA and ISDN-PRA user ports, or PCM encoded 64 kbit/s channels from PSTN user ports.
ISDN D channel information: providing the bi-directional transmission capability for the D channel information (including Ds-, p- and f-type data) of the ISDN-BRA and ISDN-PRA use ports.
PSTN signaling information: providing the bi-directional transmission capability for the signaling information of PSTN user ports.
User port control: providing the bi-directional transmission capability for the status and control information of each user port.
Control of the 2048 kbit/s link: managing the framing, multi-frame locating, alarm indication and cyclic redundancy check (CRC) information of the 2048 kbit/s link.
Control of layer 2 links: providing the bi-directional transmission capability for control and PSTN information.
Control for supporting common functions: providing the capability of the synchronous application and restart of assigned data.
Timing: providing timing information necessary for bit transmission, byte identification and frame synchronization. This timing information can also be used to synchronize the LE and AN in the work state.
BCC protocol: used to allocate bearer channels under the LE control.
Service-required multi-slot connection: provided on a 2048 kbit/s link in the V5.2 interface, always with 8 kHz and time slot sequence integrity.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-19
Link control protocol: defining the management function that supports 2048 kbit/s links on the V5.2 interface.
Protection protocol: defining logical C channels that support switching between applicable physical C channels.
8.2.2 Application of V5 Protocol
Figure 8-11 illustrates the typical application of the V5 protocol in NGN.
SoftX3000
IP MAN
UMG8900
POTS
V5 access network
ONU
ISDN
BRI
H.248/V5UA
V5
Figure 8-11 Typical application of the V5 protocol in NGN
The UMG8900 processes Q.921 messages, provides the V5 interface for accessing the standard V5 access network, and transparently transmits Q.931 messages to the SoftX3000 through V5UA.
8.2.3 Protocol Structure of V5.2 Interface
Figure 8-12 illustrates the protocol structure of the V5.2 interface.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-20
PSTNprotocol
Protectionprotocol
Linkcontrol
Control BCCprotocol
LAPV5-DL
PSTNprotocol
Protectionprotocol
Linkcontrol
ControlBCCprotocol
LAPV5-DL
Q.931
Q.921
Map function
ET/L2
LC
AN frame relay
D16/64
LAPV5-EF
C64
LAPV5-EF
C64TE
PSTN
Q.931
L2
Q.921
D16/64
Network layer
Data link layer
Physical layer
p- andf-type date
Note: excluding the function of the AN terminating at AN_FR
(Note)
AN LE
Map function
Figure 8-12 Protocol structure of the V5.2 interface
I. Physical Layer
The physical layer of the V5.2 interface can provide bi-directional bearer channels for transmitting all kinds of service information and control information, thus implementing the physical connection between the AN and LE. The V5.2 interface is composed of one to sixteen 2048 kbit/s links. The electrical and physical attributes of all 2048 kbit/s links must conform to relevant regulations of G.703 recommendations. For example:
Bit rate: 2048 kbit/s ± 50 ppm; Code: HDB3 code; Impedance: 75-ohm coaxial (out of balance) or 120-ohm twisted pair (balanced); Synchronization: pull-in range of the AN clock ≥ 1 ppm; in the work mode,
maximum offset against the nominal frequency ≤ 1 ppm. In the free work mode, frequency offset of the AN ≤50 ppm.
II. Data Link Layer
The data link layer (layer 2) of the V5.2 interface is mentioned in terms of the logical C channel. The specifications and procedure of the layer 2 protocol of the V5.2 interface (LAPV5) is based on that of the Link Access Procedure on the D channel (LAPD) protocol specified in Q.921 recommendations. The functions of LAPV5 are as follows.
LAPV5 allows flexible multiplexing of different information streams to C channels to support different service types.
Delimitation, location and transparent transmission of a frame;
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-21
Sequence control for keeping the sequence of frames connected through data links;
Checking of the transmission and format of and operation onto data link connections;
Error recovery after the transmission, format and operation check; Notifying the network layer of unrecoverable errors; Congestion control, such as end-to-end flow control, and the congestion control
on the V5.2 interface.
LAPV5 is used for the transmission of information between the AN and LE. It has three sub-layers: encapsulation function sub-layer (LAPV5-EF), used to identify the protocol type of data frames; data link sub-layer (LAPV5-DL), used to describe the protocol information of data frames; and frame relay sub-layer (AN-FR), used to support the ISDN D channel information. The communication between sub-layers is achieved through the mapping function.
III. Network Layer
The network layer (layer 3) of the V5.2 interface is application-oriented. It can implement different protocol functions with the services provided by layer 2. These protocols include:
PSTN protocol
The PSTN protocol is an excitation protocol. It does not control the call flow of the AN. Instead, it transmits relating analog line information between AN user ports and national protocol entities of the LE. Call control is still a role of the LE. The LE provides services, while the AN transparently transfers the address signals of analog user ports and most line signals, and translates part of the analog status signals to be reported to the LE through the V5 interface.
Control protocol (common control and user port control)
There are two types of control protocol: common control protocols and user port controls. The common control protocol defines the implementation of the V5 interface re-assignment and restart, and fulfills the functions such as the verification of variables and interface IDs and the unblocking of user ports. The user port control protocol defines the status indication and control (blocking control and activation control) of user ports, including the control of ISDN-BRA user ports, ISDN-PRA user ports and PSTN user ports.
Link control protocol
Because the V5.2 interface is composed of multiple links, there must be link identification and link blocking functions. These functions are realized through the link control protocol. The functions include:
The status indication of the first 2048 kbit/s link and the identification of related links;
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-22
Managing the blocking of layer-1 links and assisting in link unblocking; Allow the requesting side, by using the link identification program, to check
whether the two ends of a link are matched (consistent); Coordination among link control functions; The link control for the communication between the AN and LE during the
coordination of functions on both sides.
BCC protocol
The BCC protocol of the V5.2 interface is used to assign the bearer channels on certain links to user ports, thus realizing the dynamic connection between V5.2 interface bearer channels and user ports. In other words, it helps realize line concentration. This process is specified by the LE and executed by the AN.
The BCC protocol also has an auditing function for checking the allocation and connection of bearer channels within the AN. In addition, the BCC protocol is capable of reporting inside-AN faults. If there is a fault affecting the bearer channel connection inside the AN, the protocol notifies the LE.
The V5.1 interface does not support the BCC protocol. Therefore, it has no line concentration function.
Protection protocol
A V5.2 interface can have sixteen 2048 kbit/s links at most. According to the structure of the V5.2 protocol, one communication path can transmit information related to multiple 2048 kbit/s links. Therefore, if a communication path is faulty, it can affect the service of a large number of subscribers. For the BCC protocol, control protocol and link control protocol, when the communication path concerned is faulty, all user ports are affected. The V5.2 interface provides a protection program to enhance the reliability. If one communication path is faulty, the program switches to another. When a communication path is found faulty during fault detection or after link blocking, the system management of the LE or AN triggers the protection program. The program can also be triggered by the operator through the management interface.
The protection protocol is used only when the V5.2 interface is composed of multiple 2048 kbit/s links. Each V5.2 interface, consisting of more than one 2048 kbit/s link, must have protection group 1 and, if provisioned, protection group 2. The system management requires that protection group 1 be switched through the protection started by the management interface.
8.2.4 Layer 3 Protocol Message
Layer 3 protocols are message-oriented protocols, each message having the following information elements:
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-23
Other information elements determined by requirements (the length to be determined by information elements);
Of the above information elements, the first three are the common part, appearing in every message; the last one is to be determined by message type, as shown in Figure 8-13.
Protocol discriminator
Layer 3 address (high level)
Layer 3 address (low level)
Message type
Other information elements
8 7 6 5 4 3 2 1
0
Figure 8-13 Format of layer 3 messages of the V5 interface
I. Protocol Discriminator Information Element
The protocol discriminator is used to discriminate those other protocol messages that share the same data link connection with V5 protocol messages. In other words, different protocol discriminators can be used to support different protocols. The protocol discriminator used by the V5 protocol fixedly is 0x48. The protocol discriminator information element is the first part of a message. It takes one byte.
The purpose of defining a protocol discriminator is to discriminate it from other protocols that may be transmitted on a same V5 data link. These protocols are not defined, but they may be used in the future.
II. Layer 3 Address Information Element
The layer 3 address information element is used to identify layer 3 entities within the V5.2 interface, to which the transmitted or received message applies. The layer 3 address information element is the second part of a message. It always takes two bytes. Its structure is protocol-dependent.
For the PSTN protocol, the layer 3 address is used to identify PSTN user ports. The format of layer 3 address is illustrated in Figure 8-14. The layer 3 address ranges from 0 to 32767.
Layer 3 address (high bit) 1
Layer 3 address (low bit)
Figure 8-14 Layer 3 address information element identifying the PSTN port
For the control protocol, the layer 3 address information element is used to identify ISDN or PSTN user ports or to indicate the V5 common control function. Figure 8-14 illustrates the format of layer 3 address information element when it identifies the
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-24
PSTN port. Figure 8-15 illustrates its format when it identifies the ISDN port or common control (8177) function. The figure shows that the layer 3 address of the ISDN port ranges from 0 to 8175.
Layer 3 address (high bit) 00
1Layer 3 address (low bit)
Figure 8-15 Layer 3 address information element identifying the ISDN port or common control function
For the link control protocol, this information element retains the name layer 3 address although it is used to refer to 2048 kbit/s links. Its format is shown in Figure 8-16. The figure shows that the layer 3 address ranges from 0 to 255 when it identifies a link.
Layer 3 address (low bit)
0000 00 00
Figure 8-16 Layer 3 address information element identifying a 2048 kbit/s link
For the BCC protocol, this information element has been named the “BCC reference number” information element. Its format is shown in Figure 8-17. The source ID in the figure is a one-bit field used to indicate the entity (LE or AN) that builds the BCC reference number. For a process created by the LE, this field is coded 0; for a process created by the AN, the field is coded 1. The figure shows that the value of the BCC reference number ranges from 0 to 8191.
BCC reference number value (high bit)
0
Source ID
0 BCC reference number value (low bit)
Figure 8-17 BCC reference number information element
For the protection protocol, this information element has been named the “logical C channel identification” information element. Its format is shown in Figure 8-18. The figure shows that the value of the logical C channel identification ranges from 0 to 65535. In the RESET SN COM and RESET SN ACK messages, the value of the logical C channel identification must be 0.
Logical C-channel ID (high bit)
Logical C-channel ID (low bit)
Figure 8-18 Logical C-channel identification information element
Table 8-5 lists the usages of the layer 3 address.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-25
Table 8-5 Usages of the layer 3 address
Protocol type Name Usage Digital value
PSTN protocol L3 address Identifying PSTN user ports 0–32767
Control protocol L3 address
Identifying ISDN user ports and PSTN user ports; and used for common control
0–8175 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.2 interface
0–65535
Link control protocol 2048 kbit/s link ID
Identifying V5.2 interface links 0–255
III. Message Type Information Element
This information element is used to identify the protocol a message belongs to and the function for sending the message. The message type information element is the third part of a message. It takes one byte fixedly. Table 8-6 is the allocation table of message type codes.
Table 8-6 Allocation table of message type codes
Protocol type Scope of message type codes
PSTN protocol 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.
Table 8-7 Structure of V5 protocol message type codes
Bit
8 7 6 5 4 3 2 1 Hexadecimal Protocol message type
0 0 0 - - - - PSTN protocol message type
0 0 0 0 0 0 0 0x00 ESTABLISH
This bit is 0 fixedly
0 0 0 0 0 0 1 0x01 ESTABLISH ACK
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-26
Bit
8 7 6 5 4 3 2 1 Hexadecimal Protocol message type
0 0 0 0 0 1 0 0x02 SIGNAL
0 0 0 0 0 1 1 0x03 SIGNAL ACK
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 - - - Control protocol message type
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 - - - Protection protocol message type
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 - - - - BCC protocol message type
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
This bit is 0 fixedly
0 1 0 0 1 0 0 0x24 DE-ALLOCATION COMPLETE
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-27
Bit
8 7 6 5 4 3 2 1 Hexadecimal Protocol message type
0 1 0 0 1 0 1 0x25 DE-ALLOCATION REJECT
0 1 0 0 1 1 0 0x26 AUDIT
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 - - - Link control protocol message type
0 1 1 0 0 0 0 0x30 LINK CONTROL
0 1 1 0 0 0 1 0x31 LINK CONTROL ACK
All other values are reserved. The symbol “-“ indicates 0 or 1.
IV. Other Information Elements
These information elements can appear in different messages. According to the grammatical meaning of this message and its application in the protocol, these information elements are optional or mandatory. They are specific to different protocols.
For the coding structure of these information elements, refer to Technical Specifications on V5.2 Interface between Local Digital Exchange and Access Network (YDN 021-1996).
8.2.5 Call Control Flow of V5.2 Interface
I. Call Flow for the PSTN User
Calls of the PSTN user through the V5.2 interface requires the coordination between the BCC protocol, PSTN protocol and national call entity. The following takes a PSTN call as an example to describe the flow of the message interaction between the BCC protocol, PSTN protocol and national protocol.
PSTN call flow started by the AN side user
Suppose the PSTN user on the AN side is in the pulse dialing mode. If the user uses the DTMF dialing mode, there is no SIGNAL message sent in the signal flow; the DTMF signal is received by a dual tone number receiver on the LE side through the bearer channel. After the completion of the call, the caller hooks on first.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-28
The call flow is illustrated in Figure 8-19. In the figure, the SIGNAL ACK message returned by the peer end is omitted.
PSTN user port AN side LE side
FE establishment
NAT
Hook off
FE establishment acknowledgement
ESTABLISH
ESTABLISH ACK
FE allocation complete
SIGNAL
Ss=hook-off
Ring
Hook on
Talk
User answers
(Hook off)
FE user occupation
(Hook off)
FE allocation requestALLOCATION
ALLOCATION COMP
Dialing tone
FE line signalFE line signal SIGNAL
(Line status signal) Ds=digit
DT
Stop DT
FE line signal SIGNAL
Ds=digit
Digit 1
Digit n
Ring back tone (from terminal office) Start establishingthe call
(Hook on)
FE line signal
Ds=hook on (Hook on)
FE disconnection requestDISCONNECT
FE deallocation requestDEALLOCATION
FE disconnection complete
FE deallocation complete
Ss=normal polarity
DISCONNECT COMP
DEALLOCATION COMPIdle
(Line status signal)FE line signal
FE line signal
Figure 8-19 PSTN call flow started by the AN side user
The PSTN call establishment flow started on the network side
If the network side originates a call, the on the AN side is the callee. In this case, the call flow is similar to that when the AN side user is the caller. But the signal sequence and information elements in this call flow established at the call initiation differ from that in the call flow with the AN side user as the caller. Figure 8-20 illustrates the signal flow at the call establishment stage for a call originated on the network side.
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-29
PSTN user port AN side LE side
ALLOCATION FE allocation request
FE allocation complete
NAT
Keep on ringing
Idle
ALLOCATION COMP
FE establishmentESTABLISH
Ss=keep on ringingFE line signal
(Keep on ringing)ESTABLISH ACK FE establishment
acknowledgement
SIGNAL FE line signal indicationSs=hook off
Ring
Hook off
Talk
Ring back tone
(Hoof off)Hook off
FE line signal
Figure 8-20 PSTN call establishment flow started on the network side
II. Call Flow for the ISDN User
PSTN call flow started by the AN side user
Figure 8-21 illustrates the ISDN call flow started by the AN side user. During the establishment of an ISDN call, the protocol-required synchronization procedure is: The allocation of the bearer channel must be completed before sending the SETUP ACK message (a DSS1 message). If the allocation of the bearer channel fails, the RELEASE COMP message replaces the SETUP ACK message to cancel the establishment of this call.
ISDN user port AN side LE side
SETUP(B)
FE allocation requestALLOCATION(TS1_B1)
FE establishment complete
ALLOCATION COMP
SETUP-ACK or other messages (B1)
NAT
CONNECTUser answers
DICONNECTDisconnect the call
Hook on
FE deallocation requestDEALLOCATION
FE deallocation completeDEALLOCATION COMP
RELEASE
Figure 8-21 ISDN call and release started by the AN side user
Technical Manual – Signaling & Protocols U-SYS SoftX3000 SoftSwitch System Chapter 8 DSS1 Signaling and V5 Protocol
Huawei Technologies Proprietary
8-30
Figure 8-21 shows that protocol synchronization is not required for the ISDN call release and the de-allocation of the bearer channel. Therefore, the sending of the DEALLOCATION COMP message is independent of the order of receiving the RELEASE message.
ISDN call setup flows simultaneously started
Figure 8-22 illustrates two ISDN call setup flows simultaneously started at one ISDN user port. The figure shows the message interaction between the BCC protocol and the DSS1 protocol.
ISDN user port AN side LE side
SETUP(CR1)
FE allocation requestALLOCATION(TS1_B1)
SETUP(CR2)
ALLOCATION(TS2_B2)
ALLOCATION COMP(TS1)
SETUP-ACK or other messages (CR1-B1)
FE establishment completeALLOCATION COMP(TS2)
SETUP-ACK or other messages (CR2-B2)
NAT
FE allocation request
FE establishment complete
Figure 8-22 Two ISDN call setup flows simultaneously started at one ISDN user port
