tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3398

Proposed STD
Pages: 68
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIPPING

Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping

Part 1 of 3, p. 1 to 30
None       Next RFC Part


Top       ToC       Page 1 
Network Working Group                                       G. Camarillo
Request for Comments: 3398                                      Ericsson
Category: Standards Track                                    A. B. Roach
                                                             J. Peterson
                                                                  L. Ong
                                                           December 2002

      Integrated Services Digital Network (ISDN) User Part (ISUP)
              to Session Initiation Protocol (SIP) Mapping

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document describes a way to perform the mapping between two
   signaling protocols: the Session Initiation Protocol (SIP) and the
   Integrated Services Digital Network (ISDN) User Part (ISUP) of
   Signaling System No. 7 (SS7).  This mechanism might be implemented
   when using SIP in an environment where part of the call involves
   interworking with the Public Switched Telephone Network (PSTN).

Table of Contents

   1.      Introduction............................................  3
   2.      Scope...................................................  4
   3.      Terminology.............................................  5
   4.      Scenarios...............................................  5
   5.      SIP Mechanisms Required.................................  7
   5.1     'Transparent' Transit of ISUP Messages..................  7
   5.2     Understanding MIME Multipart Bodies.....................  7
   5.3     Transmission of DTMF Information........................  8
   5.4     Reliable Transmission of Provisional Responses..........  8
   5.5     Early Media.............................................  8
   5.6     Mid-Call Transactions which do not change SIP state.....  9

Top      ToC       Page 2 
   5.7     Privacy Protection......................................  9
   5.8     CANCEL causes........................................... 10
   6.      Mapping................................................. 10
   7.      SIP to ISUP Mapping..................................... 11
   7.1     SIP to ISUP Call flows.................................. 11
   7.1.1   En-bloc Call Setup (no auto-answer)..................... 11
   7.1.2   Auto-answer call setup.................................. 12
   7.1.3   ISUP T7 Expires......................................... 13
   7.1.4   SIP Timeout............................................. 14
   7.1.5   ISUP Setup Failure...................................... 15
   7.1.6   Cause Present in ACM Message............................ 16
   7.1.7   Call Canceled by SIP.................................... 17
   7.2     State Machine........................................... 18
   7.2.1   INVITE received......................................... 19 INVITE to IAM procedures................................ 19
   7.2.2   ISUP T7 expires......................................... 23
   7.2.3   CANCEL or BYE received.................................. 23
   7.2.4   REL received............................................ 24 ISDN Cause Code to Status Code Mapping.................. 24
   7.2.5   Early ACM received...................................... 27
   7.2.6   ACM received............................................ 27
   7.2.7   CON or ANM Received..................................... 28
   7.2.8   Timer T9 Expires........................................ 29
   7.2.9   CPG Received............................................ 29
   7.3     ACK received............................................ 30
   8.      ISUP to SIP Mapping..................................... 30
   8.1     ISUP to SIP Call Flows.................................. 30
   8.1.1   En-bloc call setup (non auto-answer).................... 31
   8.1.2   Auto-answer call setup.................................. 32
   8.1.3   SIP Timeout............................................. 33
   8.1.4   ISUP T9 Expires......................................... 34
   8.1.5   SIP Error Response...................................... 35
   8.1.6   SIP Redirection......................................... 36
   8.1.7   Call Canceled by ISUP................................... 37
   8.2     State Machine........................................... 39
   8.2.1   Initial Address Message received........................ 39 IAM to INVITE procedures................................ 40
   8.2.2   100 received............................................ 41
   8.2.3   18x received............................................ 41
   8.2.4   2xx received............................................ 43
   8.2.5   3xx Received............................................ 44
   8.2.6   4xx-6xx Received........................................ 44 SIP Status Code to ISDN Cause Code Mapping.............. 45
   8.2.7   REL Received............................................ 47
   8.2.8   ISUP T11 Expires........................................ 47
   9.      Suspend/Resume and Hold................................. 48
   9.1     Suspend (SUS) and Resume (RES) Messages................. 48
   9.2     Hold (re-INVITE)........................................ 50

Top      ToC       Page 3 
   10.     Normal Release of the Connection........................ 50
   10.1    SIP initiated release................................... 50
   10.2    ISUP initiated release.................................. 51
   10.2.1  Caller hangs up......................................... 51
   10.2.2  Callee hangs up (SUS)................................... 52
   11.     ISUP Maintenance Messages............................... 52
   11.1    Reset messages.......................................... 52
   11.2    Blocking messages....................................... 53
   11.3    Continuity Checks....................................... 53
   12.     Construction of Telephony URIs.......................... 54
   12.1    ISUP format to tel URL mapping.......................... 56
   12.2    tel URL to ISUP format mapping.......................... 57
   13.     Other ISUP flavors...................................... 58
   13.1    Guidelines for sending other ISUP messages.............. 58
   14.     Acronyms................................................ 60
   15.     Security Considerations................................. 60
   16.     IANA Considerations..................................... 64
   17.     Acknowledgments......................................... 64
   18.     Normative References.................................... 64
   19.     Non-Normative References................................ 65
           Authors' Addresses...................................... 67
           Full Copyright Statement................................ 68

1. Introduction

   SIP [1] is an application layer protocol for establishing,
   terminating and modifying multimedia sessions.  It is typically
   carried over IP.  Telephone calls are considered a type of multimedia
   sessions where just audio is exchanged.

   Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a
   level 4 protocol used in Signaling System No. 7 (SS7) networks.  It
   typically runs over Message Transfer Part (MTP) although it can also
   run over IP (see SCTP [19]).  ISUP is used for controlling telephone
   calls and for maintenance of the network (blocking circuits,
   resetting circuits etc.).

   A module performing the mapping between these two protocols is
   usually referred to as Media Gateway Controller (MGC), although the
   terms 'softswitch' or 'call agent' are also sometimes used.  An MGC
   has logical interfaces facing both networks, the network carrying
   ISUP and the network carrying SIP.  The MGC also has some
   capabilities for controlling the voice path; there is typically a
   Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public
   Switched Telephone Network - PSTN) and with IP interfaces (Voice over
   IP - VoIP).  The MGC and the MG can be merged together in one
   physical box or kept separate.

Top      ToC       Page 4 
   These MGCs are frequently used to bridge SIP and ISUP networks so
   that calls originating in the PSTN can reach IP telephone endpoints
   and vice versa.  This is useful for cases in which PSTN calls need to
   take advantage of services in IP world, in which IP networks are used
   as transit networks for PSTN-PSTN calls, architectures in which calls
   originate on desktop 'softphones' but terminate at PSTN terminals,
   and many other similar next-generation telephone architectures.

   This document describes logic and procedures which an MGC might use
   to implement the mapping between SIP and ISUP by illustrating the
   correspondences, at the message level and parameter level, between
   the protocols.  It also describes the interplay between parallel
   state machines for these two protocols as a recommendation for
   implementers to synchronize protocol events in interworking

2. Scope

   This document focuses on the translation of ISUP messages into SIP
   messages, and the mapping of ISUP parameters into SIP headers.  For
   ISUP calls that traverse a SIP network, the purpose of translation is
   to allow SIP elements such as proxy servers (which do not typically
   understand ISUP) to make routing decisions based on ISUP criteria
   such as the called party number.  This document consequently provides
   a SIP mapping only for those ISUP parameters which might be used by
   intermediaries in the routing of SIP requests.  As a side effect of
   this approach, translation also increases the overall
   interoperability by providing critical information about the call to
   SIP endpoints that cannot understand encapsulated ISUP, or perhaps
   which merely cannot understand the particular ISUP variant
   encapsulated in a message.

   This document also only takes into account the call functionality of
   ISUP.  Maintenance messages dealing with PSTN trunks are treated only
   as far as they affect the control of an ongoing call; otherwise these
   messages neither have nor require any analog in SIP.

   Messages indicating error or congestion situations in the PSTN (MTP-
   3) and the recovery mechanisms used such as User Part Available and
   User Part Test ISUP messages are outside the scope of this document

   There are several flavors of ISUP.  International Telecommunication
   Union Telecommunication Standardization Sector (ITU-T) International
   ISUP [12] is used through this document; some differences with the
   American National Standards Institute (ANSI) [11] ISUP and the
   Telecommunication Technology Committee (TTC) ISUP are also outlined.
   ITU-T ISUP is used in this document because it is the most widely
   known of all the ISUP flavors.  Due to the small number of fields

Top      ToC       Page 5 
   that map directly from ISUP to SIP, the signaling differences between
   ITU-T ISUP and specific national variants of ISUP will generally have
   little to no impact on the mapping.  Note, however, that the ITU-T
   has not substantially standardized practices for Local Number
   Portability (LNP) since portability tends to be grounded in national
   numbering plan practices, and that consequently LNP must be described
   on a virtually per-nation basis.  The number portability practices
   described in this document are presented as an optional mechanism.

   Mapping of SIP headers to ISUP parameters in this document focuses
   largely on the mapping between the parameters found in the ISUP
   Initial Address Message (IAM) and the headers associated with the SIP
   INVITE message; both of these messages are used in their respective
   protocols to request the establishment of a call.  Once an INVITE has
   been sent for a particular session, such headers as the To and From
   field become essentially fixed, and no further translation will be
   required during subsequent signaling, which is routed in accordance
   with Via and Route headers.  Hence, the problem of parameter-to-
   header mapping in SIP-T is confined more or less to the IAM and the
   INVITE.  Some additional detail is given in the population of
   parameters in the ISUP messages Address Complete Message (ACM) and
   Release Message (REL) based on SIP status codes.

   This document describes when the media path associated with a SIP
   call is to be initialized, terminated, modified, etc., but it does
   not go into details such as how the initialization is performed or
   which protocols are used for that purpose.

3. Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in RFC2119 [2] and indicate requirement levels for
   compliant SIP implementations.

4. Scenarios

   There are several scenarios where ISUP-SIP mapping takes place.  The
   way the messages are generated is different depending on the

Top      ToC       Page 6 
   When there is a single MGC and the call is from a SIP phone to a PSTN
   phone, or vice versa, the MGC generates the ISUP messages based on
   the methods described in this document.

   +-------------+       +-----+       +-------------+
   | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
   +-------------+       +-----+       +-------------+

   The scenario where a call originates in the PSTN, goes into a SIP
   network and terminates in the PSTN again is known as "SIP bridging".
   SIP bridging should provide ISUP transparency between the PSTN
   switches handling the call.  This is achieved by encapsulating the
   incoming ISUP messages in the body of the SIP messages (see [3]).  In
   this case, the ISUP messages generated by the egress MGC are the ones
   present in the SIP body (possibly with some modifications; for
   example, if the called number in the request Uniform Resource
   Identifier - URI - is different from the one present in the ISUP due
   to SIP redirection, the ISUP message will need to be adjusted).

   +------+   +-------------+   +-----+   +------------+   +------+
   | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
   +------+   +-------------+   +-----+   +------------+   +------+

   SIP is used in the middle of both MGCs because the voice path has to
   be established through the IP network between both MGs; this
   structure also allows the call to take advantage of certain SIP
   services.  ISUP messages in the SIP bodies provide further
   information (such as cause values and optional parameters) to the
   peer MGC.

   In both scenarios, the ingress MGC places the incoming ISUP messages
   in the SIP body by default.  Note that this has security
   implications; see Section 15.  If the recipient of these messages
   (typically a SIP User Agent Client/User Agent Server - UAC/UAS) does
   not understand them, a negotiation using the SIP 'Accept' and
   'Require' headers will take place and they will not be included in
   the next SIP message exchange.

   There can be a Signaling Gateway (SG) between the PSTN and the MGC.
   It encapsulates the ISUP messages over IP in a manner such as the one
   described in [19].  The mapping described in this document is not
   affected by the underlying transport protocol of ISUP.

   Note that overlap dialing mechanisms (use of the Subsequent Address
   Message - SAM) are outside the scope of this document.  This document
   assumes that gateways facing ISUP networks in which overlap dialing
   is used will implement timers to insure that all digits have been
   collected before an INVITE is transmitted to a SIP network.

Top      ToC       Page 7 
   In some instances, gateways may receive incomplete ISUP messages
   which indicate message segmentation due to excessive message length.
   Commonly these messages will be followed by a Segmentation Message
   (SGM) containing the remainder of the original ISUP message.  An
   incomplete message may not contain sufficient parameters to allow for
   a proper mapping to SIP; similarly, encapsulating (see below) an
   incomplete ISUP message may be confusing to terminating gateways.
   Consequently, a gateway MUST wait until a complete ISUP message is
   received (which may involve waiting until one or more SGMs arrive)
   before sending any corresponding INVITE.

5. SIP Mechanisms Required

   For a correct mapping between ISUP and SIP, some SIP mechanisms above
   and beyond those available in the base SIP specification are needed.
   These mechanisms are discussed below.  If the SIP UAC/UAS involved in
   the call does not support them, it is still possible to proceed, but
   the behavior in the establishment of the call may be slightly
   different than that expected by the user (e.g., other party answers
   before receiving the ringback tone, user is not informed about the
   call being forwarded, etc.).

5.1 'Transparent' Transit of ISUP Messages

   To allow gateways to take advantage of the full range of services
   afforded by the existing telephone network when placing calls from
   PSTN to PSTN across a SIP network, SIP messages MUST be capable of
   transporting ISUP payloads from gateway to gateway.  The format for
   encapsulating these ISUP messages is defined in [3].

   SIP user agents which do not understand ISUP are permitted to ignore
   these optional MIME bodies.

5.2 Understanding MIME Multipart Bodies

   In most PSTN interworking situations, SIP message bodies will be
   required to carry session information (Session Description Protocol -
   SDP) in addition to ISUP and/or billing information.

   PSTN interworking nodes MUST understand the MIME type of
   "multipart/mixed" as defined in RFC2046 [4].  Clients express support
   for this by including "multipart/mixed" in an "Accept" header.

Top      ToC       Page 8 
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information

   How DTMF tones played by the user are transmitted by a gateway is
   completely orthogonal to how SIP and ISUP are interworked; however,
   as DTMF carriage is a component of a complete gatewaying solution
   some guidance is offered here.

   Since the codec selected for voice transmission may not be ideally
   suited for carrying DTMF information, a symbolic method of
   transmitting this information in-band is desirable (since out-of-band
   transmission alone would provide many challenges for synchronization
   of the media stream for tone re-insertion).  This transmission MAY be
   performed as described in RFC2833 [5].

5.4 Reliable Transmission of Provisional Responses

   Provisional responses (in the 1xx class) are used in the transmission
   of call progress information.  PSTN interworking in particular relies
   on these messages for control of the media channel and timing of call

   When interworking with the PSTN, SIP messages MUST be sent reliably
   end-to-end; reliability of requests is guaranteed by the base
   protocol.  One application-layer provisional reliability mechanism
   for responses is described in [18].

5.5 Early Media

   Early media denotes the capability to play media (audio for
   telephony) before a SIP session has been established (before a 2xx
   response code has been sent).  For telephony, establishment of media
   in the backwards direction is desirable so that tones and
   announcements can be played, especially when interworking with a
   network that cannot signal call status out of band (such as a legacy
   MF network).  In cases where interworking has not been encountered,
   use of early media is almost always undesirable since it consumes
   inter-machine trunk recourses to play media for which no revenue is
   collected.  Note that since an INVITE almost always contains the SDP
   required to send media in the backwards direction, and requires that
   user agents prepare themselves to receive backwards media as soon as
   an INVITE transmitted, the baseline SIP protocol has enough support
   to enable rudimentary unidirectional early media systems.  However,
   this mechanism has a number of limitations - for example, media
   streams offered in the SDP of the INVITE cannot be modified or
   declined, and bidirectional RTCP required for session maintenance
   cannot be established.

Top      ToC       Page 9 
   Therefore gateways MAY support more sophisticated early media systems
   as they come to be better understood.  One mechanism that provides a
   way of initiating a fully-featured early media system is described in

   Note that in SIP networks not just switches but also user agents can
   generate the 18x response codes and initiate early backwards media,
   and that therefore some gateways may wish to enforce policies that
   restrict the use of backwards media from arbitrary user agents (see
   Section 15).

5.6 Mid-Call Transactions which do not change SIP state

   When interworking with the PSTN, there are situations when gateways
   will need to send messages to each other over SIP that do not
   correspond to any SIP operations.

   In support of mid-call transactions and other ISUP events that do not
   correspond to existing SIP methods, SIP gateways MUST support the
   INFO method, defined in RFC2976 [6].  Note that this document does
   not prescribe or endorse the use of INFO to carry DTMF digits.

   Gateways MUST accept "405 Method Not Allowed" and "501 Not
   Implemented" as non-fatal responses to INFO requests - that is, any
   call in progress MUST NOT be torn down if a destination so rejects an
   INFO request sent by a gateway.

5.7 Privacy Protection

   ISUP has a concept of presentation restriction - a mechanism by which
   a user can specify that they would not like their telephone number to
   be displayed to the person they are calling (presumably someone with
   Caller ID).  When a gateway receives an ISUP request that requires
   presentation restriction, it must therefore shield the identity of
   the caller in some fashion.

   The base SIP protocol supports a method of specifying that a user is
   anonymous.  However, this system has a number of limitations - for
   example, it reveals the identity of the gateway itself, which could
   be a privacy-impacting disclosure.  Therefore gateways MAY support
   more sophisticated privacy systems.  One mechanism that provides a
   way of supporting fully-featured privacy negotiation (which interacts
   well with identity management systems) is described in [9B].

Top      ToC       Page 10 
5.8 CANCEL causes

   There is a way in ISUP to signal that you would like to discontinue
   an attempt to set up a call - the general-purpose REL is sent in the
   forwards direction.  There is a similar concept in SIP - that of a
   CANCEL request that is sent in order to discontinue the establishment
   of a SIP dialog.  For various reasons, however, CANCEL requests
   cannot contain message bodies, and therefore in order to carry the
   important information in the REL (the cause code) end-to-end in sip
   bridging cases, ISUP encapsulation cannot be used.

   Ordinarily, this is not a big problem, because for practical purposes
   the only reason that a REL is ever issued to cancel a call setup
   attempt is that a user hangs up the phone while it is still ringing
   (which results in a "Normal clearing" cause code).  However, under
   exceptional conditions, like catastrophic network failure, a REL may
   be sent with a different cause code, and it would be handy if a SIP
   network could carry the cause code end-to-end.  Therefore gateways
   MAY support a mechanism for end-to-end delivery of such failure
   reasons.  One mechanism that provides this capability is described in

6. Mapping

   The mapping between ISUP and SIP is described using call flow
   diagrams and state machines.  One state machine handles calls from
   SIP to ISUP and the second from ISUP to SIP.  There are details, such
   as some retransmissions and some states (waiting for the Release
   Complete Message - RLC, waiting for SIP ACK etc.), that are not shown
   in the figures in order to make them easier to follow.

   The boxes represent the different states of the gateway, and the
   arrows show changes in the state.  The event that triggers the change
   in the state and the actions to take appear on the arrow: event /
   section describing the actions to take.

   For example, 'INVITE / 7.2.1' indicates that an INVITE request has
   been received by the gateway, and the procedure upon reception is
   described in the section 7.2.1 of this document.

   It is RECOMMENDED that gateways implement functional equivalence with
   the call flows detailed in Section 7.1 and Section 8.1.  Deviations
   from these flows are permissible in support of national ISUP
   variants, or any of the conservative policies recommended in Section

Top      ToC       Page 11 
7. SIP to ISUP Mapping

7.1 SIP to ISUP Call flows

   The following call flows illustrate the order of messages in typical
   success and error cases when setting up a call initiated from the SIP
   network.  "100 Trying" acknowledgements to INVITE requests are not
   displayed below although they are required in many architectures.

   In these diagrams, all call signaling (SIP, ISUP) is going to and
   from the MGC; media handling (e.g., audio cut-through, trunk freeing)
   is being performed by the MG, under the control of the MGC.  For the
   purpose of simplicity, these are shown as a single node, labeled

7.1.1 En-bloc Call Setup (no auto-answer)

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |<-----------ACM-----------|3
        4|<----------18x------------|                          |
         |<=========Audio===========|                          |
         |                          |<-----------CPG-----------|5
        6|<----------18x------------|                          |
         |                          |<-----------ANM-----------|7
         |                          |<=========Audio==========>|
        8|<----------200------------|                          |
         |<=========Audio==========>|                          |
        9|-----------ACK----------->|                          |

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.

   3.  The remote ISUP node indicates that the address is sufficient to
       set up a call by sending back an ACM message.

   4.  The "called party status" code in the ACM message is mapped to a
       SIP provisional response (as described in Section 7.2.5 and
       Section 7.2.6) and returned to the SIP node.  This response may
       contain SDP to establish an early media stream (as shown in the
       diagram).  If no SDP is present, the audio will be established in
       both directions after step 8.

Top      ToC       Page 12 
   5.  If the ISUP variant permits, the remote ISUP node may issue a
       variety of Call Progress (CPG) messages to indicate, for example,
       that the call is being forwarded.

   6.  Upon receipt of a CPG message, the gateway will map the event
       code to a SIP provisional response (see Section 7.2.9) and send
       it to the SIP node.

   7.  Once the PSTN user answers, an Answer (ANM) message will be sent
       to the gateway.

   8.  Upon receipt of the ANM, the gateway will send a 200 message to
       the SIP node.

   9.  The SIP node, upon receiving an INVITE final response (200), will
       send an ACK to acknowledge receipt.

7.1.2 Auto-answer call setup

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |<-----------CON-----------|3
         |                          |<=========Audio==========>|
        4|<----------200------------|                          |
         |<=========Audio==========>|                          |
        5|-----------ACK----------->|                          |

   Note that this flow is not supported in ANSI networks.

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.

   3.  Since the remote node is configured for automatic answering, it
       will send a Connect Message (CON) upon receipt of the IAM.  (For
       ANSI, this message will be an ANM).

   4.  Upon receipt of the CON, the gateway will send a 200 message to
       the SIP node.

   5.  The SIP node, upon receiving an INVITE final response (200), will
       send an ACK to acknowledge receipt.

Top      ToC       Page 13 
7.1.3 ISUP T7 Expires

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |    *** T7 Expires ***    |
         |             ** MG Releases PSTN Trunk **            |
        5|-----------ACK----------->|                          |

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.  The ISUP timer T7 is
       started at this point.

   3.  The ISUP timer T7 expires before receipt of an ACM or CON
       message, so a REL message is sent to cancel the call.

   4.  A gateway timeout message is sent back to the SIP node.

   5.  The SIP node, upon receiving an INVITE final response (504), will
       send an ACK to acknowledge receipt.

Top      ToC       Page 14 
7.1.4 SIP Timeout

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |<-----------CON-----------|3
         |                          |<=========Audio==========>|
        4|<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
         |<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
         |<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
         |<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
         |<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
         |<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
        5|<----------200------------|                          |
         |    *** T1 Expires ***    |                          |
         |             ** MG Releases PSTN Trunk **            |
         |                          |<-----------RLC-----------|8

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.

   3.  Since the remote node is configured for automatic answering, it
       will send a CON message upon receipt of the IAM.  In ANSI flows,
       rather than a CON, an ANM (without ACM) would be sent.

   4.  Upon receipt of the ANM, the gateway will send a 200 message to
       the SIP node and set SIP timer T1.

   5.  The response is retransmitted every time the SIP timer T1

   6.  After seven retransmissions, the call is torn down by sending a
       REL to the ISUP node, with a cause code of 102 (recover on timer

Top      ToC       Page 15 
   7.  A BYE is transmitted to the SIP node in an attempt to close the
       call.  Further handling for this clean up is not shown, since the
       SIP node's state is not easily known in this scenario.

   8.  Upon receipt of the REL message, the remote ISUP node will reply
       with an RLC message.

7.1.5 ISUP Setup Failure

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<-----------REL-----------|3
         |                          |------------RLC---------->|4
        5|<----------4xx+-----------|                          |
        6|-----------ACK----------->|                          |

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.

   3.  Since the remote ISUP node is unable to complete the call, it
       will send a REL.

   4.  The gateway releases the circuit and confirms that it is
       available for reuse by sending an RLC.

   5.  The gateway translates the cause code in the REL to a SIP error
       response (see Section 7.2.4) and sends it to the SIP node.

   6.  The SIP node sends an ACK to acknowledge receipt of the INVITE
       final response.

Top      ToC       Page 16 
7.1.6 Cause Present in ACM Message

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |<---ACM with cause code---|3
        4|<------183 with SDP-------|                          |
         |<=========Audio===========|                          |
                     ** Interwork timer expires **
        5|<----------4xx+-----------|                          |
         |                          |------------REL---------->|6
         |                          |<-----------RLC-----------|7
        8|-----------ACK----------->|                          |

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.

   3.  Since the ISUP node is unable to complete the call and wants to
       generate the error tone/announcement itself, it sends an ACM with
       a cause code.  The gateway starts an interwork timer.

   4.  Upon receipt of an ACM with cause (presence of the CAI
       parameter), the gateway will generate a 183 message towards the
       SIP node; this contains SDP to establish early media cut-through.

   5.  A final INVITE response, based on the cause code received in the
       earlier ACM message, is generated and sent to the SIP node to
       terminate the call.  See Section for the table which
       contains the mapping from cause code to SIP response.

   6.  Upon expiration of the interwork timer, a REL is sent towards the
       PSTN node to terminate the call.  Note that the SIP node can also
       terminate the call by sending a CANCEL before the interwork timer
       expires.  In this case, the signaling progresses as in Section

   7.  Upon receipt of the REL message, the remote ISUP node will reply
       with an RLC message.

   8.  The SIP node sends an ACK to acknowledge receipt of the INVITE
       final response.

Top      ToC       Page 17 
7.1.7 Call Canceled by SIP

       SIP                       MGC/MG                       PSTN
        1|---------INVITE---------->|                          |
         |<----------100------------|                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |<-----------ACM-----------|3
        4|<----------18x------------|                          |
         |<=========Audio===========|                          |
         |            ** MG Releases IP Resources **           |
        5|----------CANCEL--------->|                          |
        6|<----------200------------|                          |
         |             ** MG Releases PSTN Trunk **            |
         |                          |------------REL---------->|7
        8|<----------487------------|                          |
         |                          |<-----------RLC-----------|9
       10|-----------ACK----------->|                          |

   1.  When a SIP user wishes to begin a session with a PSTN user, the
       SIP node issues an INVITE request.

   2.  Upon receipt of an INVITE request, the gateway maps it to an IAM
       message and sends it to the ISUP network.

   3.  The remote ISUP node indicates that the address is sufficient to
       set up a call by sending back an ACM message.

   4.  The "called party status" code in the ACM message is mapped to a
       SIP provisional response (as described in Section 7.2.5 and
       Section 7.2.6) and returned to the SIP node.  This response may
       contain SDP to establish an early media stream.

   5.  To cancel the call before it is answered, the SIP node sends a
       CANCEL request.

   6.  The CANCEL request is confirmed with a 200 response.

   7.  Upon receipt of the CANCEL request, the gateway sends a REL
       message to terminate the ISUP call.

   8.  The gateway sends a "487 Call Cancelled" message to the SIP node
       to complete the INVITE transaction.

   9.  Upon receipt of the REL message, the remote ISUP node will reply
       with an RLC message.

Top      ToC       Page 18 
   10.  Upon receipt of the 487, the SIP node will confirm reception
        with an ACK.

7.2 State Machine

   Note that REL can be received in any state; the handling is the same
   for each case (see Section 10).

      +----------------------->|  Idle   |<---------------------+
      |                        +----+----+                      |
      |                             |                           |
      |                             | INVITE/6.2.1              |
      |                             V                           |
      |      T7/6.2.2   +-------------------------+   REL/6.2.4 |
      +<----------------+         Trying          +------------>+
      |                 +-+--------+------+-------+             |
      |    CANCEL/6.2.3 | |        |      |                     |
      +<----------------+ | E.ACM/ | ACM/ | CON/ANM             |
      |                   | 6.2.5  |6.2.6 | 6.2.7               |
      |                   V        |      |                     |
      | T9/6.2.8  +--------------+ |      |                     |
      +<----------+ Not alerting | |      |                     |
      |           +-------+------+ |      |                     |
      |  CANCEL/6.2.3 |   |        |      |                     |
      |<--------------+   | CPG/   |      |                     |
      |                   | 6.2.9  |      |                     |
      |                   V        V      |                     |
      |    T9/6.2.8     +---------------+ |    REL/6.2.4        |
      +<----------------+    Alerting   |-|-------------------->|
      |<----------------+--+-----+------+ |                     |
      |  CANCEL/6.2.3      |  ^  |        |                     |
      |               CPG/ |  |  | ANM/   |                     |
      |              6.2.9 +--+  | 6.2.7  |                     |
      |                          V        V                     |
      |                 +-------------------------+    REL/9.2  |
      |                 |     Waiting for ACK     |------------>|
      |                 +-------------+-----------+             |
      |                               |                         |
      |                               | ACK/6.2.10              |
      |                               V                         |
      |     BYE/9.1     +-------------------------+    REL/9.2  |
      +<----------------+        Connected        +------------>+

Top      ToC       Page 19 
7.2.1 INVITE received

   When an INVITE request is received by the gateway, a "100 Trying"
   response MAY be sent back to the SIP network indicating that the
   gateway is handling the call.

   The necessary hardware resources for the media stream MUST be
   reserved in the gateway when the INVITE is received, since an IAM
   message cannot be sent before the resource reservation (especially
   TCIC selection) takes place.  Typically the resources consist of a
   time slot in an E1/T1 and an RTP/UDP port on the IP side.  Resources
   might also include any quality-of-service provisions (although no
   such practices are recommended in this document).

   After sending the IAM the timer T7 is started.  The default value of
   T7 is between 20 and 30 seconds.  The gateway goes to the 'Trying'
   state. INVITE to IAM procedures

   This section details the mapping of the SIP headers in an INVITE
   message to the ISUP parameters in an Initial Address Message (IAM).
   A PSTN-SIP gateway is responsible for creating an IAM when it
   receives an INVITE.

   Five mandatory parameters appear within the IAM message: the Called
   Party Number (CPN), the Nature of Connection Indicator (NCI), the
   Forward Call Indicators (FCI), the Calling Party's Category (CPC),
   and finally a parameter that indicates the desired bearer
   characteristics of the call - in some ISUP variants the Transmission
   Medium Requirement (TMR) is required, in others the User Service
   Information (USI) (or both).  All IAM messages MUST contain these
   five parameters at a minimum.  Thus, every gateway must have a means
   of populating each of those five parameters when an INVITE is
   received.  Many of the values that will appear in these parameters
   (such as the NCI or USI) will most likely be the same for each IAM
   created by the gateway.  Others (such as the CPN) will vary on a
   call-by-call basis; the gateway extracts information from the INVITE
   in order to properly populate these parameters.

   There are also quite a few optional parameters that can appear in an
   IAM message; Q.763 [17] lists 29 in all.  However, each of these
   parameters need not to be translated in order to achieve the goals of
   SIP-ISUP mapping.  As is stated above, translation allows SIP network
   elements to understand the basic PSTN context of the session (who it
   is for, and so on) if they are not capable of deciphering any
   encapsulated ISUP.  Parameters that are only meaningful to the PSTN
   will be carried through PSTN-SIP- PSTN networks via encapsulation -

Top      ToC       Page 20 
   translation is not necessary for these parameters.  Of the
   aforementioned 29 optional parameters, only the following are
   immediately useful for translation: the Calling Party's Number (CIN,
   which is commonly present), Transit Network Selection (TNS), Carrier
   Identification Parameter (CIP, present in ANSI networks), Original
   Called Number (OCN), and the Generic Digits (known in some variants
   as the Generic Address Parameter (GAP)).

   When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD
   attempt to make use of encapsulated ISUP (see [3]), if any, within
   the INVITE to assist in the formulation of outbound PSTN signaling,
   but SHOULD also heed the security considerations in Section 15.  If
   possible, the gateway SHOULD reuse the values of each of the ISUP
   parameters of the encapsulated IAM as it formulates an IAM that it
   will send across its PSTN interface.  In some cases, the gateway will
   be unable to make use of that ISUP - for example, if the gateway
   cannot understand the ISUP variant and must therefore ignore the
   encapsulated body.  Even when there is comprehensible encapsulated
   ISUP, the relevant values of SIP header fields MUST 'overwrite'
   through the process of translation the parameter values that would
   have been set based on encapsulated ISUP.  In other words, the
   updates to the critical session context parameters that are created
   in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases,
   over the encapsulated ISUP.  This allows many basic services,
   including various sorts of call forwarding and redirection, to be
   implemented in the SIP network.

   For example, if an INVITE arrives at a gateway with an encapsulated
   IAM with a CPN field indicating the telephone number +12025332699,
   but the Request-URI of the INVITE indicates 'tel:+15105550110', the
   gateway MUST use the telephone number in the Request-URI, rather than
   the one in the encapsulated IAM, when creating the IAM that the
   gateway will send to the PSTN.  Further details of how SIP header
   fields are translated into ISUP parameters follow.

   Gateways MUST be provisioned with default values for mandatory ISUP
   parameters that cannot be derived from translation(such as the NCI or
   TMR parameters) for those cases in which no encapsulated ISUP is
   present.  The FCI parameter MUST also have a default, as only the 'M'
   bit of the default may be overwritten during the process of
   translation if the optional number portability translation mechanisms
   described below are used.

   The first step in the translation of the fields of an INVITE message
   to the parameters of an IAM is the inspection of the Request-URI.

Top      ToC       Page 21 
   If the optional number portability practices are supported by the
   gateway, then the following steps related to handling of the 'npdi'
   and 'rn' parameters of the Request-URI should be followed.

   If there is no 'npdi=yes' field within the Request-URI, then the
   primary telephone number in the tel URL (the digits immediately
   following 'tel:') MUST be converted to ISUP format, following the
   procedures described in Section 12, and used to populate the CPN

   If the 'npdi=yes' field exists in the Request-URI, then the FCI
   parameter bit for 'number translated' within the IAM MUST reflect
   that a number portability dip has been performed.

   If in addition to the 'npdi=yes' field there is no 'rn=' field
   present, then the main telephone number in the tel URL MUST be
   converted to ISUP format (see Section 12) and used to populate the
   CPN parameter.  This indicates that a portability dip took place, but
   that the called party's number was not ported.

   If in addition to the 'npdi=yes' field an 'rn=' field is present,
   then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format
   and used to populate the CPN.  The main telephone number in the tel
   URL MUST be converted to ISUP format and used to populate the Generic
   Digits Parameter (or GAP in ANSI).  In some other ISUP variants, the
   number given in the 'rn=' field would instead be prepended to the
   main telephone number (with or without a prefix or separator) and the
   combined result MUST be used to populate the CPN.  Once the 'rn=' and
   'npdi=' parameters have been translation, the number portability
   translation practices are complete.

   The following mandatory translation practices are performed after
   number portability translations, if any.

   If number portability practices are not supported by the gateway,
   then the primary telephone number in the tel URL (the digits
   immediately following 'tel:') MUST be converted to ISUP format,
   following the procedures described in Section 12, and used to
   populate the CPN parameter.

   If the primary telephone number in the Request-URI and that of the To
   header are at variance, then the To header SHOULD be used to populate
   an OCN parameter.  Otherwise the To header SHOULD be ignored.

   Some optional translation procedures are provided for carrier-based
   routing.  If the 'cic=' parameter is present in the Request-URI, the
   gateway SHOULD consult local policy to make sure that it is
   appropriate to transmit this Carrier Identification Code (CIC, not to

Top      ToC       Page 22 
   be confused with the MTP3 'circuit identification code') in the IAM;
   if the gateway supports many independent trunks, it may need to
   choose a particular trunk that points to the carrier identified by
   the CIC, or a tandem through which that carrier is reachable.
   Policies for such trunks (based on the preferences of the carriers
   with which the trunks are associated and the ISUP variant in use)
   SHOULD dictate whether the CIP or TNS parameter is used to carry the
   CIC.  In the absence of any pre-arranged policies, the TNS should be
   used when the CPN parameter is in an international format (i.e., the
   tel URL portion of the Request-URI is preceded by a '+', which will
   generate a CPN in international format), and (where supported) the
   CIP should be used in other cases.

   When a SIP call has been routed to a gateway, then the Request-URI
   will most likely contain a tel URL (or a SIP URI with a tel URL user
   portion) - SIP-ISUP gateways that receive Request-URIs that do not
   contain valid telephone numbers SHOULD reject such requests with an
   appropriate response code.  Gateways SHOULD however continue to
   process requests with a From header field that does not contain a
   telephone number, as will sometimes be the case if a call originated
   at a SIP phone that employs a SIP URI user@host convention.  The CIN
   parameter SHOULD be omitted from the outbound IAM if the From field
   is unusable.  Note that as an alternative, gateway implementers MAY
   consider some non-standard way of mapping particular SIP URIs to
   telephone numbers.

   When a gateway receives a message with (comprehensible) encapsulated
   ISUP, it MUST set the FCI indicator in the generated IAM so that all
   interworking-related bits have the same values as their counterparts
   in the encapsulated ISUP.  In most cases, these indicators will state
   that no interworking was encountered, unless interworking has been
   encountered somewhere else in the call path.  If usable encapsulated
   ISUP is not present in an INVITE received by the gateway, it is
   STRONGLY RECOMMENDED that the gateway set the Interworking Indicator
   bit of the FCI to 'no interworking' and the ISDN User Part Indicator
   to 'ISUP used all the way'; the gateway MAY also set the Originating
   Access indicator to 'Originating access non-ISDN' (generally, it is
   not safe to assume that SIP phones will support ISDN endpoint
   services, and the procedures in this document do not detail mappings
   to translate all such services).

   Note that when 'interworking encountered' is set in the FCI parameter
   of the IAM, this indicates that ISUP is interworking with a network
   which is not capable of providing as many services as ISUP does.
   ISUP networks will therefore not employ certain features they
   otherwise normally would, including potentially the use of ISDN cause
   codes in failure conditions (as opposed to sending ACMs followed by
   audible announcements).  If desired, gateway vendors MAY provide a

Top      ToC       Page 23 
   configurable option, usable at the discretion of service providers,
   that will signal in the FCI that interworking has been encountered
   (and that ISUP is not used all the way) when encapsulated ISUP is not
   present; however, doing so may significantly limit the efficiency and
   transparency of SIP-ISUP translation.

   Claiming to be an ISDN node might make the callee request ISDN user
   to user services.  Since user to user services 1 and 2 must be
   requested by the caller, they do not represent a problem (see [14]).
   User to user service 3 can be requested by the callee also.  In non-
   SIP bridging situations, the MGC should be capable of rejecting this
   service request.

7.2.2 ISUP T7 expires

   Since no response was received from the PSTN all the resources in the
   MG are released.  A '504 Server Timeout' SHOULD be sent back to the
   SIP network.  A REL message with cause value 102 (protocol error,
   recovery on timer expiry) SHOULD be sent to the PSTN.  Gateways can
   expect the PSTN to respond with RLC and the SIP network to respond
   with an ACK indicating that the release sequence has been completed.

7.2.3 CANCEL or BYE received

   If a CANCEL or BYE request is received before a final SIP response
   has been sent, a '200 OK' MUST be sent to the SIP network to confirm
   the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE
   transaction.  All the resources are released and a REL message SHOULD
   be sent to the PSTN with cause value 16 (normal clearing).  Gateways
   can expect an RLC from the PSTN to be received indicating that the
   release sequence is complete.

   In SIP bridging situations, a REL might be encapsulated in the body
   of a BYE request.  Although BYE is usually mapped to cause code 16
   (normal clearing), under exceptional circumstances the cause code in
   the REL message might be different.  Therefore the Cause Indicator
   parameter of the encapsulated REL should be re-used in the REL sent
   to the PSTN.

   Note that a BYE or CANCEL request may contain a Reason header that
   SHOULD be mapped to the Cause Indicator parameter (see Section 5.8).
   If a BYE contains both a Reason header and encapsulated ISUP, the
   value in the Reason header MUST be preferred.

   All the resources in the gateway SHOULD be released before the
   gateway sends any REL message.

Top      ToC       Page 24 
7.2.4 REL received

   This section applies when a REL is received before a final SIP
   response has been sent.  Typically, this condition arises when a call
   has been rejected by the PSTN.

   Any gateway resources SHOULD be released immediately and an RLC MUST
   be sent to the ISUP network to indicate that the circuit is available
   for reuse.

   If the INVITE that originated this transaction contained a legitimate
   and comprehensible encapsulated ISUP message (i.e., an IAM using a
   variant supported by the gateway, preferably with a digital
   signature), then encapsulated ISUP SHOULD be sent in the response to
   the INVITE when possible (since this suggests an ISUP-SIP-ISUP
   bridging case) - therefore, the REL message just received SHOULD be
   included in the body of the SIP response.  The gateway SHOULD NOT
   return a response with encapsulated ISUP if the originator of the
   INVITE did not enclose ISUP itself.

   Note that the receipt of certain maintenance messages in response to
   IAM such as Blocking Message (BLO) or Reset Message (RSC) (or their
   circuit group message equivalents) may also result in the teardown of
   calls in this phase of the state machine.  Behavior for maintenance
   messages is given below in Section 11. ISDN Cause Code to Status Code Mapping

   The use of the REL message in the SS7 network is very general,
   whereas SIP has a number of specific tools that, collectively, play
   the same role as REL - namely BYE, CANCEL, and the various
   status/response codes.  An REL can be sent to tear down a call that
   is already in progress (BYE), to cancel a previously sent call setup
   request that has not yet been completed (CANCEL), or to reject a call
   setup request (IAM) that has just been received (corresponding to a
   SIP status code).

   Note that it is not necessarily appropriate to map some ISDN cause
   codes to SIP messages because these cause codes are only meaningful
   to the ISUP interface of a gateway.  A good example of this is cause
   code 44 "Request circuit or channel not available." 44 signifies that
   the CIC for which an IAM had been sent was believed by the receiving
   equipment to be in a state incompatible with a new call request -
   however, the appropriate behavior in this case is for the originating
   switch to re-send the IAM for a different CIC, not for the call to be
   torn down.  Clearly, there is not (nor should there be) an SIP status
   code indicating that a new CIC should be selected - this matter is
   internal to the originating gateway.  Hence receipt of cause code 44

Top      ToC       Page 25 
   should not result in any SIP status code being sent; effectively, the
   cause code is untranslatable.

   If a cause value other than those listed below is received, the
   default response '500 Server internal error' SHOULD be used.

   Finally, in addition to the ISDN Cause Code, the CAI parameter also
   contains a cause 'location' that gives some sense of which entity in
   the network was responsible for terminating the call (the most
   important distinction being between the user and the network).  In
   most cases, the cause location does not affect the mapping to a SIP
   status code; some exceptions are noted below.  A diagnostic field may
   also be present for some ISDN causes; this diagnostic will contain
   additional data pertaining to the termination of the call.

   The following mapping values are RECOMMENDED:

   Normal event

   ISUP Cause value                        SIP response
   ----------------                        ------------
   1  unallocated number                   404 Not Found
   2  no route to network                  404 Not found
   3  no route to destination              404 Not found
   16 normal call clearing                 --- (*)
   17 user busy                            486 Busy here
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable
   21 call rejected                        403 Forbidden (+)
   22 number changed (w/o diagnostic)      410 Gone
   22 number changed (w/ diagnostic)       301 Moved Permanently
   23 redirection to new destination       410 Gone
   26 non-selected user clearing           404 Not Found (=)
   27 destination out of order             502 Bad Gateway
   28 address incomplete                   484 Address incomplete
   29 facility rejected                    501 Not implemented
   31 normal unspecified                   480 Temporarily unavailable

   (*) ISDN Cause 16 will usually result in a BYE or CANCEL

   (+) If the cause location is 'user' than the 6xx code could be given
   rather than the 4xx code (i.e., 403 becomes 603)

   (=) ANSI procedure - in ANSI networks, 26 is overloaded to signify
   'misrouted ported number'.  Presumably, a number portability dip
   should have been performed by a prior network.  Otherwise cause 26 is
   usually not used in ISUP procedures.

Top      ToC       Page 26 
   A REL with ISDN cause 22 (number changed) might contain information
   about a new number where the callee might be reachable in the
   diagnostic field.  If the MGC is able to process this information it
   SHOULD be added to the SIP response (301) in a Contact header.

   Resource unavailable

   This kind of cause value indicates a temporary failure.  A 'Retry-
   After' header MAY be added to the response if appropriate.

   ISUP Cause value                        SIP response
   ----------------                        ------------
   34 no circuit available                 503 Service unavailable
   38 network out of order                 503 Service unavailable
   41 temporary failure                    503 Service unavailable
   42 switching equipment congestion       503 Service unavailable
   47 resource unavailable                 503 Service unavailable

   Service or option not available

   This kind of cause value indicates that there is a problem with the
   request, rather than something that will resolve itself over time.

   ISUP Cause value                        SIP response
   ----------------                        ------------
   55 incoming calls barred within CUG     403 Forbidden
   57 bearer capability not authorized     403 Forbidden
   58 bearer capability not presently      503 Service unavailable

   Service or option not available

   ISUP Cause value                        SIP response
   ----------------                        ------------
   65 bearer capability not implemented    488 Not Acceptable Here
   70 only restricted digital avail        488 Not Acceptable Here
   79 service or option not implemented    501 Not implemented

   Invalid message

   ISUP Cause value                        SIP response
   ----------------                        ------------
   87 user not member of CUG               403 Forbidden
   88 incompatible destination             503 Service unavailable

Top      ToC       Page 27 
   Protocol error

   ISUP Cause value                        SIP response
   ----------------                        ------------
   102 recovery of timer expiry            504 Gateway timeout
   111 protocol error                      500 Server internal error


   ISUP Cause value                        SIP response
   ----------------                        ------------
   127 interworking unspecified            500 Server internal error

7.2.5 Early ACM received

   An ACM message is sent in certain situations to indicate that the
   call is in progress in order to satisfy ISUP timers, rather than to
   signify that the callee is being alerted.  This occurs for example in
   mobile networks, where roaming can delay call setup significantly.
   The early ACM is sent before the user is alerted to reset T7 and
   start T9.  An ACM is considered an 'early ACM' if the Called Party's
   Status Indicator is set to 00 (no indication).

   After sending an early ACM, the ISUP network can be expected to
   indicate the further progress of the call by sending CPGs.

   When an early ACM is received the gateway SHOULD send a 183 Session
   Progress response (see [1]) to the SIP network.  In SIP bridging
   situations (where encapsulated ISUP was contained in the INVITE that
   initiated this call) the early ACM SHOULD also be included in the
   response body.

   Note that sending 183 before a gateway has confirmation that the
   address is complete (ACM) creates known problems in SIP bridging
   cases, and it SHOULD NOT therefore be sent.

7.2.6 ACM received

   Most commonly, on receipt of an ACM a provisional response (in the
   18x class) SHOULD be sent to the SIP network.  If the INVITE that
   initiated this session contained legitimate and comprehensible
   encapsulated ISUP, then the ACM received by the gateway SHOULD be
   encapsulated in the provisional response.

   If the ACM contains a Backward Call Indicators parameter with a value
   of 'subscriber free', the gateway SHOULD send a '180 Ringing'
   response.  When a 180 is sent, it is assumed, in the absence of any
   early media extension, that any necessary ringback tones will be

Top      ToC       Page 28 
   generated locally by the SIP user agent to which the gateway is
   responding (which may in turn be a gateway).

   If the Backward Call Indicators (BCI) parameter of the ACM indicates
   that interworking has been encountered (generally designating that
   the ISUP network sending the ACM is interworking with a less
   sophisticated network which cannot report its status via out-of-band
   signaling), then there may be in-band announcements of call status
   such as an audible busy tone or caller intercept message, and if
   possible a backwards media transmission SHOULD be initiated.
   Backwards media SHOULD also be transmitted if the Optional Backward
   Call Indicators parameter field for in-band media is set.  For more
   information on early media (before 200 OK/ANM) see Section 5.5.
   After early media transmission has been initiated, the gateway SHOULD
   send a 183 Session Progress response code.

   Gateways MAY have some means of ascertaining the disposition of in-
   band audio media; for example, a way of determining by inspecting
   signaling in some ISUP variants, or by listening to the audio, that
   ringing, or a busy tone, is being played over the circuit.  Such
   gateways MAY elect to discard the media and send the corresponding
   response code (such as 180 or 486) in its stead.  However, the
   implementation of such a gateway would entail overcoming a number of
   known challenges that are outside the scope of this document.

   When they receive an ACM, switches in many ISUP networks start a
   timer known as "T9" which usually lasts between 90 seconds and 3
   minutes (see [13]).  When early media is being played, this timer
   permits the caller to hear backwards audio media (in the form
   ringback, tones or announcements) from a remote switch in the ISUP
   network for that period of time without incurring any charge for the
   connection.  The nearest possible local ISUP exchange to the callee
   generates the ringback tone or voice announcements.  If longer
   announcements have to be played, the network has to send an ANM,
   which initiates bidirectional media of indefinite duration.  In
   common ISUP network practice, billing commences when the ANM is
   received.  Some networks do not support timer T9.

7.2.7 CON or ANM Received

   When an ANM or CON message is received, the call has been answered
   and thus '200 OK' response SHOULD be sent to the SIP network.  This
   200 OK SHOULD contain an answer to the media offered in the INVITE.
   In SIP bridging situations (when the INVITE that initiated this call
   contained legitimate and comprehensible encapsulated ISUP), the ISUP
   message is included in the body of the 200 OK response.  If it has
   not done so already, the gateway MUST establish a bidirectional media
   stream at this time.

Top      ToC       Page 29 
   When there is interworking with some legacy networks, it is possible
   for an ISUP switch to receive an ANM immediately after an early ACM
   (without CPG or any other backwards messaging), or without receiving
   any ACM at all (when an automaton answers the call).  In this
   situation the SIP user will never have received a 18x provisional
   response, and consequently they will not hear any kind of ringtone
   before the callee answers.  This may result in some clipping of the
   initial forward media from the caller (since forward media
   transmission cannot commence until SDP has been acquired from the
   destination).  In ISDN (see [12]) this is solved by connecting the
   voice path backwards before sending the IAM.

7.2.8 Timer T9 Expires

   The expiry of this timer (which is not used in all networks)
   signifies that an ANM has not arrived a significant period of time
   after alerting began (with the transmission of an ACM) for this call.
   Usually, this means that the callee's terminal has been alerted for
   many rings but has not been answered.  It may also occur in
   interworking cases when the network is playing a status announcement
   (such as one indicating that a number is not in service) that has
   cycled several times.  Whatever the cause of the protracted
   incomplete call, when this timer expires the call MUST be released.
   All of the gateway resources related to the media path SHOULD be
   released.  A '480 Temporarily Unavailable' response code SHOULD be
   sent to the SIP network, and an REL message with cause value 19 (no
   answer from the user) SHOULD be sent to the ISUP network.  The PSTN
   can be expected to respond with an RLC and the SIP network to respond
   with an ACK indicating that the release sequence has been completed.

7.2.9 CPG Received

   A CPG is a provisional message that can indicate progress, alerting
   or in-band information.  If a CPG suggests that in-band information
   is available, the gateway SHOULD begin to transmit early media and
   cut through the unidirectional backwards media path.

Top      ToC       Page 30 
   In SIP bridging situations (when the INVITE that initiated this
   session contained legitimate and comprehensible encapsulated ISUP),
   the CPG SHOULD be sent in the body of a particular 18x response,
   determined from the CPG Event Code as follows:

   ISUP event code                         SIP response
   ----------------                        ------------
   1 Alerting                              180 Ringing
   2 Progress                              183 Session progress
   3 In-band information                   183 Session progress
   4 Call forward; line busy               181 Call is being forwarded
   5 Call forward; no reply                181 Call is being forwarded
   6 Call forward; unconditional           181 Call is being forwarded
   - (no event code present)               183 Session progress

   Note that if the CPG does not indicate "Alerting," the current state
   will not change.

7.3 ACK received

   At this stage, the call is fully connected and the conversation can
   take place.  No ISUP message should be sent by the gateway when an
   ACK is received.

(page 30 continued on part 2)

Next RFC Part