The ISDN User Part (ISUP) defines the protocol and procedures used to set-up, manage, and release

trunk
circuits that carry voice and data calls over the public switched telephone network (PSTN). ISUP is used for
both ISDN and non-ISDN calls. Calls that originate and terminate at the same switch do not use ISUP
signaling.

Basic ISUP Call Control

Figure 8 depicts the ISUP signaling associated with a basic call.

When a call is placed to an out-of-switch number, the originating SSP transmits an ISUP initial
address message (IAM) to reserve an idle trunk circuit from the originating switch to the
destination switch (1a). The IAM includes the originating point code, destination point code, circuit
identification code (circuit "5" in Fig. 8), dialed digits and, optionally, the calling party number and
name. In the example below, the IAM is routed via the home STP of the originating switch to the
destination switch (1b). Note that the same signaling link(s) are used for the duration of the call
unless a link failure condition forces a switch to use an alternate signaling link.

Figure 8. Basic ISUP Signaling

The destination switch examines the dialed number, determines that it serves the called party, and
that the line is available for ringing. The destination switch rings the called party line and transmits
an ISUP address complete message (ACM) to the originating switch (2a) (via its home STP) to
indicate that the remote end of the trunk circuit has been reserved. The STP routes the ACM to the
originating switch (2b), then the terminating switch provides power ringing to the called party and
audible ringing tone to the calling party.
In the example shown above, the originating and destination switches are directly connected with
trunks. If the originating and destination switches are not directly connected with trunks, the
originating switch transmits an IAM to reserve a trunk circuit to an intermediate switch. The
intermediate switch sends an ACM to acknowledge the circuit reservation request and then
transmits an IAM to reserve a trunk circuit to another switch. This processes continues until all

trunks required to complete the voice circuit from the originating switch to the destination switch are
reserved.

When the called party picks up the phone, the destination switch terminates the ringing tone and

transmits an ISUP answer message (ANM) to the originating switch via its home STP (3a). The
STP routes the ANM to the originating switch (3b) which verifies that the calling party's line is
connected to the reserved trunk and, if so, initiates billing.
If the calling party hangs-up first, the originating switch sends an ISUP release message (REL) to

release the trunk circuit between the switches (4a). The STP routes the REL to the destination
switch (4b). If the called party hangs up first, or if the line is busy, the destination switch sends an
REL to the originating switch indicating the release cause (e.g., normal release or busy).
Upon receiving the REL, the destination switch disconnects the trunk from the called party's line,
sets the trunk state to idle, and transmits an ISUP release complete message (RLC) to the
originating switch (5a) to acknowledge the release of the remote end of the trunk circuit. When the
originating switch receives (or generates) the RLC (5b), it terminates the billing cycle and sets the
trunk state to idle in preparation for the next call.

ISUP messages may also be transmitted during the connection phase of the call (i.e., between the ISUP
Answer (ANM) and Release (REL) messages.

ISUP Message Format

ISUP information is carried in the Signaling Information Field (SIF) of an MSU. The SIF contains the routing
label followed by a 14-bit (ANSI) or 12-bit (ITU) circuit identification code (CIC). The CIC indicates the
trunk circuit reserved by the originating switch to carry the call. The CIC is followed by the message type
field (e.g., IAM, ACM, ANM, REL, RLC) which defines the contents of the remainder of the message (Fig. 9).

Figure 9. ISUP Message Format

Each ISUP message contains a mandatory fixed part containing mandatory fixed-length parameters.
Sometimes the mandatory fixed part is comprised only of the message type field. The mandatory fixed part
may be followed by the mandatory variable part and/or the optional part. The mandatory variable part
contains mandatory variable-length parameters. The optional part contains optional parameters which are
identified by a one-octet parameter code followed by a length indicator ("octets to follow") field. Optional
parameters may occur in any order. If optional parameters are included, the end of the optional parameters
is indicated by an octet containing all zeros.

Initial Address Message

An Initial Address Message (IAM) is sent in the "forward" direction by each switch needed to complete the
circuit between the calling party and called party until the circuit connects to the destination switch. An IAM
contains the called party number in the mandatory variable part and may contain the calling party name and
number in the optional part.

Supports multi-rate connection establishment, circuit maintenance, connection

release and abnormal conditions for multi-rate calls. Multi-rate connections are
circuit switched connections requiring more than one bearer channel. This feature
is part of the ANSI 95, ITU 97 and ETSI v3 specifications.
Supports working in a decomposed media network. ISUP supports the multiple
SAP feature, which enables ISUP to support multiple SAPs (both upper and
lower) for the same variant and network type.
Supports the Distributed Fault-Tolerant/High-Availability (DFT/HA) Core
architecture.
Supports the recovery of lost primitives crossing the upper, lower and layer
management interfaces.
Supports the configurable call validation testing behavior during MTP3 Resume
primitive for the ANSI 95 variant.
Supports enbloc and overlap signalling.
Supports international and national capabilities.
Supports link-by-link signaling using the pass-along method and end-to-end
signaling using the SCCP method.
Supports multiple variants including ITU-T 1988, 1992, and 1997, ANSI 1988,
1992, and 1995, ETSI v2, ETSI v3, Italy, Germany (FTZ), Russia, Singapore,
NTT (Japan), Telcordia GR-317 and GR-394 and India 2000.
Each link may be configured to support a variant independent of any other link.
For example, one link may support ITU 1988 while another link supports ANSI
1992.
Supports supplementary services, including user access to calling party address id,
user access to called party address id, user-to-user signalling and call forwarding.
Supports Local Number Portability (LNP) for ANSI and Telcordia.
Supports multiple Originating Point Codes (OPCs).

S
S
7
I
S
U
P
M
e
s
s
a
g
e
F
o
r
m
a
t
:

I
S
D

Support message compatibility, parameter compatibility and wrong parameter

values procedures.
Supports circuit management procedures including blocking, unblocking and
reset.
Supports circuit group management procedures including blocking, unblocking,
reset and query.
Supports message segmentation procedures for ITU, ETSI, FTZ and India
variants.
Supports configurable call clearing behavior for MTP3 Pause/Resume priorities.
Supports passing proprietary parameters transparent between upper and lower
layers.
Supports Fault-Tolerant/High-Availability (FT/HA) for operation in an
active/standby environment when used in conjunction with the Protocol Specific
Function for ISUP (PSF - ISUP).
Conforms to Trillium Advanced Portability Architecture (TAPA)
Benefits of licensing Trillium software from Continuous Computing

N
U
s
e
r
P
a
r
t
M
e
s
s
a
g
e
s
a
r
e
c
a
r
r
i
e
d
o
n
t
h
e
s
i
g
n
a
l
i
n
g
l
i
n
k
b
y

m
e
a
n
s
o
f
s
i
g
n
a
l
u
n
i
t
s
.
T
h
e
s
e
r
v
i
c
e
i
n
d
i
c
a
t
o
r
f
o
r
I
S
U
P
i
s

c
o
d
e
d
0
1
0
1
.
T
h
e
s
i
g
n
a
l
i
n
g
i
n
f
o
r
m
a
t
i
o
n
f
i
e
l
d
o
f
e
a
c
h
m
e
s
s

a
g
e
s
i
g
n
a
l
u
n
i
t
c
o
n
t
a
i
n
i
n
g
S
S
7
I
S
U
P
m
e
s
s
a
g
e
c
o
n
s
i
s
t
s
o
f
t

h
e
f
o
l
l
o
w
i
n
g
p
a
r
t
s
.
a
)
R
o
u
t
i
n
g
l
a
b
e
l
:
F
o
r
e
a
c
h
i
n
d
i
v
i
d

u
a
l
c
i
r
c
u
i
t
c
o
n
n
e
c
t
i
o
n
,
t
h
e
s
a
m
e
r
o
u
t
i
n
g
l
a
b
e
l
m
u
s
t
b
e

u
s
e
d
f
o
r
e
a
c
h
m
e
s
s
a
g
e
t
h
a
t
i
s
t
r
a
n
s
m
i
s
t
t
e
d
f
o
r
t
h
a
t
c
o
n

n
e
c
t
i
o
n
.

b
)
C
I
C
C
i
r
c
u
i
t
I
d
e
n
t
i
f
i
c
a
t
i
o
n
C
o
d
e
:
W
i
t
h
t

h
i
s
C
I
C
C
o
d
e
,
e
x
c
h
a
n
g
e
i
d
e
n
t
i
f
i
e
d
s
w
h
i
c
h
c
a
l
l
c
i
r
c
u
i
t
r
e

f
e
r
s
w
h
i
c
h
s
i
g
n
a
l
.
c) Message Type Code : Consists of one octet field and mandatory for all messages. It uniquely defines the
function and format of each ISUP message. Such as IAM, ACM, ANM etc.
d) The mandatory fixed part :These are the parameters that are mandatory and of fixed length for a particular
message type will be contained in the mandatory fixed part. The position, length and order of parameters is
uniquely defined by the message type because of that the names of the parameters and the length of the
indicators are not included in the message.
e) The mandatory variable part :Mandatory parameters of variable length will be included in the mandatory
variable part. Pointers are used to indicate the beginning of each parameter. Each pointer is encoded as a single
octet. The name of the parameter and the order in which the parameters are sent is implicit in the message
type. The parameters names are therefore not included in the message. A pointer is also included to indicate the
beginning of the optional part. All the pointers are sent consecutively at the beginning of the mandatory variable
part. Each parameter contains the parameter length indicator followed by the contents of the parameter.
f) The optional part, which may contain fixed length and variable length parameter fields. : The optional part
consists of parameters that may or may not occur in particular message type. Both fixed and variable length
parameters may be included. Optional parameters cann be transmitted in any order. Each optional parameter will
include an parameter name (one octet) and the length indicator (one octet) followed by the parameter contents.
If optional parameters are present and after all parameters have been sent, an "end of optional parameters"
octet containin all zeros will be transmitted. If there is no optional parameter present then there is no "end of
optional parameter" octet is transmitted.
There might be situations where there is a need for national message types and parameters then the codes
should be chosen from the highest code downwards i.e. starting at code 11111111. The codes reserved in the
range 11111111 to 11100000 for this purpose.

3.0 Basic Call Control and Signaling Overview

3.1 SS7 IUSP Protocol
The SS7 ISUP protocol was created as the interexchange signaling between
ISDN access and PSTN , and also used as the interworking between ISDN
access and egress in PSTN.
For an unrestricted 64-kpbs circuit switched example, the ISDN Q.931 and
SS7 ISUP interworking can be showed in Figure 1.
+--------+
+------+
+------+
+-------+
| Called |
Q.931
| Orig.| SS7 ISUP | Dest.|
Q.931
|Calling|
| Party |
| Exch.|
| Exch.|
| Party |
+--------+
+------+
+------+
+-------+
|
|
|
|
|--------SETUP------>|
|
|
|
|--------IAM-------->|
|
|<-----CALL PROC-----|
|------SETUP------->|
|
|
|
|
|
|
|<--CALL PROC (opt)-|
|
|
|
|
|
|
|<-----ALERT--------|
|
|<-------ACM---------|
|
|<-------ALERT-------|
|<-----CONN---------|
|
|<-------ANM---------|
|
|<-------CONN--------|
|------CONN ACK---->|
|
|
|
|
|---CONN ACK (opt)-->|
|
|
|
|
|
|
+-------------------------------------------------------------+
|
Call Information Flow
|
+-------------------------------------------------------------+
|
|
|
|
|
|
|<-----DISC---------|
|
|<-------REL---------|
|
|<------DISC---------|
|------REL--------->|
|
|--------RLC-------->|
|
|-------REL--------->|
|<-----REL COMP-----|
|
|
|
|
|<------REL COMP-----|
|
|
|
|
|
|
Figure 1. Q.931-ISUP interworking for an ISDN call control
One of the important information elements in the Q.931 SETUP message
is the B-channel Bearer Capability, which is put in the ISUP User
Service Information parameter to indicate the requested service from
the network. The ISUP uses the CIC parameter in all of its messages to
identify the physical circuit(s) being set up based on the bearer
request from the called party.
In telecommunication industry, any emerging networks, including ISDNs,
have to interwork with other existing networks, notably the PSTNs that
are the largest and most numerous among the existing networks. For

example, a digital telephone set connected to an ISDN basic rate (2B+D)

interface certainly needs to be able to talk with a conventional set to
the conventional PSTN, which the bearer capability of speech or 3.1-kHz
audio is requested from the network to set up the call. By using ISUP,
there is no change required for either ISDN or PSTN, and protocol
conversion is provided at the ISDN interworking exchanges.
3.2 H.225 and H.245 Protocols
As we know, the packet-based IP network has the fundamental differences
from the circuit-based network PSTN. One of the important differences is
that there is no actual channel, such as ISDN B-channel or PSTN trunk
circuit, in the IP network. In other words, the H.323 terminals can have
more "channels", logical channels to carry more than one application,
such as video, audio or data, in ONE call. Because of this difference,
the call control in VoIP specified in ITU H.323 is more complicated.
In circuit-based network, the call signaling (i.e., setup and teardown)
and bearer capability control are processed in one protocol, Q.931 for
ISDN and ISUP for SS7 network. However, since different H.323 terminals
in VoIP may have different logical channel capabilities, ITU H.323 has
specified the call signaling and bearer capability control in two
separate protocols, H.225 and H.245.
The call signaling specified in H.225 begins by exchanging the RAS
information on the unreliable channel. This processing is followed by
the call setup sequence through a reliable channel, which is based on
Q.931 protocol with modifications. One modification is the bearer
capability information element in SETUP message can be ignored if the
call is bounded in the packet-based network, in which the bearer is set
up by H.245. Another difference is that closing H.225 call signaling
channel is not ending the call unless the H.245 channel is also closed.
The Release and DISConnect messages in Q.931 are forbidden in H.225 for
a H.323 entity.
H.245 uses the reliable H.225 call signaling channel to perform H.245
control functions, such as master/slave determination, terminal
capability exchange, open/closing logical channel, and others. During
the terminal capability exchange procedure, both ends are based on
their own terminal capability to set up the mutual acceptable bearer
service to the network. Then logical channel(s) are opened to handle
the bearer capability, for example, two channels for video and one for
audio. This procedure is very similar to the bearer capability request
in the ISDN Q.931 and SS7 ISUP.
4.0 H.323 to ISUP Interworking
After having a brief overview on call signaling and control for both
circuit-based and packet-based networks, interworking between SS7 ISUP
and H.323 (actually H.225 and H.245) becomes quite straightforward. As
mentioned in Section 3, the bearer capability set up within the packetbased network is done by H.245. However, for a signaling gateway
between packet-based network and circuit network, the information from
the bearer capability information element in the H.225 SETUP message is
enough to set up a call in the ISDN or PSTN through SS7 ISUP. H.245 is
just used for logical channel set up based on bearer capability carried

in the H.225 SETUP message.

The following sections describes the procedure interworking between
ISUP and H.225/H.245.
4.1 Successful Basic Call Setup
In Figure 2, H.245 control channel procedure may only contain logical
channel setup messages since the H.323 terminal that initiate the call
knows only one logical channel with the requested bearer capability
needed for the call. Remember that circuit-based ISDN or PSTN has only
one bearer capability for a call.
+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|----H.225 SETUP (with bearer)-->|
|
|
|------------IAM----------->|
|<---H.225 CALL PROC-------------|
|
|
|<-----------ACM------------|
|<---H.225 ALERT-----------------|
|
|
|<-----------ANM------------|
|<---H.225 CONN------------------|
|
|
|
|
|<==H.245 Capability Exchanges==>|
|
|<==H.245 Logical Channel Setup=>|
|
|
|
|
+------------------------------------------------------------+
|
Media Information Flow
|
+------------------------------------------------------------+
Figure 2. Successful Call Setup by Signaling Interworking
The signaling gateway can, as optional, immediately start the H.245
logical channel setup procedure based on the TSAP address given in
the H.225 SETUP message without waiting for the CONNect message, which
can reduce the entire call setup time. However, media information will
not start to flow before the called party, a H.323 terminal in this
example, received the H.225 CONNect message, even H.245 has finished
the logical channel setup. We highly recommend the implementation of
signaling gateway to use this option for H.245 control channel setup,
which is showed in the following figure.

+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|----H.225 SETUP (with bearer)-->|
|
|
|------------IAM----------->|
|<---H.225 CALL PROC-------------|
|
|
|
|
|<==H.245 Logical Channel Setup=>|
|
|
|<-----------ACM------------|
|<---H.225 ALERT-----------------|
|
|
|
|
|<---H.225 CONN------------------|<-----------ANM------------|
|
|
|
+------------------------------------------------------------+
|
Media Information Flow
|
+------------------------------------------------------------+
Figure 3. Successful Call Setup with a H.245 Option
For the call initiated from ISDN or PSTN side to a H.323 terminal, the
call setup procedure flow will be similar to Figure 2 or 3. Also, the
H.245 logical channel setup procedure can be performed based on the
bearer capability information in the ISUP IAM without waiting for the
H.225 CONNect message. Figure 4 shows a successful call setup from an
ISDN party to a H.323 terminal.
+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|
|<-----------IAM------------|
|<---H.225 SETUP (with bearer)---|
|
|
|
|
|<==H.245 Capability Exchanges==>|
|
|<==H.245 Logical Channel Setup=>|
|
|
|
|
|----H.225 ALERT---------------->|
|
|
|------------ACM----------->|
|----H.225 CONN----------------->|
|
|
|------------ANM----------->|
|
|
|
+------------------------------------------------------------+
|
Media Information Flow
|
+------------------------------------------------------------+
Figure 4. Successful Call Setup Initiated from ISDN
It is noted that no H.245 capability exchanges procedure is required
in the Figure 4. When a H.323 terminal initiates the call to an ISDN
called party, it knows its own terminal capability that is carried by
the bearer capability information element in the H.225 SETUP message
sent the signaling gateway. If the gateway has the compatible terminal
capability, it forms an ISUP IAM and sends to the ISDN called party
through SS7 ISUP protocol.

4.2 Unsuccessful Basic Call Setup

In ISDN or PSTN, many causes are attributed to unsuccessful call setup,
such as called party busy, resource unavailable, bearer service not
implemented, and others. After the destination exchange receives the
IAM and determines that the call is not able to complete, it sends back
an ISUP REL message with the reason. At the originating exchange, the
ISUP REL message is mapped into the Q.931 DISConnect message and sent
to the calling party to end the call.
However, a H.225 reliable call signaling channel is not set up until
the H.225 CONNect message is received. Therefore, in an unsuccessful
call setup across between ISDN (or PSTN) and packet-based network, no
H.225 call signaling channel is established since no H.225 CONNect
message mapped from the ISUP ANM is received. Instead, H.245 session
end procedure is used to end the call. The Figures 5 and 6 show the
unsuccessful call setup caused by either the H.323 terminal or an ISDN
party.
+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|----H.225 SETUP (with bearer)-->|
|
|
|------------IAM----------->|
|<---H.225 CALL PROC-------------|
|
|
|
|
|<==H.245 Logical Channel Setup=>|
|
|
|<-----REL (with cause)-----|
|<==H.245 End Session Command===>|
|
|
|
|
Figure 5. Unsuccessful Call Setup caused by the ISDN party
+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|
|<-----------IAM------------|
|<---H.225 SETUP (with bearer)---|
|
|
|
|
|<===H.245 Capability Setup======|
|
|
|
|
|====H.245 Capability Reject====>|
|
|
|------REL (with cause)---->|
|<===H.245 End Session Command==>|
|
|
|
|
Figure 6. Unsuccessful Call Setup caused by H.323 Terminal

4.3 Basic Call Release

In packet-based network, the H.225 Release Complete message and the
H.245 session end procedure are used to release an established call.
The call release initiated by the H.323 terminal through the signaling
gateway is showed in Figure 4.
+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|===H.245 End Session Command=====>|
|
|
|------------REL--------->|
|<==H.245 End Session Command======|
|
|
|<-----------RLC----------|
|----H.225 Release Complete------->|
|
|
|
|
Figure 7. Basic Call Release by Signaling Interworking
The call release initiated from the ISDN or PSTN side is showed in
Figure 6, which is the same as that is showed in Figure 5.
+------+
H.323/
+-----------+
SS7 ISUP
+------+
| H323 |
H.225/
| Signaling |
| Dest.|
| GK |
H.245
| Gateway |
| Exch.|
+------+
+-----------+
+------+
|
|
|
|
|<-----------REL----------|
|<==H.245 End Session Command======|
|
|===H.245 End Session Command=====>|
|
|
|------------RLC--------->|
|<---H.225 Release Complete--------|
|
|
|
|
Figure 8. Basic Call Release by Signaling Interworking

Signaling Gateways: STP vs. SEP

The SEGway Signaling Gateway can be configured as an STP (Signal Transfer
Point) or as a Signaling End Point (SEP). However, understanding how each
configuration can be applied can be confusing. The following is a description that
may be useful in distinguishing each capability.
Three important components of an SS7/IP converged network are the SSP
(service switching point), the STP and the SEP. Equipped with SS7 software, the
SSP is a telephone switch, or "end node," that sends signaling messages to
other SSPs or STPs to set up, manage and release voice circuits required to
complete a call. The STP is a signal packet switch (or router) that receives and
routes incoming signaling messages on to their destinations. SEP is a generic
term referring to an SS7 end node with similar functionality as the SSP in an IP
telephony network.
A traditional voice switch (SSP) provides call control, trunk switching and
signaling in a single (large) entity. These same functions in the IP telephony
environment are provided by separate (distributed) entities: a softswitch or media
gateway controller, a media gateway and a signaling gateway. The virtual switch
created by combining these functions in the IP environment becomes a SEP.
Both SSPs and SEPs are connected to STPs via "A" links. Both are also single
point codes in the SS7 network.
SEP and STP configurations perform unique network functions. When the
signaling gateway is configured as an STP, it can provide routing and
concentrating capabilities and may also provide global title translation (GTT) and
SS7 traffic concentration. Generally speaking, when signaling gateways are used
as STPs in a converged network, they connect to other STPs in the PSTN (via
"B" or "D links) and offer the flexibility of routing to a number of different PSTN
locations(e.g. an 800, LIDB, or local number portability database). If routing to IP
based applications (e.g. databases or softswitches) is required and the customer
needs unique SS7 network addresses (point codes), STP functionality is also
needed.
The following diagram illustrates an STP configuration with the SEGway
Signaling Gateway routing SS7 messages through various applications
appearing as unique signaling points in the PSTN network or in the IP network.
For example, the SCP in the PSTN could provide 1-800 service. The SCPs in the
IP network could provide different applications (e.g. Internet call waiting, prepaid
card, or HLR capability). More importantly, these databases have separate point
codes in the SS7 network and therefore require STP routing functionality to
access.
Figure 1 - SEGway Signaling Gateway Configured as an STP

In SEP mode, (illustrated below), the SEGway Signaling Gateway acts as an end
node, terminating SS7 links. In this mode, the signaling gateway is not used for
routing. The virtual switch composed of media gateway(s), media gateway
controller (softswitch), and signaling gateway is represented by a single point
code in the SS7 network.
Figure 2 - SEGway Signaling Gateway Configured as an SEP (End Node)