Internet Engineering Task Force INTERNET-DRAFT draft-schulzrinne-ss7-00.

ps

??? WG Schulzrinne/Kang Columbia U./Bell Atlantic September 27, 1998 Expires: January 1999

Mapping between ISUP and SIP

Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), 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 work in progress. To view the entire list of current Internet-Drafts, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacic Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited.

Copyright Notice
Copyright (c) The Internet Society (1998). All Rights Reserved.
Abstract IP-based Internet telephony end systems need to communicate with GSTN end systems. Some of the former use SIP, while GSTN signaling is largely based on SS7 and its ISUP application-layer protocol. This document describes how to translate between SIP and ISUP signaling.

Contents
1 Introduction 2 Messages 2.1 Calls from Internet to GSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Calls from GSTN to Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 ISDN User Part Parameters 3.1 Access transport . . . . . . 3.2 Automatic congestion level 3.3 Backward call indicators . 3.4 Call reference . . . . . . . 3.5 Called party number . . . 3.6 Calling party category . . . 3.7 Calling party number . . . 3.8 Cause indicator . . . . . . 3.9 Event information . . . . . 3.10 Facility Indicator . . . . . 4 6 6 9 9 9 9 10 10 10 10 11 11 11 12

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

INTERNET-DRAFT 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24

draft-schulzrinne-ss7-00.ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

September 27, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12 12 13 13 13 13 13 13 14 14 14 14 15 15 15 15 15 17 17 17 17 17 17 17 17 17 18 18 18 18 18 18 18 18 19 19 19 19 19 19 19 19 19

Forward call indicator . . . . . . . . Information Indicators . . . . . . . Information Request Indicators . . . Nature of Connection Indicators . . Optional backward call indicator . . Optional forward call indicators . . Original called number . . . . . . . Redirecting number . . . . . . . . . Redirection Information . . . . . . . Redirection Number . . . . . . . . . Suspend/resume Indicator . . . . . . Transmission medium requirements User service information . . . . . . User-to-user information . . . . . .

4 Cause Values 4.0.1 Cause No. 1: Unallocated (unassigned) number . . . . . . . . . . . . . . 4.0.2 Cause No. 2: No route to specied transit network (national use) . . . . . 4.0.3 Cause No. 3: No route to destination . . . . . . . . . . . . . . . . . . . 4.0.4 Cause No. 4: Send special information tone . . . . . . . . . . . . . . . . 4.0.5 Cause No. 5: Misdialled trunk prex (national use) . . . . . . . . . . . . 4.0.6 Cause No. 6: Channel unacceptable . . . . . . . . . . . . . . . . . . . . 4.0.7 Cause No. 7: Call awarded and being delivered in an established channel 4.0.8 Cause No. 8: Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . 4.0.9 Cause No. 9: Preemption - circuit reserved for reuse . . . . . . . . . . . 4.0.10 Cause No. 16: Normal call clearing . . . . . . . . . . . . . . . . . . . . 4.0.11 Cause No. 17: User busy . . . . . . . . . . . . . . . . . . . . . . . . . . 4.0.12 Cause No. 18: No user responding . . . . . . . . . . . . . . . . . . . . . 4.0.13 Cause No. 19: No answer from user (user alerted) . . . . . . . . . . . . 4.0.14 Cause No. 20: Subscriber absent . . . . . . . . . . . . . . . . . . . . . . 4.0.15 Cause No. 21: Call rejected . . . . . . . . . . . . . . . . . . . . . . . . 4.0.16 Cause No. 22: Number changed . . . . . . . . . . . . . . . . . . . . . . 4.0.17 Cause No. 26: Non-selected user clearing . . . . . . . . . . . . . . . . . 4.0.18 Cause No. 27: Destination out of order . . . . . . . . . . . . . . . . . . 4.0.19 Cause No. 28: Invalid number format (address incomplete) . . . . . . . . 4.0.20 Cause No. 29: Facility rejected . . . . . . . . . . . . . . . . . . . . . . 4.0.21 Cause No. 30: Response to STATUS ENQUIRY . . . . . . . . . . . . . 4.0.22 Cause No. 31: Normal, unspecied . . . . . . . . . . . . . . . . . . . . 4.1 Resource unavailable class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Cause No. 34: No circuit/channel available . . . . . . . . . . . . . . . . 4.1.2 Cause No. 38: Network out of order . . . . . . . . . . . . . . . . . . . . 4.1.3 Cause No. 39: Permanent frame mode connection out-of-service . . . . . 4.1.4 Cause No. 40: Permanent frame mode connection operational . . . . . . 4.1.5 Cause No. 41: Temporary failure . . . . . . . . . . . . . . . . . . . . . 4.1.6 Cause No. 42: Switching equipment congestion . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Schulzrinne/Kang

Expires January 1999

[Page 2]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998 19 20 20 20 20 20 20 20 20 20 20 21 21 21 21 21 21 21 21 21 21 21 22 22 22 22 22 22 22 22 22 23 23 23 23 23 23 23 23 23 24 24

4.2

4.3

4.4

4.5

4.1.7 Cause No. 43: Access information discarded . . . . . . . . . . . . . . . . . . . . . 4.1.8 Cause No. 44: Requested circuit/channel not available . . . . . . . . . . . . . . . . 4.1.9 Cause No. 46: Precedence call blocked . . . . . . . . . . . . . . . . . . . . . . . . 4.1.10 Cause No. 47: Resource unavailable, unspecied . . . . . . . . . . . . . . . . . . . Service or option unavailable class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Cause No. 49 Quality of Service not available . . . . . . . . . . . . . . . . . . . . . 4.2.2 Cause No. 50: Requested facility not subscribed . . . . . . . . . . . . . . . . . . . 4.2.3 Cause No. 53: Outgoing calls barred within CUG . . . . . . . . . . . . . . . . . . . 4.2.4 Cause No. 55: Incoming calls barred within CUG . . . . . . . . . . . . . . . . . . . 4.2.5 Cause No. 57: Bearer capability not authorized . . . . . . . . . . . . . . . . . . . . 4.2.6 Cause No. 58: Bearer capability not presently available . . . . . . . . . . . . . . . . 4.2.7 Cause No. 62: Inconsistency in designated outgoing access information and subscriber class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.8 Cause No. 63: Service or option not available, unspecied . . . . . . . . . . . . . . Service or option not implemented class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Cause No. 65: Bearer capability not implemented . . . . . . . . . . . . . . . . . . . 4.3.2 Cause No. 66: Channel type not implemented . . . . . . . . . . . . . . . . . . . . . 4.3.3 Cause No. 69: Requested facility not implemented . . . . . . . . . . . . . . . . . . 4.3.4 Cause No. 70: Only restricted digital information bearer capability is available (national use) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.5 Cause No. 79: Service or option not implemented, unspecied . . . . . . . . . . . . Invalid message (e.g. parameter out of range) class . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Cause No. 81: Invalid call reference value . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Cause No. 82: Identied channel does not exist . . . . . . . . . . . . . . . . . . . . 4.4.3 Cause No. 83: A suspended call exists, but this call identity does not . . . . . . . . . 4.4.4 Cause No. 84: Call identity in use . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 Cause No. 85: No call suspended . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.6 Cause No. 86: Call having the requested call identity has been cleared . . . . . . . . 4.4.7 Cause No. 87: User not member of CUG . . . . . . . . . . . . . . . . . . . . . . . 4.4.8 Cause No. 88: Incompatible destination . . . . . . . . . . . . . . . . . . . . . . . . 4.4.9 Cause No. 90: Non-existent CUG . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.10 Cause No. 91: Invalid transit network selection (national use) . . . . . . . . . . . . 4.4.11 Cause No. 95: Invalid message, unspecied . . . . . . . . . . . . . . . . . . . . . . Protocol error (e.g. unknown message) class . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Cause No. 96: Mandatory information element is missing . . . . . . . . . . . . . . 4.5.2 Cause No. 97: Message type non-existent or not implemented . . . . . . . . . . . . 4.5.3 Cause No. 98: Message not compatible with call state or message type non-existent or not implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Cause No. 99: Information element/parameter non-existent or not implemented . . . 4.5.5 Cause No. 100: Invalid information element contents . . . . . . . . . . . . . . . . . 4.5.6 Cause No. 101: Message not compatible with call state . . . . . . . . . . . . . . . . 4.5.7 Cause No. 102: Recovery on timer expiry . . . . . . . . . . . . . . . . . . . . . . . 4.5.8 Cause No. 103: Parameter non-existent or not implemented - passed on (national use) 4.5.9 Cause No. 110: Message with unrecognized parameter discarded . . . . . . . . . . 4.5.10 Cause No. 111: Protocol error, unspecied . . . . . . . . . . . . . . . . . . . . . . Expires January 1999

Schulzrinne/Kang

[Page 3]

INTERNET-DRAFT 4.6

draft-schulzrinne-ss7-00.ps

September 27, 1998

Interworking class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.6.1 Cause No. 127: interworking, unspecied . . . . . . . . . . . . . . . . . . . . . . . 24 24

5 Open Issues

1 Introduction
The Session Initiation Protocol (SIP) [?] provides the necessary signaling functionality to establish, modify and terminate multimedia sessions on the Internet, including two-party telephone calls. In the General Switched Telephone Network (GSTN) (formerly known as PSTN), the end system uses a user-network (UNI) protocol such as Q.931 for ISDN or hook switch indications and DTMF tones to communicate with the network. The network itself uses different protocols, with almost all modern parts of the GSTN employing Signalling System No. 7 (SS7) []. SS7 is a complete protocol stack comprising the link, network, transport and application layer. The lower layers are specic to SS7 and are not relevant for an Internet environment. Thus, only the interworking at the application layer needs to be considered. The most common application-layer signaling protocol is the ISDN user part (ISUP). This document describes how calls that originate on either the GSTN or the Internet can terminate on the other network. We refer to the interworking unit as a SIP-ISUP gateway. Note that this signaling translation is not sufcient for making phone calls: in addition, packets containing media data have to be translated to an audio digital bitstream. The translation may take place at the SIP-ISUP gateway, but it may also be delegated to equipment that is located elsewhere on the network. ISUP denes a number of messages and parameters for national use. In the United States, these are dened by ANSI and Bellcore standards []. The requirement for interworking differ depending on whether SIP terminates the call (Fig. 1, or whether SIP connects two SS7 clouds (SIP in the middle), as depicted in Fig. 2. We refer to the former as SIP termination, to the latter as SIP bridging. For SIP bridging, information that is not relevant to the Internet side needs to be relayed between the two sides to achieve full transparency. Also, translations between ISUP parameters and SIP headers need to be one-to-one in that case, while a many-to-one translation may be acceptable in the case of SIP termination. This document is primarily concerned with the former case, but tries to address SIP bridging as well. Reasons for performing SIP bridging include: An SS7-Internet gateway may not be aware of whether one of the subsequent Internet signaling hops might be connected to the SS7 network. An SS7 gateway can talk to another end point that has ISDN, E1 or T1 channel associated signaling, PBX trunk signaling or one of the ten or so different avors of SS7. (Fig. 2) The gures also show the associated media transport gateways. It is also possible that only signaling is translated into the Internet domain, with regular SCPs [terminology?] controlling traditional circuitswitched trunks. This is shown in Fig. 3. A SGW would likely be connected to many different SGWs, utilizing the Internet for call routing and as a high-speed carrier for signaling information. Fig. 1 and Fig. 2 indicate an additional protocol between the media and signaling gateway. This protocol is only necessary if the two devices are physically separate. The protocol is beyond the scope of this document; possible solutions include SGCP, . . . , proprietary RPC mechanisms or extending the PINT and generic event notication mechanisms to this problem []. Schulzrinne/Kang Expires January 1999 [Page 4]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

PSTN

Internet

ISUP

SGW

SIP

host

control protocol MGW (NAS) RTP

trunk (T1, T3, ...)

voice data streams signaling

Figure 1: Gateway between SS7 and Internet domains

PSTN

PSTN
SS7 (ANSI)

ISUP

SGW

SIP

Internet

SIP

SS7 (ETSI)

SGW

SS7 (AIN) T1/E1 ISDN

control protocol trunk (T1, T3, ...) MGW (NAS)

RTP trunk (T1, T3, ...)

MGW (NAS) voice data streams signaling

Figure 2: Using the Internet to bridge between SS7 domains

Schulzrinne/Kang

Expires January 1999

[Page 5]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

PSTN

PSTN

ISUP

SGW

SIP

Internet

SIP SIP

SGW

ISUP

control protocol

trunk (T1, T3, ...)

trunk (T1, T3, ...) SCP voice data streams signaling SCP

Figure 3: Using SIP to connect SCPs Media gateways make include systems such as automatic call distribution devices (ACD), interactive voice response systems (IVR), conferencing bridges, voice recognition servers, pay phones, and the like. Note that there is a many-to-many relationship between signaling gateways and media gateways. For example, the number of SS7 gateways is restricted by the small number of SS7 point codes (addresses).

2 Messages
The ISUP messages are summarized in Table 1.

2.1 Calls from Internet to GSTN

It is assumed that the SIP Request-URI contains a telephone number or can be translated by the gateway into such a number. The basic message ow is shown in Fig. 4. A SIP INVITE request triggers an ISUP IAM (Initial Address) message. The ISUP side returns an ACM (Address Complete) message, which is translated to a 100 response code by the gateway. When the callee answers, the ISUP side generates an ANM (Answer) message, which propagates as a 200 message to the SIP side. The SIP client conrms the call with an ACK request that generates a Connect message. At the end of the call, the SIP BYE request triggers a REL (Release) message on the ISUP side, conrmed by a RLC (Release Complete). The value of elds other than those listed in Table ?? cannot be conveyed in ISUP messages. This includes additional information about the call and caller such as the To display name, Subject, Organization, Priority and Expires. In the GSTN, a one-way voice path is established to the caller by the ACM message. This voice path is used for voice announcements and to transmit tones. In SIP, media paths are created only after a complete signaling exchange, i.e., the callee enables the media application, at the earlier, after sending a 200 response and possibly only after receiving an ACK from the caller. The caller enables its media agents after receiving Schulzrinne/Kang Expires January 1999 [Page 6]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps Address complete Answer Blocking Blocking acknowledgement Call progress Circuit group blocking Circuit group blocking acknowledgement Circuit group query Circuit group query response Circuit group reset Circuit group reset acknowledgement Circuit group unblocking Circuit group unblocking acknowledgement Charge information Confusion Connect Continuity Continuity check request Facility Facility accepted Facility reject Facility request Forward transfer Identication request Identication response Information Information request Initial address Loop back acknowledgement Loop prevention Network resource management Overload Pass-along Release Release complete Reset circuit Resume Segmentation Subsequent address Suspend Unblocking Unblocking acknowledgement Unequipped CIC User Part available User Part test User-to-user information ACM ANM 100 200

September 27, 1998

IAM

INVITE

REL RLC

Schulzrinne/Kang

Expires January 1999 Table 1: ISUP message types

[Page 7]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

SIP
INVITE

ISUP
IAM ACM

central office

100 200 ANM

ACK

connect ack

BYE

REL RLC

200

Figure 4: Call from Internet to GSTN using SIP and ISUP the 200 response from the callee. There are several possible solutions to the problem of network announcements: The gateway could translate the ACM message into a 200 response and issue a BYE if the call turns out to be unsuccessful. Alternatively, the 100 response could contain an indication to the caller that it should expect media data. As a third approach, the caller could immediately after issuing the INVITE request start Schulzrinne/Kang Expires January 1999 [Page 8]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

listening on its audio channel. Note also that the success of signaling in the GSTN has a slightly more comprehensive meaning than in the Internet. In the GSTN, call acceptance implies the availability of a channel with a given, xed bandwidth between the two parties, while such resource allocation is the realm of resource reservation protocols in the Internet.

2.2 Calls from GSTN to Internet

The message exchanges are similar to the above: 1. ISUP IAM generates SIP INVITE; 2. SIP 100 response generates ISUP ACM; 3. SIP 200 response generates ISUP ANM; 4. ISUP Connect generates SIP ACK; 5. ISUP REL generates SIP BYE; 6. 200 response to BYE generates RLC.

3 ISDN User Part Parameters

3.1 Access transport
Funtionality: Information generated on the access side of a call and transferred transparently in either direction between originating and terminating local exchanges. The information is signicant to both users and local exchanges. It is an optional parameter in IAM, INF, REL, COT, ANM, and ACM messages. Q.931: This parameter can contain one or more Q.931 information elements (IEs) such as called party subaddress, calling party subaddress, high layer compatibility, low layer compatibility, and progress indicator. All of the above IEs are optional in Q.931 SETUP messages. SIP: The subaddresses are conveyed through the SIP URL. The use of low and high layer compatibility and progress is for further study. Comments: None of the optional IEs in SETUP message of Q.931 are used for host-to-host calls in common H.323 implementations.

3.2 Automatic congestion level

Functionality: Information sent to the exchange at the other end of a circuit to indicate that a particular level of congestion exists at the sending exchange. This is an optional parameter in REL messages. When a REL is issued due to congestion, this parameter is included. The exchanges involved temporarily reduce or suspend the seizures of trunks to the congested exchange.

Schulzrinne/Kang

Expires January 1999

[Page 9]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

SIP: There currently is no parameter in the SIP BYE message to indicate the reason for terminating the call. It is suggested to extend SIP by allowing a Warning header in the BYE request indicating the reason for forced disconnection.

3.3 Backward call indicators

Functionality: Information relating to the characteristics of the connection, signalling path and called party sent in the backward direction. It includes information about whether this is a charged call (bits AB), whether the called party is free (bits CD), whether the called party is a payphone (EF), whether end-to-end methods are available (GH), whether SS7 is in use all the way (bit I), whether end-toend information is available (bit J), whether holding is requested (bit L), whether the callee supports ISDN (bit M), whether there is an echo control device (bit N) and the SCCP method (bit O). This is a mandatory parameter in ACM. Q.931: The ISDN Access Indicator (bit M), such as Called party has non-ISDN access, of the Backward Call Indicators can be mapped into Progress description, such as Destination address is non ISDN, of the Progress Indicator IE in the SETUP message. The progress description value shall be used only in the case of interworking in a full ISDN environment, e.g., when bearer capability selection is not supported or when resource or route of the preferred capability is not available. SIP: For SIP bridging, this parameter needs to be added, possibly as an additional header. For SIP termination, none of these parameters seem useful on the Internet side.

3.4 Call reference

Functionality: Circuit independent information identifying a particular call. This is an optional parameter in IAM, ACM, CPG, REL, SUS, RES, FOT, INF, and INR Messages. The parameter identies a particular ISUP call at an exchange, and consists of a call identity, and the point code of that exchange. Q.931: Call reference IE. SIP: Carried in the Call-ID header, with the point code as a host.

3.5 Called party number

Functionality: Information to identify the called party. This is a mandatory variable-length parameter in IAM. Q.931: Called party number IE. SIP: To header.

3.6 Calling party category

Functionality: Information sent in the forward direction indicating the category of the calling party and, in case of semi-automatic calls, the service language to be spoken by the incoming delay and assistance operators. Languages are limited to French, English, German, Russian and Spanish. Other code points designate a calling subscriber with priority, a voice band data call, a test call and a payphone call. This is a mandatory xed-length parameter in IAM and an optional parameter in INF. Schulzrinne/Kang Expires January 1999 [Page 10]

INTERNET-DRAFT Q.931: Not available.

draft-schulzrinne-ss7-00.ps

September 27, 1998

SIP: The Accept-Language header can indicate the language capabilities of the caller. Proxy and redirect servers can use this information to forward requests appropriately. The type of call is indicated by the session description message body. The Priority header can designate a calling subscriber with priority. SIP cannot express that a call is a test call or from a payphone. The former could be made another value in the Priority header eld. It may be useful to designate a standard user value for the From URL that indicates that the user name does not reect that of the person calling, as would be the case for a payphone. For example, [email protected].

3.7 Calling party number

Functionality: Information sent in the forward direction to identify the calling party. This is an optional paramter in IAM and INF. The parameter contains a Screening Indicator (SI) that can take the values user provided, not veried, user veried, provided and passed, user provided, veried and failed and network provided. The screening status is important in calls to TE equipment that are not attended by humans (computers, facsimile machines). These TEs can be set up to accept only calls in which the calling number is as expected, and has passed screening. The Address Presentation Restriction Indicator (RI) can take the values presentation allowed, presentation restricted, and address not available. This indicator allows the calling party to request that it does not want its identity revealed to the called party. Q.931: It supports SI and RI in Calling Party Number IE. SIP: The From header contains this information. For SIP termination, the RI would lead to the insertion of a dummy value in the From header for calls from the GSTN to the Internet. For calls from the Internet to the GSTN, the caller would use a randomized From value, but use proxy authentication to authenticate itself to the gateway. There may be a need for dening an anonymous, randomized From header value, e.g., by using a special domain name.

3.8 Cause indicator

Functionality: Information sent in either direction indicating the reason for sending the message. This is a mandatory parameter in REL messages, and optional parameter in ACM and CPG messages. Q.931: Cause IE (Q.850). SIP: See Table 2.

3.9 Event information

Functionality: Information indicating the type of event which caused a call progress message to be sent. It indicates an event that has occured during the call set-up, including alerting, progres, in-band information available, call forwarded on busy, call forwarded on no reply and call forwarded unconditional. This is a mandatory parameter in CPG. Q.931 Alerting and Progress message.

Schulzrinne/Kang

Expires January 1999

[Page 11]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

SIP: SIP sends provisional (1xx) response messages to indicate call progress. However, the basic SIP spec currently has no mechanism except a 200 response to signal to the caller to enable media reception for call progress tones (in-band information). The call control spec adds reliable 1xx messages, which could then be extended to allow such indication.

3.10 Facility Indicator

Functionality: Currently, indicates user-to-user service. Q.931: ? SIP: ?

3.11 Forward call indicator

Functionality: Information relating to the characteristics of the connection, signalling path and calling party sent in the forward direction. Bits indicate whether ISUP was used all the wayt, whether access was through ISDN, or whether end-to-end information is available. This is a mandatory parameter in IAM. Q.931: The ISDN Access Indicator, such as Called party has non-ISDN access, of Forward Call Indicators can be mapped into Progress description, such as Destination address is non ISDN of Progress Indicator IE in SETUP message. The progress description value shall be used only in the case of interworking in a full ISDN environment, e.g., when bearer capability selection is not supported or when resource or route of the preferred capability is not available. SIP: The information contained here could be mapped into Warning headers.

3.12 Information Indicators

Functionality: Information identifying the optional parameters included in a message. This is a mandatory parameter in INF message. It consists of bits representing the parameters or call-control functions that can be requested by an exchange. The bit values indicate whether the corresponding parameter is included in the message, or whether the corresponding service is being provided. Q.931: ? SIP: The functionality is indicated by the presence of SIP header elds and their content.

3.13 Information Request Indicators

Functionality: Information identifying the optional parameters requested in a message. This is a mandatory paramter in INR message. It consists of indicator bits that represent parameters or call-control functions (such as charge information, holding, malicious call information). The bit value indicates whether the corresponding parameter or function is requested. SIP: The functionality like call holding or malicious call information is provided differently in SIP. If necessary, these bits can be mapped to Call-Disposition values.

Schulzrinne/Kang

Expires January 1999

[Page 12]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

3.14 Nature of Connection Indicators

Functionality: Information relating the the transmission path used on a connection, such as the number of satellite circuits, the presence of echo control devices and whether continuity check is required. This is a mandatory parameter in IAM message. SIP: The indications can be signaled by Warning headers, while a request for continuity checks can be expressed in the Call-Disposition or possibly Proxy-Require header.

3.15 Optional backward call indicator

Functionality: Information relating to the characteristics of the connection, signalling path and called party sent in the backward direction. This is an optional parameter in ACM, CPG and ANM messages. It only used for in-band information indication. SIP: See discussion of in-band information.

3.16 Optional forward call indicators

Functionality: Information relating to the characteristics of the connection, signalling path and called party sent in the forward direction. This is an optional parameter in IAM messages, which is used in countries that offer CUG (closed user group) service. It indicates, for example, if a call can leave a closed user group. SIP: Proxy-Require?

3.17 Original called number

Functionality: Information sent in the forward direction when a call is redirected and identies the original called party. This is an optional parameter in IAM. The presentation screening indicator (RI) pertains to the original called number. SI is not used. SIP: This corresponds to the To header eld, with the exception of the address presentation restriction indicator. The latter could be indicated using a Proxy-Require option.

3.18 Redirecting number

Functionality: Information sent in the forward direction when a call is diverted, indicating the number from which the call was diverted. This is an optional parameter in IAM and CPG messages. SIP: The original destination of a call is contained in the From header eld, while the path of the request can be deduced from the Via header eld.

3.19 Redirection Information

Functionality: Information sent in either direction giving information about call redirection or call rerouting, including whether path information can be presented, the number (1 through 5) and the reasons for redirection. This is an optional parameter in IAM and REL messages.

Schulzrinne/Kang

Expires January 1999

[Page 13]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

SIP: For redirect servers, the status code does not currently provide information on why the redirection occurred. This could potentially be expressed, for human consumption, as an appropriate status message or, for machine parsing, as a Warning header eld or by adding additional 3xx status codes. Since the 3xx status codes already express the permanency and interpretation of the Location headers, Warning headers seem more appropriate. For proxy servers, information about why a call is routed in a particular manner remains hidden. Indeed, it would be difcult to encode the information about the outcome of parallel searches. The number of proxy hops can be deduced by the callee by inspecting the Via headers.

3.20 Redirection Number

Functionality: Information sent in backward direction indicating the number towards which the call must be redirected or has been forwarded. Suppose that an exchange has received the IAM of an incoming call, and determines that the connection has to be rerouted. It then sends a (backward) REL message which may include a redirection number, which is the new called number. This is an optional parameter in REL. The Redirection number is mapped into Q.952. SIP: 301 Comments: If the called party changed number, it would be nice for SIP user to get that information on screen.

3.21 Suspend/resume Indicator

Functionality: Information sent in the suspend and resume messagesto indicate whether suspend/ resume was initiated by an ISDN subscriber or by the network. This is a mandatory parameter in SUS and RES. This is for congestion control. Q.931: Suspend and resume messages are sent by the user to network in Q.931. Suspend acknowledge(or reject) and Resume acknowledge(or reject) are sent by the network to the user. SIP Comments

3.22 Transmission medium requirements

Functionality: Information sent in the forward direction indicating the type of transmission medium required for the connection. This is a mandatory parameter in IAM. Q.931: In NetMeeting this was always specied as packet mode in bearer capability IE. SIP: Can be encapsulated in SDP.

3.23 User service information

Functionality: Information sent in the forward direction indicating the bearer capability requested by the calling party. This is an optional paramter in IAM message. Schulzrinne/Kang Expires January 1999 [Page 14]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

Q.931: Bearer capability IE. In NetMeeting this was always specied as unrestricted digital information and User Layer1 protocol: Rec. H.221 and H.242 SIP: Call-Disposition?

3.24 User-to-user information

Functionality: User-to-user information is generated by a user and transferred transparently through the interexchange network between the originating and terminating local exchanges. Q.931: User-user IE. User-user IE is used to convey H.225.0 informations in Q.931 messages in the H.323 protocol. SIP: This is roughly equivalent to the message body of a SIP message.

4 Cause Values
SIP expresses error conditions mainly through status codes in responses, with additional optional information provided by zero or more Warning headers. ISUP and DSS1 use a cause IE to indicate failure reasons. Note that ISUP and DSS1 commingle failures due to the network path, resource availability and signaling failures. In the Internet side, network path problems are indicated by ICMP and lack of resource availability by failure indications of the resource reservation protocol. The mapping between DSS1 and ISUP cause values and SIP status/warning messages is given in Table 2. Warning messages are indicated by W, while network conditions indicated by ICMP are marked as such. Note that for ISUP bridging, all status codes would have to be mapped one-to-one. This is probably most readily accomplished with either a new SIP header or additional Warning headers. 4.0.1 Cause No. 1: Unallocated (unassigned) number

This cause indicates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allocated (assigned). 4.0.2 Cause No. 2: No route to specied transit network (national use)

This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause. This cause is supported on a network-dependent basis. 4.0.3 Cause No. 3: No route to destination

This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network-dependent basis.

Schulzrinne/Kang

Expires January 1999

[Page 15]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998 ISDN/ISUP? xx xx xx -x -x xxxx -x xx xx xx xx xx xx xx xxx xx xx xxx xx xx xxxx xx xx xx xx xx xxx xx xx xx xx xx xx xx xxx xx xx xxxxSIP status 404 ICMP 404? 500 ? ? 200 W W 600 408 408 480 603 301 500 484 501 200 W301 503 503 ? 503 503 400 W301 W? W399 W? 407 403 403 403 503 ? 500 501, W 501, W305 501, W 501, W 501 481 [Page 16] ? 481 481

cause denition 1 Unallocated (unassigned) number 2 No route to specied transit network 3 No route to destination 4 Send special information tone 5 Misdialled trunk prex 6 Channel unacceptable 7 Call awarded and being delivered in an established channel 8 Preemption 9 Preemption - circuit reserved for reuse 16 Normal call clearing 17 User busy 18 No user responding 19 No answer from user (user alerted) 20 Subscriber absent 21 Call rejected 22 Number changed 26 Non-selected user clearing 27 Destination out of order 28 Invalid number format (address incomplete) 29 Facility rejected 30 Response to STATUS ENQUIRY 31 Normal, unspecied 34 No circuit/channel available 38 Network out of order 39 Permanent frame mode connection out-of-service 40 Permanent frame mode connection operational 41 Temporary failure 42 Switching equipment congestion 43 Access information discarded 44 Requested circuit/channel not available 46 Precedence call blocked 47 Resource unavailable, unspecied 49 Quality of Service not available 50 Requested facility not subscribed 53 Outgoing calls barred within CUG 55 Incoming calls barred within CUG 57 Bearer capability not authorized 58 Bearer capability not presently available 62 Inconsistency in designated outgoing access 63 Service or option not available, unspecied 65 Bearer capability not implemented 66 Channel type not implemented 69 Requested facility not implemented 70 Only restricted digital information bearer 79 Service or option not implemented, unspecied 81 Invalid call reference value Schulzrinne/Kang Expires January 1999 82 Identied channel does not exist 83 A suspended call exists, but this call identity does not 84 Call identity in use

INTERNET-DRAFT 4.0.4

draft-schulzrinne-ss7-00.ps

September 27, 1998

Cause No. 4: Send special information tone

This cause indicates that the called party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party. 4.0.5 Cause No. 5: Misdialled trunk prex (national use)

This cause indicates the erroneous inclusion of a trunk prex in the called party number. 4.0.6 Cause No. 6: Channel unacceptable

This cause indicates that the channel most recently identied is not acceptable to the sending entity for use in this call. 4.0.7 Cause No. 7: Call awarded and being delivered in an established channel

This cause indicates that the user has been awarded the incoming call, and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode X.25 virtual calls). 4.0.8 Cause No. 8: Preemption

This cause indicates that the call is being preempted. 4.0.9 Cause No. 9: Preemption - circuit reserved for reuse

This cause indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange. 4.0.10 Cause No. 16: Normal call clearing

This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situations, the source of this cause is not the network. 4.0.11 Cause No. 17: User busy

This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determine user busy, it is noted that the user equipment is compatible with the call. 4.0.12 Cause No. 18: No user responding

This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.

Schulzrinne/Kang

Expires January 1999

[Page 17]

INTERNET-DRAFT 4.0.13

draft-schulzrinne-ss7-00.ps

September 27, 1998

Cause No. 19: No answer from user (user alerted)

This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers. 4.0.14 Cause No. 20: Subscriber absent

This cause value is used when a mobile station has logged off, radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable at any user-network interface. 4.0.15 Cause No. 21: Call rejected

This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic eld may contain additional information about the supplementary service and reason for rejection. 4.0.16 Cause No. 22: Number changed

This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic eld. If a network does not support this cause value, cause No. 1, unallocated (unassigned) number shall be used. 4.0.17 Cause No. 26: Non-selected user clearing

This cause indicates that the user has not been awarded the incoming call. (DSS-1 only) 4.0.18 Cause No. 27: Destination out of order

This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term not functioning correctly indicates that a signalling message was unable to be delivered to the remote party; e.g. a physical layer or data link layer failure at the remote party, or user equipment off-line. 4.0.19 Cause No. 28: Invalid number format (address incomplete)

This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. This condition may be determined: immediately after reception of an ST signal; or on time-out after the last received digit. 4.0.20 Cause No. 29: Facility rejected

This cause is returned when a supplementary service requested by the user cannot be provided by the network.

Schulzrinne/Kang

Expires January 1999

[Page 18]

INTERNET-DRAFT 4.0.21

draft-schulzrinne-ss7-00.ps

September 27, 1998

Cause No. 30: Response to STATUS ENQUIRY

This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS ENQUIRY message. 4.0.22 Cause No. 31: Normal, unspecied

This cause is used to report a normal event only when no other cause in the normal class applies.

4.1 Resource unavailable class

4.1.1 Cause No. 34: No circuit/channel available

This cause indicates that there is no appropriate circuit/channel presently available to handle the call. 4.1.2 Cause No. 38: Network out of order

This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; e.g. immediately re-attempting the call is not likely to be successful. 4.1.3 Cause No. 39: Permanent frame mode connection out-of-service

This cause is included in a STATUS message to indicate that a permanently established frame mode connection is out-of-service (e.g., due to equipment or section failure) (see Annex A/Q.933). 4.1.4 Cause No. 40: Permanent frame mode connection operational

This cause is included in a STATUS message to indicate that a permanently established frame mode connection is operational and capable of carrying user information (see Annex A/Q.933). 4.1.5 Cause No. 41: Temporary failure

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try another call attempt almost immediately. 4.1.6 Cause No. 42: Switching equipment congestion

This cause indicates that the switching equipment generating this cause is experiencing a period of high trafc. 4.1.7 Cause No. 43: Access information discarded

This cause indicates that the network could not deliver access information to the remote user as requested, i.e., user-to-user information, low layer compatibility, high layer compatibility, or sub-address, as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic.

Schulzrinne/Kang

Expires January 1999

[Page 19]

INTERNET-DRAFT 4.1.8

draft-schulzrinne-ss7-00.ps

September 27, 1998

Cause No. 44: Requested circuit/channel not available

This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface. 4.1.9 Cause No. 46: Precedence call blocked

This cause indicates that there are no preemptable circuits or that the called user is busy with a call of equal or higher preemptable level. 4.1.10 Cause No. 47: Resource unavailable, unspecied

This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.

4.2 Service or option unavailable class

4.2.1 Cause No. 49 Quality of Service not available

This cause is used to report that the requested Quality of Service, as dened in Recommendation X.213, cannot be provided (e.g., throughput or transit delay cannot be supported). 4.2.2 Cause No. 50: Requested facility not subscribed

This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause, but the user is not authorized to use. 4.2.3 Cause No. 53: Outgoing calls barred within CUG

This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call, outgoing calls are not allowed for this member of the CUG. 4.2.4 Cause No. 55: Incoming calls barred within CUG

This cause indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls are not allowed to this member of the CUG. 4.2.5 Cause No. 57: Bearer capability not authorized

This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use. 4.2.6 Cause No. 58: Bearer capability not presently available

This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time.

Schulzrinne/Kang

Expires January 1999

[Page 20]

INTERNET-DRAFT 4.2.7

draft-schulzrinne-ss7-00.ps

September 27, 1998

Cause No. 62: Inconsistency in designated outgoing access information and subscriber class

This cause indicates that there is an inconsistency in the designated outgoing access information and subscriber class. 4.2.8 Cause No. 63: Service or option not available, unspecied

This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.

4.3 Service or option not implemented class

4.3.1 Cause No. 65: Bearer capability not implemented

This cause indicates that the equipment sending this cause does not support the bearer capability requested. 4.3.2 Cause No. 66: Channel type not implemented

This cause indicates that the equipment sending this cause does not support the channel type requested. 4.3.3 Cause No. 69: Requested facility not implemented

This cause indicates that the equipment sending this cause does not support the requested supplementary service. 4.3.4 Cause No. 70: Only restricted digital information bearer capability is available (national use)

This cause indicates that the calling party has requested an unrestricted bearer service but that the equipment sending this cause only supports the restricted version of the requested bearer capability. 4.3.5 Cause No. 79: Service or option not implemented, unspecied

This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.

4.4 Invalid message (e.g. parameter out of range) class

4.4.1 Cause No. 81: Invalid call reference value

This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface. 4.4.2 Cause No. 82: Identied channel does not exist

This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call. For example, if a user has subscribed to those channels on a primary rate interface numbered from 1 to 12 and the user equipment or the network attempts to use channels 13 through 23, this cause is generated.

Schulzrinne/Kang

Expires January 1999

[Page 21]

INTERNET-DRAFT 4.4.3

draft-schulzrinne-ss7-00.ps

September 27, 1998

Cause No. 83: A suspended call exists, but this call identity does not

This cause indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended call(s). 4.4.4 Cause No. 84: Call identity in use

This cause indicates that the network has received a call suspended request containing a call identity (including the null call identity) which is already in use for a suspended call within the domain of interfaces over which the call might be resumed. 4.4.5 Cause No. 85: No call suspended

This cause indicates that the network has received a call resume request containing a call identity information element which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed. 4.4.6 Cause No. 86: Call having the requested call identity has been cleared

This cause indicates that the network has received a call resume request containing a call identity information element indicating a suspended call that has in the meantime been cleared while suspended (either by network timeout or by the remote user). 4.4.7 Cause No. 87: User not member of CUG

This cause indicates that the called user for the incoming CUG call is not a member of the specied CUG or that the calling user is an ordinary subscriber calling a CUG subscriber. 4.4.8 Cause No. 88: Incompatible destination

This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility, or other compatibility attributes (e.g. data rate) which cannot be accommodated. 4.4.9 Cause No. 90: Non-existent CUG

This cause indicates that the specied CUG does not exist. 4.4.10 Cause No. 91: Invalid transit network selection (national use)

This cause indicates that a transit network identication was received which is of an incorrect format as dened in Annex C/Q.931. 4.4.11 Cause No. 95: Invalid message, unspecied

This cause is used to report an invalid message event only when no other cause in the invalid message class applies.

Schulzrinne/Kang

Expires January 1999

[Page 22]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

4.5 Protocol error (e.g. unknown message) class

4.5.1 Cause No. 96: Mandatory information element is missing

This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed. 4.5.2 Cause No. 97: Message type non-existent or not implemented

This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not dened or dened but not implemented by the equipment sending this cause. 4.5.3 Cause No. 98: Message not compatible with call state or message type non-existent or not implemented

This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state. 4.5.4 Cause No. 99: Information element/parameter non-existent or not implemented

This cause indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element identier(s)/parameter name(s) are not dened or are dened but not implemented by the equipment sending the cause. This cause indicates that the information element(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message. 4.5.5 Cause No. 100: Invalid information element contents

This cause indicates that the equipment sending this cause has received an information element which it has implemented; however, one or more elds in the information element are coded in such a way which has not been implemented by the equipment sending this cause. 4.5.6 Cause No. 101: Message not compatible with call state

This cause indicates that a message has been received which is incompatible with the call state. 4.5.7 Cause No. 102: Recovery on timer expiry

This cause indicates that a procedure has been initiated by the expiry of a timer in association with error handling procedures. 4.5.8 Cause No. 103: Parameter non-existent or not implemented - passed on (national use)

This cause indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not dened or are dened but not implemented by the equipment Schulzrinne/Kang Expires January 1999 [Page 23]

INTERNET-DRAFT

draft-schulzrinne-ss7-00.ps

September 27, 1998

sending the cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed on unchanged. 4.5.9 Cause No. 110: Message with unrecognized parameter discarded

This cause indicates that the equipment sending this cause has discarded a received message which includes a parameter that is not recognized. 4.5.10 Cause No. 111: Protocol error, unspecied

This cause is used to report a protocol error event only when no other cause in the protocol error class applies.

4.6 Interworking class

4.6.1 Cause No. 127: interworking, unspecied

This cause indicates that there has been interworking with a network which does not provide causes for actions it takes. Thus, the precise cause for a message which is being sent cannot be ascertained.

5 Open Issues
This draft does not address the use of TCAP across the Internet. It appears that non-call signaling can simply be carried across a TCP connection, with the necessary translation of addresses from the SS7 to the TCAP domain and vice versa. (Potentially, a new DNS resource record would be needed here.) [How are point codes assigned in this environment?]

Schulzrinne/Kang

Expires January 1999

[Page 24]