\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{i-d}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage[dvips]{changebar}

\newcommand{\INVITE}{{\sf INVITE}}
\newcommand{\BYE}{{\sf BYE}}
\newcommand{\ACK}{{\sf ACK}}
\newcommand{\CANCEL}{{\sf CANCEL}}
\newcommand{\OPTIONS}{{\sf OPTIONS}}
\newcommand{\REGISTER}{{\sf REGISTER}}
\newcommand{\header}[1]{{\sf #1}}
\newcommand{\MUST}{\textsc{must}}
\newcommand{\MUSTNOT}{\textsc{must not}}
\newcommand{\REQUIRED}{\textsc{required}}
\newcommand{\SHALL}{\textsc{shall}}
\newcommand{\SHALLNOT}{\textsc{shall not}}
\newcommand{\SHOULD}{\textsc{should}}
\newcommand{\SHOULDNOT}{\textsc{should not}}
\newcommand{\MAY}{\textsc{may}}
\newcommand{\OPTIONAL}{\textsc{optional}}
\newcommand{\RECOMMENDED}{\textsc{recommended}}
\newcommand{\NOTRECOMMENDED}{\textsc{not recommended}}

\title{Mapping between ISUP and SIP}
\author{Schulzrinne/Kang}
\shorttitle{SIP}
\filename{schulzrinne-ss7-00}
\wg{??? WG}
\address{Columbia U./Bell Atlantic}
\pubdate{\today}
\expires{January 1999}

\begin{document}
\maketitle
\begin{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.
\end{abstract}
\tableofcontents

\section{Introduction}

The Session Initiation Protocol (SIP) \cite{draft-ietf-mmusic-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) \cite{}.  SS7 is a complete protocol
stack comprising the link, network, transport and application layer. 
The lower layers are specific 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 {\em SIP-ISUP gateway}.  Note that this signaling translation is
not sufficient 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 defines a number of messages and parameters for ``national use''.
In the United States, these are defined by ANSI and Bellcore standards
\cite{}.

\txtpsfigsize{\textwidth}{!}{ss7_i}{Gateway between SS7 and Internet
domains} 

\txtpsfigsize{\textwidth}{!}{ss7_i_ss7}{Using the Internet to bridge
between SS7 domains} 

The requirement for interworking differ depending on whether SIP
terminates the call (Fig.~\ref{fig:ss7_i}, or whether SIP connects two
SS7 ``clouds'' (``SIP in the middle''), as depicted in
Fig.~\ref{fig:ss7_i_ss7}.  We refer to the former as {\em SIP
termination}, to the latter as {\em 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:
\begin{itemize}
\item An SS7-Internet gateway may not be aware of whether one of the
subsequent Internet signaling hops might be connected to the SS7
network.

\item 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 flavors of SS7. (Fig.~\ref{fig:ss7_i_ss7})

\end{itemize}

The figures 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
circuit-switched trunks.  This is shown in Fig.~\ref{fig:ss7}.  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.

\txtpsfigsize{\textwidth}{!}{ss7}{Using SIP to connect SCPs}

Fig.~\ref{fig:ss7_i} and Fig.~\ref{fig:ss7_i_ss7} 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,
\ldots, proprietary RPC mechanisms or extending the PINT and generic
event notification mechanisms to this problem \cite{}.

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).

\section{Messages}

The ISUP messages are summarized in Table~\ref{tab:messages}.

\begin{table}[htbp]
\begin{center}
\begin{tabular}{lll}
Address complete                         & ACM & 100\\
Answer                                   & ANM & 200\\
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                         &     & \\
Identification request                   &     & \\
Identification response                  &     & \\
Information                              &     & \\
Information request                      &     & \\
Initial address                          & IAM & \header{INVITE}\\
Loop back acknowledgement                &     & \\
Loop prevention                          &     & \\
Network resource management              &     & \\
Overload                                 &     & \\
Pass-along                               &     & \\
Release                                  & REL & \\
Release complete                         & RLC & \\
Reset circuit                            &     & \\
Resume                                   &     & \\
Segmentation                             &     & \\
Subsequent address                       &     & \\
Suspend                                  &     & \\
Unblocking                               &     & \\
Unblocking acknowledgement               &     & \\
Unequipped CIC                           &     & \\
User Part available                      &     & \\
User Part test                           &     & \\
User-to-user information                 &     & \\
\end{tabular}
\end{center}
\caption{ISUP message types}
\label{tab:messages}
\end{table}

\subsection{Calls from Internet to GSTN}

It is assumed that the SIP \header{Request-URI} contains a telephone
number or can be translated by the gateway into such a number.

\txtpsfigsize{\textwidth}{!}{isup}{Call from Internet to GSTN using SIP
and ISUP}

The basic message flow is shown in Fig.~\ref{fig:isup}.  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 confirms the call with an \header{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, confirmed by a RLC (Release Complete).

The value of fields other than those listed in Table~\ref{tab:sip_isup}
cannot be conveyed in ISUP messages.  This includes additional
information about the call and caller such as the \header{To} display
name, \header{Subject}, \header{Organization}, \header{Priority} and
\header{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 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 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, fixed
bandwidth between the two parties, while such resource allocation is
the realm of resource reservation protocols in the Internet.

\subsection{Calls from GSTN to Internet}

The message exchanges are similar to the above:

\begin{enumerate}
\item ISUP IAM generates SIP {\INVITE};
\item SIP 100 response generates ISUP ACM;
\item SIP 200 response generates ISUP ANM;
\item ISUP Connect generates SIP {\ACK};
\item ISUP REL generates SIP {\BYE};
\item 200 response to {\BYE} generates RLC.
\end{enumerate}

\section{ISDN User Part Parameters}

\subsection{Access transport}
\begin{description}

\item[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 significant to both
users and local exchanges.  It is an optional parameter in IAM, INF,
REL, COT, ANM, and ACM messages. 

\item[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.

\item[SIP:] The subaddresses are conveyed through the SIP URL. The use
of low and high layer compatibility and progress is for further study.

\item[Comments:] None of the optional IEs in SETUP message of Q.931 are
used for host-to-host calls in common H.323 implementations.

\end{description}

\subsection{Automatic congestion level}

\begin{description}
\item[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.

\item[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 \header{Warning} header in the {\BYE} request
indicating the reason for forced disconnection.

\end{description}

\subsection{Backward call indicators}

\begin{description}
\item[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-to-end 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. 

\item[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.

\item[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.

\end{description} 

\subsection{Call reference}
\begin{description}
\item[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 identifies a
particular ISUP call at an exchange, and consists of a call identity,
and the point code of that exchange.

\item[Q.931:] Call reference IE.

\item[SIP:] Carried in the \header{Call-ID} header, with the point code
as a \header{host}.

\end{description}

\subsection{Called party number}

\begin{description}
\item[Functionality:] Information to identify the called party.  This is
a mandatory variable-length parameter in IAM.

\item[Q.931:] Called party number IE.
\item[SIP:] \header{To} header.
\end{description}

\subsection{Calling party category}

\begin{description}
\item[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 fixed-length parameter in IAM
and an optional parameter in INF.

\item[Q.931:] Not available.

\item[SIP:] The \header{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
\header{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
\header{Priority} header field. It may be useful to designate a standard
\header{user} value for the \header{From} URL that indicates that the
user name does not reflect that of the person calling, as would be the
case for a payphone. For example, {\tt anonymous@boston.payphones.com}.

\end{description}

\subsection{Calling party number}

\begin{description}
\item[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 verified'', ``user verified, provided
and passed'', ``user provided, verified 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.

\item[Q.931:] It supports SI and RI in Calling Party Number IE.

\item[SIP:] The \header{From} header contains this information.  For SIP
termination, the RI would lead to the insertion of a dummy value in the
\header{From} header for calls from the GSTN to the Internet.  For calls
from the Internet to the GSTN, the caller would use a randomized
\header{From} value, but use proxy authentication to authenticate itself
to the gateway.  There may be a need for defining an anonymous,
randomized \header{From} header value, e.g., by using a special domain
name.

\end{description}

\subsection{Cause indicator}
\begin{description}
\item[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.

\item[Q.931:] Cause IE (Q.850).
\item[SIP:] See Table~\ref{tab:cause}.
\end{description}

\subsection{Event information}
\begin{description}
\item[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. 

\item[Q.931] Alerting and Progress message.

\item[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.

\end{description}

\subsection{Facility Indicator}
\label{sec:facility}

\begin{description}
\item[Functionality:] Currently, indicates user-to-user service.
\item[Q.931:] ?
\item[SIP:] ?
\end{description}

\subsection{Forward call indicator}
\label{sec:Forward}

\begin{description}
\item[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. 

\item[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. 

\item[SIP:] The information contained here could be mapped into
\header{Warning} headers.

\end{description}

\subsection{Information Indicators}
\label{sec:InformationIndicators}

\begin{description}
\item[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.

\item[Q.931:] ?

\item[SIP:] The functionality is indicated by the presence of SIP header
fields and their content.
\end{description}

\subsection{Information Request Indicators}
\label{sec:InformationRequest}

\begin{description}
\item[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.

\item[SIP:] The functionality like call holding or malicious call
information is provided differently in SIP. If necessary, these bits can
be mapped to \header{Call-Disposition} values.

\end{description}

\subsection{Nature of Connection Indicators}

\begin{description}
\item[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.

\item[SIP:] The indications can be signaled by \header{Warning} headers,
while a request for continuity checks can be expressed in the
\header{Call-Disposition} or possibly \header{Proxy-Require} header.
\end{description}

\subsection{Optional backward call indicator}
\label{sec:OptionalBackward}

\begin{description}
\item[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.

\item[SIP:] See discussion of in-band information.
\end{description}

\subsection{Optional forward call indicators}

\begin{description}
\item[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.

\item[SIP:] \header{Proxy-Require}?
\end{description}

\subsection{Original called number}

\begin{description}
\item[Functionality:] Information sent in the forward direction when a
call is redirected and identifies 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.

\item[SIP:] This corresponds to the \header{To} header field, with the
exception of the address presentation restriction indicator. The latter
could be indicated using a \header{Proxy-Require} option.
\end{description}

\subsection{Redirecting number}

\begin{description}
\item[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.

\item[SIP:] The original destination of a call is contained in the
\header{From} header field, while the path of the request can be deduced
from the \header{Via} header field.
\end{description}

\subsection{Redirection Information}

\begin{description}
\item[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.

\item[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 \header{Warning} header
field or by adding additional 3xx status codes.  Since the 3xx status
codes already express the permanency and interpretation of the
\header{Location} headers, \header{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 difficult to
encode the information about the outcome of parallel searches.

The number of proxy hops can be deduced by the callee by inspecting the
\header{Via} headers.

\end{description}

\subsection{Redirection Number}
\begin{description}
\item[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.

\item[SIP:] 301

\item[Comments:]
If the called party changed number, it would be nice for SIP user to get that 
information on screen.

\end{description}

\subsection{Suspend/resume Indicator}
\begin{description}
\item[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.

\item[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. 

\item[SIP]
\item[Comments]
\end{description}

\subsection{Transmission medium requirements}
\begin{description}
\item[Functionality:] Information sent in the forward direction
indicating the type of transmission medium required for the connection. 
This is a mandatory parameter in IAM.

\item[Q.931:] In NetMeeting this was always specified as 'packet mode'
in bearer capability IE.

\item[SIP:] Can be encapsulated in SDP.
\end{description}

\subsection{User service information}
\begin{description}
\item[Functionality:] Information sent in the forward direction
indicating the bearer capability requested by the calling party.  This
is an optional paramter in IAM message.

\item[Q.931:] Bearer capability IE.  In NetMeeting this was always
specified as 'unrestricted digital information' and User Layer1
protocol:  'Rec.  H.221 and H.242'

\item[SIP:] \header{Call-Disposition}?
\end{description}

\subsection{User-to-user information}
\begin{description}
\item[Functionality:] User-to-user information is generated by a user
and transferred transparently through the interexchange network between
the originating and terminating local exchanges.

\item[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.

\item[SIP:] This is roughly equivalent to the message body of a SIP
message.
\end{description}

\section{Cause Values}

SIP expresses error conditions mainly through status codes in responses,
with additional optional information provided by zero or more
\header{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~\ref{tab:cause}. 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 \header{Warning} headers.

\begin{table}[htbp]
\begin{center}
\begin{tabular}{rlll}
cause & definition & ISDN/ISUP? & SIP status\\
\hline
  1 & Unallocated (unassigned) number                             & xx & 404\\
  2 & No route to specified transit network                       & xx & ICMP\\
  3 & No route to destination                                     & xx & 404?\\
  4 & Send special information tone                               & -x & 500\\
  5 & Misdialled trunk prefix                                     & -x & ?\\
  6 & Channel unacceptable                                        & x- & ?\\ 
  7 & Call awarded and being delivered in an established channel  & x- & 200\\
  8 & Preemption                                                  & xx & W\\ 
  9 & Preemption - circuit reserved for reuse                     & -x & W\\
 16 & Normal call clearing                                        & xx & --\\
 17 & User busy                                                   & xx & 600\\
 18 & No user responding                                          & xx & 408\\
 19 & No answer from user (user alerted)                          & xx & 408\\
 20 & Subscriber absent                                           & xx & 480\\
 21 & Call rejected                                               & xx & 603\\
 22 & Number changed                                              & xx & 301\\
 26 & Non-selected user clearing                                  & x- & \\
 27 & Destination out of order                                    & xx & 500\\
 28 & Invalid number format (address incomplete)                  & xx & 484\\
 29 & Facility rejected                                           & xx & 501\\
 30 & Response to STATUS ENQUIRY                                  & x- & \\
 31 & Normal, unspecified                                         & xx & 200\\
\hline
 34 & No circuit/channel available                                & xx & W301\\
 38 & Network out of order                                        & xx & 503\\
 39 & Permanent frame mode connection out-of-service              & x- & 503\\
 40 & Permanent frame mode connection operational                 & x- & ?\\
 41 & Temporary failure                                           & xx & 503\\
 42 & Switching equipment congestion                              & xx & 503\\
 43 & Access information discarded                                & xx & 400\\
 44 & Requested circuit/channel not available                     & xx & W301\\
 46 & Precedence call blocked                                     & xx & W?\\
 47 & Resource unavailable, unspecified                           & xx & W399\\
 49 & Quality of Service not available                            & x- & W?\\
\hline
 50 & Requested facility not subscribed                           & xx & 407\\
 53 & Outgoing calls barred within CUG                            & xx & 403\\
 55 & Incoming calls barred within CUG                            & xx & 403\\
 57 & Bearer capability not authorized                            & xx & 403\\
 58 & Bearer capability not presently available                   & xx & 503\\
 62 & Inconsistency in designated outgoing access                 & xx & ?\\
 63 & Service or option not available, unspecified                & xx & 500\\
\hline
 65 & Bearer capability not implemented                           & xx & 501, W\\
 66 & Channel type not implemented                                & x- & 501, W305\\
 69 & Requested facility not implemented                          & xx & 501, W\\
 70 & Only restricted digital information bearer                  & xx & 501, W\\
 79 & Service or option not implemented, unspecified              & xx & 501\\
\hline
 81 & Invalid call reference value                                & x- & 481\\
 82 & Identified channel does not exist                           & x- & ?\\
 83 & A suspended call exists, but this call identity does not    & x- & 481\\
 84 & Call identity in use                                        & x- & 481\\
 85 & No call suspended                                           & x- & 481\\
 86 & Call having the requested call identity has been cleared    & x- & 481\\
 87 & User not member of CUG                                      & xx & ?\\
 88 & Incompatible destination                                    & xx & ?, W\\
 90 & Non-existent CUG                                            & xx & ?, W\\
 91 & Invalid transit network selection                           & xx & \\
 95 & Invalid message, unspecified                                & xx & 400\\
 96 & Mandatory information element is missing                    & x- & 400, W\\
\hline
 97 & Message type non-existent or not implemented                & xx & 501\\
 98 & Message not compatible with call state \ldots               & x- & 405\\
 99 & Information element/parameter non-existent                  & xx & W\\
100 & Invalid information element contents                        & x- & W\\
101 & Message not compatible with call state                      & x- & 400\\
102 & Recovery on timer expiry                                    & xx & 408\\
103 & Parameter non-existent or not implemented, passed on        & -x & W\\
110 & Message with unrecognized parameter discarded               & -x & W\\
111 & Protocol error, unspecified                                 & xx & 400\\
\hline
127 & interworking, unspecified                                   & xx & 400\\
\end{tabular}
\end{center}
\caption{Cause values and their mapping to SIP status codes and warnings}
\label{tab:cause}
\end{table}

\subsubsection{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).''

\subsubsection{Cause No. 2: No route to specified 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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{Cause No. 5: Misdialled trunk prefix (national use)}

This cause indicates the erroneous inclusion of a trunk prefix in the
called party number. 

\subsubsection{Cause No. 6: Channel unacceptable}

This cause indicates that the channel most recently identified is not
acceptable to the sending entity for use in this call. 

\subsubsection{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).  

\subsubsection{Cause No.  8: Preemption} 

This cause indicates that the call is being preempted. 

\subsubsection{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.

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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 field
may contain additional information about the supplementary service and
reason for rejection. 

\subsubsection{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 field.  If a
network does not support this cause value, cause No.  1, unallocated
(unassigned) number shall be used. 

\subsubsection{Cause No. 26: Non-selected user clearing}

This cause indicates that the user has not been awarded the incoming
call. (DSS-1 only)

\subsubsection{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.

\subsubsection{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. 

\subsubsection{Cause No. 29: Facility rejected}

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

\subsubsection{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. 

\subsubsection{Cause No. 31: Normal, unspecified}

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

\subsection{Resource unavailable class}

\subsubsection{Cause No. 34: No circuit/channel available}

This cause indicates that there is no appropriate circuit/channel
presently available to handle the call. 

\subsubsection{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. 

\subsubsection{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). 

\subsubsection{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). 

\subsubsection{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. 

\subsubsection{Cause No.  42:  Switching equipment congestion}

This cause indicates that the switching equipment
generating this cause is experiencing a period of high traffic. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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.

\subsubsection{Cause No. 47: Resource unavailable, unspecified}

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

\subsection{Service or option unavailable class}

\subsubsection{Cause No. 49   Quality of Service not available}

This cause is used to report that the requested Quality of Service, as
defined in Recommendation X.213, cannot be provided (e.g., throughput or
transit delay cannot be supported). 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{Cause No. 63:  Service or option not available, unspecified}

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. 

\subsection{Service or option not implemented class}

\subsubsection{Cause No. 65: Bearer capability not
implemented}

This cause indicates that the equipment sending this cause
does not support the bearer capability requested. 

\subsubsection{Cause No. 66: Channel type not implemented}

This cause indicates that the equipment sending
this cause does not support the channel type requested. 

\subsubsection{Cause No. 69: Requested facility not implemented}

This cause indicates that the equipment sending this cause does not
support the requested supplementary service. 

\subsubsection{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. 

\subsubsection{Cause No. 79: Service or option not implemented, unspecified}

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.

\subsection{Invalid message (e.g. parameter out of range) class}

\subsubsection{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. 

\subsubsection{Cause No. 82: Identified 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. 

\subsubsection{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). 

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{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). 

\subsubsection{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 specified CUG or that the calling user is an
ordinary subscriber calling a CUG subscriber. 

\subsubsection{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. 

\subsubsection{Cause No. 90: Non-existent CUG}

This cause
indicates that the specified CUG does not exist. 

\subsubsection{Cause No.  91:  Invalid transit network selection (national
use)}

This cause indicates that a
transit network identification was received which is of an incorrect
format as defined in Annex C/Q.931. 

\subsubsection{Cause No. 95: Invalid message, unspecified}

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

\subsection{Protocol error (e.g. unknown message) class}

\subsubsection{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.

\subsubsection{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 defined or defined but not implemented by the equipment
sending this cause. 

\subsubsection{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. 

\subsubsection{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 identifier(s)/parameter
name(s) are not defined or are defined 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. 

\subsubsection{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 fields in the information element are coded in such a way which
has not been implemented by the equipment sending this cause. 

\subsubsection{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.

\subsubsection{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. 

\subsubsection{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 defined or are defined but not implemented by the
equipment 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. 

\subsubsection{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. 

\subsubsection{Cause No. 111: Protocol error, unspecified}

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

\subsection{Interworking class}

\subsubsection{Cause No. 127: interworking, unspecified}

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.

\section{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?]

\end{document}
