GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc3398

Network Working Group G. Camarillo Request for Comments: 3398 Ericsson Category: Standards Track A. B. Roach

                                                           dynamicsoft
                                                           J. Peterson
                                                               NeuStar
                                                                L. Ong
                                                                 Ciena
                                                         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.

Abstract

 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

Camarillo, et. al. Standards Track [Page 1] RFC 3398 ISUP to SIP Mapping December 2002

 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
 7.2.1.1 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
 7.2.4.1 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
 8.2.1.1 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
 8.2.6.1 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     SUS and RES............................................. 48
 9.2     Hold (re-INVITE)........................................ 50

Camarillo, et. al. Standards Track [Page 2] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 3] RFC 3398 ISUP to SIP Mapping December 2002

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

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

Camarillo, et. al. Standards Track [Page 4] RFC 3398 ISUP to SIP Mapping December 2002

 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",
 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
 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
 scenario.

Camarillo, et. al. Standards Track [Page 5] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 6] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 7] RFC 3398 ISUP to SIP Mapping December 2002

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

Camarillo, et. al. Standards Track [Page 8] RFC 3398 ISUP to SIP Mapping December 2002

 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
 [20].
 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].

Camarillo, et. al. Standards Track [Page 9] RFC 3398 ISUP to SIP Mapping December 2002

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
 [9].

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

Camarillo, et. al. Standards Track [Page 10] RFC 3398 ISUP to SIP Mapping December 2002

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
 "MGC/MG."

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.

Camarillo, et. al. Standards Track [Page 11] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 12] RFC 3398 ISUP to SIP Mapping December 2002

7.1.3 ISUP T7 Expires

     SIP                       MGC/MG                       PSTN
      1|---------INVITE---------->|                          |
       |<----------100------------|                          |
       |                          |------------IAM---------->|2
       |                          |<=========Audio===========|
       |                          |    *** T7 Expires ***    |
       |             ** MG Releases PSTN Trunk **            |
      4|<----------504------------|------------REL---------->|3
      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.

Camarillo, et. al. Standards Track [Page 13] RFC 3398 ISUP to SIP Mapping December 2002

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 **            |
      7|<----------BYE------------|------------REL---------->|6
       |                          |<-----------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
     expires.
 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
     expiry).

Camarillo, et. al. Standards Track [Page 14] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 15] RFC 3398 ISUP to SIP Mapping December 2002

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 7.2.4.1 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.1.7.
 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.

Camarillo, et. al. Standards Track [Page 16] RFC 3398 ISUP to SIP Mapping December 2002

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.

Camarillo, et. al. Standards Track [Page 17] RFC 3398 ISUP to SIP Mapping December 2002

 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        +------------>+
                      +-------------------------+

Camarillo, et. al. Standards Track [Page 18] RFC 3398 ISUP to SIP Mapping December 2002

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.

7.2.1.1 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 -

Camarillo, et. al. Standards Track [Page 19] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 20] RFC 3398 ISUP to SIP Mapping December 2002

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

Camarillo, et. al. Standards Track [Page 21] RFC 3398 ISUP to SIP Mapping December 2002

 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

Camarillo, et. al. Standards Track [Page 22] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 23] RFC 3398 ISUP to SIP Mapping December 2002

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.

7.2.4.1 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

Camarillo, et. al. Standards Track [Page 24] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 25] RFC 3398 ISUP to SIP Mapping December 2002

 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
    available
 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

Camarillo, et. al. Standards Track [Page 26] RFC 3398 ISUP to SIP Mapping December 2002

 Protocol error
 ISUP Cause value                        SIP response
 ----------------                        ------------
 102 recovery of timer expiry            504 Gateway timeout
 111 protocol error                      500 Server internal error
 Interworking
 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

Camarillo, et. al. Standards Track [Page 27] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 28] RFC 3398 ISUP to SIP Mapping December 2002

 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.

Camarillo, et. al. Standards Track [Page 29] RFC 3398 ISUP to SIP Mapping December 2002

 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.

8. ISUP to SIP Mapping

8.1 ISUP to SIP 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
 PSTN network.  "100 Trying" acknowledgements to INVITE requests are
 not depicted, since their presence is optional.
 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
 "MGC/MG".

Camarillo, et. al. Standards Track [Page 30] RFC 3398 ISUP to SIP Mapping December 2002

8.1.1 En-bloc call setup (non auto-answer)

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
       |-----------100----------->|                          |
      3|-----------18x----------->|                          |
       |==========Audio==========>|                          |
       |                          |=========================>|
       |                          |------------ACM---------->|4
      5|-----------18x----------->|                          |
       |                          |------------CPG---------->|6
      7|-----------200-(I)------->|                          |
       |<=========Audio==========>|                          |
       |                          |------------ANM---------->|8
       |                          |<=========Audio==========>|
      9|<----------ACK------------|                          |
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message, and sends it to an appropriate SIP node.
 3.  When an event signifying that the call has sufficient addressing
     information occurs, the SIP node will generate a provisional
     response of 180 or greater.
 4.  Upon receipt of a provisional response of 180 or greater, the
     gateway will generate an ACM message.  If the response is not
     180, the ACM will carry a "called party status" value of "no
     indication."
 5.  The SIP node may use further provisional messages to indicate
     session progress.
 6.  After an ACM has been sent, all provisional responses will
     translate into ISUP CPG messages as indicated in Section 8.2.3.
 7.  When the SIP node answers the call, it will send a 200 OK
     message.
 8.  Upon receipt of the 200 OK message, the gateway will send an ANM
     message towards the ISUP node.
 9.  The gateway will send an ACK to the SIP node to acknowledge
     receipt of the INVITE final response.

Camarillo, et. al. Standards Track [Page 31] RFC 3398 ISUP to SIP Mapping December 2002

8.1.2 Auto-answer call setup

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------200----------->|                          |
       |<=========Audio==========>|                          |
       |                          |------------CON---------->|4
       |                          |<=========Audio==========>|
      5|<----------ACK------------|                          |
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message and sends it to an appropriate SIP node based on called
     number analysis.
 3.  Since the SIP node is set up to automatically answer the call, it
     will send a 200 OK message.
 4.  Upon receipt of the 200 OK message, the gateway will send a CON
     message towards the ISUP node.
 5.  The gateway will send an ACK to the SIP node to acknowledge
     receipt of the INVITE final response.

Camarillo, et. al. Standards Track [Page 32] RFC 3398 ISUP to SIP Mapping December 2002

8.1.3 SIP Timeout

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
      3|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |                          |    *** T11 Expires ***   |
       |                          |------------ACM---------->|4
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |             ** MG Releases PSTN Trunk **            |
       |                          |------------REL---------->|5
      6|<--------CANCEL-----------|                          |
       |                          |<-----------RLC-----------|7
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message, and sends it to an appropriate SIP node based on called
     number analysis.  The ISUP timer T11 and SIP timer T1 are set at
     this time.
 3.  The INVITE message will continue to be sent to the SIP node each
     time the timer T1 expires.  The SIP standard specifies that
     INVITE transmission will be performed 7 times if no response is
     received.

Camarillo, et. al. Standards Track [Page 33] RFC 3398 ISUP to SIP Mapping December 2002

 4.  When T11 expires, an ACM message will be sent to the ISUP node to
     prevent the call from being torn down by the remote node's ISUP
     T7.  This ACM contains a 'Called Party Status' value of 'no
     indication.'
 5.  Once the maximum number of INVITE requests has been sent, the
     gateway will send a REL (cause code 18) to the ISUP node to
     terminate the call.
 6.  The gateway also sends a CANCEL message to the SIP node to
     terminate any initiation attempts.
 7.  Upon receipt of the REL, the remote ISUP node will send an RLC to
     acknowledge.

8.1.4 ISUP T9 Expires

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
      3|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |                          |    *** T11 Expires ***   |
       |                          |------------ACM---------->|4
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |                          |    *** T9 Expires ***    |
       |             ** MG Releases PSTN Trunk **            |
       |                          |<-----------REL-----------|5
       |                          |------------RLC---------->|6
      7|<--------CANCEL-----------|                          |
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message, and sends it to an appropriate SIP node based on called
     number analysis.  The ISUP timer T11 and SIP timer T1 are set at
     this time.

Camarillo, et. al. Standards Track [Page 34] RFC 3398 ISUP to SIP Mapping December 2002

 3.  The INVITE message will continue to be sent to the SIP node each
     time the timer T1 expires.  The SIP standard specifies that
     INVITE transmission will be performed 7 times if no response is
     received.  Since SIP T1 starts at 1/2 second or more and doubles
     each time it is retransmitted, it will be at least a minute
     before SIP times out the INVITE request; since SIP T1 is allowed
     to be larger than 500 ms initially, it is possible that 7 x SIP
     T1 will be longer than ISUP T11 + ISUP T9.
 4.  When T11 expires, an ACM message will be sent to the ISUP node to
     prevent the call from being torn down by the remote node's ISUP
     T7.  This ACM contains a 'Called Party Status' value of 'no
     indication.'
 5.  When ISUP T9 in the remote PSTN node expires, it will send a REL.
 6.  Upon receipt of the REL, the gateway will send an RLC to
     acknowledge.
 7.  The REL will trigger a CANCEL request, which gets sent to the SIP
     node.

8.1.5 SIP Error Response

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------4xx+---------->|                          |
      4|<----------ACK------------|                          |
       |             ** MG Releases PSTN Trunk **            |
       |                          |------------REL---------->|5
       |                          |<-----------RLC-----------|6
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message, and sends it to an appropriate SIP node based on called
     number analysis.
 3.  The SIP node indicates an error condition by replying with a
     response with a code of 400 or greater.
 4.  The gateway sends an ACK message to acknowledge receipt of the
     INVITE final response.

Camarillo, et. al. Standards Track [Page 35] RFC 3398 ISUP to SIP Mapping December 2002

 5.  An ISUP REL message is generated from the SIP code, as specified
     in Section 8.2.6.1.
 6.  The remote ISUP node confirms receipt of the REL message with an
     RLC message.

8.1.6 SIP Redirection

     SIP node 1                MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------3xx+---------->|                          |
       |                          |------------CPG---------->|4
      5|<----------ACK------------|                          |
                                  |                          |
                                  |                          |
     SIP node 2                   |                          |
      6|<--------INVITE-----------|                          |
      7|-----------18x----------->|                          |
       |<=========Audio===========|                          |
       |                          |------------ACM---------->|8
      9|-----------200-(I)------->|                          |
       |<=========Audio==========>|                          |
       |                          |------------ANM---------->|10
       |                          |<=========Audio==========>|
     11|<----------ACK------------|                          |
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message, and sends it to an appropriate SIP node based on called
     number analysis.
 3.  The SIP node indicates that the resource which the user is
     attempting to contact is at a different location by sending a 3xx
     message.  In this instance we assume the Contact URL specifies a
     valid URL reachable by a VoIP SIP call.
 4.  The gateway sends a CPG with event indication that the call is
     being forwarded upon receipt of the 3xx message.  Note that this
     translation should be able to be disabled by configuration, as
     some ISUP nodes do not support receipt of CPG messages before ACM
     messages.
 5.  The gateway acknowledges receipt of the INVITE final response by
     sending an ACK message to the SIP node.

Camarillo, et. al. Standards Track [Page 36] RFC 3398 ISUP to SIP Mapping December 2002

 6.  The gateway re-sends the INVITE message to the address indicated
     in the Contact: field of the 3xx message.
 7.  When an event signifying that the call has sufficient addressing
     information occurs, the SIP node will generate a provisional
     response of 180 or greater.
 8.  Upon receipt of a provisional response of 180 or greater, the
     gateway will generate an ACM message with an event code as
     indicated in Section 8.2.3.
 9.  When the SIP node answers the call, it will send a 200 OK
     message.
 10. Upon receipt of the 200 OK message, the gateway will send an ANM
     message towards the ISUP node.
 11. The gateway will send an ACK to the SIP node to acknowledge
     receipt of the INVITE final response.

8.1.7 Call Canceled by ISUP

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------18x----------->|                          |
       |==========Audio==========>|                          |
       |                          |------------ACM---------->|4
       |             ** MG Releases PSTN Trunk **            |
       |                          |<-----------REL-----------|5
       |                          |------------RLC---------->|6
      7|<---------CANCEL----------|                          |
       |            ** MG Releases IP Resources **           |
      8|-----------200----------->|                          |
      9|-----------487----------->|                          |
     10|<----------ACK------------|                          |
 1.  When a PSTN user wishes to begin a session with a SIP user, the
     PSTN network generates an IAM message towards the gateway.
 2.  Upon receipt of the IAM message, the gateway generates an INVITE
     message, and sends it to an appropriate SIP node based on called
     number analysis.
 3.  When an event signifying that the call has sufficient addressing
     information occurs, the SIP node will generate a provisional
     response of 180 or greater.

Camarillo, et. al. Standards Track [Page 37] RFC 3398 ISUP to SIP Mapping December 2002

 4.  Upon receipt of a provisional response of 180 or greater, the
     gateway will generate an ACM message with an event code as
     indicated in Section 8.2.3.
 5.  If the calling party hangs up before the SIP node answers the
     call, a REL message will be generated.
 6.  The gateway frees the PSTN circuit and indicates that it is
     available for reuse by sending an RLC.
 7.  Upon receipt of a REL message before an INVITE final response,
     the gateway will send a CANCEL towards the SIP node.
 8.  Upon receipt of the CANCEL, the SIP node will send a 200
     response.
 9.  The remote SIP node will send a "487 Call Cancelled" to complete
     the INVITE transaction.
 10. The gateway will send an ACK to the SIP node to acknowledge
     receipt of the INVITE final response.

Camarillo, et. al. Standards Track [Page 38] RFC 3398 ISUP to SIP Mapping December 2002

8.2 State Machine

 Note that REL may arrive in any state.  Whenever this occurs, the
 actions in section Section 8.2.7. are taken.  Not all of these
 transitions are shown in this diagram.
                               +---------+
      +----------------------->|  Idle   |<---------------------+
      |                        +----+----+                      |
      |                             |                           |
      |                             | IAM/7.2.1                 |
      |                             V                           |
      |    REL/7.2.7    +-------------------------+ 400+/7.2.6  |
      +<----------------+         Trying          |------------>|
      |                 +-+--------+------+-------+             |
      |                   |        |      |                     |
      |                   | T11/   | 18x/ | 200/                |
      |                   | 7.2.8  |7.2.3 | 7.2.4               |
      |                   V        |      |                     |
      | REL/7.2.7 +--------------+ |      |      400+/7.2.6     |
      |<----------| Progressing  |-|------|-------------------->|
      |           +--+----+------+ |      |                     |
      |              |    |        |      |                     |
      |        200/  |    | 18x/   |      |                     |
      |        7.2.4 |    | 7.2.3  |      |                     |
      |              |    V        V      |                     |
      |  REL/7.2.7   |  +---------------+ |      400+/7.2.6     |
      |<-------------|--|    Alerting   |-|-------------------->|
      |              |  +--------+------+ |                     |
      |              |           |        |                     |
      |              |           | 200/   |                     |
      |              |           | 7.2.4  |                     |
      |              V           V        V                     |
      |     BYE/9.1 +-----------------------------+    REL/9.2  |
      +<------------+          Connected          +------------>+
                    +-----------------------------+

8.2.1 Initial Address Message received

 Upon receipt of an IAM, the gateway SHOULD reserve appropriate
 internal resources (Digital Signal Processors - DSPs - and the like)
 necessary for handling the IP side of the call.  It MAY make any
 necessary preparations to connect audio in the backwards direction
 (towards the caller).

Camarillo, et. al. Standards Track [Page 39] RFC 3398 ISUP to SIP Mapping December 2002

8.2.1.1 IAM to INVITE procedures

 When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message MUST
 be created for transmission to the SIP network.  This section details
 the process by which a gateway populates the fields of the INVITE
 based on parameters found within the IAM.
 The context of the call setup request read by the gateway in the IAM
 will be mapped primarily to two URIs in the INVITE, one representing
 the originator of the session and the other its destination.  The
 former will always appear in the From header (after it has been
 converted from ISUP format by the procedure described in Section 12),
 and the latter is almost always used for both the To header and the
 Request-URI.
 Once the address of the called party number has been read from the
 IAM, it SHOULD be translated into a destination tel URL that will
 serve as the Request-URI of the INVITE.  Alternatively, a gateway MAY
 first attempt a Telephone Number Mapping (ENUM) [8] query to resolve
 the called party number to a URI.  Some additional ISUP fields MAY be
 added to the tel URL after translation has been completed, namely:
 o  If the gateway supports carrier-based routing (which is optional
    in this specification), it SHOULD ascertain if either the CIP (in
    ANSI networks) or TNS parameter is present in the IAM.  If a value
    is present, the CIC SHOULD be extracted from the given parameter
    and analyzed by the gateway.  A 'cic=' field with the value of the
    CIC SHOULD be appended to the destination tel URL, if doing so is
    in keeping with local policy (i.e., provided that the CIC does not
    indicate the network which owns the gateway or some similar
    condition).  Note that if it is created, the 'cic=' parameter MUST
    be prefixed with the country code used or implied in the called
    party number, so that CIC '5062' becomes, in the United States,
    '+1-5062'.  For further information on the 'cic=' tel URL field
    see [21].
 o  If the gateway supports number portability-based routing (which is
    optional in this specification), then the gateway will need to
    look at a few other fields.  To correctly map the FCI 'number
    translated' bit indicating that an LNP dip had been performed in
    the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL.
    If a GAP is present in the IAM, then the contents of the CPN (the
    Location Routing Number - LRN) SHOULD be translated from ISUP
    format (as described in Section 12) and copied into an 'rn=' field
    which must be appended to the tel URL, whereas the GAP itself
    should be translated to ISUP format and used to populate the
    primary telephone number field of the tel URL.  Note that in some
    national numbering plans, both the LRN and the dialed number may

Camarillo, et. al. Standards Track [Page 40] RFC 3398 ISUP to SIP Mapping December 2002

    be stored in the CPN parameter, in which case they must be
    separated out into different fields to be stored in the tel URL.
    Note that LRNs are necessarily national in scope, and consequently
    they MUST NOT be preceded by a '+' in the 'rn=' field.  For
    further information on these tel URL fields see [21].
 In most cases, the resulting destination tel URL SHOULD be used in
 both the To field and Request-URI sent by the gateway.  However, if
 the OCN parameter is present in the IAM, the To field SHOULD be
 constructed from the translation (from ISUP format following Section
 12 of the OCN parameter, and hence the Request-URI and To field MAY
 be different.
 The construction of the From header field is dependent on the
 presence of a CIN parameter.  If the CIN is not present, then the
 gateway SHOULD create a dummy From header field containing a SIP URI
 without a user portion which communicates only the hostname of the
 gateway (e.g., 'sip:gw.sipcarrier.com).  If the CIN is available,
 then it SHOULD be translated (in accordance with the procedure
 described above) into a tel URL which should populate the From header
 field.  In either case, local policy or requests for presentation
 restriction (see Section 12.1) MAY result in a different value for
 the From header field.

8.2.2 100 received

 A 100 response SHOULD NOT trigger any PSTN interworking messages; it
 only serves the purpose of suppressing INVITE retransmissions.

8.2.3 18x received

 Upon receipt of a 18x provisional response, if no ACM has been sent
 and no legitimate and comprehensible ISUP is present in the 18x
 message body, then the ISUP message SHOULD be generated according to
 the following table.  Note that if an early ACM is sent, the call
 MUST enter state "Progressing" instead of state "Alerting."
 Response received                        Message sent by the MGC
 -----------------                        -----------------------
 180 Ringing                              ACM (BCI = subscriber free)
 181 Call is being forwarded              Early ACM and CPG, event=6
 182 Queued                               ACM (BCI = no indication)
 183 Session progress message             ACM (BCI = no indication)

Camarillo, et. al. Standards Track [Page 41] RFC 3398 ISUP to SIP Mapping December 2002

 If an ACM has already been sent and no ISUP is present in the 18x
 message body, an ISUP message SHOULD be generated according to the
 following table.
 Response received                        Message sent by the MGC
 -----------------                        -----------------------
 180 Ringing                              CPG, event = 1 (Alerting)
 181 Call is being forwarded              CPG, event = 6 (Forwarding)
 182 Queued                               CPG, event = 2 (Progress)
 183 Session progress message             CPG, event = 2 (Progress)
 Upon receipt of a 180 response, the gateway SHOULD generate the
 ringback tone to be heard by the caller on the PSTN side (unless the
 gateway knows that ringback will be provided by the network on the
 PSTN side).
 Note however that a gateway might receive media at any time after it
 has transmitted an SDP offer that it has sent in an INVITE, even
 before a 18x provisional response is received.  Therefore the gateway
 MUST be prepared to play this media to the caller on the PSTN side
 (if necessary, ceasing any ringback tone that it may have begun to
 generate and then playing media).  Note that the gateway may also
 receive SDP offers in responses for an early media session using some
 SIP extension, see Section 5.5.  If a gateway receives a 183 response
 while it is playing backwards media, then when it generates a mapping
 for this response, if no encapsulated ISUP is present, the gateway
 SHOULD indicate that in-band information is available (for example,
 with the Event Information parameter of the CPG message or the
 Optional Backward Call Indicators parameter of the ACM).
 When an ACM is sent, the mandatory Backward Call Indicators parameter
 must be set, as well as any optional parameters as gateway policy
 dictates.  If legitimate and comprehensible ISUP is present in the
 18x response, the gateway SHOULD re-use the appropriate parameters of
 the ISUP message contained in the response body, including the value
 of the Backward Call Indicator parameter, as it formulates a message
 that it will send across its PSTN interface.  In the absence of a
 usable encapsulated ACM, the BCI parameter SHOULD be set as follows:

Camarillo, et. al. Standards Track [Page 42] RFC 3398 ISUP to SIP Mapping December 2002

 Message type:                            ACM
 Backward Call Indicators
 Charge indicator:                      10 charge
 Called party's status indicator:       01 subscriber free or
                                        00 no indication
 Called party's category indicator:     01 ordinary subscriber
 End-to-end method indicator:           00 no end-to-end method
 Interworking indicator:                0  no interworking
 End-to-end information indicator:      0  no end-to-end info
 ISDN user part indicator:              1  ISUP used all the way
 Holding indicator:                     0  no holding
 ISDN access indicator:                 0  No ISDN access
 Echo control device indicator:         It depends on the call
 SCCP method indicator:                 00 no indication
 Note that when the ISUP Backward Call Indicator parameter
 Interworking indicator field is set to 'interworking encountered',
 this indicates that ISDN is interworking with a network which is not
 capable of providing as many services as ISDN does.  ISUP therefore
 may not employ certain features it otherwise normally uses.  Gateway
 vendors MAY however provide a configurable option, usable at the
 discretion of service providers when they require additional ISUP
 services, that in the absence of encapsulated ISUP will signal in the
 BCI that interworking has been encountered, and that ISUP is not used
 all the way, for those operators that as a matter of policy would
 rather operate in this mode.  For more information on the effects of
 interworking see Section 7.2.1.1.

8.2.4 2xx received

 Response received                        Message sent by the MGC
 -----------------                        -----------------------
 200 OK                                   ANM, ACK
 After receiving a 200 OK response the gateway MUST establish a
 directional media path in the gateway and send an ANM to the PSTN as
 well as an ACK to the SIP network.
 If the 200 OK response arrives before the gateway has sent an ACM, a
 CON is sent instead of the ANM, in those ISUP variants that support
 the CON message.
 When a legitimate and comprehensible ANM is encapsulated in the 200
 OK response, the gateway SHOULD re-use any relevant ISUP parameters
 in the ANM it sends to the PSTN.

Camarillo, et. al. Standards Track [Page 43] RFC 3398 ISUP to SIP Mapping December 2002

 Note that gateways may sometimes receive 200 OK responses for
 requests other than INVITE (for example, those used in managing
 provisional responses, or the INFO method).  The procedures described
 in this section apply only to 200 OK responses received as a result
 of sending an INVITE.  The gateway SHOULD NOT send any PSTN messages
 if it receives a 200 OK in response to non-INVITE requests it has
 sent.

8.2.5 3xx Received

 When any 3xx response (a redirection) is received, the gateway SHOULD
 try to reach the destination by sending one or more new call setup
 requests using URIs found in any Contact header field(s) present in
 the response, as is mandated in the base SIP specification.  Such 3xx
 responses are typically sent by a redirect server, and can be thought
 of as similar to a location register in mobile PSTN networks.
 If a particular URI presented in the Contact header of a 3xx is best
 reachable (according to the gateway's routing policies) via the PSTN,
 the gateway SHOULD send a new IAM and from that moment on act as a
 normal PSTN switch (no SIP involved) - usually this will be the case
 when the URI in the Contact header is a tel URL, one that the gateway
 cannot reach locally and one for which there is no ENUM mapping.
 Alternatively, the gateway MAY send a REL message to the PSTN with a
 redirection indicator (23) and a diagnostic field corresponding to
 the telephone number in the URI.  If, however, the new location is
 best reachable using SIP (if the URI in the Contact header contains
 no telephone number at all), the MGC SHOULD send a new INVITE with a
 Request-URI possibly a new IAM generated by the MGC in the message
 body.
 While it is exploring a long list of Contact header fields with SIP
 requests, a gateway MAY send a CPG message with an event code of 6
 (Forwarding) to the PSTN in order to indicate that the call is
 proceeding (where permitted by the ISUP variant in question).
 All redirection situations have to be treated very carefully because
 they involved special charging situations.  In PSTN the caller
 typically pays for the first leg (to the gateway) and the callee pays
 the second (from the forwarding switch to the destination).

8.2.6 4xx-6xx Received

 When a response code of 400 or greater is received by the gateway,
 then the INVITE previously sent by the gateway has been rejected.
 Under most circumstances the gateway SHOULD release the resources in
 the gateway, send a REL to the PSTN with a cause value and send an

Camarillo, et. al. Standards Track [Page 44] RFC 3398 ISUP to SIP Mapping December 2002

 ACK to the SIP network.  Some specific circumstances are identified
 below in which a gateway MAY attempt to rectify a SIP-specific
 problem communicated by a status code without releasing the call by
 retrying the request.  When a REL is sent to the PSTN, the gateway
 expects the arrival of an RLC indicating that the release sequence is
 complete.

8.2.6.1 SIP Status Code to ISDN Cause Code Mapping

 When a REL message is generated due to a SIP rejection response that
 contains an encapsulated REL message, the Cause Indicator (CAI)
 parameter in the generated REL SHOULD be set to the value of the CAI
 parameter received in the encapsulated REL.  If no encapsulated ISUP
 is present, the mapping below between status code and cause codes are
 RECOMMENDED.
 Any SIP status codes not listed below (associated with SIP
 extensions, versions of SIP subsequent to the issue of this document,
 or simply omitted) should be mapping to cause code 31 "Normal,
 unspecified".  These mappings cover only responses; note that the BYE
 and CANCEL requests, which are also used to tear down a dialog,
 SHOULD be mapped to 16 "Normal clearing" under most circumstances
 (although see Section 5.8).
 By default, the cause location associated with the CAI parameter
 should be encoded such that 6xx codes are given the location 'user',
 whereas 4xx and 5xx codes are given a 'network' location.  Exceptions
 are marked below.

Camarillo, et. al. Standards Track [Page 45] RFC 3398 ISUP to SIP Mapping December 2002

 Just as there are certain ISDN cause codes that are ISUP-specific and
 have no corollary SIP action, so there are SIP status codes that
 should not simply be translated to ISUP - some SIP-specific action
 should be attempted first.  See the note on the (+) tag below.
 Response received                     Cause value in the REL
 -----------------                     ----------------------
 400 Bad Request                       41 Temporary Failure
 401 Unauthorized                      21 Call rejected (*)
 402 Payment required                  21 Call rejected
 403 Forbidden                         21 Call rejected
 404 Not found                          1 Unallocated number
 405 Method not allowed                63 Service or option
                                          unavailable
 406 Not acceptable                    79 Service/option not
                                          implemented (+)
 407 Proxy authentication required     21 Call rejected (*)
 408 Request timeout                  102 Recovery on timer expiry
 410 Gone                              22 Number changed
                                          (w/o diagnostic)
 413 Request Entity too long          127 Interworking (+)
 414 Request-URI too long             127 Interworking (+)
 415 Unsupported media type            79 Service/option not
                                          implemented (+)
 416 Unsupported URI Scheme           127 Interworking (+)
 420 Bad extension                    127 Interworking (+)
 421 Extension Required               127 Interworking (+)
 423 Interval Too Brief               127 Interworking (+)
 480 Temporarily unavailable           18 No user responding
 481 Call/Transaction Does not Exist   41 Temporary Failure
 482 Loop Detected                     25 Exchange - routing error
 483 Too many hops                     25 Exchange - routing error
 484 Address incomplete                28 Invalid Number Format (+)
 485 Ambiguous                          1 Unallocated number
 486 Busy here                         17 User busy
 487 Request Terminated               --- (no mapping)
 488 Not Acceptable here              --- by Warning header
 500 Server internal error             41 Temporary failure
 501 Not implemented                   79 Not implemented, unspecified
 502 Bad gateway                       38 Network out of order
 503 Service unavailable               41 Temporary failure
 504 Server time-out                  102 Recovery on timer expiry
 504 Version Not Supported            127 Interworking (+)
 513 Message Too Large                127 Interworking (+)
 600 Busy everywhere                   17 User busy
 603 Decline                           21 Call rejected
 604 Does not exist anywhere            1 Unallocated number
 606 Not acceptable                   --- by Warning header

Camarillo, et. al. Standards Track [Page 46] RFC 3398 ISUP to SIP Mapping December 2002

 (*) In some cases, it may be possible for a SIP gateway to provide
 credentials to the SIP UAS that is rejecting an INVITE due to
 authorization failure.  If the gateway can authenticate itself, then
 obviously it SHOULD do so and proceed with the call; only if the
 gateway cannot authenticate itself should cause code 21 be sent.
 (+) If at all possible, a SIP gateway SHOULD respond to these
 protocol errors by remedying unacceptable behavior and attempting to
 re-originate the session.  Only if this proves impossible should the
 SIP gateway fail the ISUP half of the call.
 When the Warning header is present in a SIP 606 or 488 message, there
 may be specific ISDN cause code mappings appropriate to the Warning
 code.  This document recommends that '31 Normal, unspecified' SHOULD
 by default be used for most currently assigned Warning codes.  If the
 Warning code speaks to an unavailable bearer capability, cause code
 '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping.

8.2.7 REL Received

 This circumstance generally arises when the user on the PSTN side
 hangs up before the call has been answered; the gateway therefore
 aborts the establishment of the session.  A CANCEL request MUST be
 issued (a BYE is not used, since no final response has arrived from
 the SIP side).  A 200 OK for the CANCEL can be expected by the
 gateway, and finally a 487 for the INVITE arrives (which the gateway
 ACKs in turn).
 The gateway SHOULD store state information related to this dialog for
 a certain period of time, since a 200 final response for the INVITE
 originally sent might arrive (even after the reception of the 200 OK
 for the CANCEL).  In this situation, the gateway MUST send an ACK
 followed by an appropriate BYE request.
 In SIP bridging situations, the REL message cannot be encapsulated in
 a CANCEL message (since CANCEL cannot have a message body).  Usually,
 the REL message will contain a CAI value of 16 "Normal clearing".  If
 the value is other than a 16, the gateway MAY wish to use some other
 means of communicating the cause value (see Section 5.8).

8.2.8 ISUP T11 Expires

 In order to prevent the remote ISUP node's timer T7 from expiring,
 the gateway MAY keep its own supervisory timer; ISUP defines this
 timer as T11.  T11's duration is carefully chosen so that it will
 always be shorter than the T7 of any node to which the gateway is
 communicating.

Camarillo, et. al. Standards Track [Page 47] RFC 3398 ISUP to SIP Mapping December 2002

 To clarify timer T11's relevance with respect to SIP interworking,
 Q.764 [12] explains its use as: "If in normal operation, a delay in
 the receipt of an address complete signal from the succeeding network
 is expected, the last common channel signaling exchange will
 originate and send an address complete message 15 to 20 seconds
 [timer (T11)] after receiving the latest address message." Since SIP
 nodes have no obligation to respond to an INVITE request within 20
 seconds,  SIP interworking inarguably qualifies as such a situation.
 If the gateway supports this optional mechanism, then if its T11
 expires, it SHOULD send an early ACM (i.e., called party status set
 to "no indication") to prevent the expiration of the remote node's T7
 (where permitted by the ISUP variant).  See Section 8.2.3 for the
 value of the ACM parameters.
 If a "180 Ringing" message arrives subsequently, it SHOULD be sent in
 a CPG, as shown in Section 8.2.3.
 See Section 8.1.3 for an example callflow that includes the
 expiration of T11.

9. Suspend/Resume and Hold

9.1 Suspend (SUS) and Resume (RES) Messages

 In ISDN networks, a user can generate a SUS (timer T2, user
 initiated) in order to unplug the terminal from the socket and plug
 it in another one.  A RES is sent once the terminal has been
 reconnected and the T2 timer has not expired.  SUS is also frequently
 used to signaling an on-hook state for a remote terminal before
 timers leading to the transmission of a REL message are sent (this is
 the more common case by far).  While a call is suspended, no audio
 media is passed end-to-end.
 When a SUS is sent for a call that has a SIP leg, a gateway MAY
 suspend IP media transmission until a RES is received.  Putting the
 media on hold insures that bandwidth is conserved when no audio
 traffic needs to be transmitted.
 If media suspension is appropriate, then when a SUS arrives from the
 PSTN, the MGC MAY send an INVITE to request that the far-end's
 transmission of the media stream be placed on hold.  The subsequent
 reception of a RES from the PSTN SHOULD then trigger a re-INVITE that
 requests the resumption of the media stream.  Note that the MGC may
 or may not elect to stop transmitting any media itself when it
 requests the cessation of far-end transmission.

Camarillo, et. al. Standards Track [Page 48] RFC 3398 ISUP to SIP Mapping December 2002

 If media suspension is not required by the MGC receiving the SUS from
 the PSTN, the SIP INFO [6] method MAY be used to transmit an
 encapsulated SUS rather than a re-INVITE.  Note that the recipient of
 such an INFO request may be a simple SIP phone that does not
 understand ISUP (and would therefore take no action on receipt of
 this message); if a prospective destination for an INFO-encapsulated
 SUS has not used encapsulated ISUP in any messages it has previously
 sent, the gateway SHOULD NOT relay the INFO method, but rather should
 handle the SUS and the corresponding RES without signaling their
 arrival to the SIP network.
 In any case, subsequent RES messages MUST be transmitted in the same
 method that was used for the corresponding SUS (i.e., if an INFO is
 used for a SUS, INFO should also be used for the subsequent RES).
 Regardless of whether the INFO or re-INVITE mechanism is used to
 carry a SUS message, neither has any implication that the originating
 side will cease sending IP media.  The recipient of an encapsulated
 SUS message MAY therefore elect to send a re-INVITE themselves to
 suspend media transmission from the MGC side if desired.
 The following example uses the INVITE mechanism. Note that this flow
 is informative, not proscriptive; compliant gateways are free to
 implement functionally equivalent flows, as described in the
 preceding paragraphs.
      SIP                       MGC/MG                       PSTN
        |                          |<-----------SUS-----------|1
       2|<--------INVITE-----------|                          |
       3|-----------200----------->|                          |
       4|<----------ACK------------|                          |
        |                          |<-----------RES-----------|5
       6|<--------INVITE-----------|                          |
       7|-----------200----------->|                          |
       8|<----------ACK------------|                          |
 The handling of a network-initiated SUS immediately prior to call
 teardown is handled in Section 10.2.2.

Camarillo, et. al. Standards Track [Page 49] RFC 3398 ISUP to SIP Mapping December 2002

9.2 Hold (re-INVITE)

 After a call has been connected, a re-INVITE could be sent to a
 gateway from the SIP side in order to place the call on hold.  This
 re-INVITE will have an SDP offer indicating that the originator of
 the re-INVITE no longer wishes to receive media.
      SIP                       MGC/MG                       PSTN
       1|---------INVITE---------->|                          |
        |                          |------------CPG---------->|2
       3|<----------200------------|                          |
       4|-----------ACK----------->|                          |
 When such a re-INVITE is received, the gateway SHOULD send a CPG in
 order to express that the call has been placed on hold.  The CPG
 SHOULD contain a Generic Notification Indicator (or, in ANSI
 networks, a Notification Indicator) with a value of 'remote hold'.
 If, subsequent to the sending of the re-INVITE, the SIP side wishes
 to take the remote end off hold and begin receiving media again, it
 SHOULD repeat the flow above with an INVITE that contains an SDP
 offer with an appropriate media destination.  The Generic
 Notification Indicator would in this instance have a value of 'remote
 retrieval' (or in some variants 'remote hold released').
 Finally, note that a CPG with hold indicators may be received by a
 gateway from the PSTN.  In the interests of conserving bandwidth, the
 gateway SHOULD stop sending media until the call is resumed and
 SHOULD send a re-INVITE to the SIP leg of the call requesting that
 the remote side stop sending media.

10. Normal Release of the Connection

 From the perspective of a gateway, either the SIP side or the ISUP
 side can release a call, regardless of which side initiated the call.
 Note that cancellation of a call setup request (either from the ISUP
 or SIP side) is discussed elsewhere in this document (in Section
 8.2.7 and Section 7.2.3, respectively).
 Gateways SHOULD implement functional equivalence with the flows in
 this section.

10.1 SIP initiated release

 For a normal termination of the dialog (receipt of a BYE request),
 the gateway MUST immediately send a 200 response.  The gateway then
 MUST release any media resources in the gateway (DSPs, TCIC locks,
 and so on) and send an REL with a cause code of 16 (normal call

Camarillo, et. al. Standards Track [Page 50] RFC 3398 ISUP to SIP Mapping December 2002

 clearing) to the PSTN.  Release of resources is confirmed by the PSTN
 side with an RLC message.
 In SIP bridging situations, the cause code of any REL encapsulated in
 the BYE request SHOULD be re-used in any REL that the gateway sends
 to the PSTN.
      SIP                       MGC/MG                       PSTN
       1|-----------BYE----------->|                          |
        |            ** MG Releases IP Resources **           |
       2|<----------200------------|                          |
        |             ** MG Releases PSTN Trunk **            |
        |                          |------------REL---------->|3
        |                          |<-----------RLC-----------|4

10.2 ISUP initiated release

 If the release of the connection was caused by the reception of a
 REL, the REL SHOULD be encapsulated in the BYE sent by the gateway.
 Whether the caller or callee hangs up first, the gateway SHOULD
 release any internal resources used in support of the call and then
 MUST confirm that the circuit is ready for re-use by sending an RLC.

10.2.1 Caller hangs up

 When the caller hangs up, the SIP dialog MUST be terminated by
 sending a BYE request (which is confirmed with a 200).
      SIP                       MGC/MG                       PSTN
        |                          |<-----------REL-----------|1
        |             ** MG Releases PSTN Trunk **            |
        |                          |------------RLC---------->|2
       3|<----------BYE------------|                          |
        |            ** MG Releases IP Resources **           |
       4|-----------200----------->|                          |

Camarillo, et. al. Standards Track [Page 51] RFC 3398 ISUP to SIP Mapping December 2002

10.2.2 Callee hangs up (SUS)

 In some PSTN scenarios, if the callee hangs up in the middle of a
 call, the local exchange sends a SUS instead of a REL and starts a
 timer (T6, SUS is network initiated).  When the timer expires, the
 REL is sent.  This necessitates a slightly different SIP flow; see
 Section 9 for more information on handling suspension.  It is
 RECOMMENDED that gateways implement functional equivalence with the
 following flow for this case:
      SIP                       MGC/MG                       PSTN
        |                          |<-----------SUS-----------|1
       2|<--------INVITE-----------|                          |
       3|-----------200----------->|                          |
       4|<----------ACK------------|                          |
        |                          |    *** T6 Expires ***    |
        |                          |<-----------REL-----------|5
        |             ** MG Releases PSTN Trunk **            |
        |                          |------------RLC---------->|6
       7|<----------BYE------------|                          |
        |            ** MG Releases IP Resources **           |
       8|-----------200----------->|                          |

11. ISUP Maintenance Messages

 ISUP contains a set of messages used for maintenance purposes.  They
 can be received during any ongoing call.  There are basically two
 kinds of maintenance messages (apart from the continuity check):
 messages for blocking circuits and messages for resetting circuits.

11.1 Reset messages

 Upon reception of an RSC message for a circuit currently being used
 by the gateway for a call, the call MUST be released immediately
 (this typically results from a serious maintenance condition).  RSC
 MUST be answered with an RLC after resetting the circuit in the
 gateway.  Group reset (GRS) messages which target a range of circuits
 are answered with a Circuit Group Reset ACK Message (GRA) after
 resetting all the circuits affected by the message.
 The gateways SHOULD behave as if a REL had been received in order to
 release the dialog on the SIP side.  A BYE or a CANCEL are sent
 depending of the status of the call.  See the procedures in Section
 10.

Camarillo, et. al. Standards Track [Page 52] RFC 3398 ISUP to SIP Mapping December 2002

11.2 Blocking messages

 There are two kinds of blocking messages: maintenance messages or
 hardware-failure messages.  Maintenance blocking messages indicate
 that the circuit is to be blocked for any subsequent calls, but these
 messages do not affect any ongoing call.  This allows circuits to be
 gradually quiesced and taken out of service for maintenance.
 Hardware-oriented blocking messages have to be treated as reset
 messages.  They generally are sent only when a hardware failure has
 occurred.  Media transmission for all calls in progress on these
 circuits would be affected by this hardware condition, and therefore
 all calls must be released immediately.
 BLO is always maintenance oriented and it is answered by the gateway
 with a Blocking ACK Message (BLA) when the circuit is blocked - this
 requires no corresponding SIP actions.  Circuit Group Blocking (CGB)
 messages have a "type indicator" inside the Circuit Group Supervision
 Message Type Indicator.  It indicates if the CGB is maintenance or
 hardware failure oriented.  If the CGB results from a hardware
 failure, then each call in progress in the affected range of circuits
 MUST be terminated immediately as if a REL had been received,
 following the procedures in Section 10.  CGBs MUST be answered with
 CGBAs.

11.3 Continuity Checks

 A continuity check is a test performed on a circuit that involves the
 reflection of a tone generated at the originating switch by a
 loopback at the destination switch.  Two variants of the continuity
 check appear in ISUP: the implicit continuity check request within an
 IAM (in which case the continuity check takes place as a precondition
 before call setup begins), and the explicit continuity check signaled
 by a Continuity Check Request (CCR) message.  PSTN gateways in
 regions that support continuity checking generally SHOULD have some
 way of accommodating these tests (if they hope to be fielded by
 providers that interconnect with any major carrier).
 When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT
 send any corresponding SIP messages; the scope of the continuity
 check applies only to the PSTN trunks, not to any IP media paths
 beyond the gateway.  CCR messages also do not designate any called
 party number, or any other way to determine what SIP user agent
 server should be reached.
 When an IAM with the Continuity Check Indicator flag set within the
 NCI parameter is received, the gateway MUST process the continuity
 check before sending an INVITE message (and proceeding normally with

Camarillo, et. al. Standards Track [Page 53] RFC 3398 ISUP to SIP Mapping December 2002

 call setup); if the continuity check fails (a COT with Continuity
 Indicator of 'failed' is received), then an INVITE MUST NOT be sent.

12. Construction of Telephony URIs

 SIP proxy servers MAY route SIP messages on any signaling criteria
 desired by network administrators, but generally the Request-URI is
 the foremost routing criterion.  The To and From headers are also
 frequently of interest in making routing decisions.  SIP-ISUP mapping
 assumes that proxy servers are interested in at least these three
 fields of SIP messages, all of which contain URIs.
 SIP-ISUP mapping frequently requires the representation of telephone
 numbers in these URIs.  In some instances these numbers will be
 presented first in ISUP messages, and SS7-SIP gateways will need to
 translate the ISUP formats of these numbers into SIP URIs.  In other
 cases the reverse transformation will be required.
 The most common format used in SIP for the representation of
 telephone numbers is the tel URL [7].  When converting between
 formats, the tel URL MAY constitute the entirety of a URI field in a
 SIP message, or it MAY appear as the user portion of a SIP URI.  For
 example, a To field might appear as:
 To: tel:+17208881000
 Or
 To: sip:+17208881000@level3.com
 Whether or not a particular gateway or endpoint should formulate URIs
 in the tel or SIP format is a matter of local administrative policy -
 if the presence of a host portion would aid the surrounding network
 in routing calls, the SIP format should be used.  A gateway MUST
 accept either tel or SIP URIs from its peers.
 The '+' sign preceding the number in tel URLs indicates that the
 digits which follow constitute a fully-qualified E.164 [16] number;
 essentially, this means that a country code is provided before any
 national-specific area codes, exchange/city codes, or address codes.
 The absence of a '+' sign MAY signify that the number is merely
 nationally significant, or perhaps that a private dialing plan is in
 use.  When the '+' sign is not present, but a telephone number is
 represented by the user portion of the URI, the SIP URI SHOULD
 contain the optional ';user=phone' parameter; e.g.,
 To: sip:83000@sip.example.net;user=phone

Camarillo, et. al. Standards Track [Page 54] RFC 3398 ISUP to SIP Mapping December 2002

 However, it is strongly RECOMMENDED that only internationally
 significant E.164 numbers be passed between SIP-T gateways,
 especially when such gateways are in different regions or different
 administrative domains.  In many if not most SIP-T networks, gateways
 are not responsible for end-to-end routing of SIP calls; practically
 speaking, gateways have no way of knowing if the call will terminate
 in a local or remote administrative domain and/or region, and hence
 gateways SHOULD always assume that calls require an international
 numbering plan.  There is no guarantee that recipients of SIP
 signaling will be capable of understanding national dialing plans
 used by the originators of calls - if the originating gateway does
 not internationalize the signaling, the context in which the digits
 were dialed cannot be extrapolated by far-end network elements.
 In ISUP signaling, a telephone number appears in a common format that
 is used in several parameters, including the CPN and CIN; when it
 represents a calling party number it sports some additional
 information (detailed below).  For the purposes of this document, we
 will refer to this format as 'ISUP format' - if the additional
 calling party information is present, the format shall be referred to
 as 'ISUP- calling format'.  The format consists of a byte called the
 Nature of Address (NoA) indicator, followed by another byte which
 contains the Numbering Plan Indicator (NPI), both of which are
 prefixed to a variable-length series of bytes that contains the
 digits of the telephone number in Binary Coded Decimal (BCD) format.
 In the calling party number case, the NPI's byte also contains bit
 fields which represent the caller's presentation preferences and the
 status of any call screening checks performed up until this point in
 the call.
      H G F E D C B A       H G F E D C B A
     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
     | |    NoA      |     | |    NoA      |
     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
     | | NPI | spare |     | | NPI |PrI|ScI|
     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
     | dig...| dig 1 |     | dig...| dig 1 |
     |      ...      |     |      ...      |
     | dig n | dig...|     | dig n | dig...|
     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
       ISUP format        ISUP calling format
            ISUP numbering formats
 The NPI field is generally set to the value 'ISDN (Telephony)
 numbering plan (Recommendation E.164)', but this does not mean that
 the digits which follow necessarily contain a country code; the NoA

Camarillo, et. al. Standards Track [Page 55] RFC 3398 ISUP to SIP Mapping December 2002

 field dictates whether the telephone number is in a national or
 international format.  When the represented number is not designated
 to be in an international format, the NoA generally provides
 information specific to the national dialing plan - based on this
 information one can usually determine how to convert the number in
 question into an international format.  Note that if the NPI contains
 a value other than 'ISDN numbering plan', then the tel URL may not be
 suitable for carrying the address digits, and the handling for such
 calls is outside the scope of this document.

12.1 ISUP format to tel URL mapping

 Based on the above, conversion from ISUP format to a tel URL is as
 follows.  First, provided that the NPI field indicates that the
 telephone number format uses E.164, the NoA is consulted.  If the NoA
 indicates that the number is an international number, then the
 telephone number digits SHOULD be appended unmodified to a 'tel:+'
 string.  If the NoA has the value 'national (significant) number',
 then a country code MUST be prefixed to the telephone number digits
 before they are committed to a tel URL; if the gateway performing
 this conversion interconnects with switches homed to several
 different country codes, presumably the appropriate country code
 SHOULD be chosen based on the originating switch or trunk group.  If
 the NoA has the value 'subscriber number', both a country code and
 any other numbering components necessary for the numbering plan in
 question (such as area codes or city codes) MAY need to be added in
 order for the number to be internationally significant - however,
 such procedures vary greatly from country to country, and hence they
 cannot be specified in detail here.  Only if a country or network-
 specific value is used for the NoA SHOULD a tel URL not include a '+'
 sign; in these cases, gateways SHOULD simply copy the provided digits
 into the tel URL and append a 'user=phone' parameter if a SIP URI
 format is used.  Any non-standard or proprietary mechanisms used to
 communicate further context for the call in ISUP are outside the
 scope of this document.
 If a nationally-specific parameter is present that allows for the
 transmission of the calling party's name (such as the Generic Name
 Parameter in ANSI), then generally, if presentation is not
 restricted, this information SHOULD be used to populate the display-
 name portion of the From field.

Camarillo, et. al. Standards Track [Page 56] RFC 3398 ISUP to SIP Mapping December 2002

 If ISUP calling format is being converted rather than ISUP format,
 then two additional pieces of information must be taken into account:
 presentation indicators and screening indicators.  If the
 presentation indicators are set to 'presentation restricted', then a
 special URI is created by the gateway which communicates to the far
 end that the caller's identity has been omitted.  This URI SHOULD be
 a SIP URI with a display-name and username of 'Anonymous', e.g.:
 From: Anonymous <sip:anonymous@anonymous.invalid>
 For further information about privacy in SIP, see Section 5.7.
 If presentation is set to 'address unavailable', then gateways should
 treat the IAM as if the CIN parameter was omitted.  Screening
 indicators should not be translated, as they are only meaningful
 end-to-end.

12.2 tel URL to ISUP format mapping

 Conversion from tel URLs to ISUP format is simpler.  If the URI is in
 international format, then the gateway SHOULD consult the leading
 country code of the URI.  If the country code is local to the gateway
 (the gateway has one or more trunks that point to switches which are
 homed to the country code in question), the gateway SHOULD set the
 NoA to reflect 'national (significant) number' and strip the country
 code from the URI before populating the digits field.  If the country
 code is not local to the gateway, the gateway SHOULD set the NoA to
 'international number' and retain the country code.  In either case
 the NPI MUST be set to 'ISDN numbering plan'.
 If the URI is not in international format, the gateway MAY attempt to
 treat the telephone number within the URI as if it were appropriate
 to its national or network-specific dialing plan; if doing so gives
 rise to internal gateway errors or the gateway does not support such
 procedures, then the gateway SHOULD respond with appropriate SIP
 status codes to express that the URI could not be understood (if the
 URI in question is the Request-URI, a 484).
 When converting from a tel URL to ISUP calling format, the procedure
 is identical to that described in the preceding paragraphs, but
 additionally, the presentation indicator SHOULD be set to
 'presentation allowed' and the screening indicator to 'network
 provided', unless some service provider policy or user profile
 specifically disallows presentation.

Camarillo, et. al. Standards Track [Page 57] RFC 3398 ISUP to SIP Mapping December 2002

13. Other ISUP flavors

 Other flavors of ISUP different than ITU-T ISUP have different
 parameters and more features.  Some of the parameters have more
 possible values and provide more information about the status of the
 call.
 The Circuit Query Message (CQM) and Circuit Query Response (CQR) are
 used in many ISUP variants.  These messages have no analog in SIP,
 although receipt of a CQR may cause state reconciliation if the
 originating and destination switches have become desynchronized; as
 states are reconciled some calls may be terminated, which may cause
 SIP or ISUP messages to be sent (as described in Section 10).
 However, differences in the message flows are more important.  In
 ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent
 instead (when no ACM has been sent before the call is answered).  In
 call forwarding situations, CPGs MAY be sent before the ACM is sent.
 SAMs MUST NOT be sent; 'en-bloc' signaling is always used.  The ANSI
 Exit Message (EXM) SHOULD NOT result in any SIP signaling in
 gateways.  ANSI also uses the Circuit Reservation Message (CRM) and
 Circuit Reservation Acknowledgment (CRA) as part of its interworking
 procedures - in the event that an MGC does receive a CRM, a CRA
 SHOULD be sent in return (in some implementations, transmissions of a
 CRA could conceivably be based on a resource reservation system);
 after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and
 process it normally.  Any further circuit reservation mechanism is
 outside the scope of this document.
 Although receipt of a Confusion (CFN) message is an indication of a
 protocol error, corresponding SIP messages SHOULD NOT be sent on
 receipt of a CFN - the CFN should be handled with ISUP-specific
 procedures by the gateway (usually by retransmission of the packet to
 which the CFN responded).  Only if ISUP procedures fails repeatedly
 should this cause a SIP error condition (and call failure) to arise.
 In TTC ISUP CPGs MAY be sent before the ACM is sent.  Messages such
 as a Charging Information Message (CHG) MAY be sent between ACM and
 ANM.  'En-bloc' signaling is always used and there is no T9 timer.

13.1 Guidelines for sending other ISUP messages

 Some ISUP variants send more messages than the ones described in this
 document.  Therefore, some guidelines are provided here with regard
 to transport and mapping of these ISUP message.

Camarillo, et. al. Standards Track [Page 58] RFC 3398 ISUP to SIP Mapping December 2002

 From the caller to the callee, other ISUP messages SHOULD be
 encapsulated (see [3]) inside INFO messages, even if the INVITE
 transaction is still not finished.  Note that SIP does not ensure
 that INFO requests are delivered in order, and therefore in adverse
 network conditions an egress gateway might process INFOs out of
 order.  This issue, however, does not represent an important problem
 since it is not likely to happen and its effects are negligible in
 most of the situations.  The Information (INF) message and
 Information Response (INR) are examples of messages that should be
 encapsulated within an INFO.  Gateway implementers might also
 consider building systems that wait for each INFO transaction to
 complete before initiating a new INFO transaction.
 From the callee to the caller, if a message is received by a gateway
 before the call has been answered (i.e., ANM is received) it SHOULD
 be encapsulated in an INFO, provided that this will not be the first
 SIP message sent in the backwards direction (in which case it SHOULD
 be encapsulated in a provisional 1xx response).  Similarly a message
 which is received on the originating side (probably in response to an
 INR) before a 200 OK has been received by the gateway should be
 carried within an INFO.  In order for this mechanism to function
 properly in the forward direction, any necessary Contact or To-tag
 must have appeared in a previous provisional response or the message
 might not be correctly routed to its destination.  As such all SIP-T
 gateways MUST send all provisional responses with a Contact header
 and any necessary tags in order to enable proper routing of new
 requests issued before a final response has been received.  When the
 INVITE transaction is finished INFO requests SHOULD also be used in
 this direction.

Camarillo, et. al. Standards Track [Page 59] RFC 3398 ISUP to SIP Mapping December 2002

14. Acronyms

 ACK                Acknowledgment
 ACM                Address Complete Message
 ANM                Answer Message
 ANSI               American National Standards Institute
 BLA                Blocking ACK message
 BLO                Blocking Message
 CGB                Circuit Group Blocking Message
 CGBA               Circuit Group Blocking ACK Message
 CHG                Charging Information Message
 CON                Connect Message
 CPG                Call Progress Message
 CUG                Closed User Group
 GRA                Circuit Group Reset ACK Message
 GRS                Circuit Group Reset Message
 HLR                Home Location Register
 IAM                Initial Address Message
 IETF               Internet Engineering Task Force
 IP                 Internet Protocol
 ISDN               Integrated Services Digital Network
 ISUP               ISDN User Part
 ITU-T              International Telecommunication Union
                    Telecommunication Standardization Sector
 MG                 Media Gateway
 MGC                Media Gateway Controller
 MTP                Message Transfer Part
 REL                Release Message
 RES                Resume Message
 RLC                Release Complete Message
 RTP                Real-time Transport Protocol
 SCCP               Signaling Connection Control Part
 SG                 Signaling Gateway
 SIP                Session Initiation Protocol
 SS7                Signaling System No. 7
 SUS                Suspend Message
 TTC                Telecommunication Technology Committee
 UAC                User Agent Client
 UAS                User Agent Server
 UDP                User Datagram Protocol
 VoIP               Voice over IP

15. Security Considerations

 The translation of ISUP parameters into SIP headers may introduce
 some privacy and security concerns above and beyond those that have
 been identified for other functions of SIP-T [9A].  Merely securing
 encapsulated ISUP, for example, would not provide adequate privacy

Camarillo, et. al. Standards Track [Page 60] RFC 3398 ISUP to SIP Mapping December 2002

 for a user requesting presentation restriction if the Calling Party
 Number parameter is openly mapped to the From header.  Section 12.2
 shows how SIP Privacy [9B] should be used for this function.  Since
 the scope of SIP-ISUP mapping has been restricted to only those
 parameters that will be translated into the headers and fields used
 to route SIP requests, gateways consequently reveal through
 translation the minimum possible amount of information.
 A security analysis of ISUP is beyond the scope of this document.
 ISUP bridging across SIP is discussed more fully in [9A], but Section
 7.2.1.1 discusses processing the translated ISUP values in relation
 to any embedded ISUP in a request arriving at PSTN gateway.  Lack of
 ISUP security analysis may pose some risks if embedded ISUP is
 blindly interpreted.  Accordingly, gateways SHOULD NOT blindly trust
 embedded ISUP unless the request was strongly authenticated [9A], and
 the sender is trusted, e.g., is another MGC that is authorized to use
 ISUP over SIP in bridge mode.  When requests are received from
 arbitrary end points, gateways SHOULD filter any received ISUP.  In
 particular, only known-safe commands and parameters should be
 accepted or passed through.  Filtering by deleting believed-to-be
 dangerous entries does not work well.
 In most respects, the information that is translated from ISUP to SIP
 has no special security requirements.  In order for translated
 parameters to be used to route requests, they should be legible to
 intermediaries; end-to-end confidentiality of this data would be
 unnecessary and most likely detrimental.  There are also numerous
 circumstances under which intermediaries can legitimately overwrite
 the values that have been provided by translation, and hence
 integrity over these headers is similarly not desirable.
 There are some concerns however that arise from the other direction
 of mapping, the mapping of SIP headers to ISUP parameters, which are
 enumerated in the following paragraphs.  When end users dial numbers
 in the PSTN today, their selections populate the telephone number
 portion of the Called Party Number parameter, as well as the digit
 portions of the Carrier Identification Code and Transit Network
 Selection parameters of an ISUP IAM.  Similarly, the tel URL and its
 optional parameters in the Request-URI of a SIP, which can be created
 directly by end users of a SIP device, map to those parameters at a
 gateway.  However, in the PSTN, policy can prevent the user from
 dialing certain (invalid or restricted) numbers, or selecting certain
 carrier identification codes.  Thus, gateway operators MAY wish to
 use corresponding policies to restrict the use of certain tel URLs,
 or tel URL parameters, when authorizing a call.

Camarillo, et. al. Standards Track [Page 61] RFC 3398 ISUP to SIP Mapping December 2002

 The fields relevant to number portability, which include in ANSI ISUP
 the LRN portion of the Generic Address Parameter and the 'M' bit of
 the Forward Call Indicators, are used to route calls in the PSTN.
 Since these fields are rendered as tel URL parameters in the SIP-ISUP
 mapping, users can set the value of these fields arbitrarily.
 Consequently, an end-user could change the end office to which a call
 would be routed (though if LRN value were chosen at random, it is
 more likely that it would prevent the call from being delivered
 altogether).  The PSTN is relatively resilient to calls that have
 been misrouted on account of local number portability, however.  In
 some networks, a REL message with some sort of "misrouted ported
 number" cause code is sent in the backwards direction when such a
 condition arises.  Alternatively, the PSTN switch to which a call was
 misrouted can forward the call along to the proper switch after
 making its own number portability query - this is an interim number
 portability practice that is still common in most segments of the
 PSTN that support portability.  It is not anticipated that end users
 will typically set these SIP fields, and the risks associated with
 allowing an adventurous or malicious user to set the LRN do not seem
 to be grave, but they should be noted by network operators.  The
 limited degree to which SIP signaling contributes to the interworking
 indicators of the Forward Call Indicators and Backward Call Indicator
 parameters incurs no foreseeable risks.
 Some additional risks may result from the SIP response code to ISUP
 Cause Code parameter mapping.  SIP user agents could conceivably
 respond to an INVITE from a gateway with any arbitrary SIP response
 code, and thus they can dictate (within the boundaries of the
 mappings supported by the gateway) the Q.850 cause code that will be
 sent by the gateway in the resulting REL message.  Generally
 speaking, the manner in which a call is rejected is unlikely to
 provide any avenue for fraud or denial of service - to the best
 knowledge of the authors there is no cause code identified in this
 document that would signal that some call should not be billed, or
 that the network should take critical resources off-line.  However,
 operators may want to scrutinize the set of cause codes that could be
 mapped from SIP response codes (listed in 7.2.6.1) to make sure that
 no undesirable network-specific behavior could result from operating
 a gateway supporting the recommended mappings.  In some cases,
 operators MAY wish to implement gateway policies that use alternative
 mappings, perhaps selectively based on authorization data.
 If the Request-URI and the To header field of a request received at a
 gateway differ, Section 7.2.1.1 recommends that the To header (if it
 is a telephone number) should map to the Original Called Number
 parameter, and the Request-URI to the Called Party Number parameter.
 However, the user can, at the outset of a request, select a To header
 field value that differs from the Request-URI; these two field values

Camarillo, et. al. Standards Track [Page 62] RFC 3398 ISUP to SIP Mapping December 2002

 are not required to be the same.  This essentially allows a user to
 set the ISUP Original Called Number parameter arbitrarily.  Any
 applications that rely on the Original Called Number for settlement
 purposes could be affected by this mapping recommendation.  It is
 anticipated that future SIP work in this space will arrive at a
 better general account of the re-targeting of SIP requests that may
 be applicable to the OCN mapping.
 The arbitrary population of the From header of requests by SIP user
 agents has some well-understood security implications for devices
 that rely on the From header as an accurate representation of the
 identity of the originator.  Any gateway that intends to use the From
 header to populate the called party's number parameter of an ISUP IAM
 message should authenticate the originator of the request and make
 sure that they are authorized to assert that calling number (or make
 use of some more secure method to ascertain the identity of the
 caller).  Note that gateways, like all other SIP user agents, MUST
 support Digest authentication as described in [1].
 There is another class of potential risk that is related to the cut-
 through of the backwards media path before the call is answered.
 Several practices described in this document recommend that a gateway
 signal an ACM when a called user agent returns a 18x provisional
 response code.  At that time, backwards media will be cut through
 end-to-end in the ISUP network, and it is possible for the called
 user agent then to play arbitrary audio to the caller for an
 indefinite period of time before transmitting a final response (in
 the form of a 2xx or higher response code).  There are conceivable
 respects in which this capability could be used illegitimately by the
 called user agent.  It is also however a useful feature to allow
 progress tones and announcements to be played in the backwards
 direction in the 'ACM sent' state (so that the caller won't be billed
 for calls that don't actually complete but for which failure
 conditions must be rendered to the user as in-band audio).  In fact,
 ISUP commonly uses this backwards cut-through capability in order to
 pass tones and announcements relating to the status of a call when an
 ISUP network interworks with legacy networks that are not capable of
 expressing Q.850 cause codes.
 It is the contention of the authors that SIP introduces no risks with
 regard to backwards media that do not exist in Q.931-ISUP mapping,
 but gateways implementers MAY develop an optional mechanism (possibly
 something that could be configured by an operator) that would cut off
 such 'early media' on a brief timer - it is unlikely that more than
 20 or 30 seconds of early media is necessary to convey status
 information about the call (see Section 7.2.6).  A more conservative
 approach would be to never cut through backwards media in the gateway
 until a 2xx final response has been received, provided that the

Camarillo, et. al. Standards Track [Page 63] RFC 3398 ISUP to SIP Mapping December 2002

 gateway implements some way of prevent clipping of the initial media
 associated with the call.
 Unlike a traditional PSTN phone, a SIP user agent can launch multiple
 simultaneous requests in order to reach a particular resource.  It
 would be trivial for a SIP user agent to launch 100 SIP requests at a
 100 port gateway, thereby tying up all of its ports.  A malicious
 user could choose to launch requests to telephone numbers that are
 known never to answer, which would saturate these resources
 indefinitely and potentially without incurring any charges.  Gateways
 therefore MAY support policies that restrict the number of
 simultaneous requests originating from the same authenticated source,
 or similar mechanisms to address this possible denial-of-service
 attack.

16. IANA Considerations

 This document introduces no new considerations for IANA.

17. Acknowledgments

 This document existed as an Internet-Draft for four years, and it
 received innumerable contributions from members of the various
 Transport Area IETF working groups that it called home (which
 included the MMUSIC, SIP and SIPPING WGs).  In particular, the
 authors would like to thank Olli Hynonen, Tomas Mecklin, Bill
 Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada,
 Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir,
 Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan
 Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter
 Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars
 Tovander, Al Varney and William T.  Marshall for their help and
 feedback on this document.  The authors would also like to thank
 ITU-T SG11 for their advice on ISUP procedures.

18. Normative References

 [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [2]  Bradner, S., "Key words for use in RFCs to indicate requirement
      levels", BCP 14, RFC 2119, March 1997.
 [3]  Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
      Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
      objects", RFC 3204, December 2001.

Camarillo, et. al. Standards Track [Page 64] RFC 3398 ISUP to SIP Mapping December 2002

 [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part Two: Media Types", RFC 2046, November
      1996.
 [5]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
      Telephony Tones and Telephony Signals", RFC 2833, May 2000.
 [6]  Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
 [7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
      2000.
 [8]  Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
 [9]  Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header
      Field for the Session Initiation Protocol", RFC 3326, December
      2002.
 [9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
      Telephones (SIP-T): Context and Architectures", BCP 63, RFC
      3372, September 2002.
 [9B] Peterson, J., "A Privacy Mechanism for the Session Initiation
      Protocol (SIP)", RFC 3323, November 2002.

19. Non-Normative References

 [10] International Telecommunications Union, "Application of the ISDN
      user part of CCITT Signaling System No. 7 for international ISDN
      interconnection", ITU-T Q.767, February 1991,
      <http://www.itu.int>.
 [11] American National Standards Institute, "Signaling System No. 7;
      ISDN User Part", ANSI T1.113, January 1995,
      <http://www.itu.int>.
 [12] International Telecommunications Union, "Signaling System No. 7;
      ISDN User Part Signaling procedures", ITU-T Q.764, December
      1999, <http://www.itu.int>.
 [13] International Telecommunications Union, "Abnormal conditions -
      Special release", ITU-T Q.118, September 1997,
      <http://www.itu.int>.
 [14] International Telecommunications Union, "Specifications of
      Signaling System No. 7 - ISDN supplementary services", ITU-T
      Q.737, June 1997, <http://www.itu.int>.

Camarillo, et. al. Standards Track [Page 65] RFC 3398 ISUP to SIP Mapping December 2002

 [15] International Telecommunications Union, "Usage of cause location
      in the Digital Subscriber Signaling System No. 1 and the
      Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998,
      <http://www.itu.int>.
 [16] International Telecommunications Union, "The international
      public telecommunications numbering plan", ITU-T E.164, May
      1997, <http://www.itu.int>.
 [17] International Telecommunications Union, "Formats and codes of
      the ISDN User Part of Signaling System No. 7", ITU-T Q.763,
      December 1999, <http://www.itu.int>.
 [18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
      Responses in SIP", RFC 3262, June 2002.
 [19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960,
      October 2000.
 [20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
      Method", RFC 3311, October 2002.
 [21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
      Number Portability and Freephone Service", Work in Progress.

Camarillo, et. al. Standards Track [Page 66] RFC 3398 ISUP to SIP Mapping December 2002

Authors' Addresses

 Gonzalo Camarillo
 Ericsson
 Advanced Signalling Research Lab.
 FIN-02420 Jorvas
 Finland
 Phone: +358 9 299 3371
 URI: http://www.ericsson.com/
 EMail: Gonzalo.Camarillo@Ericsson.com
 Adam Roach
 dynamicsoft
 5100 Tennyson Parkway
 Suite 1200
 Plano, TX  75024
 USA
 URI: sip:adam@dynamicsoft.com
 EMail: adam@dynamicsoft.com
 Jon Peterson
 NeuStar, Inc.
 1800 Sutter St
 Suite 570
 Concord, CA  94520
 USA
 Phone: +1 925/363-8720
 EMail: jon.peterson@neustar.biz
 URI: http://www.neustar.biz/
 Lyndon Ong
 Ciena
 10480 Ridgeview Court
 Cupertino, CA  95014
 USA
 URI: http://www.ciena.com/
 EMail: lyOng@ciena.com

Camarillo, et. al. Standards Track [Page 67] RFC 3398 ISUP to SIP Mapping December 2002

Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Camarillo, et. al. Standards Track [Page 68]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3398.txt · Last modified: 2002/12/05 17:14 (external edit)