Network Working Group                                       G. Camarillo
Internet-Draft                                                  Ericsson
Expires: December 30, 2002                                      A. Roach
                                                             dynamicsoft
                                                             J. Peterson
                                                                 NeuStar
                                                                  L. Ong
                                                                   Ciena
                                                               July 2002


                          ISUP to SIP Mapping
                       draft-ietf-sipping-isup-05

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 30, 2002.

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
   ISDN User Part (ISUP) of 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).




Camarillo, et al.       Expires December 30, 2002               [Page 1]


Internet-Draft             ISUP to SIP Mapping                 July 2002


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   2.      Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
   4.      Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.      SIP Mechanisms Required  . . . . . . . . . . . . . . . . . 10
   5.1     'Transparent' Transit of ISUP Messages . . . . . . . . . . 10
   5.2     Understanding MIME Multipart Bodies  . . . . . . . . . . . 10
   5.3     Transmission of DTMF Information . . . . . . . . . . . . . 10
   5.4     Reliable Transmission of Provisional Responses . . . . . . 11
   5.5     Early Media  . . . . . . . . . . . . . . . . . . . . . . . 11
   5.6     Mid-Call Transactions which do not change SIP state  . . . 11
   5.7     Privacy Protection . . . . . . . . . . . . . . . . . . . . 12
   5.8     CANCEL causes  . . . . . . . . . . . . . . . . . . . . . . 12
   6.      Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.      SIP to ISUP Mapping  . . . . . . . . . . . . . . . . . . . 15
   7.1     SIP to ISUP Call flows . . . . . . . . . . . . . . . . . . 15
   7.1.1   En-bloc Call Setup (no auto-answer)  . . . . . . . . . . . 15
   7.1.2   Auto-answer call setup . . . . . . . . . . . . . . . . . . 16
   7.1.3   ISUP T7 Expires  . . . . . . . . . . . . . . . . . . . . . 17
   7.1.4   SIP Timeout  . . . . . . . . . . . . . . . . . . . . . . . 18
   7.1.5   ISUP Setup Failure . . . . . . . . . . . . . . . . . . . . 19
   7.1.6   Cause Present in ACM Message . . . . . . . . . . . . . . . 20
   7.1.7   Call Canceled by SIP . . . . . . . . . . . . . . . . . . . 21
   7.2     State Machine  . . . . . . . . . . . . . . . . . . . . . . 22
   7.2.1   INVITE received  . . . . . . . . . . . . . . . . . . . . . 23
   7.2.1.1 INVITE to IAM procedures . . . . . . . . . . . . . . . . . 23
   7.2.2   ISUP T7 expires  . . . . . . . . . . . . . . . . . . . . . 27
   7.2.3   CANCEL or BYE received . . . . . . . . . . . . . . . . . . 27
   7.2.4   REL received . . . . . . . . . . . . . . . . . . . . . . . 27
   7.2.4.1 ISDN Cause Code to Status Code Mapping . . . . . . . . . . 28
   7.2.5   Early ACM received . . . . . . . . . . . . . . . . . . . . 31
   7.2.6   ACM received . . . . . . . . . . . . . . . . . . . . . . . 31
   7.2.7   CON or ANM Received  . . . . . . . . . . . . . . . . . . . 32
   7.2.8   Timer T9 Expires . . . . . . . . . . . . . . . . . . . . . 32
   7.2.9   CPG Received . . . . . . . . . . . . . . . . . . . . . . . 33
   7.3     ACK received . . . . . . . . . . . . . . . . . . . . . . . 33
   8.      ISUP to SIP Mapping  . . . . . . . . . . . . . . . . . . . 34
   8.1     ISUP to SIP Call Flows . . . . . . . . . . . . . . . . . . 34
   8.1.1   En-bloc call setup (non auto-answer) . . . . . . . . . . . 34
   8.1.2   Auto-answer call setup . . . . . . . . . . . . . . . . . . 35
   8.1.3   SIP Timeout  . . . . . . . . . . . . . . . . . . . . . . . 36
   8.1.4   ISUP T9 Expires  . . . . . . . . . . . . . . . . . . . . . 37
   8.1.5   SIP Error Response . . . . . . . . . . . . . . . . . . . . 38
   8.1.6   SIP Redirection  . . . . . . . . . . . . . . . . . . . . . 39
   8.1.7   Call Canceled by ISUP  . . . . . . . . . . . . . . . . . . 40
   8.2     State Machine  . . . . . . . . . . . . . . . . . . . . . . 41



Camarillo, et al.       Expires December 30, 2002               [Page 2]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   8.2.1   Initial Address Message received . . . . . . . . . . . . . 42
   8.2.1.1 IAM to INVITE procedures . . . . . . . . . . . . . . . . . 42
   8.2.2   100 received . . . . . . . . . . . . . . . . . . . . . . . 44
   8.2.3   18x received . . . . . . . . . . . . . . . . . . . . . . . 44
   8.2.4   2xx received . . . . . . . . . . . . . . . . . . . . . . . 46
   8.2.5   3xx Received . . . . . . . . . . . . . . . . . . . . . . . 46
   8.2.6   4xx-6xx Received . . . . . . . . . . . . . . . . . . . . . 47
   8.2.6.1 SIP Status Code to ISDN Cause Code Mapping . . . . . . . . 47
   8.2.7   REL Received . . . . . . . . . . . . . . . . . . . . . . . 49
   8.2.8   ISUP T11 Expires . . . . . . . . . . . . . . . . . . . . . 49
   9.      Suspend/Resume and Hold  . . . . . . . . . . . . . . . . . 51
   9.1     SUS and RES  . . . . . . . . . . . . . . . . . . . . . . . 51
   9.2     Hold (re-INVITE) . . . . . . . . . . . . . . . . . . . . . 52
   10.     Normal Release of the Connection . . . . . . . . . . . . . 53
   10.1    SIP initiated release  . . . . . . . . . . . . . . . . . . 53
   10.2    ISUP initiated release . . . . . . . . . . . . . . . . . . 53
   10.2.1  Caller hangs up  . . . . . . . . . . . . . . . . . . . . . 53
   10.2.2  Callee hangs up (SUS)  . . . . . . . . . . . . . . . . . . 54
   11.     ISUP Maintenance Messages  . . . . . . . . . . . . . . . . 55
   11.1    Reset messages . . . . . . . . . . . . . . . . . . . . . . 55
   11.2    Blocking messages  . . . . . . . . . . . . . . . . . . . . 55
   11.3    Continuity Checks  . . . . . . . . . . . . . . . . . . . . 56
   12.     Construction of Telephony URIs . . . . . . . . . . . . . . 57
   12.1    ISUP format to tel URL mapping . . . . . . . . . . . . . . 59
   12.2    tel URL to ISUP format mapping . . . . . . . . . . . . . . 60
   13.     Other ISUP flavors . . . . . . . . . . . . . . . . . . . . 61
   13.1    Guidelines for sending other ISUP messages . . . . . . . . 61
   14.     Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 63
   15.     Security Considerations  . . . . . . . . . . . . . . . . . 64
   16.     IANA Considerations  . . . . . . . . . . . . . . . . . . . 67
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 70
   A.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 71
           References . . . . . . . . . . . . . . . . . . . . . . . . 68
           References . . . . . . . . . . . . . . . . . . . . . . . . 69
   B.      Revision History . . . . . . . . . . . . . . . . . . . . . 72
           Full Copyright Statement . . . . . . . . . . . . . . . . . 75















Camarillo, et al.       Expires December 30, 2002               [Page 3]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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.

   ISUP [12] is a level 4 protocol used in SS7 networks.  It typically
   runs over 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 PSTN)
   and with IP interfaces (VoIP).  The MGC and the MG can be merged
   together in one physical box or kept separate.

   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.














Camarillo, et al.       Expires December 30, 2002               [Page 4]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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
   message 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.  ITU-T Q.767 International ISUP
   [10] is used through this document; some differences with ANSI [11]
   ISUP and TTC ISUP are outlined.  ISUP Q.767 is used in this document
   because it is the least complex of all the ISUP flavors.  Due to the
   small number of fields that map directly from ISUP to SIP, the
   signaling differences between Q.767 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 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-



Camarillo, et al.       Expires December 30, 2002               [Page 5]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 ACM and REL messages 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.










































Camarillo, et al.       Expires December 30, 2002               [Page 6]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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.












































Camarillo, et al.       Expires December 30, 2002               [Page 7]


Internet-Draft             ISUP to SIP Mapping                 July 2002


4. Scenarios

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

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




Camarillo, et al.       Expires December 30, 2002               [Page 8]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.

   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.



































Camarillo, et al.       Expires December 30, 2002               [Page 9]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

5.3 Transmission of 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].






Camarillo, et al.       Expires December 30, 2002              [Page 10]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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.

   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



Camarillo, et al.       Expires December 30, 2002              [Page 11]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

5.8 CANCEL causes

   There is a way in ISUP to signal that you like to discontinue an
   attempt to set up a call - the general-purpose RELease message 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
   exceptions 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



Camarillo, et al.       Expires December 30, 2002              [Page 12]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   reasons.  One mechanism that provides this capability is described in
   [9].

















































Camarillo, et al.       Expires December 30, 2002              [Page 13]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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 RLC, waiting for
   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.       Expires December 30, 2002              [Page 14]


Internet-Draft             ISUP to SIP Mapping                 July 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



Camarillo, et al.       Expires December 30, 2002              [Page 15]


Internet-Draft             ISUP to SIP Mapping                 July 2002


       both directions after step 8.

   5.  If the ISUP variant permits, the remote ISUP node may issue a
       variety of 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 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 CON message 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.



Camarillo, et al.       Expires December 30, 2002              [Page 16]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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


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.       Expires December 30, 2002              [Page 17]


Internet-Draft             ISUP to SIP Mapping                 July 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.       Expires December 30, 2002              [Page 18]


Internet-Draft             ISUP to SIP Mapping                 July 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.       Expires December 30, 2002              [Page 19]


Internet-Draft             ISUP to SIP Mapping                 July 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.       Expires December 30, 2002              [Page 20]


Internet-Draft             ISUP to SIP Mapping                 July 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.

   10.  Upon receipt of the 487, the SIP node will confirm reception



Camarillo, et al.       Expires December 30, 2002              [Page 21]


Internet-Draft             ISUP to SIP Mapping                 July 2002


        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.       Expires December 30, 2002              [Page 22]


Internet-Draft             ISUP to SIP Mapping                 July 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 draft).  Before sending an IAM
   the gateway SHOULD connect the backward media path (unless provider
   policy dictates that doing so is unsafe; see Section 15).

   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



Camarillo, et al.       Expires December 30, 2002              [Page 23]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   encapsulated ISUP.  Parameters that are only meaningful to the PSTN
   will be carried through PSTN-SIP- PSTN networks via encapsulation -
   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.
   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 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.

   If the optional number portability practices are supported by the



Camarillo, et al.       Expires December 30, 2002              [Page 24]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 is 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 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
   be confused with the MTP3 'circuit identification code') in the IAM -



Camarillo, et al.       Expires December 30, 2002              [Page 25]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 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 gateways 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 value of the FCI indicator parameter that is
   present in the message for all bits in the parameter related to
   interworking (unless interworking has been encountered somewhere else
   in the call path, these indicators will most likely state that no
   interworking was encountered).  If usable encapsulated ISUP is not
   present in an INVITE received by the gateway, it is RECOMMENDED that
   the set the 'interworking encountered' bit of the FCI to
   'interworking encountered' and set the two ISDN access parameters,
   the ISDN User Part Indicator and the Originating Access indicator, to
   state that ISDN is not available for the entire call path (values of
   'ISDN not used all the way' and 'Originating access non-ISDN',
   respectively).

   Note that when the ISUP parameters regarding interworking are set in
   the Forward Call Indicators (FCI) parameter of the IAM, this
   indicates that ISDN is interworking with a network which is not
   capable of providing as many services as ISDN does.  ISUP will
   therefore not employ certain features it otherwise normally uses.
   Gateway vendors therefore MAY provide a configurable option, usable
   at the discretion of service providers, that when encapsulated will
   signal in the FCI that no interworking has been encountered.  When
   ISUP feature transparency is available, `interworking encountered'



Camarillo, et al.       Expires December 30, 2002              [Page 26]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   MUST NOT be specified so that ISUP behaves normally.

   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 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 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 released before the gateway
   sends any REL message.

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.



Camarillo, et al.       Expires December 30, 2002              [Page 27]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 BLO or 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 Circuit Identification Code (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 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.




Camarillo, et al.       Expires December 30, 2002              [Page 28]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.

   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.




Camarillo, et al.       Expires December 30, 2002              [Page 29]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 something that will resolved 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

   Protocol error

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

   Interworking



Camarillo, et al.       Expires December 30, 2002              [Page 30]


Internet-Draft             ISUP to SIP Mapping                 July 2002


        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 `180 Ringing' 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 180 response.

   When it transmits a 180, the gateway also MAY begin to transmit early
   media in order to offer special announcements and tones played by the
   PSTN.  If the Backwards Call Indicator (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 an early media transmission SHOULD be initiation.
   Early media SHOULD also be transmitted sent if the Optional Backwards
   Call Indicator parameter field for in-band media is set.  For more
   information on early media see Section 5.5.




Camarillo, et al.       Expires December 30, 2002              [Page 31]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   When a 180 is sent without any early media, it is assumed that any
   necessary ringback tones will be generated by the SIP user agent to
   which the gateway is responding.

   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.

   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



Camarillo, et al.       Expires December 30, 2002              [Page 32]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

   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.











Camarillo, et al.       Expires December 30, 2002              [Page 33]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

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



Camarillo, et al.       Expires December 30, 2002              [Page 34]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.


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.       Expires December 30, 2002              [Page 35]


Internet-Draft             ISUP to SIP Mapping                 July 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.

   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.




Camarillo, et al.       Expires December 30, 2002              [Page 36]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.

   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.




Camarillo, et al.       Expires December 30, 2002              [Page 37]


Internet-Draft             ISUP to SIP Mapping                 July 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.  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.

   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.






Camarillo, et al.       Expires December 30, 2002              [Page 38]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

   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



Camarillo, et al.       Expires December 30, 2002              [Page 39]


Internet-Draft             ISUP to SIP Mapping                 July 2002


        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.

   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.



Camarillo, et al.       Expires December 30, 2002              [Page 40]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.


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.



























Camarillo, et al.       Expires December 30, 2002              [Page 41]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

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



Camarillo, et al.       Expires December 30, 2002              [Page 42]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 an 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 carrier identification code (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 he 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, or 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
      be stored in the CPN parameter, in which case they must be
      separately out into separate 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



Camarillo, et al.       Expires December 30, 2002              [Page 43]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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
        181 Call is being forwarded              Early ACM and CPG, event=6
        182 Queued                               ACM
        183 Session progress message             ACM

   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 18x response without any SDP, the gateway SHOULD
   generates the ringback tone to be heard by the caller on the PSTN



Camarillo, et al.       Expires December 30, 2002              [Page 44]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   side (unless the gateway knows that ringback will be provided by some
   other device 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.
   Therefore the gateway MUST be prepared to play this media to the
   caller on the PSTN side (ceasing any ringback tone that it may have
   begun to generate).  Note that the gateway may also receive SDP
   offers for an early media session, see Section 5.5.

   When an ACM is sent, the mandatory Backward Call Indicator 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
   ISUP message contained in the response body, including the value of
   the Backwards Call Indicators parameter as it formulates an 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:

        Message type:                            ACM

        Backward Call Indicators
        Charge indicator:                      10 charge
        Called party's status indicator:       01 subscriber free or
                                               00 no indication (E.ACM)
        Called party's category indicator:     01 ordinary subscriber
        End-to-end method indicator:           00 no end-to-end method
        Interworking indicator:                1  interworking encountered
        End-to-end information indicator:      0  no end-to-end info
        ISDN user part indicator:              0  ISUP not 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 parameters regarding interworking are set in
   the Backwards Call Indicators parameter of the ACM, this indicates
   that ISDN is interworking with a network which is not capable of
   providing as many services as ISDN does.  ISUP will therefore not
   employ certain features it otherwise normally uses.  Gateway vendors
   therefore MAY provide a configurable option, usable at the discretion
   of service providers when they require additional ISUP services, that
   even in the absence of encapsulated ISUP will signal in the BCI that
   no interworking has been encountered.







Camarillo, et al.       Expires December 30, 2002              [Page 45]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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.

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



Camarillo, et al.       Expires December 30, 2002              [Page 46]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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
   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 an REL message is generated upon a SIP rejection response, the
   Cause Indicator (CAI) parameter any encapsulated ISUP REL in the SIP
   response SHOULD be used in the REL generated by the gateway.  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.

   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.



Camarillo, et al.       Expires December 30, 2002              [Page 47]


Internet-Draft             ISUP to SIP Mapping                 July 2002


        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

   (*) 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



Camarillo, et al.       Expires December 30, 2002              [Page 48]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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
   hands 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 to 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.

   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



Camarillo, et al.       Expires December 30, 2002              [Page 49]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.



































Camarillo, et al.       Expires December 30, 2002              [Page 50]


Internet-Draft             ISUP to SIP Mapping                 July 2002


9. Suspend/Resume and Hold


9.1 SUS and RES

   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.

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




Camarillo, et al.       Expires December 30, 2002              [Page 51]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   The following example uses the INVITE mechanism.  Compliant gateways
   MAY implement functional equivalence with this flows in accordance
   with the language above.

        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.

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 Call
   Progress Message (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 to 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.



Camarillo, et al.       Expires December 30, 2002              [Page 52]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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






Camarillo, et al.       Expires December 30, 2002              [Page 53]


Internet-Draft             ISUP to SIP Mapping                 July 2002


        SIP                       MGC/MG                       PSTN
          |                          |<-----------REL-----------|1
          |             ** MG Releases PSTN Trunk **            |
          |                          |------------RLC---------->|2
         3|<----------BYE------------|                          |
          |            ** MG Releases IP Resources **           |
         4|-----------200----------->|                          |


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




















Camarillo, et al.       Expires December 30, 2002              [Page 54]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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 a reset (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 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.

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 (blocking) is always maintenance oriented and it is answered by
   the gateway with BLA when the circuit is blocked - this requires no
   corresponding SIP actions.  CGB (group blocking) 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.






Camarillo, et al.       Expires December 30, 2002              [Page 55]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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
   Nature of Connection Indicators (NCI) parameter is received, the
   gateway MUST process the continuity check before sending an INVITE
   message (and proceeding normally with call setup); if the continuity
   check fails (a COT with Continuity Indicator of 'failed' is
   received), then an INVITE MUST NOT be sent.

























Camarillo, et al.       Expires December 30, 2002              [Page 56]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

   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



Camarillo, et al.       Expires December 30, 2002              [Page 57]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 Called Party's Number
   (CPN) and Calling Party's Number (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
   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



Camarillo, et al.       Expires December 30, 2002              [Page 58]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.

   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>



Camarillo, et al.       Expires December 30, 2002              [Page 59]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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 in
   international format.

   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.       Expires December 30, 2002              [Page 60]


Internet-Draft             ISUP to SIP Mapping                 July 2002


13. Other ISUP flavors

   Other flavors of ISUP different than Q.767 [10] have more 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 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.

   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



Camarillo, et al.       Expires December 30, 2002              [Page 61]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.       Expires December 30, 2002              [Page 62]


Internet-Draft             ISUP to SIP Mapping                 July 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










Camarillo, et al.       Expires December 30, 2002              [Page 63]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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.  Merely securing
   encapsulated ISUP, for example, would not provide adequate privacy
   for a user requesting presentation restriction if the calling party
   number field is openly mapped to the From header.  However, since the
   scope of the 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.

   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 that arise from the other direction of
   mapping, the mapping of SIP headers to ISUP parameters, which are
   enumerated in the following section.  By way of introduction, no
   known risk is associated with end-users having arbitrary control over
   the value of the Carrier Identification Code or Transit Network
   Selection parameter and the telephone number portion of the Called
   Party Number field; these fields are already set directly by the user
   today.  The limited degree to which SIP signaling contributes to the
   interworking indicators of the Forward Call Indicators and Backwards
   Call Indicators parameters similarly incurs no foreseeable risks.

   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 a 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 in interim number



Camarillo, et al.       Expires December 30, 2002              [Page 64]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   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.

   Some additional risks may result from the SIP response code to ISUP
   REL Cause Code parameter mapping.  Called SIP user agents could
   conceivably respond to an INVITE 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 that identified in
   this draft 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.

   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
   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 retargeting 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 related to the cut-through



Camarillo, et al.       Expires December 30, 2002              [Page 65]


Internet-Draft             ISUP to SIP Mapping                 July 2002


   of the backwards media path.  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 want to consider 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.























Camarillo, et al.       Expires December 30, 2002              [Page 66]


Internet-Draft             ISUP to SIP Mapping                 July 2002


16. IANA Considerations

   This document introduces no new considerations for IANA.
















































Camarillo, et al.       Expires December 30, 2002              [Page 67]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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, May 2002.

   [2]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", 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.

   [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", draft-ietf-sip-
        reason-01 (work in progress), August 2002.





















Camarillo, et al.       Expires December 30, 2002              [Page 68]


Internet-Draft             ISUP to SIP Mapping                 July 2002


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

   [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", draft-ietf-sip-100rel-06 (work in progress),
         February 2002.

   [19]  Stewart, R., "Stream Control Transmission Protocol", RFC 2960,
         October 2000.

   [20]  Rosenberg, J., "The SIP UPDATE Method", draft-ietf-sip-update-
         02 (work in progress), March 2002.

   [21]  Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
         Number Portability and Freephone Service", draft-yu-tel-url-04



Camarillo, et al.       Expires December 30, 2002              [Page 69]


Internet-Draft             ISUP to SIP Mapping                 July 2002


         (work in progress), November 2001.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Center
   FIN-02420 Jorvas
   Finland

   Phone: +358 9 299 3371
   EMail: Gonzalo.Camarillo@Ericsson.com
   URI:   http://www.ericsson.com/


   Adam Roach
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024
   USA

   EMail: adam@dynamicsoft.com
   URI:   sip: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

   EMail: lyOng@ciena.com
   URI:   http://www.ciena.com/




Camarillo, et al.       Expires December 30, 2002              [Page 70]


Internet-Draft             ISUP to SIP Mapping                 July 2002


Appendix A. 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 and Steve Bellovin for their help and feedback on
   this document.  The authors would also like to thank ITU-T SG11 for
   their advice on ISUP procedures.





































Camarillo, et al.       Expires December 30, 2002              [Page 71]


Internet-Draft             ISUP to SIP Mapping                 July 2002


Appendix B. Revision History

   Changes from draft-ietf-sip-isup-00:

      - Merged draft-jfp-sip-isup-header-00 into this draft

      - Removed overlap signaling component (now draft-ietf-sip-overlap-
      00)

      - Adjusted cause code to status code mappings

   Changes from draft-ietf-sip-isup-01:

      - Added procedures for placing calls on hold

      - Generalized language and procedures for LNP, removing ANSI bias

      - Fixed usage of 'user=phone'

      - Added handling for Segmentation Message in ISUP

      - Updated SUS/RES handling to use INFO consistently (rather than
      183)

   Changes from draft-ietf-sip-isup-02:

      - Fixed some more ANSI-specific references (GNI, screening)

      - Fixed timer expiry cause code values (6.2.2)

      - Removed some bis04 incompatibilities (6.2.10)

      - Added motivational text to abstract and introduction

   Changes from draft-ietf-sip-isup-03:

      - Added provision for SUS/RES over INFO method

      - Fixed ANSI CRM/CRA behavior

      - Corrected a few status code conflicts

      - Righted many nits (thanks Igor!)

   Changes from draft-ietf-sipping-isup-00:

      - Removed PRACK from call flows




Camarillo, et al.       Expires December 30, 2002              [Page 72]


Internet-Draft             ISUP to SIP Mapping                 July 2002


      - Some updating to bring language in parity with bis

      - Various nits

   Changes from draft-ietf-sipping-isup-01:

      - Minor editorial corrections.

      - Updated references from RFC 2543 to RFC 3261.

      - Split normative and non-normative references.

   Changes from draft-ietf-sipping-isup-02:

      - Strengthened language about overwriting parameters.

      - Improved text on interworking indicators in FCI/BCI

      - Various nits

   Changes from draft-ietf-sipping-isup-03:

      - Improved scope language (translation and request routing)

      - Number portability / carrier id code mechanisms are optional

      - Strengthened Security Considerations

   Changes from draft-ietf-sipping-isup-04:

      - Added a significant amount of text to Security Considerations

      - Fixed requirements section (removing outdated references)

      - Added RFC2119 reference and language

      - Integrated some Reason header usage

      - Improved early media text in requirements and in state machine

      - Added some better text on privacy and presentation restriction

      - Corrected some straggling text about the use of bodies in CANCEL
      requests

      - Numerous editorial fixes for clarity

      - Made a few last Cause Code to Response Code mapping corrections



Camarillo, et al.       Expires December 30, 2002              [Page 73]


Internet-Draft             ISUP to SIP Mapping                 July 2002


      - Tweaked FCI/BCI text


















































Camarillo, et al.       Expires December 30, 2002              [Page 74]


Internet-Draft             ISUP to SIP Mapping                 July 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.       Expires December 30, 2002              [Page 75]