Internet Engineering Task Force Frank Miller
draft-miller-sip-isup-annex-01 Shan Lu
Priya Gupta
Akif Arsoy
sentitO Networks
Carrying ISUP in SIP Messages
(SIP-ISUP-ANNEX)
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with all
the provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Task
Force, 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 works in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
ABSTRACT
SIP-ISUP-ANNEX is a mechanism by which an XML representation of certain
ISUP messages can be transported in the body of SIP INFO messages.
This mechanism can be used to allow PSTN elements to control trunk
interfaces that are terminated by SIP-controlled access equipment
without having to implement the binary ISUP protocol.
1 Introduction
This document specifies a mechanism by which a network element that has
the ability to utilize SIP signaling can perform certain ancillary
functions associated with existing PSTN equipment. The basic approach
is to provide a simplified textual representation of certain ISUP
messages that can be encapsulated in the body of SIP INFO messages.
This document focuses on those messages that are not used to setup and
teardown telephone calls. Translations between SIP and ISUP for
setting up and tearing down phone calls have been addressed elsewhere.
Figure 1 illustrates the environment that this messaging proposal
exists in. If a SIP element needs to function in the PSTN network,
SIP signaling information must traverse the IP network to a Signaling
Gateway where it is converted into SS7 signaling. For those SIP
messages that are used to affect the setup and teardown of sessions,
it is possible to map the messages onto analogous message in the SS7
signaling network. For a number of other functions in the PSTN that
have signaling associated with them, there is no obvious corresponding
message in the SIP signaling network to those used in the SS7 signaling
network. In the absence of analogous SIP messages this document uses
a simple XML representation of the information necessary to format
binary SS7 ISUP messages and carries the information between SIP
elements and Signaling Gateways in the body of a SIP INFO messages.
+-------------+ +------------+ +-----------+ +------+
| | SIP | | SIP | | SS7 | |
| SIP Element |<--->| IP Network |<--->| Signaling |<--->| PSTN |
| | | | | Gateway | | |
+-------------+ +------------+ +-----------+ +------+
Figure 1: Signaling Architecture
2 An Overview of the ISUP Message Structure
This section provides a high-level overview of the SS7 ISUP message
structure as specified in [1] and [2]. ISUP messages are binary
encoded, i.e. various fields are coded by specifying predefined binary
values. The purpose of this section is to provide the reader with
background before presenting the syntax of the textual representation
proposed later in this document. Figure 2 illustrates the overall
structure of an ISUP message.
+--------------+
| Message Type |
+--------------+
| Mandatory |
| Fixed |
| Part |
+--------------+
| Mandatory |
| Variable |
| Part |
+--------------+
| Optional |
| Part |
+--------------+
| Circuit ID |
| Code |
+--------------+
Figure 2: The Structure of an ISUP Message
The Message Type identifies the specific ISUP message that is being
transmitted. The format and length of all the other fields are implied
by the Message Type. The Mandatory Fixed Part consists of a list of
mandatory parameters where each parameter has a format that has a fixed
length and as such, no additional length information is required. The
Mandatory Variable Part consists of a list of mandatory parameters
where each parameter can have a variable length. Both the Mandatory
parts are lists that are required to be present based on the Message
Type. The Optional Part consists of a list of parameters that are, as
the name implies, optional. All of these parameters are formatted as
if they are variable in length.
The messages addressed by this document fall into groups where each
group represents a transaction. The transactions addressed include:
1. Circuit Blocking
2. Circuit Unblocking
3. Circuit Resetting
4. Circuit Group Blocking
5. Circuit Group Unblocking
6. Circuit Group Reset
7. Circuit Group Query
8. Continuity Checking
Each of these transactions has two simple state machines associated
with them that are maintained by the SIP UA. The first state machine
is used if the transaction is initiated by the SIP UA and the second
is used if the transaction is initiated by the PSTN.
ISUP messages originating or terminating at a SIP element will be
carried by the INFO method. The INFO method is actually intended for
mid session communication. To be consistent with this approach, a
provisionary SIP call may be established within which all INFO methods
carrying ISUP messages in their bodies can be transmitted.
To ensure that the ISUP messages belonging to a transaction are
transmitted in sequence between the signaling gateway and the SIP
element, the 200 OK to an INFO will be expected before the next INFO
in the same direction is transmitted. This implies that any SS7 side
messages received in the mean time are queued.
SIP Element Signaling Gateway SS7 Network
| | |
|---------- INFO ------------>| |
|<-------- 200 OK ------------| |
| |------------ BLO ----------->|
| |<----------- BLA ------------|
| | |
|<--------- INFO -------------| |
|--------- 200 OK ----------->| |
| | |
Figure 3: SIP Originated Circuit Blocking Example
SIP Element Signaling Gateway SS7 Network
| | |
| |<----------- BLO ------------|
| | |
|<--------- INFO -------------| |
|--------- 200 OK ----------->| |
|---------- INFO ------------>| |
|<-------- 200 OK ------------| |
| |------------ BLA ----------->|
Figure 4: SS7 Originated Circuit Blocking Example
3 INFO Header
The Content-type header shall be coded as follows:
Content-type: applicaton/isupxml
The request-uri header shall be coded to identify the SIP element or
the Signaling Gateway, which is to receive the INFO method.
The contact header shall be present and shall be coded to identify the
SIP element or the Signaling Gateway, to which further ISUP-carrying
INFO requests of the current transaction are to be sent.
The rest of the INFO headers shall be coded in accordance with the
requirements in [5] and [6].
4 INFO Body
This section specifies how an ISUP message is represented in the body
of a SIP INFO method. Throughout this section, INFO method should be
read to mean INFO method encapsulating an ISUP message in its body.
The following choices are made to specify the syntax:
1. XML will be used to represent the ISUP message in the body of the
INFO method.
2. Not all fields of the ISUP method will be carried in the INFO
method. The signaling gateway converting INFO methods to ISUP
messages can compute or deduce certain fields of the ISUP message
even though they will not be present in the INFO method.
3. The text values for the information elements in the ISUP message
are defined in this draft. The guiding rule for these definitions
is to take the descriptive text from the base specification and
declare it as the text value in XML. The text representation
unifies the GR-246-CORE and ITU Q.764 parameters and messages into
a unified representation so that the SIP element need not be
concerned with the protocol variances with respect to encoding of
the SIP messages. Where applicable, the SIP element may need to be
aware of procedural differences in SS7 variants.
Using the guideline described above, this document defines the text
representation of the ISUP messages and parameters. Information element
definitions refer to the base types from ABNF (i.e. DIGIT), which are
defined in [7].
The message body section of the INFO method shall be coded as follows:
Parameter-List
where:
Group-Value: 1*5DIGIT
Circuit-Value: 2*DIGIT
The INFO body shall include one, and only one, element marked by .
4.1 Message-Type-Value
Since this draft addresses only the circuit supervision messages, only
those messages are included in the definition below:
Message-Type-Value:
BLO | BLA | CGB | CGBA | GRS | GRA | CGU | CGUA | CQM |
CQR | COT | CCR | LPA | RLC | RSC | UBL | UBA | UCIC
4.2 Parameter-List
Parameter-List defines only those parameters that can be included in
one the ISUP messages included in Message-Type-Value.
Parameter-List: *(Parameter)
Parameter:
Cause-Indicators-Parameter |
Cct-Grp-Spvsn-Msg-Type-Ind-Parameter |
Circuit-State-Indicator |
Continuity-Indicators |
Range-and-Status-Parameter
It is necessary at times to carry a parameter with no content (i.e.
zero for its ISUP length indicator). The following syntax shall be
used to code a parameter with no content:
where tag is the parameterĘs name tag.
4.2.1 Cause-Indicators
Cause-Indicators-Parameter:
Location-Value:
local-private | local local | transit | remote-local |
remote-private | local-interface | international | unknown
Class-Value:
normal | resource-unavailable | service-unavailable |
service-not-implemented | invalid-message |
protocol-error | interworking
Cause-Value:
unallocated-number |
no-route-to-transit-network |
no-route-to-destination |
send-info-tone |
misdialed-trunk-prefix |
normal-clearing |
user-busy |
no-user-responding |
no-answer-from-user |
call-rejected |
number-changed |
destination-oos |
address-incomplete |
facility-rejected |
normal |
unallocated-destination-number |
unknown-business-group |
no-cct-available |
network-out-of-order |
temporary-failure |
switching-congestion |
requested-channel-unavail |
resource-unavailable |
preemption |
precedence-call-blocked |
not-subscribed |
incoming-calls-barred |
bearer-cap-not-auth |
bearer-cap-not-avail |
service-not-available |
call-type-incompatible |
call-blocked |
bearer-cap-not-implemented |
facility-not-implemented |
restricted-bearer-cap-avail |
not-member-of-cug |
incompatible-destination |
invalid-transit-network |
invalid-message |
msg-type-not-implemented |
parameter-discarded |
recovery-on-timer-expiry |
parameter-passed-on |
protocol-error |
interworking-unspecified
Diagnostics-Value:
TBD
4.2.2 Circuit Group Supervision Message Type Indicator
Cct-Grp-Spvsn-Msg-Type-Ind-Parameter:
Cct-Grp-Spvsn-Mst-Type-Ind-Value:
block_wout_release | block_with_immediate_release
4.2.3 Circuit State Indicator
Circuit-State-Indicator-Parameter:
Circuit-State-Indicator-Value:
transient | unequipped | incoming-active | incoming-LB |
incoming-RB | incoming-LRB | outgoing-active | outgoing-LB |
outgoing-RB | outgoing-LRB | idle | idle-LB | idle-RB | idle-LRB
4.2.4 Continuity-Indicators-Parameter:
Continuity-Indicators-Parameter:
4.2.5 Range and Status Parameter
Range-and-Status-Parameter:
5 Example Message Encodings
This section provides a set of examples that use the specified syntax
to implement various features by utilizing ISUP interactions with the
PSTN. Each example is presented with three message types, 1) a sample
invocation, 2) a sample successful returned result, and 3) a sample
error returned result. Each message type includes the textual
representation that is carried in the body of a SIP INFO message and
the corresponding ISUP representation. The ISUP representation is
presented as a table. The first three columns of the table provide
the name, bit encoding and a short description of an ISUP message
field. The fourth column describes how the field is derived when an
ISUP message is being generated from a SIP body representation. The
types of derivation are listed as follows:
+-------------+------------------------------------------------------+
| Field Type | Description |
+-------------+------------------------------------------------------+
| Implicit | The field is generated implicitly, i.e. it has the |
| | same value every time this message is generated |
+-------------+------------------------------------------------------+
| Computed | The field is computed based on the construction of |
| | the message |
+-------------+------------------------------------------------------+
| SIP Message | The field is generated based on some element present |
| | in the SIP INFO body message representation |
+-------------+------------------------------------------------------+
5.1 Gateway Initiated Circuit Blocking
Gateway initiated Circuit Blocking generally results from a user
management request. This can either be from a command line request or
over SNMP from a network management center.
5.1.1 SIP Request - BLO
The BLO request carried in SIP INFO is shown below with example values
for DPC, OPC and CIC fields.
5.1.2 ISUP Request - BLO
Shown below is the SS7 representation of the BLO in the ITU variant.
The ANSI variant would be different but can be derived from the SIP BLO
message.
+--------------------+----------+----------------------+--------------+
| Field Name | Bit | Description | Derived From |
| | Encoding | | |
+--------------------+----------+----------------------+--------------+
| Service Information| 00000011 | ITU ISUP message | Implicit |
| Octet | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00101110 | Lower bits of DPC | SIP Message |
| Octet 1 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 11100000 | Upper bits of DPC | SIP Message |
| Octet 2 | | Lower bits of OPC | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00000100 | More bits of OPC | SIP Message |
| Octet 3 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | xxxx0100 | Upper bits of OPC | SIP Message |
| Octet 4 | | SLC | |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 01010001 | Lower bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 00000011 | Upper bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| ISUP message type | 00010011 | BLO | SIP Message |
+--------------------+----------+----------------------+--------------+
5.1.3 ISUP Response - BLA
The expected response to a BLO is the Blocking Acknowledgement message
(BLA). Show is the ITU version of the message with example values.
+--------------------+----------+----------------------+--------------+
| Field Name | Bit | Description | Derived From |
| | Encoding | | |
+--------------------+----------+----------------------+--------------+
| Service Information| 00000011 | ITU ISUP message | Implicit |
| Octet | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00010011 | Lower bits of DPC | SIP Message |
| Octet 1 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 10001000 | Upper bits of DPC | SIP Message |
| Octet 2 | | Lower bits of OPC | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00001011 | More bits of OPC | SIP Message |
| Octet 3 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | xxxx1000 | Upper bits of OPC | SIP Message |
| Octet 4 | | SLC | |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 01010001 | Lower bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 00000011 | Upper bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| ISUP message type | 00010101 | BLA | SIP Message |
+--------------------+----------+----------------------+--------------+
5.1.4 SIP Response - BLA
Shown below is the BLA response derived from the ITU BLA message. The
SIP message below would be the same if the SS7 variant were the ANSI
variant.
5.2 SS7 Initiated Circuit Group Reset
ISUP message originate from the SS7 network when a PSTN element wants
to assert control over a trunk that is connected to a SIP controlled
element.
5.2.1 ISUP Request - GRS
Shown below is an example for the GRS in the ITU variant.
+--------------------+----------+----------------------+--------------+
| Field Name | Bit | Description | Derived From |
| | Encoding | | |
+--------------------+----------+----------------------+--------------+
| Service Information| 00000011 | ITU ISUP message | Implicit |
| Octet | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00010011 | Lower bits of DPC | SIP Message |
| Octet 1 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 10001000 | Upper bits of DPC | SIP Message |
| Octet 2 | | Lower bits of OPC | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00001011 | More bits of OPC | SIP Message |
| Octet 3 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | xxxx1000 | Upper bits of OPC | SIP Message |
| Octet 4 | | SLC | |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 01010001 | Lower bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 00000011 | Upper bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| ISUP message type | 00011101 | GRS | SIP Message |
+--------------------+----------+----------------------+--------------+
| Pointer to Range | 00000001 | Points to next octet | Implicit |
| and Status | | | |
+--------------------+----------+----------------------+--------------+
| Length indicator | 00000100 | Four octets | SIP Message |
+--------------------+----------+----------------------+--------------+
| Range | 00011101 | 29 circuits in range | SIP Message |
+--------------------+----------+----------------------+--------------+
5.2.2 SIP Request - GRS
The BLO request carried in SIP INFO is shown below with example values
for DPC, OPC and CIC fields.
5.2.3 SIP Response - GRA
Shown below is the BLA response derived from the ITU BLA message. The
SIP message below would be the same if the SS7 variant were the ANSI
variant.
5.2.4 ISUP Response - GRA
The expected response to a BLO is the Blocking Acknowledgement message
(BLA). Shown below is the ITU version of the message.
+--------------------+----------+----------------------+--------------+
| Field Name | Bit | Description | Derived From |
| | Encoding | | |
+--------------------+----------+----------------------+--------------+
| Service Information| 00000011 | ITU ISUP message | Implicit |
| Octet | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00101110 | Lower bits of DPC | SIP Message |
| Octet 1 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 11100000 | Upper bits of DPC | SIP Message |
| Octet 2 | | Lower bits of OPC | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | 00000100 | More bits of OPC | SIP Message |
| Octet 3 | | | |
+--------------------+----------+----------------------+--------------+
| Routing Label - | xxxx0010 | Upper bits of OPC | SIP Message |
| Octet 4 | | SLC | |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 01010001 | Lower bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| Circuit ID Code | 00000011 | Upper bits of CIC | SIP Message |
+--------------------+----------+----------------------+--------------+
| ISUP message type | 00101001 | GRA | SIP Message |
+--------------------+----------+----------------------+--------------+
| Pointer to Range | 00000001 | Points to next octet | Implicit |
| and Status | | | |
+--------------------+----------+----------------------+--------------+
| Length indicator | 00000101 | Five octets | SIP Message |
+--------------------+----------+----------------------+--------------+
| Status - Octet 1 | 00001111 | First 4 circuits | SIP Message |
| | | blocked | |
+--------------------+----------+----------------------+--------------+
| Status - Octet 2 | 00000000 | | SIP Message |
+--------------------+----------+----------------------+--------------+
| Status - Octet 3 | 00000000 | | SIP Message |
+--------------------+----------+----------------------+--------------+
| Status - Octet 4 | 00000000 | | SIP Message |
+--------------------+----------+----------------------+--------------+
6 Applicable Documents
[1] Telcordia GR-246-CORE, Issue 3, Bell Communications Research
Specification of Signaling System Number 7
[2] ITU-T, Q.763, SS7 ISDN User Part Formats and Codes
[3] ITU-T, Q.764, ISUP Messages and Procedures, 09/97
[4] ITU-T, Q.704, Signaling Network Functions and Messages, 07/96
[5] Rosenberg, Schulzrinne, Camarillo, Johnston, Peterson, Sparks,
Handley, Schooler, RFC 3261, SIP: Session Initiation Protocol,
June 2002.
[6] Donovan, RFC 2976, The SIP INFO Method.
[7] Crocker, D. and P. Overell, Augmented BNF for Syntax
Specifications: ABNF, RFC 2234, November 1997.
7 Author's Addresses
Frank W. Miller, Ph.D.
Shan Lu, Ph.D.
Priya Gupta
Akif Arsoy
sentitO Networks
2096 Gaither Road, Suite 100
Rockville, Maryland 20850
(301) 947-1900
{fmiller,slu,pgupta,aarsoy}@sentito.com