[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Internet Engineering Task Force             Gonzalo Camarillo/Adam Roach
Internet Draft                                                  Ericsson
<draft-ietf-sip-isup-03.txt>                                Jon Peterson
Category: Informational                                     NeuStar, Inc
August 2001                                                   Lyndon Ong
Expires: February 2001                                             Ciena



                          ISUP to SIP Mapping


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 cite them other than as "work in progress".

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

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

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.

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

Table of Contents
   1.       Introduction........................................... 3
   2.       Scope.................................................. 3
   3.       Scenarios.............................................. 5
   4.       SIP Mechanisms Required................................ 6



Camarillo/Roach/Peterson/Ong                                    [Page 1]


ISUP to SIP Mapping                                          August 2001


   4.1.     "Transparent" Transit of ISUP messages................. 6
   4.2.     Understanding of Multipart Bodies...................... 6
   4.3.     Transmission of DTMF information....................... 7
   4.4.     Reliable Transmission of Provisional Responses......... 7
   4.5.     Provisional Media Streams.............................. 7
   4.6.     Mid-Call Transactions Which do not Change SIP State.... 7
   5.       Mapping................................................ 7
   6.       SIP to ISUP mapping.................................... 8
   6.1.     Call Flows............................................. 8
   6.1.1.   En-bloc Call Setup (non auto-answer)................... 8
   6.1.2.   Auto-answer call setup................................. 10
   6.1.3.   ISUP T7 expires........................................ 10
   6.1.4.   SIP Timeout............................................ 11
   6.1.5.   ISUP Setup Failure..................................... 12
   6.1.6.   Cause present in ACM message........................... 13
   6.1.7.   Call cancelled by SIP node............................. 14
   6.2.     State Machine.......................................... 15
   6.2.1.   INVITE received........................................ 16
   6.2.1.1  INVITE to IAM procedures............................... 17
   6.2.2.   ISUP T7 expires........................................ 19
   6.2.3.   CANCEL or BYE received................................. 19
   6.2.4.   REL received........................................... 20
   6.2.4.1  ISDN Cause Code to SIP Status Code mapping............. 20
   6.2.5.   Early ACM received..................................... 23
   6.2.6.   ACM received........................................... 23
   6.2.7.   CON or ANM received.................................... 24
   6.2.8.   Timer T9 expires....................................... 24
   6.2.9.   CPG received........................................... 24
   6.2.10.  ACK received........................................... 25
   7.       ISUP to SIP mapping.................................... 25
   7.1.     Call Flows............................................. 25
   7.1.1.   En-bloc call setup (non auto-answer)................... 25
   7.1.2.   Auto-answer call setup................................. 27
   7.1.3.   SIP Timeout............................................ 27
   7.1.4.   ISUP T9 Expires........................................ 28
   7.1.5.   SIP Error Response..................................... 30
   7.1.6.   SIP Redirection........................................ 30
   7.1.7.   Call Cancelled by ISUP................................. 32
   7.2.     State Machine.......................................... 33
   7.2.1.   Initial Address Message received....................... 34
   7.2.1.1  IAM to INVITE procedures............................... 34
   7.2.2.   100 received........................................... 36
   7.2.3.   18x received........................................... 36
   7.2.4.   200 received........................................... 37
   7.2.5.   3xx received........................................... 38
   7.2.6.   4xx - 6xx received..................................... 38
   7.2.6.1  SIP Status Code to ISDN Cause Code mapping............. 38
   7.2.7.   REL received........................................... 40



Camarillo/Roach/Peterson/Ong                                    [Page 2]


ISUP to SIP Mapping                                          August 2001


   7.2.8.   ISUP T11 Expires....................................... 40
   8.       Suspend/Resume and hold................................ 41
   8.1.     SUS and RES............................................ 41
   8.2.     Hold (re-INVITE)....................................... 41
   9.       Normal Release of the Connection....................... 42
   9.1.     SIP initiated.......................................... 42
   9.2.     ISUP Initiated......................................... 43
   9.2.1.   Caller hangs up........................................ 43
   9.2.2.   Callee hangs up........................................ 43
   10.      ISUP maintenance messages.............................. 43
   10.1.    Reset messages......................................... 44
   10.2.    Blocking messages...................................... 44
   10.3.    Continuity checks...................................... 44
   11.      Construction of Telephony URIs......................... 45
   12.      Other ISUP flavors..................................... 48
   12.1.    Guidelines to send other ISUP messages................. 49
   13.      Acronyms............................................... 50
   14.      Acknowledgments........................................ 51
   15.      Revision History....................................... 51
   16.      References............................................. 51
   17.      Security Considerations................................ 53
   18.      Authors' Addresses..................................... 53


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 [2] is a level 4 protocol used in SS7 networks. It typically
   runs over MTP although it can also run over IP [15]. 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



Camarillo/Roach/Peterson/Ong                                    [Page 3]


ISUP to SIP Mapping                                          August 2001


   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 protcols.  It also describes the interplay between parallel state
   machines for these two protocols as a recommendation for implementors
   to synchronize protocol events in interworking architectures.

2. Scope

   This document focuses on the translation of ISUP messages into SIP
   messages, and the mapping of ISUP parameters into SIP headers. The
   purpose of translation in ISUP-SIP interworking is twofold: for ISUP
   calls that traverse a SIP network, translation allows SIP elements
   such as proxy servers to make routing decisions based on ISUP
   criteria such as the called party number; translation also provides
   critical information about the call to SIP endpoints that cannot
   understand encapsulated ISUP (or perhaps which merely cannot
   understand the particular ISUP variant in use).

   This document 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 [2]
   is used through this document; some differences with ANSI ISUP [3]
   and TTC ISUP are outlined. ISUP Q.767 [2] 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 standarized 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.

   Mapping of SIP headers to ISUP parameters in this document focuses



Camarillo/Roach/Peterson/Ong                                    [Page 4]


ISUP to SIP Mapping                                          August 2001


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

3. 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 [4]).  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



Camarillo/Roach/Peterson/Ong                                    [Page 5]


ISUP to SIP Mapping                                          August 2001


   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 17. 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 [15]. The mapping described in this document is not
   affected by the underlying transport protocol of ISUP.

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

   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.

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

4.1. "Transparent" Transit of ISUP messages

   To provide users the ability to take advantage of the full range of
   services afforded by the existing telephone network when placing



Camarillo/Roach/Peterson/Ong                                    [Page 6]


ISUP to SIP Mapping                                          August 2001


   calls from PSTN to PSTN across a SIP network, SIP messages will need
   to carry ISUP payloads from gateway to gateway. The format for
   carrying these messages is defined in "MIME media types for ISUP and
   QSIG Objects" [4] .

   SIP clients and servers which do not understand ISUP are permitted to
   ignore these (and other) optional MIME bodies.

4.2. Understanding of Multipart Bodies

   In most PSTN interworking situations, the SIP body will be required
   to carry session information (SDP) in addition to ISUP and/or billing
   information.

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

4.3. Transmission of DTMF information

   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 should
   be performed as described in "RTP Payload for DTMF Digits, Telephony
   Tones and Telephony Signals" [6], and is in all respects orthogonal
   to the mapping of ISUP and SIP.

4.4. Reliable Transmission of Provisional Responses

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

   PSTN interoperation nodes should implement the extension defined in
   "Reliability of Provisional Responses in SIP" [8] .

4.5. Provisional Media Streams

   To allow the transmission of messages and tones before a final
   connection has been established, SIP nodes which interwork with the
   PSTN need to be able to establish temporary media connections during
   this period.

   PSTN interoperating nodes should support the establishment of
   temporary provisional media streams using the 183 status code
   (described in [9]).



Camarillo/Roach/Peterson/Ong                                    [Page 7]


ISUP to SIP Mapping                                          August 2001


4.6. Mid-Call Transactions Which do not Change SIP State

   When interworking with PSTN, there are situations when PSTN nodes
   will need to send messages which do not correspond to any SIP
   operations to each other across a SIP network.

   The method for performing this transit will be in the INFO method,
   defined in "The SIP INFO Method" [10] .

   Nodes which do serve as PSTN interworking points should accept "405
   Method Not Allowed" and "501 Not Implemented" responses to INFO
   requests as non-fatal.

5. 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 / 6.2.1' indicates that an INVITE request has
   been received by the gateway, and the procedure upon reception is
   described in the section 6.2.1 of this document.

6. SIP to ISUP mapping

6.1. 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, since their presence is optional.

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






Camarillo/Roach/Peterson/Ong                                    [Page 8]


ISUP to SIP Mapping                                          August 2001


6.1.1. En-bloc Call Setup (non auto-answer)

   SIP                       MGC/MG                       PSTN
    1|---------INVITE---------->|                          |
     |<----------100------------|                          |
     |                          |------------IAM---------->|2
     |                          |<=========Audio===========|
     |                          |<-----------ACM-----------|3
    4|<----------18x------------|                          |
     |<=========Audio===========|                          |
    5|----------PRACK---------->|                          |
    6|<----------200------------|                          |
     |                          |<-----------CPG-----------|7
    8|<----------18x------------|                          |
    9|----------PRACK---------->|                          |
   10|<----------200------------|                          |
     |                          |<-----------ANM-----------|11
     |                          |<=========Audio==========>|
   12|<----------200------------|                          |
     |<=========Audio==========>|                          |
   13|-----------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 6.2.5 and 6.2.6).
      and returned to the SIP node. This
      response may contain SDP to establish an early media stream
      (as shown in the diagram). If no SDP is present, the audio
      will be established in both directions after step 12.

     (5) The SIP node sends a PRACK message to confirm receipt of the
      provisional response.

     (6) The PRACK is confirmed.

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




Camarillo/Roach/Peterson/Ong                                    [Page 9]


ISUP to SIP Mapping                                          August 2001


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

     (9) The SIP node sends a PRACK message to confirm receipt of the
      provisional response.

     (10) The PRACK is confirmed

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

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

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

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

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



Camarillo/Roach/Peterson/Ong                                   [Page 10]


ISUP to SIP Mapping                                          August 2001


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

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



Camarillo/Roach/Peterson/Ong                                   [Page 11]


ISUP to SIP Mapping                                          August 2001


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

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

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




Camarillo/Roach/Peterson/Ong                                   [Page 12]


ISUP to SIP Mapping                                          August 2001


     (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 6.2.4.) and sends it to the SIP
      node.

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

6.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===========|                          |
      5|----------PRACK---------->|                          |
      6|<----------200------------|                          |
                   ** Interwork timer expires **
      7|<----------4xx+-----------|                          |
       |                          |------------REL---------->|8
       |                          |<-----------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) 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



Camarillo/Roach/Peterson/Ong                                   [Page 13]


ISUP to SIP Mapping                                          August 2001


      establish early media cut-through.

     (5) The SIP node sends a PRACK message to confirm receipt of the
      provisional response.

     (6) The PRACK is confirmed.

     (7) 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 6.2.4. for the table
      which contains the mapping from cause code to SIP response.

     (8) 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 6.1.7.

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

     (10) The SIP node sends an ACK to acknowledge receipt of the
      INVITE final response.

6.1.7. Call cancelled by SIP node

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

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




Camarillo/Roach/Peterson/Ong                                   [Page 14]


ISUP to SIP Mapping                                          August 2001


     (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 6.2.5 and 6.2.6)
      and returned to the SIP node. This
      response may contain SDP to establish an early media stream.

     (5) The SIP node sends a PRACK message to confirm receipt of the
      provisional response.

     (6) The PRACK is confirmed.

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

     (8) The CANCEL request is confirmed with a 200 response.

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

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

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

     (12) Upon receipt of the 487, the SIP node will confirm reception
      with an ACK.

6.2. State Machine

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














Camarillo/Roach/Peterson/Ong                                   [Page 15]


ISUP to SIP Mapping                                          August 2001


                                   +---------+
          +----------------------->|  Idle   |<---------------------+
          |                        +----+----+                      |
          |                             |                           |
          |                             | INVITE/6.2.1              |
          |                             V                           |
          |      T7/6.2.2   +-------------------------+   REL/6.2.4 |
          +<----------------+         Trying          +------------>+
          |                 +-+--------+------+-------+             |
          |    CANCEL/6.2.3 | |        |      |                     |
          +<----------------+ | E.ACM/ | ACM/ | CON/                |
          |                   | 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        +------------>+
                            +-------------------------+

6.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 MGC
   is handling the call.

   The resources for the media stream have to be reserved at this stage,
   since an IAM message cannot be sent before the resource reservation
   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 QoS or/and security provisions.  Before sending the IAM the



Camarillo/Roach/Peterson/Ong                                   [Page 16]


ISUP to SIP Mapping                                          August 2001


   MG generally connects the backward media path.

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

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

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

   There are quite a few optional parameters that can appear in an IAM
   message; Q.763 [20] 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 PSTN context of the session if they are
   not capable of deciphering any encapsulated ISUP. Parameters that are
   only meaningful to the PSTN will be carried through PSTN-SIP- PSTN
   networks via encapsulation - 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 any encapsulated ISUP (see [4]) to assist in
   the formulation of outbound PSTN signaling. However, three conditions
   can complicate this process:

     o There is no ISUP encapsulated in the SIP INVITE - the SIP INVITE
     originated at a device other than an ISUP-SIP gateway.
     o There is encapsulated ISUP, but the gateway cannot understand
     the ISUP variant and therefore the ISUP must be discarded.
     o There is encapsulated ISUP, but there is more recent session
     context information available in the SIP headers, and consequently
     the SIP headers must 'overwrite' the encapsulated ISUP.

   In all of these cases translation must be performed. Gateways should
   use default values for mandatory ISUP parameters that are not derived



Camarillo/Roach/Peterson/Ong                                   [Page 17]


ISUP to SIP Mapping                                          August 2001


   from translation or encapsulation (such as the NCI or TMR
   parameters). The FCI parameter should also have a default, although
   its 'M' bit may be overwritten during the process of translation.

   First, the Request-URI should be inspected.

   If there is no 'npdi=yes' field within the Request-URI, then the main
   telephone number in the tel URL (the digits immediately following
   'tel:') should be converted to ISUP format, following the procedure
   described in section 11, and used to populate the CPN parameter.

   In ANSI networks, if the 'npdi=yes' field exists in the Request-URI,
   then the FCI parameter bit for 'number translated' within the IAM
   should 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 should be
   converted to ISUP format (see section 11) and used to populate the
   CPN parameter.

   If in addition to the 'npdi=yes' field an 'rn=' field is present,
   then in ANSI networks the 'rn=' field should be converted to ISUP
   format and used to populate the CPN. The main telephone number in the
   tel URL should be converted to ISUP format and used to populate the
   Generic Digits Parameter (or GAP in ANSI). In some networks the
   number given in the 'rn=' field should be prepended to the main
   telephone number and the combined result should be used to populate
   the CPN.

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

   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 in the IAM. If the gateway
   supports many independent trunks, it may need to choose a particular
   trunk that points to the carrier identified by the CIC, or a tandem
   through which that carrier is reachable. Policies for such trunks
   (based on the preferences of the carriers with which the trunks are
   associated) may dictate whether the CIP or TNS parameter should be
   used (although note that in non-ANSI networks the CIP will never be
   used). 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
   NoA field of the CPN indicates that this is an international number),
   and the CIP should be used in other cases.

   If a SIP call has arrived at a gateway, then the Request-URI will



Camarillo/Roach/Peterson/Ong                                   [Page 18]


ISUP to SIP Mapping                                          August 2001


   most likely contain a tel URL (or a SIP URI with a tel URL user
   portion). However, if the call originated at a native IP endpoint
   such as a SIP phone, the From field may not reflect any telephone
   number - it may be a simple user@host construction. The CIN parameter
   should be omitted from the outbound IAM if the From field is
   unusable.

   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.

   Thus, `interworking encountered' must not be specified so that ISUP
   behaves normally. SIP is considered as an SS7 network and a SIP phone
   is considered as ISDN access since the SIP network is supposed to
   provide at least as many services as ISUP.

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

6.2.2. ISUP T7 expires

   Since no response was received from the PSTN all the resources in the
   MG are released. A `504 gateway timeout' is sent back to the SIP
   network. A REL message with cause value 102 (protocol error, recovery
   on timer expiry) is sent to the PSTN. The PSTN responds with RLC and
   the SIP network responds with an ACK indicating that the release
   sequence has been completed.

6.2.3. CANCEL or BYE received

   If a CANCEL or BYE request is received, a `200 OK' is sent to the SIP
   network to confirm the CANCEL or BYE; a 487 is also sent to terminate
   the INVITE transaction. All the resources are released and a REL
   message is sent to the PSTN with cause value 16 (normal clearing). A
   RLC from the PSTN is received indicating that the release sequence is
   complete.

   It is important that all the resources are released before the
   gateway sends any REL message.

   In SIP bridging situations, a REL might arrive in the CANCEL or BYE
   request body. This REL is sent to the PSTN.



Camarillo/Roach/Peterson/Ong                                   [Page 19]


ISUP to SIP Mapping                                          August 2001


   This section ( 6.2.3. ) applies every time that a CANCEL or a BYE is
   received before a final SIP response has been sent.

6.2.4. REL received

   This section applies every time that a REL is received before a final
   SIP response has been sent.

   The resources are released in the MG and a RLC is sent to the ISUP
   network to indicate that the circuit is available for reuse.

   If the INVITE originating this transaction contained an ISUP message
   in its body (such as an IAM), the MGC is handling a SIP bridging
   situation. Therefore, the REL message just received should be
   included in the body of the response.

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

6.2.4.1 ISDN Cause code to SIP Status Code mapping

   An REL message contains an ISDN Cause Code (see [16]) in the Cause
   Indicator (CAI) parameter. Most ISUP variants (including ANSI and
   ETSI) use these cause codes to represent conditions surrounding the
   termination of a call.

   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 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 status 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 (IAM) 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).

   If a cause value other than what is listed below is received, the



Camarillo/Roach/Peterson/Ong                                   [Page 20]


ISUP to SIP Mapping                                          August 2001


   default response `500 Server internal error' would be used.

   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.

     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       302 Moved Temporarily
     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.


   A REL with ISDN cause 22 (number changed) might contain information
   about a new number where the callee might be reachable in the




Camarillo/Roach/Peterson/Ong                                   [Page 21]


ISUP to SIP Mapping                                          August 2001


   diagnostic field. If the MGC is able to parse this information it
   might be added to the SIP response (301) in a Contact header.

     Resource unavailable

     This kind of cause value indicates a non permanent situation. A
     `Retry-After' header has to be added to the response.

     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 a permanent situation

     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 implemented

     ISUP Cause value                        SIP response
     ----------------                        ------------
     65 bearer capability not implemented    501 Not implemented
     79 service or option not implemented    501 Not implemented


     Invalid message

     ISUP Cause value                        SIP response
     ----------------                        ------------
     87 user not member of CUG               503 Service unavailable
     88 incompatible destination             503 Service unavailable
     95 invalid message                      503 Service unavailable


     Protocol error




Camarillo/Roach/Peterson/Ong                                   [Page 22]


ISUP to SIP Mapping                                          August 2001


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


     Interworking

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


6.2.5. Early ACM received

   This message is sent in certain situations for resetting the timers.
   In these cases this message indicates that the call is in progress
   but callee is not being alerted. This occurs for example in mobile
   networks, where roaming can take a long time. 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 receiving an early ACM the progress of the call is indicated by
   the network sending CPGs.

   When there is interworking with some old systems, it is possible to
   receive an ANM immediately after an early ACM (without CPG).  In this
   situation the SIP user will not hear any kind of ringback tone before
   the callee answers. In ISDN [11] this is solved by connecting the
   voice path backwards before sending the IAM.

   The MGC sends a 183 Session Progress [9] to the SIP network with a
   media description inside. In SIP bridging situations the early ACM is
   included in the response body. Thus, the problem of missing the ring
   back tone is solved and the early ACM is transported transparently
   through the SIP network.

6.2.6. ACM received

   Upon reception of an ACM timer T9 is started. T9 typically lasts
   between 90 seconds and 3 minutes [12] . It allows the caller to hear
   announcements from the network for that period of time without being
   charged for the connection. If longer announcements have to be played
   the network has to send an ANM. When the ANM is sent the call begins
   being charged.




Camarillo/Roach/Peterson/Ong                                   [Page 23]


ISUP to SIP Mapping                                          August 2001


   The nearest local exchange to the callee generates the ringback tone
   and may send voice announcements.

   Usually on receipt of an ACM a `180 Ringing' is sent to the SIP
   network.  It should generally contain a session description in order
   to allow SIP UAs to prevent clipping of initial callee media.  The
   ringback tone or the proper announcements will be generated by the
   PSTN exchange, and not by the callers SIP UAC/UAS.

   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 support cause codes), then there
   may be in-band announcements of call status such as an audible busy
   tone or caller intercept message. In this case rather than a 180
   status code, a 183 Session Progress message should be sent in order
   to allow pre-ANM media to flow in the backwards direction.

   In SIP bridging situations, the ACM is included in the body of the
   180 response.

6.2.7. CON or ANM received

   A `200 OK' response is sent to the SIP network. In SIP bridging
   situations, the ISUP message is included in the body of the 200 OK
   response. This is also the point at which a two-way media stream will
   be established.

6.2.8. Timer T9 expires

   This indicates that the ANM has not arrived in time specified.  This
   results in the call being aborted. All the resources related to the
   media path are released. A `480 temporarily unavailable' is sent to
   the SIP network. A REL message with cause value 19 (no answer from
   the user) is sent to the ISUP part. The PSTN responds with RLC and
   the SIP network responds with an ACK indicating that the release
   sequence has been completed.

6.2.9. CPG received

   A CPG can indicate progress, alerting or in-band information. If the
   CPG comes after an ACM, there is already a one-way voice path open,
   so there is no need of taking further action in the media path.

   In SIP bridging situations, the CPG is sent in the body of a 18x
   response, determined from the CPG event code.

     ISUP event code                         SIP response



Camarillo/Roach/Peterson/Ong                                   [Page 24]


ISUP to SIP Mapping                                          August 2001


     ----------------                        ------------
     1 Alerting                              180 Ringing
     2 Progress                              183 Call progress
     3 In-band information                   183 Call 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 Call progress

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

6.2.10. ACK received

   At this stage, the call is connected and the conversation can take
   place.

7. ISUP to SIP mapping

7.1. 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 explained, 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."

7.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|<---------PRACK-----------|                          |
      6|-----------200----------->|                          |
      7|-----------18x----------->|                          |
       |                          |------------CPG---------->|8
      9|<---------PRACK-----------|                          |



Camarillo/Roach/Peterson/Ong                                   [Page 25]


ISUP to SIP Mapping                                          August 2001


     10|-----------200----------->|                          |
     11|-----------200----------->|                          |
       |<=========Audio==========>|                          |
       |                          |------------ANM---------->|12
       |                          |<=========Audio==========>|
     13|<----------ACK------------|                          |

     (1) When a PSTN user wishes to begin a session with a SIP user,
      the PSTN network generates an IAM message towards the
      gateway.

     (2) Upon receipt of the IAM message, the gateway generates an
      INVITE message, and sends it to an appropriate SIP node.

     (3) When an event signifying that the call has sufficient
      addressing information occurs, the SIP node will generate a
      provisional response of 180 or greater.

     (4) Upon receipt of a provisional response of 180 or greater, the
      gateway will generate an ACM message. If the response is not
      180, the ACM will carry a "called party status" value of "no
      indication."

     (5) The gateway sends a PRACK message  to confirm receipt of the
      provisional response.

     (6) The PRACK is confirmed

     (7) The SIP node may use further provisional messages to indicate
      call progress.

     (8) After an ACM has been sent, all provisional responses will
      translate into ISUP CPG messages as indicated in 7.2.3.

     (9) The gateway sends a PRACK message  to confirm receipt of the
      provisional response.

     (10) The PRACK is confirmed

     (11) When the SIP node answers the call, it will send a 200 OK
      message.

     (12) Upon receipt of the 200 OK message, the gateway will send an
      ANM message towards the ISUP node.

     (13) The gateway will send an ACK to the SIP node to acknowledge
      receipt of the INVITE final response.




Camarillo/Roach/Peterson/Ong                                   [Page 26]


ISUP to SIP Mapping                                          August 2001


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

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



Camarillo/Roach/Peterson/Ong                                   [Page 27]


ISUP to SIP Mapping                                          August 2001


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

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

7.1.4. ISUP T9 Expires

        SIP                       MGC/MG                       PSTN
          |                          |<-----------IAM-----------|1
          |                          |==========Audio==========>|
         2|<--------INVITE-----------|                          |
          |    *** T1 Expires ***    |                          |
         3|<--------INVITE-----------|                          |
          |    *** T1 Expires ***    |                          |
          |<--------INVITE-----------|                          |
          |                          |    *** T11 Expires ***   |



Camarillo/Roach/Peterson/Ong                                   [Page 28]


ISUP to SIP Mapping                                          August 2001


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

     (4) When T11 expires, an ACM message will be sent to the ISUP
      node to prevent the 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.






Camarillo/Roach/Peterson/Ong                                   [Page 29]


ISUP to SIP Mapping                                          August 2001


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

     (6) The remote ISUP node confirms receipt of the REL message with
      an RLC message.

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



Camarillo/Roach/Peterson/Ong                                   [Page 30]


ISUP to SIP Mapping                                          August 2001


      9|<---------PRACK-----------|                          |
     10|-----------200----------->|                          |
     11|-----------200----------->|                          |
       |<=========Audio==========>|                          |
       |                          |------------ANM---------->|12
       |                          |<=========Audio==========>|
     13|<----------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.

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

     (9) The gateway sends a PRACK message  to confirm receipt of the
      provisional response.

     (10) The PRACK is confirmed

     (11) When the SIP node answers the call, it will send a 200 OK
      message.




Camarillo/Roach/Peterson/Ong                                   [Page 31]


ISUP to SIP Mapping                                          August 2001


     (12) Upon receipt of the 200 OK message, the gateway will send an
      ANM message towards the ISUP node.

     (13) The gateway will send an ACK to the SIP node to acknowledge
      receipt of the INVITE final response.

7.1.7. Call Cancelled by ISUP

        SIP                       MGC/MG                       PSTN
          |                          |<-----------IAM-----------|1
          |                          |==========Audio==========>|
         2|<--------INVITE-----------|                          |
         3|-----------18x----------->|                          |
          |==========Audio==========>|                          |
          |                          |------------ACM---------->|4
         5|<---------PRACK-----------|                          |
         6|-----------200----------->|                          |
          |             ** MG Releases PSTN Trunk **            |
          |                          |<-----------REL-----------|7
          |                          |------------RLC---------->|8
         9|<---------CANCEL----------|                          |
          |            ** MG Releases IP Resources **           |
        10|-----------200----------->|                          |
        11|-----------487----------->|                          |
        12|<----------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 7.2.3.

     (5) The gateway sends a PRACK message  to confirm receipt of the
      provisional response.

     (6) The PRACK is confirmed

     (7) If the calling party hangs up before the SIP node answers the



Camarillo/Roach/Peterson/Ong                                   [Page 32]


ISUP to SIP Mapping                                          August 2001


      call, a REL message will be generated.

     (8) The gateway frees the PSTN circuit and indicates that it is
      available for reuse by sending an RLC.

     (9) Upon receipt of a REL message before an INVITE final
      response, the gateway will send a CANCEL towards the SIP
      node.

     (10) Upon receipt of the CANCEL, the SIP node will send a 200
      response.

     (11) The remote SIP node will send a "487 Call Cancelled" to
      complete the INVITE transaction.

     (12) The gateway will send an ACK to the SIP node to acknowledge
      receipt of the INVITE final response.

7.2. State Machine

   Note that REL may arrive in any state. Whenever this occurs, the
   actions in section 7.2.7. are taken. Not all of these transitions are
   shown in this diagram.




























Camarillo/Roach/Peterson/Ong                                   [Page 33]


ISUP to SIP Mapping                                          August 2001


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

7.2.1. Initial Address Message received

   Upon the reception of an IAM, resources are reserved in the media
   gateway and it connects audio in the backwards direction (towards the
   caller).

7.2.1.1 IAM to INVITE procedures

   When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message will
   be created for transmission to the SIP network. This section details
   the process by which a gateway populates the INVITE based on
   parameters found within the IAM.

   The session context information discovered by the gateway in the IAM
   will be stored primarily in two URIs in the INVITE, one representing
   the originator of the session and the other the destination. The
   former will always appear in the From header (after it has been



Camarillo/Roach/Peterson/Ong                                   [Page 34]


ISUP to SIP Mapping                                          August 2001


   converted from ISUP format by the procedure described in section 11),
   and the latter is almost always used for both the To header and the
   Request-URI.

   The construction of destination URI begins with determining which
   ISUP parameter currently contains the called party number.  Usually,
   this will be the CPN parameter. However, if the destination number
   has been ported (see [x]) and a dip to the relevant LNP database has
   already been performed, then the called party number will, in some
   ISUP variants include ANSI, in fact appear in the Generic Digits
   Parameter or GAP. Generally in such variants the 'number translated'
   bit of the FCI parameter should be consulted to determine whether the
   called party number is in the CPN parameter or the GAP parameter. In
   other variants, if a portability dip has been performed the routing
   number may be founded prepended to the called party number in the CPN
   parameter.

   Once the location of the called party number has been determined, it
   should be translated into a tel URL through the mechanism described
   above. Some additional fields may need to be added to the tel URL
   after translation has been completed, namely:

     o If (in ANSI networks) the FCI 'number translated' bit indicated
     that an LNP dip had been performed, or (in other variants) if a
     routing number has been prepended to the CPN, then an 'npdi=yes'
     field must be appended to the tel URL. If the routing number is not
     present in the CPN, then if a Generic Digits Parameter (or GAP in
     ANSI) is present in the IAM, then the contents of the CPN should be
     translated from ISUP format (as described above) and copied into an
     'rn=' field which must be appended to the tel URL.  Note that
     Location Routing Numbers (LRNs) stored in CPN for calls to ported
     numbers are necessarily national in scope, and consequently they
     will not be preceded by a '+' in the 'rn=' field. For further
     information on these tel URL fields see [17].

     o If either the CIP (in ANSI networks) or TNS is present, the
     carrier identification code (CIC) should be extracted from the
     parameter and analyzed by the gateway. 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), a
     'cic=' field with the value of the CIC should be appended to the
     tel URL. Note that the CIC should 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 [17].

   In most cases, the resulting URI should be used in the To field and
   Request-URI sent by the gateway. However, if the OCN parameter is



Camarillo/Roach/Peterson/Ong                                   [Page 35]


ISUP to SIP Mapping                                          August 2001


   present in the IAM, the To field constructed from the translation of
   the OCN parameter, and hence the Request-URI and To field will be
   different.

   The construction of the From 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 containing a SIP URI without a user
   portion which communicates only the hostname of the gateway (e.g.
   'sip:gw.level3.net'). 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 field.

7.2.2. 100 received

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

7.2.3. 18x received

   If no ACM has been sent yet and no ISUP is present in the 18x message
   body, and ISUP message is generated according to the following table.
   Note that, if an early ACM is sent, the call enters 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 is 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)

   If the reception of a `180 Ringing' response without media
   description, the MG generates the ringback tone to be heard by the
   caller.

   If the MGC receives any 1xx response (except 100)  with a session
   description present for media setup, it sets up the session being



Camarillo/Roach/Peterson/Ong                                   [Page 36]


ISUP to SIP Mapping                                          August 2001


   described. The call progress media (e.g. ringback tone or
   announcement) is generated by an entity downstream (in the SIP
   network or by a PSTN exchange in SIP bridging situations).

   If an ACM has not been sent yet, one is generated and sent. The
   mandatory parameters of the ACM are described below:

     Message type:                            ACM

     Backward 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:                0  no interworking
     End-to-end information indicator:      0  no end-to-end info
     ISDN user part indicator:              1  ISUP all the way
     Holding indicator:                     0  no holding
     ISDN access indicator:                 1  ISDN access
     Echo control device indicator:         It depends on the call
     SCCP method indicator:                 00 no indication

   In SIP bridging situations the MGC sends the ISUP message contained
   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 therefore be avoided.

7.2.4. 200 received

     Response received                        Message sent by the MGC
     -----------------                        -----------------------
     200 OK                                   ANM, ACK

   After receiving a 200 OK response the MGC establishes a two-way voice
   path in the MG and it sends an ANM to the PSTN and an ACK to the SIP
   network.

   If the `200 OK' response arrives before the MGC has sent the ACM, a
   CON is sent instead of the ANM.

   In SIP bridging situations the MGC sends the ANM or the CON in the
   response body.






Camarillo/Roach/Peterson/Ong                                   [Page 37]


ISUP to SIP Mapping                                          August 2001


7.2.5. 3xx received

   When any 3xx  response is received ,the MGC should try to contact the
   user using the `Contact' header or headers present in the response.
   These 3xx responses are typically sent by a re-direct server. This is
   a similar device to the HLR in mobile networks.  It provides another
   address where the callee may be reached.

   A CPG message with an event code of 2 (Progress) may be sent to
   indicate that the call is proceeding. Note that some ISUP nodes may
   not support CPG before ACM, so this feature should be configurable.

   If the new location presented in the Contact header of a 3xx is best
   reachable (according to the gateway's routing policies) via the PSTN,
   the MGC sends a new IAM and from that moment on acts as a normal PSTN
   switch (no SIP involved). If the new location is best reachable using
   SIP, the MGC sends an INVITE with possibly a new IAM generated by the
   MGC in the message body.

   All redirection situations have to be treated very carefully because
   they involved special charging situations. In PSTN the caller
   typically pays the first call leg and the callee pays the second.

7.2.6. 4xx - 6xx received

   The MGC releases the resources in the MG, send a REL to the PSTN with
   a cause value and send an ACK to the SIP network. An RLC arrives
   indicating that the release sequence is complete.

7.2.6.1 SIP Status Code to ISDN Cause Code mapping

   By default, the cause location associated with the CAI parameter
   should be encoded such 6xx codes are given the location 'user',
   whereas 4xx and 5xx codes are given a 'network' location. Exceptions
   are marked below.

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

   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 be translated to ISUP. Examples are flagged with (+)
   below.

     Response received                        Cause value in the REL
     -----------------                        ----------------------



Camarillo/Roach/Peterson/Ong                                   [Page 38]


ISUP to SIP Mapping                                          August 2001


     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
     409 Conflict                             48 Temporary failure
     410 Gone                                 22 Number changed
                                                 (w/o diagnostic)
     411 Length required                     127 Interworking (+)
     413 Request Entity too long             127 Interworking (+)
     414 Request-URI too long                127 Interworking (+)
     415 Unsupported media type               79 Service/option not
                                                 implemented (+)
     420 Bad extension                       127 Interworking (+)
     480 Temporarily unavailable              18 No user responding
     483 Too many hoops                       25 Exchange - routing error
     484 Address incomplete                   28 Invalid Number Format (+)
     485 Ambiguous                             1 Unallocated number
     486 Busy here                            17 User busy
     488 Not Acceptable here                 --- by Warning header
     500 Server internal error                41 Temporary failure
     501 Not implemented                      38 Network out of order
     502 Bad gateway                          38 Network out of order
     503 Service unavailable                  41 Temporary failure
     504 Server time-out                     102 Recovery on timer expiry
     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 gateway
   cannot authorize 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



Camarillo/Roach/Peterson/Ong                                   [Page 39]


ISUP to SIP Mapping                                          August 2001


   code. This document assumes that sending '31 Normal, unspecified'
   will be sufficient for all currently assigned Warning codes.

7.2.7. REL received

   The MGC should abort the establishment of the session. A CANCEL
   request has to be issued. A BYE is not used, since no final response
   has arrived from the SIP side. A 200 OK for the CANCEL arrives, and a
   487 for the INVITE arrives.

   The MGC has to store state information 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 MGC sends an ACK and then a BYE.

   In SIP bridging situations, the REL message may be included in the
   CANCEL message body. CANCEL requests are answered with a final
   response (such as 200 OK) by the first proxy. Therefore, the MGC does
   not know if the CANCEL has arrived to the end user (egress MGC in
   this scenario). Hence, if a 200 OK response for the previously sent
   INVITE arrives the MGC sends an ACK and then a BYE with the REL in
   the message body.

7.2.8. ISUP T11 Expires

   In order to prevent the remote ISUP node's timer T7 from expiring,
   the gateway may choose 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 [14] explains its use as: "If in normal operation, a delay in
   the receipt of an address complete signal from the succeeding network
   is expected, the last common channel signaling exchange will
   originate and send an address complete message 15 to 20 seconds
   [timer (T11)] after receiving the latest address message." Since SIP
   nodes have no obligation to respond to an INVITE request within 20
   seconds,  SIP interworking inarguably qualifies as such a situation.

   If the gateway's T11 expires, it will send an early ACM (i.e.  called
   party status set to "no indication") to prevent the expiration of the
   remote node's T7. See section 7.2.3. for the value of the ACM
   parameters.

   If a "180 Ringing" message arrives subsequently, it will be sent in a
   CPG, as shown in section 7.2.3.




Camarillo/Roach/Peterson/Ong                                   [Page 40]


ISUP to SIP Mapping                                          August 2001


   See 7.1.3. for an example callflow that includes the expiration of
   T11.

8. Suspend/Resume and hold

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

   When a SUS arrives from the PSTN, the MGC should send an INVITE to
   put the media stream on hold. The reception of a RES triggers a re-
   INVITE that resumes the media stream. For the SIP UAC/UAS the result
   is an interruption in the voice path until the other party picks up
   the phone again. Putting the media on hold insures that bandwidth is
   conserved when no audio traffic needs to be transmitted.

   In some instances it may be undesirable to put the media for a call
   on hold when a SUS is received. In these instances a re-INVITE should
   still be used to carry the SUS message; however, the SDP within the
   INVITE should repeat the last SDP given rather than substituting the
   'null' SDP used to put calls on hold (i.e. in which the c= line or
   port in the m= line indicates '0').

   In SIP bridging situations, the SUS and RES messages can be
   transferred in the body of the INVITE.

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

8.2. Hold (re-INVITE)

   After a call has been connected, a re-INVITE may be sent to a gateway
   from the SIP side in order to place the call on hold. This re-INVITE
   will have an SDP indicating that the originator of the re-INVITE no
   longer wishes to receive media.



Camarillo/Roach/Peterson/Ong                                   [Page 41]


ISUP to SIP Mapping                                          August 2001


     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
   may repeat the flow above with an INVITE that contains an SDP with a
   reachable 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 may wish to stop sending media until the call is resume,
   and/or send a re-INVITE to the SIP leg of the call requesting that
   the remote side stop sending media.

9. Normal Release of the Connection

   Either the SIP side or the ISUP side may release a call, regardless
   of which side initiated the call.

9.1. SIP initiated

   For a normal release of the call (reception of BYE), the MGC
   immediately sends a 200 response. It then releases the resources in
   the MG and sends an REL with a cause code of 16 (normal call
   clearing) to the PSTN. Release of resources is confirmed by the PSTN
   with a RLC.

   In SIP bridging situations, the REL contained in the BYE is sent to
   the PSTN.

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



Camarillo/Roach/Peterson/Ong                                   [Page 42]


ISUP to SIP Mapping                                          August 2001


9.2. ISUP Initiated

   If the release of the connection was caused by the reception of a
   REL, the REL is included in the BYE sent by the MGC.

9.2.1. Caller hangs up

   For a normal release of the call (reception of REL from the PSTN),
   the MGC first releases the resources in the MG and then confirms that
   they are ready for re-use by sending an RLC. The SIP connection is
   released by sending a  BYE (which is confirmed with a 200).

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


9.2.2. Callee hangs up

   In analog PSTN, 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.

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

10. ISUP maintenance messages

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





Camarillo/Roach/Peterson/Ong                                   [Page 43]


ISUP to SIP Mapping                                          August 2001


10.1. Reset messages

   Upon reception of a reset message for the circuit being used, the
   call has to be released. RSC messages are answered with RLC after
   resetting the circuit in the MG. GRS messages are answered with GRA
   after resetting all the circuits affected by the message.

   The MGC acts as if a REL had been received in order to release the
   connection on the SIP side. The session will be terminated. A BYE or
   a CANCEL are sent depending of the status of the call.

10.2. Blocking messages

   There are two kinds of blocking messages: maintenance oriented or
   hardware failure oriented. Maintenance oriented blocking messages
   indicates that the circuit has to be blocked for subsequent calls.
   Therefore, these messages do not affect any ongoing call.

   Hardware oriented blocking messages have to be treated as reset
   messages. The call is released.

   BLO is always maintenance oriented and it is answered by the MGC with
   BLA when the circuit is blocked. CGB messages have a "type indicator"
   inside the "circuit group supervision message type indicator". It
   indicates if the CGB is maintenance or hardware failure oriented.
   CGBs are answered with CGBAs.

10.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 before call setup
   begins), and the explicit continuity check signaled by a Continuity
   Check Request (CCR) message.

   When a CCR is received by a PSTN-SIP gateway, the gateway should not
   send any SIP messages; the scope of the continuity check applies only
   to the PSTN trunks, not to any IP media paths.

   When an IAM with the Continuity Check Indicator flag set within the
   Nature of Connection Indicators (NCI) parameter is received, the
   gateway should process the continuity check before sending an INVITE
   message; if the continuity check fails (a COT with Continuity
   Indicator of 'failed' is received), then an INVITE should not be
   sent.




Camarillo/Roach/Peterson/Ong                                   [Page 44]


ISUP to SIP Mapping                                          August 2001


11. 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, defined in [18]. 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 should
   accept either tel or SIP URIs from its peers.

   The '+' sign preceding the number in these examples indicates that
   the digits which follow constitute a fully-qualified E.164 [19]
   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 could mean that the number
   is 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 highly 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/Roach/Peterson/Ong                                   [Page 45]


ISUP to SIP Mapping                                          August 2001


   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


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



Camarillo/Roach/Peterson/Ong                                   [Page 46]


ISUP to SIP Mapping                                          August 2001


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

   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 should be 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. 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 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 use to populate the display-
   name portion of the From field.

   If ISUP calling format is used 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
   should be created by the gateway which communicates to the far end
   that the caller's identity has been elided. This URI should be a SIP
   URI with the hostname of the gateway but with a display name of
   'Anonymous' username of 'restricted', e.g.:





Camarillo/Roach/Peterson/Ong                                   [Page 47]


ISUP to SIP Mapping                                          August 2001


     From: Anonymous <sip:restricted@gw.level3.net>

   As further general-purpose privacy mechanisms are developed for the
   SIP protocol, they may also be used to protect the identity of a
   caller.

   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.

   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 should be set to 'ISDN numbering plan'.

   If the URI is not in international format, the gateway should 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, then this condition
   is most likely best handled with appropriate SIP status codes (e.g.
   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.

12. Other ISUP flavors

   Other flavors of ISUP different than Q.767 [2] 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 dropped, which may cause SIP
   or ISUP messages to be sent.



Camarillo/Roach/Peterson/Ong                                   [Page 48]


ISUP to SIP Mapping                                          August 2001


   However, differences in the message flows are more important. In ANSI
   ISUP [3], there is no CON message; an ANM is sent instead (with no
   ACM). In call forwarding situations, CPGs can be sent before the ACM
   is sent. SAMs are never used; `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 - although a SIP gateway should not ever receive these
   messages, if it does receive such a message there is no appropriate
   SIP action to be taken (the recommended behavior is sending a REL in
   response to the CRM).

   Although receipt of a Confusion (CFN) message is an indication of a
   protocol error, no SIP message should be sent on receipt of a CFN -
   the CFN should be handled internally by the gateway (usually by
   retransmission of the packet to which the CFN responded). Only if
   this fails repeatedly should this cause a SIP error condition to
   arise.

   In TTC ISUP CPGs can be sent before the ACM is sent. Messages such as
   CHG can be sent between ACM and ANM. `En bloc' signaling is always
   used and there is no T9 timer.

12.1. Guidelines to send other ISUP messages

   Some ISUP flavors send more messages than the ones described in this
   document. It is good to follow some guidelines to transport these
   ISUP messages inside SIP bodies.

   From the caller to the callee ISUP messages should be encapsulated
   (see [4]) inside INFO messages, even if the INVITE transaction is
   still not finished. Note that SIP does not ensure that INFO requests
   are delivered in order. Therefore, an egress gateway might process
   first an INFO request that was sent after another INFO request.  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.

   Note that if an INR is received before call establishment is complete
   (i.e. ANM is received) it should be encapsulated in a an INFO, rather
   than any provisional 1xx response.  Similarly an INF is received on
   the originating side (probably in reponse to an INR) before a 200 has
   been received 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



Camarillo/Roach/Peterson/Ong                                   [Page 49]


ISUP to SIP Mapping                                          August 2001


   its destination. As such all SIP-T gateways should send 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.

   ISUP messages from the callee to the caller should be sent inside
   provisional responses. SIP ensures that provisional responses
   transmitted reliably are delivered in order. When the INVITE
   transaction is finished INFO requests should be used also in this
   direction.

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



Camarillo/Roach/Peterson/Ong                                   [Page 50]


ISUP to SIP Mapping                                          August 2001


     UAC                User Agent Client
     UAS                User Agent Server
     UDP                User Datagram Protocol
     VoIP               Voice over IP

14. Acknowledgments

   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, and
   Jan Van Geel for their help and feedback on this document.

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





Camarillo/Roach/Peterson/Ong                                   [Page 51]


ISUP to SIP Mapping                                          August 2001


16. References

   [1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
    Session Initiation Protocol", RFC 2543, IETF; March 1999.

   [2] "Application of the ISDN user part of CCITT signaling system
    No. 7 for international ISDN interconnections" ITU-T Q.767
    recommendation, February 1991.

   [3] "Signaling System No. 7; ISDN User Part" T1.113-1995 ANSI.
    January 1995.

   [4] E Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M.
    Watson, M. Zonoun, "MIME media types for ISUP and QSIG
    Objects", Internet Draft <draft-ietf-sip-isup-mime-10.txt>,
    IETF; April 2001. Work in progress.

   [5] N. Freed, N. Borenstein, "Multipurpose Internet Mail
    Extensions (MIME) Part Two: Media Types", RFC 2046, IETF;
    November 1996.

   [6] H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits,
    Telephony Tones and Telephony Signals", RFC 2833, IETF; May
    2000.

   [8] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional
    Responses in SIP", Internet Draft <draft-ietf-sip-100rel-03.txt>,
    IETF; March 2001. Work in progress.

   [9] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
    Session Initiation Protocol", Internet Draft
    <draft-ietf-sip-rfc2543bis-04.txt>, IETF; August 2001. Work in
    progress.

    Former reference placeholder for 183 work:
    S. Donovan, M. Cannon, H. Schulzrinne, J. Rosenberg, A. Roach,
    "SIP 183 Session Progress Message", Internet Draft, IETF
    October 1999. (expired I-D)

   [10] Steven R. Donovan, "The SIP INFO Method", RFC 2976, IETF;
    February 2000.

   [11] "Signaling System No. 7; ISDN User Part Signaling
    procedures", ITU-T Q.764 recommendation, September 1997.

   [12] Abnormal conditions - Special release ITU-T Q.118
    recommendation, September 1997.




Camarillo/Roach/Peterson/Ong                                   [Page 52]


ISUP to SIP Mapping                                          August 2001


   [13] "Specifications of Signaling System No. 7 - ISDN
    supplementary services" ITU-T Q.737 recommendation, June
    1997.

   [14] "Specifications of Signaling System No. 7 - ISDN User Part
    Signaling Procedures" ITU-T Q.764 recommendation, March
    1993.

   [15] R. Stewart et al, "Stream Control Transmission Protocol".
    RFC 2960, IETF; October 2000.

   [16] "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 Recommendation, May 1998

   [17] J. Yu, "Extensions to the 'tel' and 'fax' URLs to Support Number
    Portability and Freephone Service", Internet-Draft
    <draft-yu-tel-url-02.txt>, IETF, Feb 2001. (Work in progress)

   [18] A. Vaha-Sipila, "URLs for Telephone Calls", RFC2806, IETF, April
    2000.

   [19] "The international public telecommunication number plan", ITU-T
    E.164  Recommendation, May 1997

   [20] "Formats and codes of the ISDN User Part of Signaling System No.
    7", ITU-T Q.763 recommendation, March 1993.

17. Security Considerations

   The transit of ISUP in SIP bodies may provide may opportunities for
   abuse and fraud. In particular, SIP users may be able to interpret
   "private" (i.e. caller-id-blocked) numbers by examining the ISUP.
   Similarly, if care is not taken, SIP clients would be able to send
   ISUP messages into the SS7 network with invalid calling line
   identification and spoofed billing numbers.

   For these reasons, it is absolutely necessary that any ISUP sent
   through an IP network be strongly encrypted and authenticated.  The
   keys used for encryption should not be static, to prevent replay
   attacks. A challenge-response model is recommended. As an extra layer
   of security, it is recommended that ISUP be sent and received only to
   and from nodes that are known to have an established trust
   relationship with the gateway.







Camarillo/Roach/Peterson/Ong                                   [Page 53]


ISUP to SIP Mapping                                          August 2001


18. Authors' Addresses

     Gonzalo Camarillo
     Ericsson
     Advanced Signalling Research Lab
     FIN-02420 Jorvas
     Finland
     Phone: +358 9 299 3371
     Fax: +358 9 299 3052
     Email: Gonzalo.Camarillo@ericsson.com

     Adam Roach
     Ericsson Inc.
     Mailstop L-04
     851 International Pkwy.
     Richardson, TX 75081
     USA
     Phone: +1 972-583-7594
     Fax: +1 972-669-0154
     E-Mail: Adam.Roach@ericsson.com

     Jon Peterson
     NeuStar, Inc
     1800 Sutter Street, Suite 570
     Concord, CA 94520
     USA
     Phone: +19253638700
     E-Mail: jon.peterson@neustar.com

     Lyndon Ong
     Ciena
     10480 Ridgeview Court
     Cupertino, CA 95014
     E-Mail: lyOng@ciena.com

Full Copyright Statement

Copyright (c) The Internet Society (2001). 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



Camarillo/Roach/Peterson/Ong                                   [Page 54]


ISUP to SIP Mapping                                          August 2001


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.






































Camarillo/Roach/Peterson/Ong                                   [Page 55]