| draft-bidulock-sigtran-isua-01 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-isua-01.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
July 26, 2003
Expires in January 2004
SS7 ISUP-User Adaptation Layer
(ISUA)
<draft-bidulock-sigtran-isua-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 or RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress'.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines a protocol for the transport of any SS7 ISUP-
User signalling (e.g, Call Control) over IP using the Stream Control
Transport Protocol [RFC 2960]. The protocol should be modular and
symmetric, to allow it to work in diverse architectures, such as a
Signalling Gateway and IP Signalling End-point architecture. Protocol
elements are added to allow seamless operation between peers in the
SS7 and IP domains.
B. Bidulock Version 0.1 Page 1
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Contents
A complete table of contents, list of illustrations, list of tables
and document change history appear at the end of this document.
1. Introduction
This draft defines a protocol for the transport of SS7 ISUP [Q.761,
T1.113] Users (i.e, Call Control) signalling messages over IP using
the Stream Control Transmission Protocol (SCTP) [RFC 2960]. This
protocol would be used between a Signalling Gateway (SG) and
Signalling End-point located in an IP network. Additionally, the
protocol can be used to transport SS7 ISUP users between two
signalling end-points located within an IP network.
1.1. Scope
There is on-going integration of SCN networks and IP networks.
Network service providers are designing all IP architectures that
include support for SS7 signalling protocols. IP provides an
effective way to transport user data and for operators to expand their
networks and build new services. In these networks, there is a need
for interworking between the SS7 and IP domains [RFC 2719].
This document details the delivery of Call Control messages over IP
between two signalling end-points. Consideration is given for the
transport from an SS7 Signalling Gateway (SG) to an IP signalling node
(such as an IP-resident Database) as described in the Framework
Architecture for Signalling Transport [RFC 2719] This protocol can
also support transport of Call Control messages between two end-points
wholly contained within and IP network.
The delivery mechanism addresses the following criteria:
+ Support for transfer of ISUP messages (Call Control)
+ Support for the seamless operation of Call Control protocol peers.
+ Support for the management of SCTP transport associations between
an SG and one ore more IP-based signalling nodes.
+ Support for distributed IP-based signalling nodes.
+ Support for the asynchronous reporting of status changes to
management.
1.2. Abbreviations and Terminology
1.2.1. Abbreviations
ANSI -- American National Standards Institute.
API -- Application Programming Interface.
AS -- Application Server.
ASP -- Application Server Process.
BLA -- Blocking Acknowledgement.
B. Bidulock Version 0.1 Page 2
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
BLO -- Blocking Request.
CA -- Certificate Authority.
CC -- Call Control.
CCR -- Continuity Check Request.
CGBA -- Circuit Group Blocking Acknowledgement.
CGB -- Circuit Group Blocking Request.
CGUA -- Circuit Group Unblocking Acknowledgement.
CGU -- Circuit Group Unblocking Request.
CMF -- Circuit Mapping Function.
COT -- Continuity Test.
CP -- Call Processing.
CQM -- Circuit Group Query Request.
CQR -- Circuit Group Query Response.
CTP -- Common Transport Protocol.
ETSI -- European Telecommunication Standards Institute.
GRS -- Group Reset.
HLR -- Home Location Register.
IANA -- Internet Assigned Numbers Authority.
IETF -- Internet Engineering Task Force.
IP -- Internet Protocol.
IPSP -- IP Signalling Point.
ISDN -- Integrated Services Digital Network.
ISO -- International Standards Organization.
ISUA -- SS7 ISUP-User Adaptation Layer.
ISUP -- ISDN User Part.
ITU -- International Telecommunications Union.
L1 -- Layer 1.
LM -- Layer Management.
LPA -- Loop Back Acknowledgement.
MGC -- Media Gateway Controller.
MTP2 -- MTP Level 2.
MTP3 -- MTP Level 3.
MTP -- Message Transfer Part.
NA -- Network Appearance.
NIF -- Network Interworking Function.
PSTN -- Public Switched Telephone Network.
RC -- Routing Context.
RFC -- Request For Comments.
RK -- Routing Key.
RKM -- Routing Key Management.
RSC -- Reset Circuit.
SCN -- Switch Circuit Network.
SCP -- Service Control Point.
SCTP -- Stream Control Transmission Protocol.
SG -- Signalling Gateway.
SGP -- Signalling Gateway Process.
SS7 -- Signalling System No. 7.
SSP -- Service Switching Point.
STP -- Signalling Transfer Point.
TLI -- Transport Layer Interface.
TLS -- Transport Layer Security.
TLV -- Tag-Length-Value.
UBA -- Unblocking Acknowledgement.
B. Bidulock Version 0.1 Page 3
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
UBL -- Unblocking Request.
VPN -- Virtual Private Network.
XTI -- X/Open Transport Interface.
1.2.2. Terminology
Application Server (AS) - a logical entity serving a specific Routing
Key. An example of an Application Server is a virtual database
element handling all HLR or SCP transactions for a particular SS7
Signalling Point. The AS contains a set of one or more unique
Application Server Processes, of which one or more is normally
actively processing traffic. There is a one-to-one relationship
between an Application Server and a Routing Key.
Application Server Process (ASP) - a process instance of an
Application Server. An Application Server Process serves as an
active, backup, load-share or broadcast process of an Application
Server (e.g, part of a distributed signalling node or database
element). Examples of ASPs are MGCs, IP SCPs, or IP HLRs. An ASP
contains an SCTP end-point and may be configured to process
traffic within more that one Application Server.
Association - refers to an SCTP association [RFC 2960]. The
association provides the transport for the delivery of ISUP
protocol data units and ISUA layer peer messages.
Call Control - The layer above the ISDN User Part in the SS7 protocol
stack that exchanges primitives with the ISUP provider. Call
Control has two major functional blocks: Call Processing and
Circuit Supervision. Unlike other layers of the SS7 stack, ISUP
does not have individual "Users" or ISUP-SAPs. A single Call
Control entity is responsible for controlling both ISUP and other
switch signalling stacks at the Application Layer of the ISO
7-layer model. for
Call Processing] - Call Processing is a major functional block of both
ISUP and Call Control which is responsible for signalling and
controlling the state of calls (as opposed to circuits).
Circuit Supervision] - Circuit Supervision is a major functional block
of both ISUP and Call Control which is responsible for signalling
and controlling the state of circuits (as opposed to calls).
Fail-over - the capability to reroute signalling traffic as required
to an alternate Application Server Process, or group of ASPs,
within an Application Server in the event of failure or
unavailability of a currently used Application Server Process.
Fail-over may apply upon the return to service of a previously
unavailable Application Server Process.
Host - the computing platform that the process (SGP, ASP or IPSP) is
running on.
B. Bidulock Version 0.1 Page 4
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
IP Server Process (IPSP) - a process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except
that it uses ISUA in a point-to-point fashion.
ISDN User Part (ISUP) - The Integrated Services Digital Network (ISDN)
User Part [Q.761, T1.113] of the SS7 protocol.
Layer Management (LM) - a nodal function that handles the inputs and
outputs between the ISUA layer and a local management entity.
Message Transfer Part (MTP) - The Message Transfer Part [Q.701,
T1.111] of the SS7 protocol.
Nodal Interworking Function (NIF) - an implementation dependent
interworking function present at a Signalling Gateway that
interworks primitives and procedures between the ISUP and ISUA
layers in the SG.
Network Appearance (NA) - a value that identifies the SS7 network
context of a Routing Key. The Network Appearance value is of
significance only within an administrative domain; it is
coordinated between the SG and ASP.
Network Byte Order - the ordering of bytes most-significant-byte
first, also referred to as Big Endian.
Routing Context (RC) - a value that uniquely identifies a Routing Key
and an Application Server. Routing Context values are either
configured using a configuration management interface, or by using
the Routing Key Management (RKM) messages and procedures defined
for ISUA.
Routing Key (RK) - describes a set of SS7 parameters and parameter
values that uniquely define the range of signalling traffic to be
handled by a particular Application Server.
Signalling Gateway (SG) - a signalling agent that exchanges SCN native
signalling at the edge of the IP network [RFC 2719]. An SG
appears to the SS7 network as an SS7 Signalling Point. An SG
contains a set of one or more Signalling Gateway Processes, of
which one or more is normally actively processing traffic. When
an SG contains more than one SGP, the SG is a logical entity and
the contained SGPs are assumed to be coordinated into a single
management view both toward the SS7 network and toward the
supported Application Servers.
Signalling Gateway Process (SGP) - a process instance of a Signalling
Gateway. It serves as an active, backup, load-sharing or
broadcast process of a Signalling Gateway.
Stream - an SCTP stream; a unidirectional logical channel established
from one SCTP endpoint to another associated SCTP endpoint, within
which all user messages are delivered in sequence, except for
those submitted to the unordered delivery service.
B. Bidulock Version 0.1 Page 5
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Circuit Mapping Function (CMF) - an implementation dependent function
that is responsible for resolving the address and application
context presented in the incoming ISUA message to the correct SCTP
association and Routing Context for the desired application. The
CMF MAY use routing context or routing key information as
selection criteria for the appropriate SCTP association.
Transport Address - an address that serves as a source or destination
for the unreliable packet transport service used by SCTP. In IP
networks, a transport address is defined by the combination of IP
address and an SCTP port number [1].
1.3. ISUA Overview
1.3.1. Signalling Transport Architecture
The framework architecture that has been defined for SCN signalling
transport over IP [RFC 2719] uses multiple components, including an IP
transport protocol, a signalling common transport protocol and an
adaptation module to support the services expected by a particular SCN
signalling protocol from its underlying protocol layer.
In general terms, the ISUA architecture can be modeled as a peer-
to-peer architecture. The first section considers the SS7-to-IP
interworking architectures for ISUP call control. For this case, it
is assumed that the ASP initiates the establishment of the SCTP
association with the SG.
1.3.2. Protocol Architecture for Call Control
In this architecture (illustrated in Figure 1), the ISUP and ISUA
layers interface in the SG. A Nodal Interworking Function (NIF)
provides for interworking between the ISUP and ISUA layers and
provides for the transfer of the call processing as well as circuit
supervision messages.
B. Bidulock Version 0.1 Page 6
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
......... ............... .........
: : : : : :
: SEP : SS7 : : IP : :
: or :.........: SG :........: ASP :
: STP : : : : :
:.......: :.............: :.......:
_______ _____________ _______
| | | | | |
| CC | | NIF | | CC |
|-------| |------ ------| |-------|
| ISUP | | ISUP | ISUA | | ISUA |
|-------| |------|------| |-------|
| MTP3 | | MTP3 | | | |
|-------| |------| SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
|-------| |------|------| |-------|
| L1 | | L1 | IP | | IP |
|_______| |______|______| |_______|
| | | |
|________________| |_______________|
CC - Call Control
STP - SS7 Signaling Transfer Point
NIF - Nodal Interworking Function
Figure 1. Protocol Architecture
1.3.3. All IP Architecture
This architecture, illustrated in Figure 2, can be used to carry a
protocol which uses the transport services of ISUP, but is contained
within an IP network. This allows extra flexibility in developing
networks, especially when interaction between legacy signalling is not
needed. The architecture removes the need for a signalling gateway
function.
B. Bidulock Version 0.1 Page 7
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
........ ........
: : IP : :
: AS :........: AS :
: : : :
:......: :......:
______ ______
| | | |
| AP | | AP |
|------| |------|
| ISUA | | ISUA |
|------| |------|
| SCTP | | SCTP |
|------| |------|
| IP | | IP |
|______| |______|
| |
|________________|
AP - Application Protocol (e.g. - Call Control)
Figure 2. All IP Architecture
1.3.4. ASP Fail-over Model and Terminology
The ISUA protocol supports ASP fail-over functions to support a
high availability of transaction processing capability.
An Application Server can be considered as a list of all ASPs
configured or registered to handled Call Control messages within a
certain range of routing information, or within a certain set of
transaction dialogues, known as a `Routing Key.' One or more ASPs in
the list may normally be active to handle traffic, while others may be
inactive but available in the event of failure or unavailability of
the active ASPs.
For operational considerations, see Appendix A.
1.3.5. Services Provided by the ISUA Layer
1.3.5.1. Support for the transport of Call Control Messages
The ISUA supports the transfer of Call Control messages. The ISUA
layer at the SG and the ASP support the seamless transport of user
messages between the SG and the ASP.
1.3.5.1.1. ISUP Call Control Support
Depending on the specific implementation of Call Control supported,
the ISUA shall support Call Control transparently. Call Control
consists of two major functional blocks:
Call Processing is responsible for signalling and control of calls
(as opposed to circuits). Call processing functions move a call
B. Bidulock Version 0.1 Page 8
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
through its life-cycle by providing the following functions:
+ call setup,
+ call suspend/resume,
+ call release,
+ call exception handling.
Circuit Supervision is responsible for signalling and control of
circuits (as opposed to calls). Circuit supervision functions affect
the management state of circuits and provides the following functions:
+ circuit testing,
+ circuit reset,
+ circuit blocking and unblocking due to hardware failure and
recovery events,
+ circuit blocking and unblocking maintenance action,
+ circuit state query.
1.3.5.2. Native Management Functions
The ISUA layer provides the capability to indicate errors
associated with the ISUA protocol messages and to provide notification
to local circuit management and the remote peer as necessary.
1.3.5.3. Interworking with Circuit Supervision Functions
The ISUA layer provides interworking with Circuit Supervision
functions at the SG for seamless inter-operation between the SCN
network and the IP network. ISUA provides the following circuit
supervision functions:
+ Provides an indication or accpets a request to perform a continuity
check on a circuit.
+ Provides an indication or accepts a request to reset a circuit or
circuit group.
+ Provides an indication or accepts a request to block a circuit or
circuit group.
+ Provides an indication or accepts a request to unblock a circuit or
circuit group.
+ Provides an indication or accepts a request to query a circuit or
circuit group.
The interworking with ISUP circuit supervision messages consists of
CCNT, CCNA, CREP, CRSC, CBLO, CBLA, CUBL, CUBA, CQRY and CQRA messages
on receipt of circuit supervision events to the appropriate ASPs. The
primitives in Table 1 are sent between the ISUP and ISUA circuit
supervision functions in the SG to trigger events in the IP and SS7
domain.
The ISUA layer provides transparent passing of circuit reset,
blocking and query primitives (RESET, BLOCKING, UNBLOCKING, CCT GROUP
QUERY) as provided for in ITU-T Q.724 [Q.724] Q.764 [Q.764], and ANSI
T1.113 [T1.113].
B. Bidulock Version 0.1 Page 9
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Table 1. Mapping of Circuit Supervision Primitives
+---------------------------+---------------------------+------------+
| Name | Message | ISUA |
+--------------+------------+-------------+-------------+ Cc't Supv. |
| Generic [2] | Specific | ITU-T Q.764 | ANSI T1.113 | Message |
+--------------+------------+-------------+-------------+------------+
|CONT RECHECK | Request | CCR | CCR | CCNT |
| | Indication | | | |
| +------------+-------------+-------------+------------+
| | Response | - | LPA | CCNA |
| | Confirm | | | |
+--------------+------------+-------------+-------------+------------+
|CONT REPORT | Request | COT | COT | CREP |
| | Indication | | | |
+--------------+------------+-------------+-------------+------------+
|RESET | Request | RSC, GRS | RSC, GRS | CRSC |
| +------------+-------------+-------------+------------+
| | Confirm | RLC, GRA | RLC, GRA | CRSA |
+--------------+------------+-------------+-------------+------------+
|BLOCKING | Request | BLO, CGB | BLO, CGB | CBLO |
| | Indication | | | |
| +------------+-------------+-------------+------------+
| | Response | BLA, CGBA | BLA, CGBA | CBLA |
| | Confirm | | | |
+--------------+------------+-------------+-------------+------------+
|UNBLOCKING | Request | UBL, CGU | UBL, CGU | CUBL |
| | Indication | | | |
| +------------+-------------+-------------+------------+
| | Response | UBA, CGUA | UBA, CGUA | CUBA |
| | Confirm | | | |
+--------------+------------+-------------+-------------+------------+
|CCT GRP QUERY | Request | CQM | CQM | CQRY |
| | Indication | | | |
| +------------+-------------+-------------+------------+
| | Response | CQR | CQR | CQRA |
| | Confirm | | | |
+--------------+------------+-------------+-------------+------------+
1.3.5.4. Support for the Management of SCTP Associations
The ISUA layer at the SGP maintains the availability state of all
configured remote ASPs, to manage the SCTP Associations and the
traffic between ISUA peers. As well, the active/inactive and
congestion state of remote ASPs is maintained.
The ISUA layer MAY be instructed by local management to establish
an SCTP association to a peer ISUA node. This can be achieved using
the M-SCTP_ESTABLISH primitives to request, indicate and confirm the
establishment of an SCTP association with a peer ISUA node. To avoid
redundant SCTP associations between two ISUA peers, one side (client)
SHOULD be designated to establish the SCTP association, or ISUA
configuration information maintained to detect redundant associations
B. Bidulock Version 0.1 Page 10
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
(e.g, via knowledge of the expected local and remote SCTP endpoint
addresses).
Local management MAY request from the ISUA layer the status of the
underlying SCTP associations using the M-SCTP_STATUS request and
confirm primitives. Also, the ISUA MAY autonomously inform local
management of the reason for the release of an SCTP association,
determined either locally within the ISUA layer or by a primitive from
the SCTP.
Also, the ISUA layer MAY inform the local management of the change
in status of an ASP or AS. This MAY be achieved using the M-
ASP_STATUS request or M-AS_STATUS request primitives.
1.4. Functional Areas
1.4.1. Circuit Identifiers, Routing Contexts and Routing Keys
1.4.1.1. Overview
The mapping of ISUP messages into calls between the SGP and the
Application Servers is determined by Circuit Identifiers, Routing Keys
and their associated Routing Contexts.
A Routing Key is essentially a set of ISUP parameters used to
direct ISUP messages; whereas, the Routing Context parameter is a
4-byte value (unsigned integer) that is associated to that Routing Key
in a one-to-one relationship. The Routing Context therefore can be
viewed as an index into a sending node's Circuit Mapping Function
tables containing the Routing Key entries.
Possible ISUP address/routing information that comprise a Routing
Key entry includes, for example, a local and remote Point Code, and a
Circuit Identification Code or Call Control specific information such
as Circuit Group or Trunk Group Identifiers. The particular
information used to define a ISUA Routing Key is application and
network dependent, and none of the above examples are requirements for
ISUA.
An Application Server Process (ASP) may be configured to process
signalling traffic related to more than one Application Server (AS),
over a single SCTP Association. ASP Active (ASPAC) and ASP Inactive
(ASPIA) management messages (see Section 3) use the Routing Context to
discriminate signalling traffic to be started or stopped. At an ASP,
the Routing Context parameter uniquely identifies the range of
signalling traffic associated with each Application Server that the
ASP is configured to receive.
1.4.1.2. Routing Key Limitations
Routing Keys SHOULD be unique in the sense that each received ISUP
message SHOULD have a full or partial match to a single routing
result. It is not necessary for the parameter range values within a
particular Routing Key to be continuous. For example, an AS could be
B. Bidulock Version 0.1 Page 11
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
configured to support call processing for multiple ranges of circuits
that are not represented by contiguous Circuit Identification Codes.
1.4.1.3. Managing Routing Context and Routing Keys
There are two ways to provision a Routing Key at an SGP. A Routing
Key may be configured statically using an implementation dependent
management interface, or dynamically managed using the the ISUA
Routing Key registration procedures.
When using a management interface to configure Routing Keys, the
Circuit Mapping Function within the SGP is not limited to the set of
parameters defined in this document. Other implementation dependent
distribution algorithms may be used.
1.4.1.4. Circuit Mapping Function
To perform its addressing and relaying capabilities, the ISUA makes
use of an Circuit Mapping Function (CMF). This function is considered
part of ISUA, but the way it is realized is left implementation or
deployment dependent (local tables, database, etc.)
The CMF is invoked when a message is received at the incoming
interface. The CMF is responsible for resolving the Circuit
Identification Code (CIC) and any necessary ISUP message parameters
presented in the incoming ISUP message to SCTP associations and
destinations within the IP network. The CMF will select the key
information available. The Routing Keys reference an Application
Server, which will normally have one or more ASPs processing
transactions for the AS. The availability and status of the ASPs is
handled by ISUA ASP management messages.
Possible SS7 routing information that comprise a Routing Key entry
includes, for example, ISUP Circuit Identification Code (CIC), Range
and Status parameters.
It is expected that the routing keys will be provisioned via a MIB,
dynamic registration or an external process, such as a database.
1.4.1.4.1. Circuit Mapping at the SG
To direct messages received from the SS7 network to the appropriate
IP destination, the SGP must perform a circuit mapping function using
information from the received ISUP message.
To support this circuit mapping, the SGP might, for example,
maintain the equivalent of a network address translation table,
mapping incoming ISUP message information to an Application Server for
a particular application and set of transactions. This could be
accomplished by comparing the circuit identification code and range
and status portions of the incoming ISUP message to currently defined
Routing Keys in the SGP. These Routing Keys could in turn map
directly to an Application Server that is enabled by one or more ASPs.
These ASPs proxy dynamic status information regarding their
B. Bidulock Version 0.1 Page 12
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
availability, call handling capabilities and congestion to the SGP
using various management messages defined in the ISUA protocol.
The list of ASPs in the AS is assumed to be dynamic, taking into
account the availability, call handling capability and congestion
status of the individual ASPs in the list, as well as configuration
changes and possible fail-over mechanisms.
Normally, one or more ASPs are active in the AS (i.e, currently
processing calls) but in certain failure and transition cases it is
possible that there may not be an active ASP available. The SGP will
buffer the message destined for this AS for a time T(r) or until an
ASP becomes available. When no ASP becomes available before expiry of
T(r), the SGP will flush the buffered messages and initiate the
appropriate ISUP call clearing procedures.
If there is no match for an incoming message, a default treatment
MAY be specified. Possible solutions are to provide a default
Application Server to direct all unallocated call processing and
circuit supervision messages to a (set of) default ASP(s), or to drop
the messages and provide a notification to management. The treatment
of unallocated circuits is implementation dependent.
1.4.1.4.2. Circuit Mapping at the ASP
To direct messages to the SS7 network, the ASP MAY perform a
circuit mapping to choose the proper SGP for the given message. This
is accomplished by observing the Circuit Identification Code, Range
and Status, and other elements of the outgoing message, SS7 network
status, SGP availability, and Routing Context configuration tables.
A Signalling Gateway may be composed of one or more SGPs. There
is, however, no ISUA messaging to manage the status of an SGP.
Whenever an SCTP association to an SGP exists, it is assumed to be
available. Also, every SGP of one SG communicating with one ASP
regarding one AS provides identical call control to this ASP.
In general, an ASP routes responses to the SGP that it received
messages from; within the routing context which it is currently active
and receiving transactions. The routing context itself is used by the
ASP to select the SGP.
1.4.1.5. Signalling Gateway SS7 Layers
The SG is responsible for terminating up to the Call Control of the
SS7 protocol, and offering an IP-based extension to its users.
From an SS7 perspective, it is expected that the Signalling Gateway
transmits and receives ISUP messages to and from the SS7 Network over
standard SS7 network interfaces, using the services of the MTP [Q.704]
to provide transport of the messages.
Note that it is also possible for the MTP services to be provided
using the services of the MTP-User Adaptation Layer (M3UA) [M3UA].
B. Bidulock Version 0.1 Page 13
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
The ISUP-SAP through which ISUA at the SG obtains its services
could reside at a Signalling Transfer Point (STP) or Signalling End
Point (SEP) [Q.701].
1.4.1.6. SS7 and ISUA Interworking at the SG
The SGP provides a functional interworking of transport functions
between the SS7 network and the IP network by also supporting the ISUA
adaptation layer. It allows the ISUP application to exchange call
control messages with an IP-based Application Server Process where the
peer Call Control protocol layer exists.
To perform ISUP circuit supervision, it is required that the Call
Control protocols at ASPs receive indications of circuit state, as
well as call state as they would be expected by an SS7 ISUP
application. To accomplish this, the RESET, BLOCKING, UNBLOCKING and
CCT GROUP QUERY primitives received at the ISUP upper layer interface
at the SG need to be propagated to the remote Call Control lower layer
interface at the ASP.
ISUP call processing and circuit supervision messages (such as BLO,
BLA, CGB, CGBA) received from the SS7 network MUST NOT be
encapsulated. The SG MUST terminate these messages and generate ISUA
message as appropriate.
1.4.1.7. Application Server
A cluster of Application Servers is responsible for providing the
overall support for one ore more SS7 upper layers. From an ISUP
standpoint, Call Control provides complete support for the upper layer
service for given Circuits or Trunk Groups. As an example, Call
Control could provide complete support for Central Office Call Control
for a given point code.
1.4.1.8. SCTP Stream Mapping
The ISUA supports SCTP streams. The SG and AS need to maintain a
list of SCTP and Call Control for mapping purposes. Call Control
requiring sequenced message transfer need to be sent over a stream
using sequenced delivery.
ISUA SHOULD NOT use stream 0 for ISUA circuit supervision messages.
It is OPTIONAL that sequence delivery be used to preserve the order of
circuit supervision message delivery.
All ISUA Circuit Supervision (CS) messages MAY select unordered
delivery, depending on the requirements of Call Control. Normally one
stream is used to send ISUA Circuit Supervision (CS) messages between
peers, regardless of Application Server.
All Call Processing (CP) messages MUST be sent using ordered
delivery. All Call Processing (CP) messages relating to the same call
MUST be sent on the same stream as other Call Processing (CP) messages
relating to the same call. The stream selected is based upon the Call
B. Bidulock Version 0.1 Page 14
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Reference given by the Call Control over the primitive interface and
other traffic information available to the SGP or ASP.
1.4.2. Redundancy Models
1.4.2.1. Application Server Redundancy
All CSET and Circuit Supervision (CS) messages (e.g, SETUP, RESET,
BLOCKING) which match a provisioned Routing Key at an SGP are mapped
to an Application Server.
The Application Server is the set of all ASPs associated with a
specific Routing Key. Each ASP in this set may be active, inactive or
unavailable. Active ASPs handle traffic; inactive ASPs might be used
when active ASPs become unavailable.
The fail-over model supports an "n+k" redundancy model, where "n"
ASPs is the minimum number of redundant ASPs required to handle
traffic and "k" ASPs are available to take over for a failed or
available ASP. A "1+1" active/backup redundancy is a subset of this
model. A simplex "1+0" model is also supported as a subset, with no
ASP redundancy.
1.4.3. Flow Control
Local Management at an ASP may wish to stop traffic across an SCTP
association to temporarily remove the association from service or to
perform testing and maintenance activity. The function could
optionally be used to control the start of traffic onto a newly
available SCTP association.
1.4.4. Congestion Management
The ISUA layer is informed of local and IP network congestion by
means of an implementation-dependent function (e.g, an implementation-
dependent indication from the SCTP of IP network congestion).
At an ASP or IPSP, the ISUA layer indicates congestion to local
Call Control by means of an appropriate ISUP primitive, as per current
ISUP procedures, to invoke appropriate upper layer responses. When an
SG determines that the transport of SS7 messages is encountering
congestion, the SG might trigger SS7 Congestion messages to
originating SS7 nodes, per the congestion procedures of the relevant
ISUP [T1.113, Q.764] or MTP [T1.111, Q.704] standard. (The triggering
of SS7 Management messages from an SG is an implementation-dependent
function.)
1.5. Definition of ISUA Boundaries
ISUA has three protocol boundaries: an upper boundary between ISUA
and Call Control; a lower boundary between ISUA and SCTP; and a layer
management boundary between ISUA and the Layer Management Function.
Figure 3 illustrates the ISUA protocol boundaries.
B. Bidulock Version 0.1 Page 15
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
...........
: CC :
:.........: Layer
Upper Boundary : Management
____:____ Boundary ............
| ISUA |.............: LM :
|_________| :..........:
Lower Boundary :
.....:.....
: SCTP :
:.........:
Figure 3. ISUA Protocol Boundaries
1.5.1. Definition of Upper Boundary
The primitives and messages listed in Table 2 are provided between
the ISUA and Call Control in support of Call Control [Q.761, T1.113].
Table 2. Mapping of Call Control Primitives
+-------------+------------+---------------+---------------+------+
|Generic | Specific | ITU-T Q.764 | ANSI T1.113 | ISUA |
|Name | Name | Message | Message | Msg |
+-------------+------------+---------------+---------------+------+
|Call Setup Messages |
+-------------+------------+---------------+---------------+------+
|SETUP | Request | IAM | IAM | CSET |
| | Indication | | | |
| +------------+---------------+---------------+------+
| | Response | ANM, CON | ANM | CCON |
| | Confirm | | | |
+-------------+------------+---------------+---------------+------+
|MORE INFO | Request | - | - | CMOR |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|TIMEOUT | Indication | - | - | CTOT |
+-------------+------------+---------------+---------------+------+
|INFO | Request | SAM | SAM | CINF |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|PROC | Request | ACM, CPG | ACM, CPG | CPRO |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|ALERT | Request | ACM, CPG | ACM, CPG | CALR |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|PROG | Request | ACM, CPG | ACM, CPG | CPRG |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
B. Bidulock Version 0.1 Page 16
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
+-------------+------------+---------------+---------------+------+
|Generic | Specific | ITU-T Q.764 | ANSI T1.113 | ISUA |
|Name | Name | Message | Message | Msg |
+-------------+------------+---------------+---------------+------+
|Call Established Messages |
+-------------+------------+---------------+---------------+------+
|SUSPEND | Request | SUS | SUS | CSUS |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|RESUME | Request | RES | RES | CRES |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|Call Termination Messages |
+-------------+------------+---------------+---------------+------+
|REATTEMPT | Indication | - | - | CREA |
+-------------+------------+---------------+---------------+------+
|CALL FAILURE | Indication | RST, REL, RLC | RST, REL, RLC | CERR |
+-------------+------------+---------------+---------------+------+
|IBI | Request | ACM, CPG | ACM, CPG | CIBI |
| | Indication | | | |
+-------------+------------+---------------+---------------+------+
|RELEASE | Request | REL | REL | CREL |
| | Indication | | | |
| +------------+---------------+---------------+------+
| | Response | REL, RLC | REL, RLC | CRLC |
| | Confirm | | | |
+-------------+------------+---------------+---------------+------+
1.5.2. Definition of Boundary between ISUA and Layer Management
M-SCTP_ESTABLISH request
Direction: LM->ISUA
Purpose: LM request ASP to establish an SCTP association with its
peer.
M-SCTP_ESTABLISH confirm
Direction: ISUA -> LM
Purpose: ASP confirms to LM that it has established an SCTP
association with its peer.
M-SCTP_ESTABLISH indication
Direction: ISUA -> LM
Purpose: ISUA informs LM that a remote ASP has established an SCTP
association.
M-SCTP_RELEASE request
Direction: LM -> ISUA
Purpose: LM requests ASP to release an SCTP association with its
peer.
M-SCTP_RELEASE confirm
B. Bidulock Version 0.1 Page 17
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Direction: ISUA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with its peer.
M-SCTP_RELEASE indication
Direction: ISUA -> LM
Purpose: ISUA informs LM that a remote ASP has released an SCTP
Association or the SCTP association has failed.
M-SCTP RESTART indication
Direction: ISUA -> LM
Purpose: ISUA informs LM that an SCTP restart indication has been
received.
M-SCTP_STATUS request
Direction: LM -> ISUA
Purpose: LM requests ISUA to report the status of an SCTP
association.
M-SCTP_STATUS confirm
Direction: ISUA -> LM
Purpose: ISUA responds with the status of an SCTP association.
M-SCTP_STATUS indication
Direction: ISUA -> LM
Purpose: ISUA reports the status of an SCTP association.
M-ASP_STATUS request
Direction: LM -> ISUA
Purpose: LM requests ISUA to report the status of a local or
remote ASP.
M-ASP_STATUS confirm
Direction: ISUA -> LM
Purpose: ISUA reports status of local or remote ASP.
M-AS_STATUS request
Direction: LM -> ISUA
Purpose: LM requests ISUA to report the status of an AS.
M-AS_STATUS confirm
Direction: ISUA -> LM
Purpose: ISUA reports the status of an AS.
M-NOTIFY indication
Direction: ISUA -> LM
Purpose: ISUA reports that it has received a Notify (NTFY) message
from its peer.
M-ERROR indication
Direction: ISUA -> LM
B. Bidulock Version 0.1 Page 18
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Purpose: ISUA reports that it has received an Error (ERR) message
from its peer or that a local operation has been
unsuccessful.
M-ASP_UP request
Direction: LM -> ISUA
Purpose: LM requests ASP to start its operation and send an ASP Up
(ASPUP) message to its peer.
M-ASP_UP confirm
Direction: ISUA -> LM
Purpose: ASP reports that is has received an ASP UP Ack (ASPUP
ACK) message from its peer. T} ; ls l1lw(5.7i). M-
ASP_UP indication Direction:;ISUA -> LM Purpose:;T{ ISUA
reports it has successfully processed an incoming ASP Up
(ASPUP) message from its peer.
M-ASP_DOWN request
Direction: LM -> ISUA
Purpose: LM requests ASP to stop its operation and send an ASP
Down (ASPDN) message to its peer.
M-ASP_DOWN confirm
Direction: ISUA -> LM
Purpose: ASP reports that is has received an ASP Down Ack (ASPDN
ACK) message from its peer.
M-ASP_DOWN indication
Direction: ISUA -> LM
Purpose: ISUA reports it has successfully processed an incoming
ASP Down (ASPDN) message from its peer, or the SCTP
association has been lost or reset.
M-ASP_ACTIVE request
Direction: LM -> ISUA
Purpose: LM requests ASP to send an ASP Active (ASPAC) message to
its peer.
M-ASP_ACTIVE confirm
Direction: ISUA -> LM
Purpose: ASP reports that is has received an ASP Active Ack (ASPAC
ACK) message from its peer.
M-ASP_ACTIVE indication
Direction: ISUA -> LM
Purpose: ISUA reports it has successfully processed an incoming
ASP Active (ASPAC) message from its peer.
M-ASP_INACTIVE request
Direction: LM -> ISUA
Purpose: LM requests ASP to send an ASP Inactive (ASPIA) message
to its peer.
B. Bidulock Version 0.1 Page 19
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
M-ASP_INACTIVE confirm
Direction: LM -> ISUA
Purpose: ASP reports that is has received an ASP Inactive Ack
(ASPIA ACK) message from its peer.
M-ASP_INACTIVE indication
Direction: ISUA -> LM
Purpose: ISUA reports it has successfully processed an incoming
ASP Inactive (ASPIA) message from its peer.
M-AS_ACTIVE indication
Direction: ISUA -> LM
Purpose: ISUA reports that an AS has moved to the AS-ACTIVE state.
M-AS_INACTIVE indication
Direction: ISUA -> LM
Purpose: UA reports that an AS has moved to the AS-INACTIVE state.
M-AS_DOWN indication
Direction: ISUA -> LM
Purpose: UA reports that an AS has moved to the AS-DOWN state.
If the ISUA layer supports dynamic registration of Routing Key, the
layer MAY support the following additional primitives:
M-RK_REG request
Direction: LM -> ISUA
Purpose: LM requests ASP to register RK(s) with its peer by
sending Registration Request (REG REQ) message
M-RK_REG confirm
Direction: ISUA -> LM
Purpose: ASP reports that it has received Registration Response
(REG RSP) message with registration status as successful
from its peer.
M-RK_REG indication
Direction: ISUA -> LM
Purpose: ISUA informs LM that it has successfully processed an
incoming Registration Request (REG REQ) message.
M-RK_DEREG request
Direction: LM -> ISUA
Purpose: LM requests ASP to deregister RK(s) with its peer by
sending Deregistration Request (DEREG REQ) message.
M-RK_DEREG confirm
Direction: ISUA -> LM
B. Bidulock Version 0.1 Page 20
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Purpose: ASP reports that it has received Deregistration Request
(DEREG REQ) message with deregistration status as
successful from its peer.
M-RK_DEREG indication
Direction: ISUA -> LM
Purpose: ISUA informs LM that it has successfully processed an
incoming Deregistration Request (DEREG REQ) message from
its peer.
1.5.3. Definition of the Lower Boundary
The upper layer primitives provided by the SCTP are provided in the
SCTP specification "Stream Control Transmission Protocol (SCTP)" [RFC
2960].
Notes for Section 1
[1] IMPLEMENTATION NOTE:- Only one SCTP port may be defined for
each endpoint, but each SCTP endpoint may have multiple IP
addresses [RFC 2960].
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
appear in this document, are to be interpreted as described in [RFC
2119].
In this document, the following conventions are used to describe how a
parameter is used in the message:
Mandatory The parameter MUST be present in the message. A
message listing a parameter as Mandatory without
containing such a parameter is is incorrectly
formatted.
Conditional The parameter SHOULD be present in the message
under the conditions specified. A message listing
a parameter as Conditional without containing such
a parameter under the conditions specified is
incorrectly formatted.
Optional The parameter MAY be present in the message as
specified. A message listing a parameter as
Optional without containing such a parameter is
correctly formatted.
B. Bidulock Version 0.1 Page 21
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3. Protocol Elements
The general message format includes a Common Message Header
together with a list of zero or more parameters as defined by the
Message Type.
For forward compatibility, all Message Types MAY have attached
parameters even if none are specified in this version.
3.1. Common Message Header
The protocol messages for the ISUP-User Adaptation Protocol (ISUA)
require a message structure that contains a version, message type,
message length and message contents:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+---------------+---------------+---------------+---------------+
| Message Length |
+---------------------------------------------------------------+
| Message Data |
Notes:
+ This message header is common among all signalling protocol
adaptation layers.
+ The 'data' portion of ISUA messages SHALL contain zero or more ISUA
parameters, and SHALL NOT contain an encapsulated ISUP message.
+ All fields in the ISUA message MUST be transmitted in the network
byte order, unless otherwise stated.
+ The Reserved field SHALL be coded zero by the sender of the message
and SHALL be ignored by the receiver of the message.
3.1.1. ISUA Protocol Version
Version: 8-bits (unsigned integer)
The Version field of the Common Message Header contains the version
of the ISUA adaptation layer. The supported versions are:
1 - ISUA Version 1.0
3.1.2. Message Classes
Message Class: 8-bits (unsigned integer)
The Message Class field of the Common Message Header contains the
class of the message. The supported classes are as follows:
B. Bidulock Version 0.1 Page 22
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 Management (MGMT) Message
7 Reserved for Other Signalling Adaptation Layers
2 Reserved for Other Signalling Adaptation Layers
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Reserved for Other Signalling Adaptation Layers
6 Reserved for Other Signalling Adaptation Layers
7 Reserved for Other Signalling Adaptation Layers
8 Reserved for Other Signalling Adaptation Layers
9 Routing key Management (RKM) Messages
10 ISUA Call Processing (CP) Messages
11 ISUA Circuit Supervision (CS) Messages
12 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.3. Message Types
Message Type: 8-bits (unsigned integer)
The Message Type field of the Common Message Header contains the
type of message within a message class. The supported types of
messages within the supported classes are as follows:
Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process State Maintenance (ASPSM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heartbeat Ack (BEAT ACK)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process Traffic Maintenance (ASPTM) Messages
0 Reserved
1 ASP Active (ASPAC)
2 ASP Inactive (ASPIA)
3 ASP Active Ack (ASPAC ACK)
4 ASP Inactive Ack (ASPIA ACK)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Routing Key Management (RKM) Messages
B. Bidulock Version 0.1 Page 23
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 Reserved
1 Registration Request (REG REQ)
2 Registration Response (REG RSP)
3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
ISUA Call Processing (CP) Messages
0 Reserved
1 Setup (CSET)
2 More Information (CMOR)
3 Timeout (CTOT)
4 Information (CINF)
5 Proceeding (CPRO)
6 Alerting (CALR)
7 Progress (CPRG)
8 Connect (CCON)
9 Suspend (CSUS)
10 Resume (CRES)
11 Reattempt (CREA)
12 Failure (CERR)
13 In Band Information (CIBI)
14 Release (CREL)
15 Release Complete (CRLC)
16 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
ISUA Circuit Supervision (CS) Messages
0 Reserved
1 Continuity Check (CCNT)
2 Loop Back (CLBK)
3 Report (CREP)
4 Reset (CRSC)
5 Reset Acknowledgement (CRSA)
6 Block (CBLO)
7 Block Acknowledgement (CBLA)
8 Unblock (CUBL)
9 Unblock Acknowledgement (CUBA)
10 Query (CQRY)
11 Query Acknowledgement (CQRA)
12 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.4. Message Length
Message Length: 32-bits (unsigned integer)
The Message Length field of the Common Message Header defines the
length of the message in octets, including the header.
B. Bidulock Version 0.1 Page 24
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3.1.5. Tag-Length-Value Format
ISUA messages consist of a Common Message Header followed by zero
or more parameters, as defined by the message type. The Tag-Length-
Value (TLV) parameters contained in a message are defined in a Tag-
Length-Value format as shown below [1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-------------------------------+-------------------------------+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Tag: 16-bits (unsigned integer)
The Parameter Tag field is a 16-bit identifier of the type of
parameter. It takes a value of 0 to 65534.
Parameter Length: 16-bits (unsigned integer)
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. However, composite parameters will contain all padding
bytes, since all parameters contained within this composite
parameter will considered multiples of 4 bytes.
Parameter Value: 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 4 bytes. If the length of the parameter is not a
multiple of 4 bytes, the sender MUST pad the Parameter at the end
(i.e., after the Parameter Value field) with all zero bytes. The
length of the padding MUST NOT be included in the parameter length
field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
3.2. ISUA Message Header
In addition to the Common Message Header, a specific message header
is included for ISUA messages. The ISUA message header will
immediately follow the Common Message Header in ISUA Call Processing
(CP) and Circuit Supervision (CS) messages.
The ISUA Message Header is formatted as follows:
B. Bidulock Version 0.1 Page 25
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Routing Context |
+-------------------------------+-------------------------------+
| Tag = 0x0013 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ISUA Message header can contain the following parameters:
Parameters
---------------------------------------------
Routing Context Conditional *1
Correlation Id Conditional *2
Note 1: When an ASP is registered or configured for multiple AS with
an SG, the Routing Context MUST be present in the ISUA Message
Header. The Routing Context SHOULD always be placed in the
ISUA Message Header. When the Routing Context is present in
the ISUA Message Header it SHOULD be placed first in the
header because the context of the Correlation Id depends on
the Routing Context.
Note 2: Under some circumstances, the Correlation Id parameter MUST be
included in the ISUA Message Header. See sections "3.9.9 -
Correlation Id" and "4.3.4.3 - ASP Active Procedures".
3.3. ISUA Call Processing (CP) Messages
The following section describes the ISUA Call Processing (CP)
messages and parameter contents. The general message format includes
a Common Message Header, the ISUA Message Header and the CP Message
Header, together with a list of zero or more parameters as defined by
the Message Type. For forward compatibility, all Message Types MAY
have optional attached parameters in addition to the message headers.
These messages are ISUA Call Processing (CP) messages:
ISUA Call Processing (CP) Messages
----------------------------------------------------
Message Name Message Type Section
----------------------------------------------------
CP Header 3.3.1
Setup CSET 1 3.3.2
More Information CMOR 2 3.3.3
B. Bidulock Version 0.1 Page 26
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Timeout CTOT 3 3.3.4
Information CINF 4 3.3.5
Proceeding CPRO 5 3.3.6
Alerting CALR 6 3.3.7
Progress CPRG 7 3.3.8
Connect CCON 8 3.3.9
Suspend CSUS 9 3.3.10
Resume CRES 10 3.3.11
Reattempt CREA 11 3.3.12
Failure CERR 12 3.3.13
In Band Information CIBI 13 3.3.14
Release CREL 14 3.3.15
Release Complete CRLC 15 3.3.16
----------------------------------------------------
3.3.1. CP Message Header
In addition to the Common Message Header and ISUA Message Header, a
specific message header is included for ISUA Call Processing (CP)
messages. The CP Message Header will immediately follow the ISUA
Message header in these messages.
The CP Message Header is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0520 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Circuit Id |
+-------------------------------+-------------------------------+
| Tag = 0x0501 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Call Reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CP Message Header contains the following parameters:
Parameters
---------------------------------------------
Circuit Id Conditional *1
Call Reference Conditional *2
Note 1: The Circuit Id MUST be placed in the ISUA CP Message Header
for all CP messages sent from the SGP to the ASP, and is
OPTIONAL in the ISUA CP Message Header for all CP messages
sent from the ASP to the SGP for which a Circuit Id was
assigend to the call by the SGP before the message was sent.
If Circuit Id was not assigned by the SGP before the ASP sends
a CP message, the ASP MAY include the Circuit Id parameter for
B. Bidulock Version 0.1 Page 27
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
simplicity, but it MUST then be coded zero (0). CP messages
for which a Circuit Id has not been assigned by the SGP
include only the Setup (CSET) request message sent from the
ASP to the SGP.
Note 2: The Call Reference MUST be placed in the ISUA CP Message
Header for all CP messages sent from ASP to the SGP, and is
OPTIONAL in the ISUA CP Message Header for all CP messages
sent from the SGP to the ASP for which a Call Reference was
assigned to the call by the ASP before the message was sent.
If Call Reference was not assigned by the ASP before the SGP
sends a CP message, the SGP MAY include the Call Reference
parameter for simplicity, but it MUST then be coded zero (0).
CP messages for which a Call Reference has not been assigned
by the ASP include only the Setup (CSET) indication message
sent from the SGP to the ASP.
3.3.2. Setup (CSET)
The Setup (CSET) Request message is sent from an ASP to an SG or
IPSP to initiate an outgoing ISUP call setup. The CSET Indication
message is sent from an SGP to an ASP to indicate an incoming ISUP
call setup.
The CSET message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Setup' (Request, Indication) primitive and the ITU-T and
ANSI ISUP `IAM' message [T1.113, Q.763].
The CSET message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0502 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Call Type |
+-------------------------------+-------------------------------+
| Tag = 0x0503 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Call Flags |
+-------------------------------+-------------------------------+
| Tag = 0x0504 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Called Party Number /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B. Bidulock Version 0.1 Page 28
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
The CSET message can contain the following parameters:
Parameters
-------------------------------------------
Call Type Mandatory
Call Flags Mandatory
Called Party Number Mandatory
Optional Parameters Optional *1
Note 1: Although the Optional Parameters are optional in the CSET
message, the specific ISUP variant and network policy in which
the implementation is operating could require that the
implementation always place specific parameters in the
Optional Parameters parameter. An example of this would be
the Charge Number of GR-394 networks.
3.3.3. More Information (CMOR)
The More Information (CMOR) message is sent from an SGP to an ASP
to request additional address information for an outgoing ISUP call
setup.
The CMOR message does not correspond to a Call Control primitive or
ISUP message.
The COMR message has no message-type-specific parameters beyond the
CP Message Header.
3.3.4. Timeout (CTOT)
The Timeout (CTOT) message is sent from an SGP to an ASP to
indicate that the SG has timed out while waiting for additional
address information.
The CTOT message does not correspond to a Call Control primitive or
ISUP message.
The CTOT message has no message-type-specific parameters beyond the
CP Message Header.
3.3.5. Information (CINF)
The Information (CINF) message is sent from an ASP to an SGP to
provide additional address information for an outgoing ISUP call
setup. The CINF message is sent from an SGP to an ASP to provide
additional address information for an incoming ISUP call setup.
The CINF message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Info' primitive and the ITU-T and ANSI ISUP `SAM'
message [T1.113, Q.763].
B. Bidulock Version 0.1 Page 29
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
The CINF message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0505 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Subsequent Number /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CINF message can contain the following parameters:
Parameters
------------------------------------------
Subsequent Number Mandatory
Optional Parameters Optional
Note 1:
3.3.6. Proceeding (CPRO)
The Proceeding (CPRO) message is sent from an ASP to an SG to
indicate that an outgoing call setup is proceeding. The CPRO message
is sent from an SGP to an ASP to indicate that an incoming call setup
is proceeding.
The CPRO message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`Proceeding' primitive and the ITU-T and ANSI ISUP `ACM' and `CPG'
message [T1.113, Q.763].
The CPRO message is formatted as follows:
B. Bidulock Version 0.1 Page 30
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0508 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Proceeding Flags |
+-------------------------------+-------------------------------+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CPRO message can contain the following parameters:
Parameters
-------------------------------------------
Proceeding Flags Mandatory
Optional Parameters Optional
*1
Note 1:
3.3.7. Alerting (CALR)
The Alerting (CALR) message is sent from an ASP to an SG to
indicate that the terminating access on a incoming call setup is being
alerted. The CALR message is sent from an SGP to an ASP to indicate
that the terminating access on an outgoing call setup is being
alerted.
The CALR message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`Alerting' primitive and the ITU-T and ANSI `IAM' message [T1.113,
Q.763].
The CALR message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CALR message can contain the following parameters:
B. Bidulock Version 0.1 Page 31
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Parameters
------------------------------------------
Optional Parameters Optional
*1
Note 1:
3.3.8. Progress (CPRG)
The Progress (CPRG) message is sent from an ASP to an SG to
indicate that an incoming call setup is in progress. The CPRG message
is sent from an SGP to an ASP to indicate that an outgoing call setup
is in progress.
The CPRG message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`Progress' primitive and the ITU-T and ANSI ISUP `ACM' and `CPG'
message [T1.113, Q.763].
The CPRG message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0509 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Progress Event |
+-------------------------------+-------------------------------+
| Tag = 0x050A | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Progress Flags |
+-------------------------------+-------------------------------+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CPRG message can contain the following parameters:
Parameters
-------------------------------------------
Progress Event Mandatory
Progress Flags Mandatory
Optional Parameters Optional
*1
Note 1:
B. Bidulock Version 0.1 Page 32
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3.3.9. Connect (CCON)
The Connect (CCON) message is sent from an ASP to an SG to indicate
that an incoming ISUP call has been connected. The CCON message is
sent from an SGP to an ASP to indicate that an outgoing ISUP call has
ben connected.
The CCON message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Setup' (Response and Confirmation) primitive and the
ITU-T `ANM' and `CON' and ANSI `ANM' message [T1.113, Q.763].
The CCON message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CCON message can contain the following parameters:
Parameters
------------------------------------------
Optional Parameters Optional
*1
Note 1:
3.3.10. Suspend (CSUS)
The Suspend (CSUS) message is sent from the ASP to an SG or from
the SGP to the ASP to indicate that an established call has been
suspended.
The CSUS message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Suspend' primitive and the ITU-T and ANSI `SUS' message
[T1.113, Q.763].
The CSUS message is formatted as follows:
B. Bidulock Version 0.1 Page 33
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050B | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Suspend/Resume Flags |
+-------------------------------+-------------------------------+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CSUS message can contain the following parameters:
Parameters
------------------------------------------
Suspend/Resume Flags Mandatory
Optional Parameters Optional
Note 1:
3.3.11. Resume (CRES)
The Resume (CRES) message is sent from the ASP to an SG or from the
SGP to the ASP to indicate that a previously suspended established
call has been resumed.
The CRES message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Resume' primitive and the ITU-T and ANSI `RES' message
[T1.113, Q.763].
The CRES message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050B | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Suspend/Resume Flags |
+-------------------------------+-------------------------------+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B. Bidulock Version 0.1 Page 34
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
The CRES message can contain the following parameters:
Parameters
------------------------------------------
Suspend/Resume Flags Mandatory
Optional Parameters Optional
Note 1:
3.3.12. Reattempt (CREA)
The Reattempt (CREA) Indication message is sent from an SGP to an
ASP to indicate that a call attempt on a circuit should be reattempted
on an alternate circuit.
If the ASP selected the outgoing circuit in the corresponding CSET,
then the ASP is responsible for selecting another circuit and issuing
a new CSET message. If the ASP did not select the outgoing circuit in
the corresponding CSET message, then the SGP is responsible for
performing an automatic reattempt on a new circuit or subsequently
indicating call failure with a CERR message.
The CREA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Reattempt' primitive and does not correspond to an ISUP
message.
The CREA message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0506 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Reattempt Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CREA message can contain the following parameters:
Parameters
------------------------------------------
Reattempt Reason Mandatory
3.3.13. Failure (CERR)
The Failure (CERR) message is sent from an ASP to an SG to indicate
the failure of an incoming call setup. The CERR message is sent from
an SGP to an ASP to indicate the failure of an outgoing call setup.
The CERR message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Failure `Call Failure' primitive and the ITU-T and ANSI `RST,'
B. Bidulock Version 0.1 Page 35
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
`REL' and `RLC' message [T1.113, Q.763].
The CERR message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050C | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Failure Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CERR message can contain the following parameters:
Parameters
-------------------------------------------
Failure Reason Mandatory
*1
Note 1:
3.3.14. In Band Information (CIBI)
The In Band Information (CIBI) message is sent from an ASP to an SG
to indicate that in band information is now available for an incoming
call. The CIBI message is sent from an SGP to an ASP to indicate that
in band information is now available for an outgoing call.
The CIBI message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Setup `In Band Information' primitive and the ITU-T and ANSI
`ACM' and `CPG' message [T1.113, Q.763].
The CIBI message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Optional Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CIBI message can contain the following parameters:
Parameters
------------------------------------------
B. Bidulock Version 0.1 Page 36
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Optional Parameters Optional
*1
3.3.15. Release (CREL)
The Release (CREL) message is sent from an ASP to an SG or from the
SGP to an ASP to release a call during the setup or established phase.
The CREL message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Release' (Request, Indication) primitive and the ITU-T
and ANSI `REL' message [T1.113, Q.763].
The CREL message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050D | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CREL message can contain the following parameters:
Parameters
------------------------------------------
Cause Mandatory
3.3.16. Release Complete (CRLC)
The Release Complete (CRLC) message is sent from an ASP to an SG or
from an SGP to an ASP to confrim the release of a call.
The CRLC message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Release' (Response, Confirmation) primitive and the ITU-
T and ANSI `REL' and `RLC' message [T1.113, Q.763].
The CRLC message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x050D | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CRLC message can contain the following parameters:
B. Bidulock Version 0.1 Page 37
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Parameters
------------------------------------------
Cause Mandatory
3.4. ISUA Circuit Supervision (CS) Messaegs
ISUA Circuit Supervision (CS) Messages are used to convey circuit
management information to Call Control. Theses messages correspond to
specific RESET, BLOCKING, UNBLOCKING and CCT GROUP QUERY primitives.
The general message format includes a Common Message Header, the ISUA
Message Header, and the CS Message Header, together with a list of
zero or more parameters as defined by the Message Type. For forward
compatibility, all Message Types MAY have optional attached parameters
in addition to the message headers.
These messages are ISUA Circuit Supervision (CS) Messages:
ISUA Circuit Supervision (CS) Messages
--------------------------------------------------------
Message Name Message Type Section
--------------------------------------------------------
CS Header 3.4.1
Continuity Check CCNT 6 3.4.2
Loop Back CLBK 7 3.4.3
Report CREP 8 3.4.4
Reset CRSC 1 3.4.5
Reset Acknowledgement CRSA 2 3.4.6
Block CBLO 3 3.4.7
Block Acknowledgement CBLA 4 3.4.8
Unblock CUBL 5 3.4.9
Unblock Acknowledgement CUBA 6 3.4.10
Query CQRY 7 3.4.11
Query Acknowledgement CQRA 8 3.4.12
--------------------------------------------------------
3.4.1. CS Message Header
In addition the the Common Message Header and ISUA Message Header,
a specific message header is included for ISUA Circuit Supervision
(CS) messages. The CS Message Header will immediately follow the ISUA
Message Header in these messages.
The CS Message Header is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0520 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Circuit Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B. Bidulock Version 0.1 Page 38
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
The CS Message Header contains the following parameters:
Parameters
------------------------------------------
Circuit Id Mandatory
3.4.2. Continuity Check (CCNT)
The Continuity Check (CCNT) message is sent from an ASP to an SGP
to request an continuity check on a specified circuit. The CCNT
message is sent from an SGP to an ASP to indicate an a continuity
check request on the specified circuit.
The CCNT message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Continuity Recheck' (Request) primitive and the ITU-T
and ANSI ISUP `CCR' message [T1.113, Q.763].
The CCNT message has no message-type-specific parameters beyond the
CS Message Header.
3.4.3. Loop Back (CLBK)
The Loop Back (CLBK) message is sent from an ASP to an SGP to
indicate that a loop back has been established on the local end of the
specified circuit. The CLBK message is sent from an ASP to an SGP to
indicate that a loop back has been establish on the remote end of the
specified circuit.
The CLBK message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
Call Control `Continuity Recheck' (Confirmation) primitive and the
ITU-T and ANSI ISUP `LPA' message [T1.113, Q.763].
The CLBK message has no message-type-specific parameters beyond the
CS Message Header.
3.4.4. Report (CREP)
The Report (CREP) Request message is sent from an ASP to SG or from
an SGP to an ASP to indicate the success or failure of a continuity
test operation on the specified circuit.
The CREP message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`Continuity Report' primitive and the ITU-T and ANSI ISUP `COT'
message [T1.113, Q.763].
The CREP message is formatted as follows:
B. Bidulock Version 0.1 Page 39
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0507 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Check Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CREP message can contain the following parameters:
Parameters
------------------------------------------
Check Result Mandatory
3.4.5. Reset (CRSC)
The Reset (CRSC) message is sent from an ASP to an SG to request
the reset of the specified circuit(s). The CRSC message is sent from
the SGP to an ASP to indicate the reset reset of the specified
circuit(s).
The CRSC message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`Reset' (Request) primitive and the ITU-T and ANSI ISUP `RSC' and
`GRS' message [T1.113, Q.763].
The CRSC message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CRSC message can contain the following parameters:
Parameters
---------------------------------------------
Circuit Range Conditional *1
Note 1: When the Circuit Range parameter is included in the message,
the CRSC message corresponds to the `GRS' message. When the
Circuit Range is not present in the message, the CRSC message
corresponds to the `RSC' message.
B. Bidulock Version 0.1 Page 40
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3.4.6. Reset Acknowledgement (CRSA)
The Reset Acknowledgement (CRSA) message is sent from an SGP to an
ASP to confirm the reset of the specified circuit(s).
The CRSA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`Reset' (Confirmation) primitive and the ITU-T and ANSI ISUP `RLC' and
'GRA' message.
The CRSA message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CRSA message can contain the following parameters:
Parameters
---------------------------------------------
Circuit Range Conditional *1
Note 1: When the Circuit Range parameter is included in the message,
the CRSA message corresponds to the `GRA' message and the
Circuit Range parameter SHOULD match the corresponding
parameter in the CRSC request message. When the Circuit Range
is not present in the message, the CRSA message corresponds to
the `RLC' message.
3.4.7. Block (CBLO)
The CBLO Request message is sent from an ASP to an SG or IPSP to
perform a blocking request. The CBLO Indication message is sent from
the SGP to an ASP to indicate the blocking indication.
The CBLO message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`BLOCKING' primitive and the ITU-T and ANSI `BLO' and `CGB' message.
The CBLO message is formatted as follows:
B. Bidulock Version 0.1 Page 41
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CBLO message can contain the following parameters:
Parameters
---------------------------------------------
Circuit Range Conditional *1
Note 1: When the Circuit Range parameter is included in the message,
the CBLO message corresponds to the `CGB' message. When the
Circuit Range is not present in the message, the CBLO message
corresponds to the `BLO' message.
3.4.8. Block Acknowledgement (CBLA)
The Block Acknowledgement (CBLA) Request message is sent from an
ASP to an SG or IPSP to perform a blocking response. The CBLA
Indication message is sent from the SGP to an ASP to indicate the
blocking confirmation.
The CBLA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`BLOCKING' primitive and the ITU-T and ANSI `BLA' and `CGBA' message.
The CBLA message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CBLA message can contain the following parameters:
Parameters
---------------------------------------------
Circuit Range Conditional *1
B. Bidulock Version 0.1 Page 42
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Note 1: When the Circuit Range parameter is included in the message,
the CBLA message corresponds to the `CGBA' message and the
Circuit Range parameter SHOULD match the corresponding
parameter in the CBLO request message. When the Circuit Range
is not present in the message, the CBLA message corresponds to
the `BLA' message.
3.4.9. Unblock (CUBL)
The Unblock (CUBL) Request message is sent from an ASP to an SG or
IPSP to perform a unblocking request. The CUBL Indication message is
sent from the SGP to an ASP to indicate the unblocking indication.
The CUBL message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`UNBLOCKING' primitive and the ITU-T and ANSI `UBL' and `CGU' message.
The CUBL message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CUBL message can contain the following parameters:
Parameters
---------------------------------------------
Circuit Range Conditional *1
Note 1: When the Circuit Range parameter is included in the message,
the CUBL message corresponds to the `CGU' message. When the
Circuit Range is not present in the message, the CUBL message
corresponds to the `UBL' message.
3.4.10. Unblock Acknowledgement (CUBA)
The Unblock Acknowledgement (CUBA) Request message is sent from an
ASP to an SG or IPSP to perform a unblocking response. The CUBA
Indication message is sent from the SGP to an ASP to indicate the
unblocking confirmation.
The CUBA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`UNBLOCKING' primitive and the ITU-T and ANSI `UBA' and `CGUA'
message.
B. Bidulock Version 0.1 Page 43
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
The CUBA message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CUBA message can contain the following parameters:
Parameters
---------------------------------------------
Circuit Range Conditional *1
Note 1: When the Circuit Range parameter is included in the message,
the CUBA message corresponds to the `CGUA' message and the
Circuit Range parameter SHOULD match the corresponding
parameter in the CUBL request message. When the Circuit Range
is not present in the message, the CUBA message corresponds to
the `UBA' message.
3.4.11. Query (CQRY)
The Query (CQRY) Request message is sent from an ASP to an SG or
IPSP to perform a query request. The CQRY Indication message is sent
from the SGP to an ASP to indicate the query indication.
The CQRY message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`CCT GROUP QUERY' primitive and the ITU-T and ANSI `CQM' message.
The CQRY message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0523 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Range /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CQRY message can contain the following parameters:
B. Bidulock Version 0.1 Page 44
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
Parameters
------------------------------------------
Circuit Range Mandatory 1
3.4.12. Query Acknowledgement (CQRA)
The Query Acknowledgement (CQRA) Request message is sent from an
ASP to an SG or IPSP to perform a query response. The CQRA Indication
message is sent from the SGP to an ASP to indicate the query
confirmation.
The CQRA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
`CCT GROUP QUERY' primitive and the ITU-T and ANSI `CQMA' message.
The CQRA message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x05XX | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Circuit Status /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CQRA message can contain the following parameters:
Parameters
-------------------------------------------
Circuit Status Mandatory *1
Note 1: The Circuit Status parameter SHOULD contain a circuit status
for each of the circuit identifiers present in the
corresponding CQRY message.
3.5. Application Server Process State Maintenance (ASPSM) Messages
3.5.1. ASP Up (UP)
The ASP Up (UP) message is used to indicate to a remote ISUA peer
that the Adaptation layer is up and running.
The ASP UP message is formatted as follows:
B. Bidulock Version 0.1 Page 45
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| ASP Identifier |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ASP UP message can contain the following parameters:
Parameters
---------------------------------------------
ASP Identifier Conditional *1
Info String Optional
Note 1: ASP Identifier MUST be used where the IPSP/SGP cannot identify
the ASP by pre-configured address/port number information
(e.g, where an ASP is resident on a Host using dynamic
address/port number assignment).
3.5.2. ASP Up Ack (UP ACK)
The ASP Up Ack (UP ACK) message is used to acknowledge an ASP UP
message received from a remote ISUA peer.
The ASP UP ACK message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ASP UP ACK message can contain the following parameters:
Parameters
-----------------------------------------
Info String Optional
B. Bidulock Version 0.1 Page 46
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3.5.3. ASP Down (DOWN)
The ASP Down (DOWN) message is used to indicate to a remote ISUA
peer that the adaptation layer is not running.
The ASP DOWN message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ASP DOWN message can contain the following parameters:
Parameters
-----------------------------------------
Info String Optional
3.5.4. ASP Down Ack (DOWN ACK)
The ASP Down Ack (DOWN ACK) message is used to acknowledge an ASP
DOWN message received from a remote ISUA peer.
The ASP DOWN ACK message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ASP DOWN ACK message can contain the following parameters:
Parameters
-----------------------------------------
Info String Optional
Note:
The ASP DOWN ACK message will always be sent to acknowledge an
ASP DOWN message.
B. Bidulock Version 0.1 Page 47
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3.5.5. Heartbeat (BEAT)
The Heartbeat (BEAT) message is optionally used to ensure that the
ISUA peers are still available to each other.
The BEAT message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BEAT message can contain the following parameters:
Parameters
-----------------------------------------
Heartbeat Data Optional
3.5.6. Heartbeat Ack (BEAT ACK)
The Heartbeat ACK (BEAT ACK) message is sent in response to a BEAT
message. A peer MUST send a BEAT ACK in response to a BEAT message.
It includes all the parameters of the received BEAT message, without
any change.
The BEAT ACK message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BEAT ACK message can contain the following parameters:
Parameters
-----------------------------------------
Heartbeat Data Optional
B. Bidulock Version 0.1 Page 48
Internet Draft SS7 ISUP-User Adaptation Layer July 26, 2003
3.6. Application Server Process Traffic Maintenance (ASPTM) Messages
3.6.1. ASP Active (ASPAC)
The ASP Active (ASPAC) message is sent by an ASP to indicate to a
remote ISUA peer that it is Active and ready to process signalling
traffic for a particular Application Server.
The ASPAC message is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Routing Context /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x000B | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Traffic Mode Type |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - |
Documentation