One document matched: draft-miller-sip-tcap-00.txt
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:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE section SYSTEM "tcap.dtd">
<tcap>
<Transaction-Portion>
Transaction-Portion-Structure
</Transaction-Portion>
[<Dialogue-Portion>
Dialogue-Portion-Structure
</Dialogue-Portion>]
[<Component-Portion>
Component-Portion-Structure
</Component-Portion>)]
</tcap>
The <Transaction-Portion> is mandatory in all messages. The
<Dialogue-Portion> and <Component-Portion> 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 <tcap>.
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:
<Event-Name value = Event-Name-Value />
<Package-Type value = Package-Type-Value />
<Transaction-ID value = Transaction-ID-Value />
[<P-Abort-Cause value = P-Abort-Cause-Value />]
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> Component-Structure </component>)
Each component is represented as follows:
Component-Structure:
<Comp-Type value = Comp-Type-Value />
[<Invoke-ID value = *(DIGIT) />]
[<Correlation-ID value = *(DIGIT) />]
<Opcode value = Opcode-Value />
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:
<Comp-Type value = "Return-Error" >
<Correlation-ID value = *(DIGIT) />
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:
<Comp-Type value = "Reject" >
<Correlation-ID value = *(DIGIT) />
Problem-Code-Parameter
5.4 Error Codes
Error-Code-Parameter:
<Error-Code value = Error-Code-Value />
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 = Problem-Code-Value />
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:
<tag />
where tag is the parameter's name tag.
5.6.1 Timestamp
Timestamp-Parameter:
<Timestamp>
<Year value = 2DIGIT />
<Month value = 2DIGIT />
<Day value = 2DIGIT />
<Hour value = 2DIGIT />
<Minute value = 2DIGIT />
<PlusMinus = "+" / "-" />
<Hour2 value = 2DIGIT />
<Minute2 value = 2DIGIT />
</Timestamp>
5.6.2 Automatic Code Gap
ACG-Indicators-Parameter:
<ACG-Indicators>
<Control-Cause-Indication value = Control-Cause-Indication-Value />
<Duration value = Duration-Value />
<Gap value = Gap-Value />
</ACG-Indicators>
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 = Standard-Announcement-Value />
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:
<Customized-Announcement>
<Announcement-Set value = Announcement-Set-Value />
<Announcement-ID1 = Announcement-ID1-Value />
<Announcement-ID2 = Announcement-ID2-Value />
</Customized-Announcement>
Announcement-Set-Value: *(alphanum)
Announcement-ID1-Value: *(alphanum)
Announcement-ID2-Value: *(alphanum)
5.6.5 Digits
Digits-Parameter:
<Digits>
<Type-Of-Digits value = Type-Of-Digits-Value />
<Nature-Of-Number value = Nature-Of-Number-Value />
<Numbering-Plan value = Numbering-Plan-Value />
<Encoding value = Encoding-Value />
<DigitList value = *(DIGIT) />
</Digits>
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 = Standard-User-Error-Code-Value />
Standard-User-Error-Code-Value:
"Caller-Abandon" | "Improper-Caller-Response"
5.6.7 Problem Data
Problem-Data-Parameter:
<Problem-Data>
Parameter
</Problem-Data>
5.6.8 Service Key
Service-Key-Parameter:
<Service-Key>
Parameter
</Service-Key>
5.6.9 Busy Idle Status
Busy-Idle-Status-Parameter:
<Busy-Idle-Status value = Busy-Idle-Status-Value />
Busy-Idle-Status-Value:
"Busy" |
"Idle"
5.6.10 Call Forwarding Status
Call-Forwarding-Status-Parameter:
<Call-Forwarding-Status>
<Call-Forwarding-Variable value = Call-Forwarding-Status-Value />
<Call-Forwarding-on-Busy value = Call-Forwarding-Status-Value />
<Call-Forwarding-Do-Not-Answer value =
Call-Forwarding-Status-Value />
<Selective-Forwarding value = Call-Forwarding-Status-Value >
</Call-Forwarding-Status>
Call-Forwarding-Status-Value:
"Service-not-supported" | "Active" | "Not-Active" | "Spare"
5.6.11 Origination Restrictions
Originating-Restrictions-Parameter:
<Originating-Restrictions value = Originating-Restrictions-Value />
Originating-Restriction-Value:
"Denied-Origination" |
"Fully-Restricted-Origination" |
"Semi-Restricted-Origination" |
"Unrestricted-Origination"
5.6.12 Termination Restrictions
Terminating-Restrictions-Parameter:
<Terminating-Restrictions value = Terminating-Restrictions-Value />
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:
<DN-to-Line-Service-Type-Mapping>
<Match-Status value = Match-Status-Value />
<Line-Service-Type value = Line-Service-Type-Value />
</DN-to-Line-Service-Type-Mapping>
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:
<Duration>
<Hours value = Hours-Value />
<Minutes value = Minutes-Value />
<Seconds value = Seconds-Value />
</Duration>
Hours-Value: 2DIGIT
Minutes-Value: 2DIGIT
Seconds-Value: 2DIGIT
5.6.15 Returned Data
Problem-Data-Parameter:
<Returned-Data>
Parameter
</Returned-Data>
5.6.16 Bearer Capability Requested
Bearer-Capability-Requested-Parameter:
<Bearer-Capability-Requested>
<Coding-Standard value = Coding-Standard-Value />
<Information-Transfer-Capability value =
Information-Xfer-Capability-Value />
<Transfer-Mode value = Transfer-Mode-Value />
<Information-Transfer-Rate value =
Information-Transfer-Rate-Value />
<Structure value = Structure-Value />
<Configuration value = Configuration-Value />
<Establishment value = Establishment-Value />
<Symmetry value = Symmetry-Value />
<Multiplier-or-layer-id value = Multiplier-or-layer-id-Value />
<User-Info-layer1-protocol-id value =
User-Info-layer1-proto-id-Value />
<Rate-Adaptation value = Rate-Adaptation-Value />
<User-Info-layer2-protocol-id value =
User-Info-layer2-proto-id-Value />
<User-Info-layer3-protocol-id value =
User-Info-layer3-proto-id-Value />
</Bearer-Capability-Requested>
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 =
Bearer-Capability-Supported-Value />
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:
<Business-Group>
<AttSt value = AttSt-Value />
<BGID-Type value = BGID-Type-Value />
<LPII value = LPII-Type-Value />
<Party-Selector value = Party-Selector-Value />
<BGID-Octet1 value = BGID-Octet1-Value />
<BGID-Octet2 value = BGID-Octet2-Value />
<BGID-Octet3 value = BGID-Octet3-Value />
</Business-Group>
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:
<Signaling-Networks-Identifier>
*(<Network-ID-Octet1 value = alphanum />
<Network-ID-Octet2 value = alphanum />)
</Signaling-Networks-Identifier>
5.6.21 Generic Name
Generic-Name-Parameter:
<Generic-Name>
<Type-of-Name value = Type-of-Name-Value />
<Availability value = Availability-Value />
<Presentation value = Presentation-Value />
<Name value = alpha />
</Generic-Name>
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:
<Message-Waiting-Indicator-Type value = 2DIGIT />
5.6.23 Look Ahead for Busy Response
Look-Ahead-for-Busy-Response-Parameter:
<Look-Ahead-for-Busy-Response>
<Ack-Type value = Ack-Type-Value />
<Location value = Location-Type-Value />
</Look-Ahead-for-Busy-Response>
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: <cic value = hex-val />
5.6.25 Precedence Identifier
Precedence-Identifier-Parameter:
<Precedence-Identifier>
<Precedence-Level value = />
<MLPP value = hex-val />
</Precedence-Identifier>
5.6.26 Call Reference
Call-Reference-Parameter:
<Call-Reference>
<Call-Identity-Octet1 value = hex-val />
<Call-Identity-Octet1 value = hex-val />
<Call-Identity-Octet1 value = hex-val />
<Point-Code-Octet1 value = hex-val />
<Point-Code-Octet1 value = hex-val />
<Point-Code-Octet1 value = hex-val />
</Call-Reference>
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:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE section SYSTEM "tcap.dtd">
<tcap>
<Transaction-Portion>
<Event-Name value = "CNAM" />
<Package-Type value = "QWP" />
<Transaction-ID value = "11223344@10.0.0.10" />
</Transaction-Portion>
<Component-Portion>
<component>
<Comp-Type value = "Invoke-Last" />
<Invoke-ID value = "3" />
<Opcode value = "Parameter-Provide-Value" />
<Generic-Name />
<Service-Key>
<Digits>
<Type-of-Digits value = "Calling-Directory-Number" />
<Nature-of-Number value = "National">
<Numbering-Plan value = "ISDN-Numbering" />
<Encoding = value "BCD" />
<DigitList value = "9785551234" />
</Digits>
</Service-Key>
</component>
</Component-Portion>
</tcap>
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:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE section SYSTEM "tcap.dtd">
<tcap>
<Transaction-Portion>
<Event-Name value = "CNAM" />
<Package-Type value = "Response" />
<Transaction-ID value = "11223344@10.0.0.10" />
</Transaction-Portion>
<Component-Portion>
<component>
<Comp-Type value = "Return-Result-Last" />
<Correlation-ID value = "3" />
<Generic-Name>
<Type-of-Name value = "Calling-name" />
<Availability value = "Name-available-unknown"/>
<Presentation value = "Presentation-allowed"/>
<Name value = "DOE,JOHN" />
</Generic-Name>
</component>
</Component-Portion>
</tcap>
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:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE section SYSTEM "tcap.dtd">
<tcap>
<Transaction-Portion>
<Event-Name value = "CNAM" />
<Package-Type value = "Response" />
<Transaction-ID value = "11223344@10.0.0.10" />
</Transaction-Portion>
<Component-Portion>
<component>
<Comp-Type value = "Return-Error" />
<Correlation-ID value = "3" />
<Error-code value = "Missing-customer-record" />
</component>
</Component-Portion>
</tcap>
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
| PAFTECH AB 2003-2026 | 2026-04-23 22:24:17 |