Internet Engineering Task Force             Gonzalo Camarillo/Adam Roach
Internet Draft                                                  Ericsson
Category: Informational                                       March 2000
                                                  Expires September 2000
                                   <draft-camarillo-sip-isup-bcp-00.txt>


             Best Current Practice for 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
     signalling protocols: SIP and ISUP.

Table of Contents

    1.       Introduction........................................... 3
    2.       Scope.................................................. 3
    3.       Scenarios.............................................. 4
    4.       Extensions Required.................................... 5
    4.1.     "Transparent" Transit of ISUP messages................. 5
    4.2.     Understanding of Multipart Bodies...................... 5
    4.3.     Transmission of DTMF information....................... 5
    4.4.     Reliable Transmission of Provisional Responses......... 6
    4.5.     Provisional Media Streams.............................. 6
    4.6.     Mid-Call Transactions Which do not Change SIP State.... 6
    5.       Mapping................................................ 6
    6.       SIP to ISUP mapping.................................... 7
    6.1.     Call Flows............................................. 7



Camarillo/Roach                                                 [Page 1]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


    6.1.1.   En-bloc Call Setup (non auto-answer)................... 7
    6.1.2.   Overlap Call Setup..................................... 8
    6.1.3.   Overlap call setup with a routing (redirect) server.... 11
    6.1.4.   Auto-answer call setup................................. 12
    6.1.5.   ISUP T7 expires........................................ 13
    6.1.6.   SIP Timeout............................................ 13
    6.1.7.   ISUP Setup Failure..................................... 15
    6.1.8.   Cause present in ACM message........................... 15
    6.1.9.   Call cancelled by SIP node............................. 17
    6.2.     State Machine.......................................... 18
    6.2.1.   INVITE received........................................ 19
    6.2.2.   ISUP T7 expires........................................ 21
    6.2.3.   CANCEL or BYE received................................. 21
    6.2.4.   REL received........................................... 22
    6.2.5.   Early ACM received..................................... 24
    6.2.6.   ACM received........................................... 24
    6.2.7.   CON or ANM received.................................... 25
    6.2.8.   Timer T9 expires....................................... 25
    6.2.9.   CPG received........................................... 25
    6.2.10.  ACK received........................................... 26
    7.       ISUP to SIP mapping.................................... 26
    7.1.     Call Flows............................................. 26
    7.1.1.   En-bloc call setup (non auto-answer)................... 26
    7.1.2.   Overlap call setup..................................... 27
    7.1.3.   Overlap call setup with a routing (redirect) server.... 30
    7.1.4.   Auto-answer call setup................................. 32
    7.1.5.   SIP Timeout............................................ 33
    7.1.6.   ISUP T9 Expires........................................ 34
    7.1.7.   SIP Error Response..................................... 35
    7.1.8.   SIP Redirection........................................ 36
    7.1.9.   Call Cancelled by ISUP................................. 37
    7.2.     State Machine.......................................... 38
    7.2.1.   Address received....................................... 39
    7.2.2.   100 received........................................... 40
    7.2.3.   18x received........................................... 40
    7.2.4.   200 received........................................... 41
    7.2.5.   3xx received........................................... 42
    7.2.6.   4xx - 6xx received..................................... 42
    7.2.7.   REL received........................................... 43
    7.2.8.   ISUP T11 Expires....................................... 44
    8.       Suspend/Resume......................................... 44
    9.       Normal Release of the Connection....................... 45
    9.1.     SIP initiated.......................................... 45
    9.2.     ISUP Initiated......................................... 45
    9.2.1.   Caller hangs up........................................ 46
    9.2.2.   Callee hangs up........................................ 46
    10.      ISUP maintenance messages.............................. 46
    10.1.    Reset messages......................................... 46
    10.2.    Blocking messages...................................... 47
    11.      Other ISUP flavours.................................... 47



Camarillo/Roach                                                 [Page 2]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


    12.      Acronyms............................................... 47
    13.      Acknowledgments........................................ 48
    14.      References............................................. 48
    15.      Security Considerations................................ 50
    16.      Authors' Addresses..................................... 50


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 will run also over IP (work in
     progress, IETF SIGTRAN working group). ISUP is used for
     controlling telephone calls and for maintenance of the network
     (blocking circuits, resetting circuits etc.).

     The module performing the mapping between these two protocols is
     usually referred to as Media Gateway Controller (MGC). It has
     logical interfaces towards both networks, the network carrying
     ISUP and the network carrying SIP, although usually they are on
     the same physical interface. The MGC also has capabilities for
     controlling the voice path. There is typically a Media Gateway
     (MG) with E1/T1 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.

2. Scope

     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.

     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 flavours of ISUP. ITU-T Q.767 International
     ISUP [2] is used through this document and some differences with
     ANSI ISUP [3] are outlined. ISUP Q.767 [2] was chosen because is
     the least complex of all the ISUP flavours. Once the mapping
     between this flavour of ISUP and SIP is clear, mapping from other
     flavours to SIP will be easier to resolve.

     This document describes when the media path has to be
     initialized, terminated, modified, etc., but it does not go into



Camarillo/Roach                                                 [Page 3]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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 carrying
     the incoming ISUP messages in the body of the SIP messages [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
     structure also allows the call to take advantage of certain SIP
     services. ISUP messages in the SIP bodies provide further
     information (such as cause values and optional parameters) to the
     peer MGC.

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

     There can be a Signalling Gateway (SG) between the PSTN and the
     MGC. It encapsulates the ISUP messages over IP. The mapping



Camarillo/Roach                                                 [Page 4]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     described in this document is not affected by its presence.

4. Extensions Required

     For a correct mapping between ISUP and SIP, some extensions to
     the basic SIP specification are needed. These extensions 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 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
     encouraged to recognize this MIME type and ignore it.

4.2. Understanding of Multipart Bodies

     In most PSTN interworking situations, the SIP body will be
     required to carry session information 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
     syncronization of the media stream for tone re-insertion). This
     transmission will be performed as described in "RTP Payload for
     DTMF Digits, Telephony Tones and Telephony Signals" [6] .

     In addition to the need to faithfully carry telephony tones
     across the audio channel, PSTN interworking situations will
     require the capability on the part of SIP nodes to collect
     further digits from the end user. This may be used, for example,



Camarillo/Roach                                                 [Page 5]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     to provide authentication information to a SIP node via DTMF
     without the SIP node needing to process the media stream. This
     transit is accomplished using the method described in section 2.1
     of "Sample Uses of SIP INFO with Varying Reliability Needs" [7] .

4.4. Reliable Transmission of Provisional Responses

     Provisional responses are used to transmission of various
     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 establishement of
     temporary provisional media streams, as specified in "SIP 183
     Session Progress Message" [9] .

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



Camarillo/Roach                                                 [Page 6]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     change in the state and the actions to take appear on the arrow:
     event / section describing the actions to take.

     For example, `INVITE / 6.1' indicates that an INVITE request has
     been received by the gateway, and the procedure upon reception is
     described in the section 6.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 explained, since their presence is optional.

     In these diagrams, all call singnalling (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."

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.



Camarillo/Roach                                                 [Page 7]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



     (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 (180 for "subscriber free" and
         183 for "no indication") 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) The remote ISUP node may issue a variety of CPG messages to
         indicate, for example, that the call is being forwarded.

     (8) Upon receipt of a CPG message, the gateway will map the event
         code to a SIP provisional response (see section 6.2.6. ) 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. Overlap Call Setup















Camarillo/Roach                                                 [Page 8]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     SIP                       MGC/MG                       PSTN
      1|---------INVITE---------->|                          |
      2|<----------484------------|                          |
      3|-----------ACK----------->|                          |
      4|---------INVITE---------->|                          |
       |<----------100------------|                          |
       |                          |------------IAM---------->|5
       |                          |<=========Audio===========|
      6|---------INVITE---------->|                          |
       |<----------100------------|                          |
       |                          |------------SAM---------->|7
      8|---------INVITE---------->|                          |
       |<----------100------------|                          |
       |                          |------------SAM---------->|9
     10|---------INVITE---------->|                          |
       |<----------100------------|                          |
       |                          |------------SAM---------->|11
       |                          |<-----------ACM-----------|12
     13|<----------180------------|                          |
       |<=========Audio===========|                          |
     14|<----------484------------|                          |
     15|<----------484------------|                          |
     16|<----------484------------|                          |
     17|----------PRACK---------->|                          |
     18|<----------200------------|                          |
     19|-----------ACK----------->|                          |
     20|-----------ACK----------->|                          |
     21|-----------ACK----------->|                          |
       |                          |<-----------ANM-----------|22
       |                          |<=========Audio==========>|
     23|<----------200------------|                          |
       |<=========Audio==========>|                          |
     24|-----------ACK----------->|                          |


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

     (2) The gateway may be able to determine that the number in the
         SIP message is not long enough to set up a call (for example;
         it may not have enough of a number to know what PSTN node to
         route to). Under these circumstances, it will immediately
         return a "484 Address Incomplete" message.

     (3) The 484 is acknowledged.

     (4) After collecting more digits, the SIP node sends another
         INVITE. This invite contains the same "From" and "Call-ID"
         headers. The "To" field is updated to reflect the entire
         called number as known so far. Since the "To" field is



Camarillo/Roach                                                 [Page 9]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         different, this transaction represents a different call leg
         than the INVITE in step 1; consequently, there is no
         relationship between the CSeq values in the two INVITE
         messages. Note that the gateway may drop state knowledge
         between steps 3 and 4 unless ISUP tunnelling is being
         performed. (For ISUP tunneling, the IAM present in the
         initial INVITE will need to be reserved for step 5).

     (5) Once the gateway is not sure that the number is too short, it
         will send out the digits from the INVITE message as an IAM.

     (6) As more digits are collected, they will also be sent as
         INVITE messages. Note that the "To" field still contains the
         entire string of digits collected so far, not just the new
         ones.

     (7) The newly collected digits are sent to the PSTN as SAM
         messages.

     (8) See step 6

     (9) See step 7

     (10) See step 6

     (11) See step 7

     (12) Once the remote PSTN node receives enough digits, it will
         send an ACM message to indicate that it can now route the
         call.

     (13) The gateway sends a 180 message for the most recent pending
         transaction (or a 183 if the "called party status" field is
         marked "no indication"). The transaction to which this
         response belongs will be same as the INVITE which contains a
         complete phone number in its "To" field (the one sent in step
         10).

     (14) "484 Address Incomplete" is sent to complete the INVITE
         transaction started in step 4.

     (15) "484 Address Incomplete" is sent to complete the INVITE
         transaction started in step 6.

     (16) "484 Address Incomplete" is sent to complete the INVITE
         transaction started in step 8.

     (17) The remote node sends a PRACK to acknowledge receipt of the
         18x message sent in step 13.




Camarillo/Roach                                                [Page 10]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     (18) The 484 from step 14 is acknowledged.

     (19) The 484 from step 15 is acknowledged.

     (20) The 484 from step 16 is acknowledged.

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

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

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

6.1.3. Overlap call setup with a routing (redirect) server

     SIP                    Routing Server                  PSTN
      1|---------INVITE---------->|                          |
      2|<----------484------------|                          |
      3|-----------ACK----------->|                          |
      4|---------INVITE---------->|                          |
      5|<----------484------------|                          |
      6|-----------ACK----------->|                          |
      7|---------INVITE---------->|                          |
      8|<----------302------------|                          |
      9|-----------ACK----------->|                          |
       |                                                     |
       |                                                     |
       |                       MGC/MG                        |
     10|---------INVITE---------->|                          |
                   ...


     (1) When a SIP user wishes to begin a session with a PSTN user,
         the SIP node issues an INVITE request. In this example, the
         INVITE is sent to a server which knows how to select the
         egress gateway based on a numbering prefix.

     (2) Since the routing server doesn't have enough information to
         select an egress gateway, it responds with a "484 Address
         Incomplete".

     (3) The 484 is acknowledged.

     (4) After collecting more digits, the SIP node sends another
         INVITE. This invite contains the same "From" and "Call-ID"
         headers. The "To" field is updated to reflect the entire
         called number as known so far. Since the "To" field is
         different, this transaction represents a different call leg



Camarillo/Roach                                                [Page 11]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         than the INVITE in step 1; consequently, there is no
         relationship between the CSeq values in the two INVITE
         messages. Note that the routing server will probably drop
         state knowledge between steps 3 and 4.

     (5) In this example, there is still not enough information to
         route the call.

     (6) The 484 is acknowledged.

     (7) As in step 4, more digits are collected. While this INVITE
         contains enough information for the routing server to select
         a gateway, it is quite probable that the number is not yet
         complete.

     (8) A "302 Temporarily Moved" response is returned to redirect
         the SIP node to the appropriate gateway. (In practice, this
         may not necessarily be a gateway; it might be another
         redirect server, a proxy server, or a native client).

     (9) The 302 is acknowledged.

     (10) The call now continues as in step 1 of section 6.1.2.

6.1.4. Auto-answer call setup

     SIP                       MGC/MG                       PSTN
      1|---------INVITE---------->|                          |
       |<----------100------------|                          |
       |                          |------------IAM---------->|2
       |                          |<=========Audio===========|
       |                          |<-----------CON-----------|3
       |                          |<=========Audio==========>|
      4|<----------200------------|                          |
       |<=========Audio==========>|                          |
      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.

     (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 ANM, the gateway will send a 200 message
         to the SIP node.



Camarillo/Roach                                                [Page 12]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



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

6.1.5. 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.6. SIP Timeout




















Camarillo/Roach                                                [Page 13]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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


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

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

     (3) Since the remote node is configured for automatic answering,
         it will send a CON message upon receipt of the IAM.

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




Camarillo/Roach                                                [Page 14]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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

6.1.7. ISUP Setup Failure

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


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

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

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

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

     (5) The gateway translates the cause code in the REL to a SIP
         error response (see section 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.8. Cause present in ACM message


















Camarillo/Roach                                                [Page 15]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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, the gateway will generate
         a 183  message towards the SIP node; this contains SDP to
         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 SIP 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 signalling
         progresses as in section 6.1.9.

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




Camarillo/Roach                                                [Page 16]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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

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

     (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 (180 for "subscriber free" and
         183 for "no indication") 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



Camarillo/Roach                                                [Page 17]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         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                                                [Page 18]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


                                   +---------+
          +----------------------->|  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 MG gets backward through connected.



Camarillo/Roach                                                [Page 19]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



     An ISUP IAM is sent. If the incoming INVITE contains a IAM in its
     body this IAM is sent (possibly with certain changes; for
     example, the called number may need to be updated from the "To"
     field if the call was redirected inside the SIP network). If no
     IAM is present the MGC generates one. The mandatory parameters of
     the IAM are described below:




     Message type:                             IAM

     Nature of connection indicators
     Satellite Indicator:                    00 no satellite circuit
     Continuity check indicator:             It depends on the call
                                             typically, 0 (no check)
     Echo control device indicator:          It depends on the call

     Forward call indicators
     National/International call indicator:  It depends on the call
     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
     ISDN user part preference indicator:    00 ISUP preferred
     ISDN access indicator:                  1  ISDN access
     SCCP method indicator:                  0  no indication

     Calling party's category:               Depends on caller; usually
                                             00001010 ordinary

     Transmission medium requirement:        It depends on the call

     Called party's number:                  Based on the 'to' field


     The optional parameter `Calling party number' can be added. Its
     value can be derived based on the SIP `from' header. Optionally,
     if this information cannot be verified, it may be sent as a
     `Generic Address Parameter.' Further, the gateway may choose to
     populate the `Original Called Number' (if it had to update the
     `Called Number' field) and the `Charge Number' field (based on a
     billing number obtained through means which are outside the scope
     of this document).

     When the ISUP parameters regarding interworking are set, 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.



Camarillo/Roach                                                [Page 20]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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

     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.

     When overlap signalling is used in SIP bridging situations, more
     INVITEs might arrive containing subsequent digits of the callees'
      number. These INVITEs have the same Call-ID and From fields, but
     the To field contains more digits.

     The MGC receives these digits and sends a SAM with the new digits
     and restarts T7 every time a new INVITE arrives. All the INVITEs
     but the last one containing all the digits are answered with 484
     Address Incomplete. The reception of an ACM from the ISUP network
     confirms that the callees' address is complete.

     See sections 6.1.2. and 7.1.2. for a more detailed handling of
     overlapped dialing.

6.2.2. ISUP T7 expires

     Since no response was received from the PSTN all the resources in
     the MG are released. A `408 request timeout' is sent back to the
     SIP network. A REL message with cause value 111 (protocol error)
     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.



Camarillo/Roach                                                [Page 21]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



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

     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 ISUP
     messages in its body (IAM or SAMs), the MGC is handling a SIP
     bridging situation. Therefore, the REL message jut received
     should be included in the body of the  response.

     The REL contains a cause value. The SIP response is sent based on
     this cause value. If a cause value other than what is listed
     below is received, the default response `500 Server internal
     error' would be used.

     Normal event

     ISUP Cause value                        SIP response
     ----------------                        ------------
     1  unallocated number                   410 Gone
     2  no route to network                  404 Not found
     3  no route to destination              404 Not found
     4  send special information tone        ---
     16 normal call clearing                 ---
     17 user busy                            486 Busy here
     18 no user responding                   480 Temporarily unavailable
     19 no answer from the user              480 Temporarily unavailable
     21 call rejected                        603 Decline
     22 number changed                       301 Moved Permanently
     27 destination out of order             404 Not found
     28 address incomplete                   484 Address incomplete
     29 facility rejected                    501 Not implemented
     31 normal unspecified                   404 Not found


     A REL with cause 22 (number changed) might contain information
     about a new number where the callee might be reachable. If the
     MGC is able to parse this information it might be added to the
     SIP response in a Contact header.




Camarillo/Roach                                                [Page 22]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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
     44 requested channel not available      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 bared within CUG      603 Decline
     57 bearer capability not authorized     503 Service unavailable
     58 bearer capability not presently      503 Service unavailable
        available
     63 service/option not available         503 Service unavailable


     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                                                [Page 23]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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.

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



Camarillo/Roach                                                [Page 24]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



     A `180 Ringing' is sent to the SIP network. It contains a media
     description. The ringback tone or the proper announcements will
     be generated by the PSTN exchange, and not by the callers SIP
     UAC/UAS.

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




Camarillo/Roach                                                [Page 25]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


6.2.10. ACK received

     At this stage, the two-way voice channel may be modified based on
     the SDP present in the ACK. 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 singnalling (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-----------|                          |
     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



Camarillo/Roach                                                [Page 26]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         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. If this 180 contains
         a session description,

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

7.1.2. Overlap call setup

     Note that supporting overlap dialing in the SIP network is an
     option that may be deemed undesirable due to the large number of
     messages involved. In this case, the gateway may elect to collect
     digits until a timer expires or a stop digit (such as #) is
     entered by the user.









Camarillo/Roach                                                [Page 27]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------484----------->|                          |
      4|<----------ACK------------|                          |
       |                          |<-----------SAM-----------|5
      6|<--------INVITE-----------|                          |
       |-----------100----------->|                          |
       |                          |<-----------SAM-----------|7
      8|<--------INVITE-----------|                          |
       |-----------100----------->|                          |
       |                          |<-----------SAM-----------|9
     10|<--------INVITE-----------|                          |
       |-----------100----------->|                          |
       |                          |<-----------SAM-----------|11
     12|<--------INVITE-----------|                          |
       |-----------100----------->|                          |
     13|-----------18x----------->|                          |
       |==========Audio==========>|                          |
     14|<---------PRACK-----------|                          |
       |                          |------------ACM---------->|15
     16|-----------484----------->|                          |
     17|<----------ACK------------|                          |
     18|-----------484----------->|                          |
     19|<----------ACK------------|                          |
     20|-----------484----------->|                          |
     21|<----------ACK------------|                          |
     22|-----------200----------->|                          |
     23|-----------18x----------->|                          |
       |                          |------------CPG---------->|24
     25|<---------PRACK-----------|                          |
     26|-----------200----------->|                          |
     27|-----------200----------->|                          |
       |<=========Audio==========>|                          |
       |                          |------------ANM---------->|28
       |                          |<=========Audio==========>|
     29|<----------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. It is possible that the gateway
         won't have enough information to send the INVITE yet; this
         situation is not shown. Under these circumstances, the
         gateway holds on to the IAM until it has received enough



Camarillo/Roach                                                [Page 28]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         digits that it knows where to send the INVITE.

     (3) The far end may immediately determine that it is unable to
         terminate the call due to an insufficient number of digits.
         It will return a "484 Address Incomplete" message under these
         circumstances.

     (4) The 484 is acknowledged.

     (5) A SAM arrives from the PSTN with additional digits present.

     (6) The gateway appends the new digits to the number it is
         sending in the "To" field and re-sends the INVITE.  This
         INVITE contains the same "From" and "Call-ID" headers. Since
         the "To" field of this message is different from the previous
         INVITE(s), this transaction represents a different call leg
         than the INVITE in step 1; consequently, there is no
         relationship between the CSeq values in the two INVITE
         messages.

     (7) See step 5

     (8) See step 6

     (9) See step 5

     (10) See step 6

     (11) See step 5

     (12) See step 6

     (13) Once the far end SIP node has determined that it has enough
         information to successfully route the call, it sends a 18x
         message.

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

     (15) Upon receipt of a provisional response of 180 or greater,
         the gateway will generate an ACM message to indicate that
         enough digits have been collected. If the response is not
         180, the ACM will carry a "called party status" value of "no
         indication."

     (16) "484 Address Incomplete" arrives to complete the INVITE
         transaction started in step 6.

     (17) The 484 in step 16 is acknowledged




Camarillo/Roach                                                [Page 29]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     (18) "484 Address Incomplete" arrives to complete the INVITE
         transaction started in step 8.

     (19) The 484 in step 18 is acknowledged

     (20) "484 Address Incomplete" arrives to complete the INVITE
         transaction started in step 10.

     (21) The 484 in step 20 is acknowledged

     (22) The PRACK from step 14 is acknowledged

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

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

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

     (26) The PRACK is confirmed

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

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

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

7.1.3. Overlap call setup with a routing (redirect) server




















Camarillo/Roach                                                [Page 30]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     Redirect Server           MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------484----------->|                          |
      4|<----------ACK------------|                          |
       |                          |<-----------SAM-----------|5
      6|<--------INVITE-----------|                          |
      7|-----------484----------->|                          |
      8|<----------ACK------------|                          |
       |                          |<-----------SAM-----------|9
     10|<--------INVITE-----------|                          |
     11|-----------302----------->|                          |
     12|<----------ACK------------|                          |
                                  |                          |
                                  |                          |
     Egress MGC/MG                |                          |
     13|<--------INVITE-----------|                          |
       |-----------100----------->|                          |
       |                          |<-----------SAM-----------|
                   ...


     (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. In this example, this node is a
         routing (redirection) server.

     (3) Since the routing server doesn't have enough information to
         select an egress gateway, it responds with a "484 Address
         Incomplete".

     (4) The 484 is acknowledged.

     (5) After collecting more digits, the PSTN node sends a SAM with
         the additional digits.

     (6) The gateway appends the new digits to the number it is
         sending in the "To" field and re-sends the INVITE.  This
         INVITE contains the same "From" and "Call-ID" headers. Since
         the "To" field of this message is different from the previous
         INVITE(s), this transaction represents a different call leg
         than the INVITE in step 1; consequently, there is no
         relationship between the CSeq values in the two INVITE
         messages.




Camarillo/Roach                                                [Page 31]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     (7) In this example, there is still not enough information to
         route the call.

     (8) The 484 is acknowledged.

     (9) See step 5.

     (10) See step 6.

     (11) The INVITE finally contains enough digits that the redirect
         server can select a next-hop SIP node. A "302 Temporarily
         Moved" response is returned to redirect the SIP node to the
         appropriate gateway. (In practice, this may not necessarily
         be a gateway; it might be another redirect server, a proxy
         server, or a native client). Note that it is quite probable
         that the called number is not completely collected at this
         time; sending an ACM towards the PSTN would be extremely
         destructive at this point in the call, since it would prevent
         any further collection of digits.

     (12) The 302 is acknowledged.

     (13) The call now continues as in step 2 of section 7.1.2.

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



Camarillo/Roach                                                [Page 32]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



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

7.1.5. SIP Timeout

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
      3|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |                          |    *** T11 Expires ***   |
       |                          |------------ACM---------->|4
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |             ** MG Releases PSTN Trunk **            |
       |                          |------------REL---------->|5
      6|<--------CANCEL-----------|                          |
       |                          |<-----------RLC-----------|7


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

     (2) Upon receipt of the IAM message, the gateway generates an
         INVITE message, and sends it to an appropriate SIP node based
         on called number analysis. The ISUP timer T11 and SIP timer
         T1 are set at this time.

     (3) The INVITE message will continue to be sent to the SIP node
         each time the timer T1 expires. The SIP standard specifies
         that INVITE transmission will be performed 7 times if no
         response is received.

     (4) When T11 expires, an ACM message will be sent to the ISUP
         node to prevent the from being torn down by the remote node's
         ISUP T7. This ACM contains a `Called Party Status' value of
         `no indication.'




Camarillo/Roach                                                [Page 33]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     (5) Once the maximum number of INVITE requests has been sent, the
         gateway will send a REL to the ISUP node to terminate the
         call. Since this would appear to be a serious problem with
         the network, the REL contains a cause code of 38: network out
         of order.

     (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.6. ISUP T9 Expires

     SIP                       MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
      3|<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |                          |    *** T11 Expires ***   |
       |                          |------------ACM---------->|4
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |    *** T1 Expires ***    |                          |
       |<--------INVITE-----------|                          |
       |                          |    *** T9 Expires ***    |
       |             ** MG Releases PSTN Trunk **            |
       |                          |<-----------REL-----------|5
       |                          |------------RLC---------->|6
      7|<--------CANCEL-----------|                          |


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

     (2) Upon receipt of the IAM message, the gateway generates an
         INVITE message, and sends it to an appropriate SIP node based
         on called number analysis. The ISUP timer T11 and SIP timer
         T1 are set at this time.

     (3) The INVITE message will continue to be sent to the SIP node
         each time the timer T1 expires. The SIP standard specifies
         that INVITE transmission will be performed 7 times if no
         response is received. Since SIP T1 starts at 1/2 second or



Camarillo/Roach                                                [Page 34]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         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.

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




Camarillo/Roach                                                [Page 35]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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

7.1.8. SIP Redirection

     SIP node 1                MGC/MG                       PSTN
       |                          |<-----------IAM-----------|1
       |                          |==========Audio==========>|
      2|<--------INVITE-----------|                          |
      3|-----------3xx+---------->|                          |
       |                          |------------CPG---------->|4
      5|<----------ACK------------|                          |
                                  |                          |
                                  |                          |
     SIP node 2                   |                          |
      6|<--------INVITE-----------|                          |
      7|-----------18x----------->|                          |
       |<=========Audio===========|                          |
       |                          |------------ACM---------->|8
      9|<---------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



Camarillo/Roach                                                [Page 36]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         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.

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



Camarillo/Roach                                                [Page 37]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         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
         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                                                [Page 38]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


                                   +---------+
          +----------------------->|  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.1  |
          +<------------+          Connected          +------------>+
                        +-----------------------------+


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

     The called number can be received in just one IAM (`en bloc'
     signalling) or in one IAM followed by one or several SAMs
     (overlap signalling). In some countries there is no way for the
     MGC to know whether the callees' number is already complete or
     some SAMs will still arrive.

     If the MGC relies on the inter-digit timeout to assume that the
     number is complete, the establishment of the connection is
     delayed. Alternatively, if the MGC sends the INVITE request
     immediately after receiving the IAM, heavy signalling traffic may
     be generated.




Camarillo/Roach                                                [Page 39]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     Therefore, an individual MGC might implement a timer and/or a
     stop digit (such as #). All the digits that arrive before this
     timer expires will be included in the INVITE sent. The timer can
     be bypassed by the user sending the stop digit. This timer should
     not be larger than 5 seconds.

     Thus, after receiving the IAM and possibly one or several SAMs,
     the MGC issues an INVITE request. The "To" field contains the
     digits received so far. If, after sending this INVITE request,
     one or more SAMs are received, the MGC sends a new INVITE. This
     new INVITE has the same "From" and "Call-ID" as  the previous
     INVITE sent. The "To" field is updated and contains all the
     available digits.

     `484 Address Incomplete' responses will be received for all the
     INVITEs sent with the incomplete callees number. Thus, all the
     call legs (same `Call-ID', different to) created while the digits
     are arriving are deleted.

     See sections 6.1.2. and 7.1.2. for a more detailed handling of
     overlapped dialing.

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.








Camarillo/Roach                                                [Page 40]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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

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



Camarillo/Roach                                                [Page 41]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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. If the response body contains an ACM and an
     ANM both are sent to the PSTN (first the ACM and then the ANM).

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.

     The 3xx MUST NOT  result in the generation of an ACM message,
     since there may be more digits pending in overlap dialing
     situations. See sections 6.1.3. and 7.1.3. for callflows that
     demonstrate the situations in which this behavior would prove
     harmful.

     In SIP bridging situations, the MGC sends the ISUP message
     contained in the response body (if any). It is worthwhile
     mentioning that a REL with cause value 22 (number changed) might
     be contained in the response body of the 3xx response. This REL
     might contain a new number where the callee might be reachable.

     This REL can be sent to the PSTN, but most of the PSTN switches
     are not able to process this information. Thus, if the MGC is
     able to parse the new number, it might try the new location.

     If the new location is reachable via 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 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



Camarillo/Roach                                                [Page 42]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



     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.

     Response received                        Cause value in the REL
     -----------------                        ----------------------
     400 Bad request                         127 Interworking
     401 Unauthorized                         21 Call rejected
     402 Payment required                     21 Call rejected
     403 Forbidden                             1 Unallocated number
     404 Not found                             1 Unallocated number
     405 Method not allowed                   38 Network out of order
     406 Not acceptable                       58 Bearer capability not
                                                 presently available
     407 Proxy authentication required        21 Call rejected
     408 Request timeout                     102 Recovery on timer expiry
     409 Conflict                             41 Temporary failure
     410 Gone                                  1 Unallocated number
     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
     481 Call leg/transaction doesn't exist  127 Interworking
     482 Loop detected                       127 Interworking
     483 Too many hoops                      127 Interworking
     484 Address incomplete                  ---
     485 Ambiguous                             1  Unallocated number
     486 Busy here                            17 User busy
     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 Gateway time-out                    102 Recovery on timer expiry
     505 Version not supported               127 Interworking
     600 Busy everywhere                      17 User busy
     603 Decline                              21 Call rejected
     604 Does not exist anywhere               1 Unallocated number
     606 Not acceptable                       38 Network out of order


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.



Camarillo/Roach                                                [Page 43]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



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

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

8. Suspend/Resume

     In ISDN networks, the 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.




Camarillo/Roach                                                [Page 44]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     When a SUS arrives from the PSTN, the MGC sends an INVITE to put
     the media stream on hold. The reception of a RES triggers another
     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.

     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 prior to call teardown is
     handled in section 9.2.2.

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


9.2. ISUP Initiated




Camarillo/Roach                                                [Page 45]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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.

10.1. Reset messages



Camarillo/Roach                                                [Page 46]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000



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

11. Other ISUP flavours

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

     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. No SAMs are sent. `En bloc' signalling is
     always used.

12. Acronyms













Camarillo/Roach                                                [Page 47]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


     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
     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               Signalling Connection Control Part
     SG                 Signalling Gateway
     SIP                Session Initiation Protocol
     SS7                System Signalling No. 7
     SUS                Suspend Message
     UAC                User Agent Client
     UAS                User Agent Server
     UDP                User Data Protocol
     VoIP               Voice over IP


13. Acknowledgments

     The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill
     Kavadas, and Miguel A. Garcia for their help and feedback on this
     document.

14. References

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




Camarillo/Roach                                                [Page 48]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


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

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

     [4] E Zimmerer/A. Vemuri/L. Ong/M. Zonoun/M. Watson, "MIME media
         types for ISUP and QSIG Objects", Internet Draft
         <draft-ietf-sip-isup-mime-00.txt>, IETF; January 2000. 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", Internet Draft
         <draft-ietf-avt-tones-07.txt>, IETF; February 2000. Work in
         progress.

     [7] Jiri Kuthan, "Sample Uses of SIP INFO with Varying
         Reliability Needs", Internet Draft
         <draft-kuthan-sip-infopayload-00.txt>, IETF; October 1999.
         Work in progress.

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

     [9] S. Donovan/M. Cannon/H. Schulzrinne/J. Rosenberg/A. Roach,
         "SIP 183 Session Progress Message", Internet draft IETF
         October 1999. Work in progress.

     [10] Steven R. Donovan, "The SIP INFO Method", Internet Draft
         <draft-ietf-sip-info-method-02.txt>, IETF; February 2000.
         Work in progress.

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

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

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

     [14] "Specifications of Signalling System No. 7 - ISDN User Part



Camarillo/Roach                                                [Page 49]


Internet Draft        BCP for SIP to ISUP Mapping             March 2000


         Signalling Procedures" ITU-T Q.764 recommendation, March
         1993.

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

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













Camarillo/Roach                                                [Page 50]