Internet Engineering Task Force Frank Miller draft-miller-sip-tcap-00 Shan Lu Priya Gupta Akif Arsoy sentitO Networks Carrying TCAP in SIP Messages (SIP-TCAP) 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-TCAP is a mechanism by which an XML representation of TCAP messages can be transported in the body of SIP INFO messages. This mechanism can be used to allow SIP elements to access features implemented by PSTN equipment without having to implement the binary TCAP protocol. 1 Introduction This document specifies a mechanism by which a network element that has the ability to utilize SIP signaling can make use of PSTN features using SS7 TCAP signaling. The basic approach is to provide an XML representation of TCAP messages that can be encapsulated in the body of SIP INFO messages. Figure 1 illustrates the environment that this messaging proposal exists in. If a SIP element needs to utilize services available on an SS7 signaling network, e.g. SCP, SIP signaling information must traverse the IP network to a Signaling Gateway to get access to the SS7 signaling network. There are two parts to this problem. First, the SIP endpoint can format a binary TCAP message or it can use an intermediate representation that is then converted to a binary TCAP message by the Signaling Gateway. Second, the SIP element can use SIP itself for the transport or some other transport mechanism to deliver the TCAP message to the Signaling Gateway. The proposal in this document uses SIP INFO messages to transport an intermediate representation (an XML encoding) of a TCAP message from the SIP endpoint to the Signaling Gateway. +-------------+ +------------+ +-----------+ +------+ | | SIP | | SIP | | SS7 | | | SIP Element |<--->| IP Network |<--->| Signaling |<--->| PSTN | | | | | | Gateway | | | +-------------+ +------------+ +-----------+ +------+ Figure 1: Signaling Architecture 2 An Overview of the TCAP Message Structure This section provides an overview of the SS7 TCAP message structure. TCAP 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 that may or may not be necessary before presenting the syntax of the XML representation proposed later in this document. Figure 2 illustrates the overall structure of a TCAP message. +-------------+ | Package | | Type | +-------------+ | Transaction | | Portion | +-------------+ | Dialogue | | Portion | +-------------+ | Component | +-------------+ . . . +-------------+ | Component | +-------------+ Figure 2: The Structure of a TCAP Message The first element is called the Package Type and it is mandatory. The second element is called the Transaction Portion. It is mandatory and there are small set of fixed formats that this element can take. The third element is the Dialogue Portion. The entire element is optional but if it is there it can consist of a variable set of fixed size sub-elements. The final element is a list of Components. No Components are required, but either the Dialogue Portion or at least one Component is required. Each component specifies a service invocation or a returned result or error. Figure 3 gives the structure of the Package Type. It consists of two subfields, the Package Type Identifier and the Total TCAP Message Length. The Package Type Identifier defines relationship between the SS7 endpoints, be they SSPs or SCPs. The Package Type Identifier determines the structure of Transaction Portion. The Total TCAP Message Length gives the length, in bytes, of the overall TCAP message. Package Type +--------------------+ | +----------------+ | | | Package Type | | | | Identifier | | | +----------------+ | | | Total TCAP | | | | Message Length | | | +----------------+ | +--------------------+ Figure 3: The Structure of a TCAP Package Type There are eight different Package Types: Unidirectional, Query with Permission, Query without Permission, Response, Conversation with Permission, Conversation without Permission, P-Abort, and U-Abort. Several of these types use the same format for their Transaction Portions however, so we have four possible Transaction Portion formats that are implied by the Package Type Identifier in the Package Type element of the TCAP message. 2.1 Transaction Portion Figure 4 gives the Transaction Portion for a Unidirectional Package Type. It consists of a Transaction ID Identifier and the Transaction ID Length which is set to zero. Transaction Portion +--------------------+ | +----------------+ | | | Transaction ID | | | | Identifier | | | +----------------+ | | | Transaction ID | | | | Length (=0) | | | +----------------+ | +--------------------+ Figure 4: Transaction Portion for Unidirectional Package Type Figure 5 illustrates the Transaction Portion for the two Query package types, Query with Permission and Query without Permission. The Transaction ID Identifier and Transaction ID Length are here as well. In addition, an Originating Transaction ID is added. Transaction Portion +--------------------+ | +----------------+ | | | Transaction ID | | | | Identifier | | | +----------------+ | | | Transaction ID | | | | Length | | | +----------------+ | | | Originating | | | | Transaction ID | | | +----------------+ | +--------------------+ Figure 5: Transaction Portion for Query with Permission and Query without Permission Package Types Figure 6 illustrates the Transaction Portion for the Response and the two Abort package types, P-Abort and U-Abort. It is similar to Figure 5 except that the Originating Transaction ID is replaced by the Responding Transaction ID. Transaction Portion +--------------------+ | +----------------+ | | | Transaction ID | | | | Identifier | | | +----------------+ | | | Transaction ID | | | | Length | | | +----------------+ | | | Responding | | | | Transaction ID | | | +----------------+ | +--------------------+ Figure 6: Transaction Portion for Response, P-Abort, and U-Abort Package Types Figure 7 illustrates the Transaction Portion for the two Conversation package types, Conversation with Permission and Conversation without Permission. In addition to the Transaction ID Identifier and Transaction ID Length, these package types include both the Originating and Responding Transaction Ids. Transaction Portion +--------------------+ | +----------------+ | | | Transaction ID | | | | Identifier | | | +----------------+ | | | Transaction ID | | | | Length | | | +----------------+ | | | Originating | | | | Transaction ID | | | +----------------+ | | | Responding | | | | Transaction ID | | | +----------------+ | +--------------------+ Figure 7: Transaction Portion for Conversation with Permission and Conversation without Permission Package Types 2.2 Dialogue Portion The Dialogue Portion is considered optional under most circumstances and is not described in detail here. 2.3 Component Portion The Component portion specifies the operation and parameters that are to be either invoked or for which a result is to be returned. A number of Components can be included in a single TCAP message. Figure 8 illustrates the overall structure of the Component Portion. The Component Sequence Identifier is a fixed value that indicates the beginning of the component sequence. The Component Sequence Length gives the overall length of the Component Portion. The remainder of the Component Portion is a list of individual components. Component Portion +-------------------------+ | +---------------------+ | | | Component | | | | Sequence Identifier | | | +---------------------+ | | | Component | | | | Sequence Length | | | +---------------------+ | | | Component | | | +---------------------+ | | . | | . | | . | | +---------------------+ | | | Component | | | +---------------------+ | +-------------------------+ Figure 8: The Structure of a TCAP Component Portion Each Component within the Component Portion specifies and individual operation and parameters to be either invoked or returned as a result. Figure 9 illustrates the structure of each Component. Component +--------------------+ | +----------------+ | | | Component Type | | | | Identifier | | | +----------------+ | | | Component | | | | Length | | | +----------------+ | | | Component ID | | | | Identifer | | | +----------------+ | | | Component ID | | | | Length | | | +----------------+ | | | Component IDs | | | +----------------+ | | | Operation Code | | | | Identifier | | | +----------------+ | | | Operation Code | | | | Length | | | +----------------+ | | | Operation Code | | | +----------------+ | | | Parameter | | | | Set/Sequence | | | +----------------+ | +--------------------+ Figure 9: The Structure of a TCAP Component The Component Type Identifier specifies the intent of the component. It can be encoded to take on one of several different meanings: Invoke (qualified by whether this is the last invocation or not), Return Result (with a similar qualification), Return Error, or Reject. The Component Length gives the length of this component. The number of Component IDs is determined by the Component Type Identifier. The Component ID Identifier indicates the beginning of a list of Component IDs. The Component ID Length provides the length of the Component IDs. Finally, the Component IDs themselves are listed. The Operation Code Identifier indicates the location of an Operation Code. The Operation Code Length gives the length of the Operation Code. The Operation Code itself specifies the specific service that is being handled by the component. The last element of the Component is the list of parameters, called the Parameter Set/Sequence. Figure 10 illustrates the structure of the Parameter Set/Sequence. The Parameter Set/Sequence Identifier marks the beginning of the list of parameters. The Parameter Set/Sequence Length provides the overall length of the set of parameters. The Parameter Set/Sequence is then followed by a list of Parameters. Parameter Set/Sequence +------------------+ | +--------------+ | | | Parameter | | | | Set/Sequence | | | | Identifier | | | +--------------+ | | | Parameter | | | | Set/Sequence | | | | Length | | | +--------------+ | | | Parameter | | | +--------------+ | | . | | . | | . | | +--------------+ | | | Parameter | | | +--------------+ | +------------------+ Figure 10: The Structure of a Parameter Set/Sequence Figure 11 gives the internal structure of a Parameter. Each consists of a Parameter Identifier that determines the parameter contents and a Parameter Length that provides the length of the individual parameter. The last element is the actual parameter contents. Parameter +----------------+ | +------------+ | | | Parameter | | | | Identifier | | | +------------+ | | | Parameter | | | | Length | | | +------------+ | | | Parameter | | | | Contents | | | +------------+ | +----------------+ Figure 11: The Structure of a Parameter 3 Message Flows TCAP 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 TCAP messages in their bodies can be transmitted. To ensure that the TCAP 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. 3.1.1 SIP Originated Query Example SIP Element Signaling Gateway SS7 Network | | | |-------- INFO ---------->| | |<------ 200 OK ----------| | | |--------- QWP --------->| | |<------ Response -------| |<------- INFO -----------| | |------- 200 OK --------->| | | | | 3.1.2 SS7 Originated Query Example SIP Element Signaling Gateway SS7 Network | | | | |<-------- QWP ----------| |<------- INFO -----------| | |------- 200 OK --------->| | |-------- INFO ---------->| | |<------ 200 OK ----------| | | |------- Response ------>| | | | 3.1.3 SIP Originated Query with Conversation Example SIP Element Signaling Gateway SS7 Network | | | |-------- INFO ---------->| | |<------ 200 OK ----------| | | |--------- QWP --------->| | |<-------- CWP ----------| |<------- INFO -----------| | |------- 200 OK --------->| | | |<------ Response -------| |<------- INFO -----------| | |------- 200 OK --------->| | | | | 3.1.4 SIP Originated Query with Conversation and Delayed ACK Example SIP Element Signaling Gateway SS7 Network | | | |-------- INFO ---------->| | |<------ 200 OK ----------| | | |--------- QWP --------->| | |<-------- CWP ----------| |<------- INFO -----------| | | | | | | | | |<------ Response -------| |------- 200 OK --------->| | |<------- INFO -----------| | |------- 200 OK --------->| | | | | Note that the Signaling Gateway queues the incoming TCAP package. It will not be forwarded to the SIP element until the ACK for the previous INFO method is received to ensure in sequence delivery of TCAP packages over UDP/IP. 4 INFO Header The Content-type header shall be coded as follows: Content-type: applicaton/tcapxml 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 TCAP-carrying INFO requests are to be sent. The rest of the INFO headers shall be coded in accordance with the requirements in [2] and [3]. 5 INFO Body This section specifies how a TCAP package is represented in the body of a SIP INFO method. Throughout this section, INFO method should be read to mean INFO method encapsulating a TCAP package in its body. The following choices are made to specify the syntax: 1. XML will be used to represent the TCAP package in the body of the INFO method. 2. Not all fields of the TCAP package will be carried in the INFO method. The signaling gateway converting INFO methods to TCAP packages can compute or deduce certain fields of the TCAP package even though they will not be present in the INFO method. 3. The text values for the information elements in the TCAP package 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. Using these guidelines, this document defines the TCAP national operation codes, error codes, problem codes and parameters of [1]. Applications in need of using operation codes, messages, parameters from other specifications such as AIN, IS-41D can extend this document in a similar manner. The INFO header fields shall be coded in accordance with the requirements in [2] and [3]. Additionally, the following rules are introduced. The message body section of the INFO method shall be coded as follows: Transaction-Portion-Structure [ Dialogue-Portion-Structure ] [ Component-Portion-Structure )] The is mandatory in all messages. The and are optional. In the information element definitions, the base types from ABNF (DIGIT, alpha, alphanum, hex-val) are used, which are defined in [7]. The INFO body shall included one, and only one, element marked by . 5.1 Transaction Portion Structure The following structure describes the Transaction-Portion-Structure in the message body section of the INFO method: Transaction-Portion-Structure: [] These elements can appear in the transaction portion in any order though it is recommended that they appear, if present, in the order listed. The elements of the transaction portion are defined below: Event-Name-Value: "LNP" | "CNAM" | "Toll-Free" This element conveys the query type and it is mandatory for all INFO methods. The Signaling Gateway is presumed to be configured with the routing data so that it knows what kind of routing (DPC-SSN vs. GTT) and what values for each routing kind (DPC, SSN, GTIE, translation type, etc.) to apply for the delivery of a given type of TCAP query into the SS7 network. Without this element, either the INFO method has to contain SS7 routing information or the signaling gateway analyzes the body of the INFO to deduce the routing information needed. This document rejects both choices and requires the SIP element specify the query type (in the form of an event name) which is used at the signaling gateway to access the preconfigured routing data. Once the transaction is initiated with an event name, the parameter is no longer essential for routing purposes since the transaction context can be used to determine that. Nevertheless, the parameter is carried in all messages for consistency and potential use for other purposes. Package-Type-Value: "QWP" | "QWOP" | "CWP" | "CWOP" | "Response" | "Abort" This element is mandatory for all INFO methods. The values stand for the following TCAP package types respectively: Query With Permission, Query Without Permission, Conversation With Permission, Conversation Without Permission, Response, and Abort. Transaction-ID-Value: alphanum The transaction id, which is mandatory in all INFO methods, uniquely identifies the transaction so that multiple messages belonging to it can be identified as such. The transaction ID is assigned by the originator of the transaction in the QWP or QWOP. It is copied by both ends of the transaction in all subsequent messages in that transaction. That is, CWP, CWOP, Response and Abort packages (carried in INFO) all include the transaction id value assigned in the QWP/QWOP that started the transaction id. The transaction id must be unique in the SIP network. That is, other SIP elements or signaling gateways must not generate a transaction id that is identical to a transaction id of another. While this document specifies no rules on the format of the transaction id, the appending of the IP address is suggested to meet the spatial uniqueness requirement on the transaction id. For transaction originating in the SS7 network, the Signaling Gateway receives them with an originating transaction id assigned by the SS7 network element. The Signaling Gateway then generates a transaction id of its own visible only by the SIP element to receive the QWP/QWOP. This last transaction id can be perceived as the SIP-transaction id since it never leaves the SIP network. The SIP element responds with this unique SIP-transaction id to the signaling gateway. The signaling gateway, then, has to send the responding TCAP package to the SS7 network element using a responding transaction id (copied from the incoming originating transaction id). The SS7 network element never sees the SIP-transaction id and the SIP element never sees the originating transaction id assigned by the SS7 network element. The point is that the signaling gateway is at least transaction stateful and does the mapping of transaction IDs. For transactions originating in the SIP network, the process is similar in the sense that the signaling gateway does the transaction id management with both its peers in the SIP and SS7 networks. Finally, for transactions that include the CWP or CWOP packages, there will be two transaction ids involved on the SS7 leg of the transaction; namely, the originating and responding transaction ids. In similar fashion, the SIP element is not exposed to this as it continues to deal only with the SIP-transaction id carried in the SIP INFO method. The P-Abort-Cause-Value information element expresses an abort cause value and is present only when the package type is Abort. The values for P-Abort-Cause-Value are give as follows: P-Abort-Cause-Value: "Unrecognized-package-type" | "Incorrect-transaction-portion" | "Badly-structured-transaction-portion" | "Unassigned-responding-transaction-id" | "Permission-to-release-problem" | "Resource-unavailable" | "Unrecognized-dialog-portion-id" | "Badly-structured-dialog-portion" | "Inconsistent-dialog-portion" These values are based on the descriptive text in [1]. 5.2 Dialogue Portion The Dialogue Portion is considered optional under most circumstances and is not yet described in detail here. 5.3 Component Portion The component portion may include multiple components. Component-Portion-Structure: *( Component-Structure ) Each component is represented as follows: Component-Structure: [] [] Parameter-List The presence or absence of the Invoke-ID and Correlation-ID elements are to be controlled as defined in [1]. The Comp-Type represents the component type. Comp-Type-Value: "Invoke-Last" | "Invoke-Not-Last" | "Return-Result-Last" | "Return-Result-Not-Last" | "Return-Error" | "Reject" The Opcode represents the operation code (unifying the family and specifier into one textual word). The Opcode is present only if the Comp-Type indicates Invoke-Last or Invoke-Not-Last. Using the national operations codes in [1] and some of the operational codes in [6] we define: Opcode-Value: "Parameter-Provide-Value" | "Parameter-Set-Value" | "Charging-Bill-Call" | "Provide-Instructions-Start" | "Provide-Instructions-Assist" | "Connection-Control-Connect" | "Connection-Control-Temporary-Connect" | "Connection-Control-Disconnect" | "Connection-Control-Forward-Disconnect" | "Caller-Interaction-Play-Announcement" | "Caller-Interaction-Play-Announcement-Collect-Digits" | "Caller-Interaction-Indicate-Information-Waiting" | "Caller-Interaction-Indicate-Information-Provided" | "Send-Notification-When-Party-Free" | "Network-Management-Automatic-Code-Gap" | "Operation-Control-Cancel" | "Report-Event-Voice-Message-Available" | "Report-Event-Voice-Message-Retrieved" | "Miscellaneous-Queue-Call" | "Miscellaneous-Dequeue-Call" | "AIN-ACG" | "AIN-ACG-Global-Ctrl-Restore" | "AIN-ACG-Global-Ctrl-Restore-Success" | "AIN-ACG-Overflow" | "AIN-Analyze-Route" | "AIN-Application-Error" | "AIN-Collect-Information" | "AIN-Continue" | "AIN-Info-Analyzed" | "AIN-Info-Collected" | "AIN-Network-Busy" | "AIN-O-Abandon" | "AIN-O-Answer" | "AIN-O-Called-Party-Busy" | "AIN-O-Disconnect" | "AIN-O-Mid-Call" | "AIN-O-No-Answer" | "AIN-O-Suspended" | "AIN-O-Term-Seized" | "AIN-Origination-Attempt" | "AIN-T-Answer" | "AIN-T-Busy" | "AIN-T-Disconnect" | "AIN-T-Mid-Call" | "AIN-T-No-Answer" | "AIN-Termination-Attempt" | "AIN-Timeout" The list can be extended with other AIN defined operation codes or with operation codes from other protocols (that sit on top of TCAP). The partial inclusion of AIN operation codes is to illustrate the expansion of the Method-Value. 5.3.1 Return-Error Component If the method is Return-Error, there is only one parameter in the Parameter-List, the error code parameter. The Component-Structure for this component reduces to: Error-Code-Parameter 5.3.2 Reject-Component If the method is Reject, there is only one parameter in the Parameter-List, the problem code parameter. The Component-Structure for this component reduces to: Problem-Code-Parameter 5.4 Error Codes Error-Code-Parameter: Error-Code-Value: "Not-Used" | "Unexpected-Component-Sequence" | "Unexpected-Data-Value" | "Unavailable-Resource" | "Missing-Customer-Record" | "Spare" "Data-Unavailable" | "Task-Refused" | "Queue-Full" | "No-Queue" | "Timer-Expired" | "Data-Already-Exists" | "Unauthorized-Request" | "Not-Queued" | "Unassigned-DN" | "Notification-Unavailable-to-Destination-DN" | "VMSR-System-ID-did-not-Match-User-Profile" | "Security-Error" | "Missing-Parameter" | "Unexpected-Parameter-Sequence" | "Unexpected-Message" | "Unexpected-Package-Type" 5.5 Problem Codes Problem Codes are partitioned in a manner similar to Operation Codes. There are two subfields called the Problem Type and the Problem Specifier. These two fields are combined in the SIP text representation to allow for a single Problem Code. Problem-Code-Parameter: Problem-Code-Value: "Unrecognized-Component-Type" | "Incorrect-Component-Portion" | "Badly-Structured-Component-Portion" | "Incorrect-Component-Coding" | "Duplicate-Invoke-ID" | "Unrecognized-Operation-Code" | "Incorrect-Parameter" | "Unrecognized-Correlation-ID" | "Unassigned-Correlation-ID" | "Unexpected-Return-Result" | "Incorrect-Parameter" | "Unassigned-Correlation-ID" | "Unexpected-Return-Error" | "Unrecognized-Error" | "Unexpected-Error" | "Unrecognized-Package-Type" | "Incorrect-Transaction-Portion" | "Badly-Structured-Transaction-Portion" | "Unassigned-Responding-Transaction-ID" | "Permission-to-Release" | "Resource-Unavailable" 5.6 Parameters This section defines the parameters of [1]. In some parameters, the inclusion or exclusion of a subfield depends on the value of another. Such rules are not specified in this document. Users should refer to [1] for further details. This document only specifies the XML representation of information elements. Parameter-List: *(Parameter) Parameter: Error-Code-Parameter | Problem-Code-Parameter | Timestamp-Parameter | ACG-Indicators-Parameter | Standard-Announcement-Parameter | Customized-Announcement-Parameter | Digits-Parameter | Standard-User-Error-Code-Parameter | Problem-Data-Parameter-Parameter | Service-Key-Parameter-Parameter | Busy-Idle-Status-Parameter | Call-Forwarding-Status-Parameter | Originating-Restrictions-Parameter | Terminating-Restrictions-Parameter | DN-to-Line-Service-Type-Mapping-Parameter | Duration-Parameter | Returned-Data-Parameter | Bearer-Capability-Requested-Parameter | Bearer-Capability-Supported-Parameter | Reference-ID-Parameter | Business-Group-Parameter | Signaling-Networks-Identifier | Generic-Name-Parameter | Message-Waiting-Indicator-Type-Parameter | Look-Ahead-for-Busy-Response-Parameter | Circuit-Identification-Code-Parameter | Precedence-Identifier-Parameter | Call-Reference-Parameter | Authorization | Integrity-Parameter | Sequence-Number-Parameter | Key-Exchange-Parameter It is necessary at times to carry a parameter with no content (i.e. zero for its TCAP length indicator). The following syntax shall be used to code a parameter with no content: where tag is the parameter's name tag. 5.6.1 Timestamp Timestamp-Parameter: 5.6.2 Automatic Code Gap ACG-Indicators-Parameter: Control-Cause-Indication-Value: "Vacant-Code" | "Out-Of-Band" | "Database-Overload" | "Destination-Mass-Calling" | "OSS-Initiated" Duration-Value: "Not-Used" | "1-Second" | "2-Seconds" | "4-Seconds" | "8-Seconds" | "16-Seconds" | "32-Seconds" | "64-Seconds" | "128-Seconds" | "256-Seconds" | "512-Seconds" | "1024-Seconds" | "2048-Seconds" Gap-Value: "Remove-Gap-Control" | "0.00-Seconds" | "0.10-Seconds" | "0.25-Seconds" | "0.50-Seconds" | "1.00-Seconds" | "2.00-Seconds" | "5.00-Seconds" | "10.00-Seconds" | "15.00-Seconds" | "30.00-Seconds" | "60.00-Seconds" | "120.00-Seconds" | "300.00-Seconds" | "600.00-Seconds" | "Stop-All-Calls" 5.6.3 Standard Announcement Standard-Announcement-Parameter: Standard-Announcement-Value: "Not-Used" | "Out-of-Band" | "Vacant-Code" | "Disconnected-Number" | "Reorder-(120-IPM)" | "Busy-(60-IPM)" | "No-Circuit-Available" | "Reorder" | "Audible-Ring" 5.6.4 Customized Announcement Customized-Announcement-Parameter: Announcement-Set-Value: *(alphanum) Announcement-ID1-Value: *(alphanum) Announcement-ID2-Value: *(alphanum) 5.6.5 Digits Digits-Parameter: Type-Of-Digits-Value: "Not-Used" | "Called-Party-Number" | "Calling-Party-Number" | "Caller-Interaction" | "Routing-Number" | "Billing-Number" | "Destination-Number" | "LATA" | "Carrier" | "Last-Calling-Party" | "Last-Party-Called" | "Calling-Directory-Number" | "VMSR-Identifier" | "Original-Called-Number" | "Redirecting-Number" | "Connected-Number" Nature-of-Number-Value: "National" | "International" | "No-Presentation-Restriction" | "Presentation-Restriction" Numbering-Plan-Value: "Unknown-or-Not-applicable" | "ISDN-Numbering" | "Telephony-Numbering" | "Data-Numbering" | "Telex-Numbering" | "Maritime-Mobile-Numbering" | "Land-Mobile-Numbering" | "Private-Numbering-Plan" Encoding-Value: "Not-Used" | "BCD" | "IA5" 5.6.6 Standard User Error Code Standard-User-Error-Code-Parameter: Standard-User-Error-Code-Value: "Caller-Abandon" | "Improper-Caller-Response" 5.6.7 Problem Data Problem-Data-Parameter: Parameter 5.6.8 Service Key Service-Key-Parameter: Parameter 5.6.9 Busy Idle Status Busy-Idle-Status-Parameter: Busy-Idle-Status-Value: "Busy" | "Idle" 5.6.10 Call Forwarding Status Call-Forwarding-Status-Parameter: Call-Forwarding-Status-Value: "Service-not-supported" | "Active" | "Not-Active" | "Spare" 5.6.11 Origination Restrictions Originating-Restrictions-Parameter: Originating-Restriction-Value: "Denied-Origination" | "Fully-Restricted-Origination" | "Semi-Restricted-Origination" | "Unrestricted-Origination" 5.6.12 Termination Restrictions Terminating-Restrictions-Parameter: Terminating-Restrictions-Value: "Denied-Origination" | "Fully-Restricted-Origination" | "Semi-Restricted-Origination" | "Unrestricted-Origination" | "Call-Rejection-Applies" 5.6.13 DN to Line Service Type Mapping Identifier DN-to-Line-Service-Type-Mapping-Parameter: Match-Status-Value: "Spare" | "No-Match" | "Match" Line-Service-Type-Value: "Individual" | "Coin" | "Multiline-Hunt" | "PBX" | "Choke" | "Series-Completion" | "Unassigned-DN" | "Multi-Party" | "Non-Specific" | "Temporarily-Out-of-Service" 5.6.14 Duration Duration-Parameter: Hours-Value: 2DIGIT Minutes-Value: 2DIGIT Seconds-Value: 2DIGIT 5.6.15 Returned Data Problem-Data-Parameter: Parameter 5.6.16 Bearer Capability Requested Bearer-Capability-Requested-Parameter: Coding-Standard-Value: "CCITT" | "National-Standard" Information-Xfer-Capability-Value: "Speech" | "Unrestricted-Digital-Information" | "Restricted-Digital-Information" | "3.1KHz-audio" | "7KHz-audio" | "15KHz-audio" | "Video" Transfer-Mode-Value: "Circuit-Mode" | "Packet-Mode" Information-Transfer-Rate-Value: "Channel-Size" | "64kbit/s" | "384kbits/s" | "1536kbits/s" | "1920kbits/s" Structure-Value: "Default" | "8kHz-Integrity" | "SDU-integrity" | "Unstructured" Configuration-Value: "Point-to-Point" | "Multipoint" Establishment-Value: "Demand" Symmetry-Value: "Bidirectional-Symmetric" | "Bidirectional-Asymmetric" | "Unidirectional-orig-to-dest" | "Unidirectional-dest-to-orig" Multiplier-or-layer-id-Value: "Bearer-Capability-Multiplier" | "User-Info-layer1-protocol" | "User-Info-layer2-protocol" | "User-Info-layer3-protocol" User-Info-layer1-proto-id -Value: "I.412" | "Rate-Adaptation" | "G.711u-law" | "G.711a-law" | "G.721" | "G.722-G.725-7kHz-audio" Rate-Adaptation-Value: "0.6kbit/s" | "1.2kbit/s" | "2.4kbit/s" | "3.6kbit/s" | "4.8kbit/s" | "7.2kbit/s" | "8.0kbit/s" | "9.6kbit/s" | "14.4kbit/s" | "16.0kbit/s" | "19.2kbit/s" | "32.0kbit/s" | "48.0kbit/s" | "56.0kbit/s" User-Info-layer2-proto-id -Value: "Undefined" | "Q.921" | "Q.710" | "X.25" User-Info-layer3-proto-id -Value: "Undefined" | "Q.931" | "X.25" 5.6.17 Bearer Capability Supported Bearer-Capability-Supported-Parameter: Bearer-Capability-Supported-Value: "Not-Supported" | "Supported" | "Not-Authorized" | "Not-Presently-Available" | "Not-Implemented" 5.6.18 Reference ID Not currently specified. 5.6.19 Business Group Business-Group-Parameter: AttSt-Value: "No-Indication" | "Attendant-Line" BGID-Type-Value: "MBG" | "IWPN" LPII-Type-Value: "Fixed-Line-Privileges" | "Customer-Defined-Line-Privileges" Party-Selector-Value: "No-Indication" | "Calling-Party-Number" | "Called-Party-Number" | "Connected-Party-Number" | "Redirecting-Number" | "Original-Called-Number" BGID-Octet1-Value: "No-Indication" BGID-Octet2-Value: "Public-Network" BGID-Octet3-Value: alpha 5.6.20 Signaling Networks Identifier Signaling-Networks-Identifier-Parameter: *( ) 5.6.21 Generic Name Generic-Name-Parameter: Type-of-Name-Value: "Spare" | "Calling-name" | "Original-called-name" | "Redirecting-name" | "Connected-name" Availability-Value: "Name-available-unknown" | "Name-not-available" Presentation-Value: "Presentation-allowed" | "Presentation-restricted" | "Blocking-toggle" | "No-indication" 5.6.22 Message Waiting Indicator Type Message-Waiting-Indicator-Type-Parameter: 5.6.23 Look Ahead for Busy Response Look-Ahead-for-Busy-Response-Parameter: Ack-Type-Value: "Path-Reservation-Denied" | "Negative-Ack" | "Positive-Ack" | "Spare" Location-Type-Value: "User" | "Private-Network-Serving-Local-User" | "Public-Network-Serving-Local-User" | "Transit-Network" | "Public-Network-Serving-Remote-User" | "Private-Network-Serving-Remote-User" | "Local-Interface-Controlled-by-this-Signaling-Link" | "International-Network" | "Network-Beyond-Interworking-Point" 5.6.24 Circuit Identification Code Circuit-Identification-Code-Parameter: 5.6.25 Precedence Identifier Precedence-Identifier-Parameter: 5.6.26 Call Reference Call-Reference-Parameter: 5.6.27 Authorization Not currently specified. 5.6.28 Integrity Not currently specified. 5.6.29 Sequence Number Not currently specified. 5.6.30 Key Exchange Not currently specified. 6 Example Message Encodings This section provides a set of examples that use the specified syntax to implement various features by utilizing TCAP 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 XML representation that is carried in the body of a SIP INFO message and the corresponding TCAP representation. The TCAP representation is presented as a table. The first three columns of the table provide the name, bit encoding and a short description of a TCAP message field. The fourth column describes how the field is derived when a TCAP 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 | +-------------+------------------------------------------------------+ 6.1 Calling Name Delivery Calling Name Delivery is a CLASS Feature that allows switching equipment to query the Subscriber Name associated with a phone number [4]. When an incoming call is received, it may be necessary to issue a query to determine the name associated with the originating party's phone number. The name returned can then be displayed on the Caller ID Customer Premise Equipment (CPE) of the destination party. The query is only necessary if the name is not provided as a parameter of the ISUP IAM message the initiated the call setup at the destination party?s switching equipment. 6.1.1 Query An element that terminates the signaling associated with a phone call, either SIP or SS7, may need to issue a query to obtain a Calling Name. This query is initiated by issuing a TCAP Query. 6.1.1.1 SIP Query The SIP Element can parse or generate the text representation of the TCAP query when it is formatted as follows: 6.1.1.2 TCAP Query The following is a binary TCAP representation of the SIP TCAP Query just presented. The following representation is for a Residence Name Query Message and assumes no ACG controls are in effect. +--------------------+----------+----------------------+--------------+ | Field Name | Bit | Description | Derived From | | | Encoding | | | +--------------------+----------+----------------------+--------------+ | Package Type | 11100010 | Query w/Permission | SIP Message | | Identifier | | | | +--------------------+----------+----------------------+--------------+ | Package Length | 00100010 | 34 octets for the | Computed | | | | Package | | +--------------------+----------+----------------------+--------------+ | Transaction ID | 11000111 | Originating | Implicit | | Identifier | | Transaction ID | | | | | follows next | | +--------------------+----------+----------------------+--------------+ | Transaction ID | 00000100 | 4-octet Transaction | Implicit | | Length | | ID | | +--------------------+----------+----------------------+--------------+ | Originating | 01000110 | Example value | SIP Message | | Transaction ID | 11000110 | | | | | 00110011 | | | | | 11110001 | | | +--------------------+----------+----------------------+--------------+ | Component Sequence | 11101000 | Component Portion | Implicit | | Identifier | | starts | | +--------------------+----------+----------------------+--------------+ | Component Sequence | 00011010 | 26 octets in the | Computed | | Length | | Component Portion | | +--------------------+----------+----------------------+--------------+ | Component Type | 11101001 | Invoke (Last) | Implicit, | | Identifier | | | when opcode | | | | | specified | +--------------------+----------+----------------------+--------------+ | Component Length | 00011000 | 24 octets for the | Computed | | | | Component | | +--------------------+----------+----------------------+--------------+ | Component ID | 11001111 | Components ID to | Implicit | | Identifier | | follow next | | +--------------------+----------+----------------------+--------------+ | Component ID | 00000001 | Single octet | Computed | | Length | | component ID | | +--------------------+----------+----------------------+--------------+ | Component ID | 00000011 | Example Invoke ID | SIP Message | | | | value | | +--------------------+----------+----------------------+--------------+ | Operation Code | 11010001 | National TCAP | Implicit | | Identifier | | | | +--------------------+----------+----------------------+--------------+ | Operation Code | 00000010 | 2-octet Operation | Implicit | | Length | | Code | | +--------------------+----------+----------------------+--------------+ | Operation Code | 10000001 | Family: Parameter | SIP Message | | Family | | | | +--------------------+----------+----------------------+--------------+ | Operation Code | 00000001 | Specifier: | SIP Message | | Specifier | | Provide-Value | | +--------------------+----------+----------------------+--------------+ | Parameter Set | 11110010 | Component parameters | Implicit | | Identifier | | start here | | +--------------------+----------+----------------------+--------------+ | Parameter Set | 00001111 | 15 octets for the | Computed | | Length | | Component parameters | | +--------------------+----------+----------------------+--------------+ | Generic Name | 10010111 | Generic Name | SIP Message | | Identifier | | Parameter | | +--------------------+----------+----------------------+--------------+ | Generic Name | 00000000 | Empty field | Computed | | Length | | | | +--------------------+----------+----------------------+--------------+ | Service Key | 10101010 | Service Key | SIP Message | | Identifier | | Parameter | | +--------------------+----------+----------------------+--------------+ | Service Key Length | 00001011 | Service Key in next | Computed | | | | 11 digits | | +--------------------+----------+----------------------+--------------+ | Digits Identifier | 10000100 | Digits Parameter | SIP Message | +--------------------+----------+----------------------+--------------+ | Digits Length | 00001001 | Digits in next 9 | Computed | | | | digits | | +--------------------+----------+----------------------+--------------+ | Digits Type | 00001011 | Calling Directory | SIP Message | | of Digits | | Number | | +--------------------+----------+----------------------+--------------+ | Digits Nature of | 00000000 | National, No | SIP Message | | Number | | restriction | | +--------------------+----------+----------------------+--------------+ | Digits Numbering | 00010001 | ISDN Numbering plan, | SIP Message | | Plan - Encoding | | BCD | | +--------------------+----------+----------------------+--------------+ | Digits Number | 00001010 | 10 digits. Example | Computed | | of Digits | | below uses | | | | | 978-555-1234 | | +--------------------+----------+----------------------+--------------+ | Digits | 01111001 | Digits 7,9 | SIP Message | | | 01011000 | Digits 5,8 | | | | 01010101 | Digits 5,5 | | | | 00100001 | Digits 2,1 | | | | 01000011 | Digits 4,3 | | +--------------------+----------+----------------------+--------------+ 6.1.2 Successful Response When a response to a TCAP Query for a Calling Name is successful, a response is sent that contains the Calling Name. 6.1.2.1 TCAP Successful Response The following is a binary TCAP representation of the SIP TCAP successful response just presented. The following representation is for a Residence Name Query Message and assumes no ACG controls are in effect. +--------------------+----------+----------------------+--------------+ | Field Name | Bit | Description | Derived From | | | Encoding | | | +--------------------+----------+----------------------+--------------+ | Package Type | 11100100 | Response | SIP Message | | Identifier | | | | +--------------------+----------+----------------------+--------------+ | Package Length | 00011101 | 26 octet package | Computed | +--------------------+----------+----------------------+--------------+ | Transaction ID | 11000111 | Responding | Implicit | | Identifier | | Transaction ID | | | | | follows next | | +--------------------+----------+----------------------+--------------+ | Transaction ID | 00000100 | 4-byte Transaction | Implicit | | Length | | ID | | +--------------------+----------+----------------------+--------------+ | Responding | 01000110 | Reflected from the | SIP Message | | Transaction ID | 11000110 | originating | | | | 00110011 | transaction ID | | | | 11110001 | | | +--------------------+----------+----------------------+--------------+ | Component Sequence | 11101000 | Component Portion | Implicit | | Identifier | | starts | | +--------------------+----------+----------------------+--------------+ | Component Sequence | 00010010 | 18 octet component | Computed | | Length | | sequence | | +--------------------+----------+----------------------+--------------+ | Component Type | 11101010 | Return Result (Last) | SIP Message | | Identifier | | | | +--------------------+----------+----------------------+--------------+ | Component Length | 00010000 | 16 octet component | Computed | +--------------------+----------+----------------------+--------------+ | Component ID | 11001111 | Components ID to | Implicit | | Identifier | | follow next | | +--------------------+----------+----------------------+--------------+ | Component ID | 00000001 | 1-byte Correlation | Computed | | Length | | ID | | +--------------------+----------+----------------------+--------------+ | Component ID | 00000011 | Correlation ID, | SIP Message | | | | reflected from | | | | | invoke id | | +--------------------+----------+----------------------+--------------+ | Parameter Set | 11110010 | Component parameters | Implicit | | Indentifier | | start here | | +--------------------+----------+----------------------+--------------+ | Parameter Set | 00001011 | 11 octet parameter | Computed | | Length | | length | | +--------------------+----------+----------------------+--------------+ | Generic Name | 10010111 | Generic Name | SIP Message | | Indentifier | | Parameter | | +--------------------+----------+----------------------+--------------+ | Generic Name | 00001001 | 9 octet name | Computed | | Length | | parameter | | +--------------------+----------+----------------------+--------------+ | Generic Name | 00100000 | Calling name, | SIP Message | | Subfields | | available, | | | | | Presentation allowed | | +--------------------+----------+----------------------+--------------+ | Generic Name | 01000100 | D | SIP Message | | Characters | 01001111 | O | | | | 01000101 | E | | | | 00101100 | , | | | | 01001010 | J | | | | 01001111 | O | | | | 01001000 | H | | | | 01001110 | N | | +--------------------+----------+----------------------+--------------+ 6.1.2.2 SIP Successful Response The SIP Element can parse and generate the text representation of the TCAP successful response when it is formatted as follows: 6.1.3 Error Response When a response to a TCAP Query for a Calling Name is not successful, an error response is sent that contains an error code. 6.1.3.1 TCAP Error Response +--------------------+----------+----------------------+--------------+ | Field Name | Bit | Description | Derived From | | | Encoding | | | +--------------------+----------+----------------------+--------------+ | Package Type | 11100100 | Response | SIP Message | | Indentifier | | | | +--------------------+----------+----------------------+--------------+ | Package Length | | | Computed | +--------------------+----------+----------------------+--------------+ | Transaction ID | 11000111 | Responding | Implicit | | Identifier | | Transaction ID | | | | | follows next | | +--------------------+----------+----------------------+--------------+ | Transaction ID | 00000100 | 4-byte Transaction | Implicit | | Length | | ID | | +--------------------+----------+----------------------+--------------+ | Transaction ID | 01000110 | Reflected from the | SIP Message | | | 11000110 | originating | | | | 00110011 | transaction ID | | | | 11110001 | | | +--------------------+----------+----------------------+--------------+ | Component Sequence | 11101000 | Component Portion | Implicit | | Indentifier | | starts | | +--------------------+----------+----------------------+--------------+ | Component Sequence | | XX octet component | Computed | | Length | | sequence | | +--------------------+----------+----------------------+--------------+ | Component Type | 11101011 | Return Error | Implicit | | Identifier | | | | +--------------------+----------+----------------------+--------------+ | Component Length | | XX octet component | Computed | +--------------------+----------+----------------------+--------------+ | Component ID | 11001111 | Components ID to | Implicit | | Identifier | | follow next | | +--------------------+----------+----------------------+--------------+ | Component ID | 00000001 | 1-byte Correlation | Computed | | Length | | ID | | +--------------------+----------+----------------------+--------------+ | Component ID | 00000011 | Correlation ID, | SIP Message | | | | reflected from | | | | | invoke id | | +--------------------+----------+----------------------+--------------+ | Error Code | 11010011 | National TCAP Error | Implicit | | Identifier | | | | +--------------------+----------+----------------------+--------------+ | Error Code Length | 00000001 | 1-octet Error Code | Implicit | +--------------------+----------+----------------------+--------------+ | Error Code | 00000100 | Missing customer | SIP Message | | | | record | | +--------------------+----------+----------------------+--------------+ | Parameter Set | 11110010 | Component parameters | Implicit | | Identifier | | start here | | +--------------------+----------+----------------------+--------------+ | Parameter Set | 00000000 | No parameters | SIP Message | | Length | | included | | +--------------------+----------+----------------------+--------------+ 6.1.3.2 SIP Error Response The SIP Element can parse and generate the text representation of the TCAP error response when it is formatted as follows: 7 Applicable Documents [1] Telcordia GR-246-CORE, Issue 3, Bell Communications Research Specification of Signaling System Number 7 [2] Rosenberg, Schulzrinne, Camarillo, Johnston, Peterson, Sparks, Handley, Schooler, RFC 3261, SIP: Session Initiation Protocol, June 2002. [3] Donovan, RFC 2976, The SIP INFO Method. [4] Telcordia TR-NWT-1188, CLASS Feature: Calling Name Delivery Generic Requirements. [5] sentitO Networks Inc, Jade System Design Document. [6] Telcordia GR-1299-CORE, AINGR: Switch-Service Control Point/Adjunct Interface [7] Crocker, D. and P. Overell, Augmented BNF for Syntax Specifications: ABNF, RFC 2234, November 1997. 8 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