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