tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3398

 
 
 

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

Part 2 of 3, p. 30 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 30 
8. ISUP to SIP Mapping

8.1 ISUP to SIP Call Flows

   The following call flows illustrate the order of messages in typical
   success and error cases when setting up a call initiated from the
   PSTN network.  "100 Trying" acknowledgements to INVITE requests are
   not depicted, since their presence is optional.

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

Top      Up      ToC       Page 31 
8.1.1 En-bloc call setup (non auto-answer)

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

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

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

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

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

   5.  The SIP node may use further provisional messages to indicate
       session progress.

   6.  After an ACM has been sent, all provisional responses will
       translate into ISUP CPG messages as indicated in Section 8.2.3.

   7.  When the SIP node answers the call, it will send a 200 OK
       message.

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

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

Top      Up      ToC       Page 32 
8.1.2 Auto-answer call setup

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

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

   2.  Upon receipt of the IAM message, the gateway generates an INVITE
       message and sends it to an appropriate SIP node based on called
       number analysis.

   3.  Since the SIP node is set up to automatically answer the call, it
       will send a 200 OK message.

   4.  Upon receipt of the 200 OK message, the gateway will send a CON
       message towards the ISUP node.

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

Top      Up      ToC       Page 33 
8.1.3 SIP Timeout

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

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

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

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

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

   5.  Once the maximum number of INVITE requests has been sent, the
       gateway will send a REL (cause code 18) to the ISUP node to
       terminate the call.

   6.  The gateway also sends a CANCEL message to the SIP node to
       terminate any initiation attempts.

   7.  Upon receipt of the REL, the remote ISUP node will send an RLC to
       acknowledge.

8.1.4 ISUP T9 Expires

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

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

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

Top      Up      ToC       Page 35 
   3.  The INVITE message will continue to be sent to the SIP node each
       time the timer T1 expires.  The SIP standard specifies that
       INVITE transmission will be performed 7 times if no response is
       received.  Since SIP T1 starts at 1/2 second or more and doubles
       each time it is retransmitted, it will be at least a minute
       before SIP times out the INVITE request; since SIP T1 is allowed
       to be larger than 500 ms initially, it is possible that 7 x SIP
       T1 will be longer than ISUP T11 + ISUP T9.

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

   5.  When ISUP T9 in the remote PSTN node expires, it will send a REL.

   6.  Upon receipt of the REL, the gateway will send an RLC to
       acknowledge.

   7.  The REL will trigger a CANCEL request, which gets sent to the SIP
       node.

8.1.5 SIP Error Response

       SIP                       MGC/MG                       PSTN
         |                          |<-----------IAM-----------|1
         |                          |==========Audio==========>|
        2|<--------INVITE-----------|                          |
        3|-----------4xx+---------->|                          |
        4|<----------ACK------------|                          |
         |             ** MG Releases PSTN Trunk **            |
         |                          |------------REL---------->|5
         |                          |<-----------RLC-----------|6

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

   2.  Upon receipt of the IAM message, the gateway generates an INVITE
       message, and sends it to an appropriate SIP node based on called
       number analysis.

   3.  The SIP node indicates an error condition by replying with a
       response with a code of 400 or greater.

   4.  The gateway sends an ACK message to acknowledge receipt of the
       INVITE final response.

Top      Up      ToC       Page 36 
   5.  An ISUP REL message is generated from the SIP code, as specified
       in Section 8.2.6.1.

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

8.1.6 SIP Redirection

       SIP node 1                MGC/MG                       PSTN
         |                          |<-----------IAM-----------|1
         |                          |==========Audio==========>|
        2|<--------INVITE-----------|                          |
        3|-----------3xx+---------->|                          |
         |                          |------------CPG---------->|4
        5|<----------ACK------------|                          |
                                    |                          |
                                    |                          |
       SIP node 2                   |                          |
        6|<--------INVITE-----------|                          |
        7|-----------18x----------->|                          |
         |<=========Audio===========|                          |
         |                          |------------ACM---------->|8
        9|-----------200-(I)------->|                          |
         |<=========Audio==========>|                          |
         |                          |------------ANM---------->|10
         |                          |<=========Audio==========>|
       11|<----------ACK------------|                          |

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

   2.  Upon receipt of the IAM message, the gateway generates an INVITE
       message, and sends it to an appropriate SIP node based on called
       number analysis.

   3.  The SIP node indicates that the resource which the user is
       attempting to contact is at a different location by sending a 3xx
       message.  In this instance we assume the Contact URL specifies a
       valid URL reachable by a VoIP SIP call.

   4.  The gateway sends a CPG with event indication that the call is
       being forwarded upon receipt of the 3xx message.  Note that this
       translation should be able to be disabled by configuration, as
       some ISUP nodes do not support receipt of CPG messages before ACM
       messages.

   5.  The gateway acknowledges receipt of the INVITE final response by
       sending an ACK message to the SIP node.

Top      Up      ToC       Page 37 
   6.  The gateway re-sends the INVITE message to the address indicated
       in the Contact: field of the 3xx message.

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

   8.  Upon receipt of a provisional response of 180 or greater, the
       gateway will generate an ACM message with an event code as
       indicated in Section 8.2.3.

   9.  When the SIP node answers the call, it will send a 200 OK
       message.

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

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

8.1.7 Call Canceled by ISUP

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

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

   2.  Upon receipt of the IAM message, the gateway generates an INVITE
       message, and sends it to an appropriate SIP node based on called
       number analysis.

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

Top      Up      ToC       Page 38 
   4.  Upon receipt of a provisional response of 180 or greater, the
       gateway will generate an ACM message with an event code as
       indicated in Section 8.2.3.

   5.  If the calling party hangs up before the SIP node answers the
       call, a REL message will be generated.

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

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

   8.  Upon receipt of the CANCEL, the SIP node will send a 200
       response.

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

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

Top      Up      ToC       Page 39 
8.2 State Machine

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

                                 +---------+
        +----------------------->|  Idle   |<---------------------+
        |                        +----+----+                      |
        |                             |                           |
        |                             | IAM/7.2.1                 |
        |                             V                           |
        |    REL/7.2.7    +-------------------------+ 400+/7.2.6  |
        +<----------------+         Trying          |------------>|
        |                 +-+--------+------+-------+             |
        |                   |        |      |                     |
        |                   | T11/   | 18x/ | 200/                |
        |                   | 7.2.8  |7.2.3 | 7.2.4               |
        |                   V        |      |                     |
        | REL/7.2.7 +--------------+ |      |      400+/7.2.6     |
        |<----------| Progressing  |-|------|-------------------->|
        |           +--+----+------+ |      |                     |
        |              |    |        |      |                     |
        |        200/  |    | 18x/   |      |                     |
        |        7.2.4 |    | 7.2.3  |      |                     |
        |              |    V        V      |                     |
        |  REL/7.2.7   |  +---------------+ |      400+/7.2.6     |
        |<-------------|--|    Alerting   |-|-------------------->|
        |              |  +--------+------+ |                     |
        |              |           |        |                     |
        |              |           | 200/   |                     |
        |              |           | 7.2.4  |                     |
        |              V           V        V                     |
        |     BYE/9.1 +-----------------------------+    REL/9.2  |
        +<------------+          Connected          +------------>+
                      +-----------------------------+

8.2.1 Initial Address Message received

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

Top      Up      ToC       Page 40 
8.2.1.1 IAM to INVITE procedures

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

   The context of the call setup request read by the gateway in the IAM
   will be mapped primarily to two URIs in the INVITE, one representing
   the originator of the session and the other its destination.  The
   former will always appear in the From header (after it has been
   converted from ISUP format by the procedure described in Section 12),
   and the latter is almost always used for both the To header and the
   Request-URI.

   Once the address of the called party number has been read from the
   IAM, it SHOULD be translated into a destination tel URL that will
   serve as the Request-URI of the INVITE.  Alternatively, a gateway MAY
   first attempt a Telephone Number Mapping (ENUM) [8] query to resolve
   the called party number to a URI.  Some additional ISUP fields MAY be
   added to the tel URL after translation has been completed, namely:

   o  If the gateway supports carrier-based routing (which is optional
      in this specification), it SHOULD ascertain if either the CIP (in
      ANSI networks) or TNS parameter is present in the IAM.  If a value
      is present, the CIC SHOULD be extracted from the given parameter
      and analyzed by the gateway.  A 'cic=' field with the value of the
      CIC SHOULD be appended to the destination tel URL, if doing so is
      in keeping with local policy (i.e., provided that the CIC does not
      indicate the network which owns the gateway or some similar
      condition).  Note that if it is created, the 'cic=' parameter MUST
      be prefixed with the country code used or implied in the called
      party number, so that CIC '5062' becomes, in the United States,
      '+1-5062'.  For further information on the 'cic=' tel URL field
      see [21].

   o  If the gateway supports number portability-based routing (which is
      optional in this specification), then the gateway will need to
      look at a few other fields.  To correctly map the FCI 'number
      translated' bit indicating that an LNP dip had been performed in
      the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL.
      If a GAP is present in the IAM, then the contents of the CPN (the
      Location Routing Number - LRN) SHOULD be translated from ISUP
      format (as described in Section 12) and copied into an 'rn=' field
      which must be appended to the tel URL, whereas the GAP itself
      should be translated to ISUP format and used to populate the
      primary telephone number field of the tel URL.  Note that in some
      national numbering plans, both the LRN and the dialed number may

Top      Up      ToC       Page 41 
      be stored in the CPN parameter, in which case they must be
      separated out into different fields to be stored in the tel URL.
      Note that LRNs are necessarily national in scope, and consequently
      they MUST NOT be preceded by a '+' in the 'rn=' field.  For
      further information on these tel URL fields see [21].

   In most cases, the resulting destination tel URL SHOULD be used in
   both the To field and Request-URI sent by the gateway.  However, if
   the OCN parameter is present in the IAM, the To field SHOULD be
   constructed from the translation (from ISUP format following Section
   12 of the OCN parameter, and hence the Request-URI and To field MAY
   be different.

   The construction of the From header field is dependent on the
   presence of a CIN parameter.  If the CIN is not present, then the
   gateway SHOULD create a dummy From header field containing a SIP URI
   without a user portion which communicates only the hostname of the
   gateway (e.g., 'sip:gw.sipcarrier.com).  If the CIN is available,
   then it SHOULD be translated (in accordance with the procedure
   described above) into a tel URL which should populate the From header
   field.  In either case, local policy or requests for presentation
   restriction (see Section 12.1) MAY result in a different value for
   the From header field.

8.2.2 100 received

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

8.2.3 18x received

   Upon receipt of a 18x provisional response, if no ACM has been sent
   and no legitimate and comprehensible ISUP is present in the 18x
   message body, then the ISUP message SHOULD be generated according to
   the following table.  Note that if an early ACM is sent, the call
   MUST enter state "Progressing" instead of state "Alerting."

   Response received                        Message sent by the MGC
   -----------------                        -----------------------
   180 Ringing                              ACM (BCI = subscriber free)
   181 Call is being forwarded              Early ACM and CPG, event=6
   182 Queued                               ACM (BCI = no indication)
   183 Session progress message             ACM (BCI = no indication)

Top      Up      ToC       Page 42 
   If an ACM has already been sent and no ISUP is present in the 18x
   message body, an ISUP message SHOULD be generated according to the
   following table.

   Response received                        Message sent by the MGC
   -----------------                        -----------------------
   180 Ringing                              CPG, event = 1 (Alerting)
   181 Call is being forwarded              CPG, event = 6 (Forwarding)
   182 Queued                               CPG, event = 2 (Progress)
   183 Session progress message             CPG, event = 2 (Progress)

   Upon receipt of a 180 response, the gateway SHOULD generate the
   ringback tone to be heard by the caller on the PSTN side (unless the
   gateway knows that ringback will be provided by the network on the
   PSTN side).

   Note however that a gateway might receive media at any time after it
   has transmitted an SDP offer that it has sent in an INVITE, even
   before a 18x provisional response is received.  Therefore the gateway
   MUST be prepared to play this media to the caller on the PSTN side
   (if necessary, ceasing any ringback tone that it may have begun to
   generate and then playing media).  Note that the gateway may also
   receive SDP offers in responses for an early media session using some
   SIP extension, see Section 5.5.  If a gateway receives a 183 response
   while it is playing backwards media, then when it generates a mapping
   for this response, if no encapsulated ISUP is present, the gateway
   SHOULD indicate that in-band information is available (for example,
   with the Event Information parameter of the CPG message or the
   Optional Backward Call Indicators parameter of the ACM).

   When an ACM is sent, the mandatory Backward Call Indicators parameter
   must be set, as well as any optional parameters as gateway policy
   dictates.  If legitimate and comprehensible ISUP is present in the
   18x response, the gateway SHOULD re-use the appropriate parameters of
   the ISUP message contained in the response body, including the value
   of the Backward Call Indicator parameter, as it formulates a message
   that it will send across its PSTN interface.  In the absence of a
   usable encapsulated ACM, the BCI parameter SHOULD be set as follows:

Top      Up      ToC       Page 43 
   Message type:                            ACM

   Backward Call Indicators
   Charge indicator:                      10 charge
   Called party's status indicator:       01 subscriber free or
                                          00 no indication
   Called party's category indicator:     01 ordinary subscriber
   End-to-end method indicator:           00 no end-to-end method
   Interworking indicator:                0  no interworking
   End-to-end information indicator:      0  no end-to-end info
   ISDN user part indicator:              1  ISUP used all the way
   Holding indicator:                     0  no holding
   ISDN access indicator:                 0  No ISDN access
   Echo control device indicator:         It depends on the call
   SCCP method indicator:                 00 no indication

   Note that when the ISUP Backward Call Indicator parameter
   Interworking indicator field is set to 'interworking encountered',
   this indicates that ISDN is interworking with a network which is not
   capable of providing as many services as ISDN does.  ISUP therefore
   may not employ certain features it otherwise normally uses.  Gateway
   vendors MAY however provide a configurable option, usable at the
   discretion of service providers when they require additional ISUP
   services, that in the absence of encapsulated ISUP will signal in the
   BCI that interworking has been encountered, and that ISUP is not used
   all the way, for those operators that as a matter of policy would
   rather operate in this mode.  For more information on the effects of
   interworking see Section 7.2.1.1.

8.2.4 2xx received

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

   After receiving a 200 OK response the gateway MUST establish a
   directional media path in the gateway and send an ANM to the PSTN as
   well as an ACK to the SIP network.

   If the 200 OK response arrives before the gateway has sent an ACM, a
   CON is sent instead of the ANM, in those ISUP variants that support
   the CON message.

   When a legitimate and comprehensible ANM is encapsulated in the 200
   OK response, the gateway SHOULD re-use any relevant ISUP parameters
   in the ANM it sends to the PSTN.

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

8.2.5 3xx Received

   When any 3xx response (a redirection) is received, the gateway SHOULD
   try to reach the destination by sending one or more new call setup
   requests using URIs found in any Contact header field(s) present in
   the response, as is mandated in the base SIP specification.  Such 3xx
   responses are typically sent by a redirect server, and can be thought
   of as similar to a location register in mobile PSTN networks.

   If a particular URI presented in the Contact header of a 3xx is best
   reachable (according to the gateway's routing policies) via the PSTN,
   the gateway SHOULD send a new IAM and from that moment on act as a
   normal PSTN switch (no SIP involved) - usually this will be the case
   when the URI in the Contact header is a tel URL, one that the gateway
   cannot reach locally and one for which there is no ENUM mapping.

   Alternatively, the gateway MAY send a REL message to the PSTN with a
   redirection indicator (23) and a diagnostic field corresponding to
   the telephone number in the URI.  If, however, the new location is
   best reachable using SIP (if the URI in the Contact header contains
   no telephone number at all), the MGC SHOULD send a new INVITE with a
   Request-URI possibly a new IAM generated by the MGC in the message
   body.

   While it is exploring a long list of Contact header fields with SIP
   requests, a gateway MAY send a CPG message with an event code of 6
   (Forwarding) to the PSTN in order to indicate that the call is
   proceeding (where permitted by the ISUP variant in question).

   All redirection situations have to be treated very carefully because
   they involved special charging situations.  In PSTN the caller
   typically pays for the first leg (to the gateway) and the callee pays
   the second (from the forwarding switch to the destination).

8.2.6 4xx-6xx Received

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

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

8.2.6.1 SIP Status Code to ISDN Cause Code Mapping

   When a REL message is generated due to a SIP rejection response that
   contains an encapsulated REL message, the Cause Indicator (CAI)
   parameter in the generated REL SHOULD be set to the value of the CAI
   parameter received in the encapsulated REL.  If no encapsulated ISUP
   is present, the mapping below between status code and cause codes are
   RECOMMENDED.

   Any SIP status codes not listed below (associated with SIP
   extensions, versions of SIP subsequent to the issue of this document,
   or simply omitted) should be mapping to cause code 31 "Normal,
   unspecified".  These mappings cover only responses; note that the BYE
   and CANCEL requests, which are also used to tear down a dialog,
   SHOULD be mapped to 16 "Normal clearing" under most circumstances
   (although see Section 5.8).

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

Top      Up      ToC       Page 46 
   Just as there are certain ISDN cause codes that are ISUP-specific and
   have no corollary SIP action, so there are SIP status codes that
   should not simply be translated to ISUP - some SIP-specific action
   should be attempted first.  See the note on the (+) tag below.

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

Top      Up      ToC       Page 47 
   (*) In some cases, it may be possible for a SIP gateway to provide
   credentials to the SIP UAS that is rejecting an INVITE due to
   authorization failure.  If the gateway can authenticate itself, then
   obviously it SHOULD do so and proceed with the call; only if the
   gateway cannot authenticate itself should cause code 21 be sent.

   (+) If at all possible, a SIP gateway SHOULD respond to these
   protocol errors by remedying unacceptable behavior and attempting to
   re-originate the session.  Only if this proves impossible should the
   SIP gateway fail the ISUP half of the call.

   When the Warning header is present in a SIP 606 or 488 message, there
   may be specific ISDN cause code mappings appropriate to the Warning
   code.  This document recommends that '31 Normal, unspecified' SHOULD
   by default be used for most currently assigned Warning codes.  If the
   Warning code speaks to an unavailable bearer capability, cause code
   '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping.

8.2.7 REL Received

   This circumstance generally arises when the user on the PSTN side
   hangs up before the call has been answered; the gateway therefore
   aborts the establishment of the session.  A CANCEL request MUST be
   issued (a BYE is not used, since no final response has arrived from
   the SIP side).  A 200 OK for the CANCEL can be expected by the
   gateway, and finally a 487 for the INVITE arrives (which the gateway
   ACKs in turn).

   The gateway SHOULD store state information related to this dialog for
   a certain period of time, since a 200 final response for the INVITE
   originally sent might arrive (even after the reception of the 200 OK
   for the CANCEL).  In this situation, the gateway MUST send an ACK
   followed by an appropriate BYE request.

   In SIP bridging situations, the REL message cannot be encapsulated in
   a CANCEL message (since CANCEL cannot have a message body).  Usually,
   the REL message will contain a CAI value of 16 "Normal clearing".  If
   the value is other than a 16, the gateway MAY wish to use some other
   means of communicating the cause value (see Section 5.8).

8.2.8 ISUP T11 Expires

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

Top      Up      ToC       Page 48 
   To clarify timer T11's relevance with respect to SIP interworking,
   Q.764 [12] explains its use as: "If in normal operation, a delay in
   the receipt of an address complete signal from the succeeding network
   is expected, the last common channel signaling exchange will
   originate and send an address complete message 15 to 20 seconds
   [timer (T11)] after receiving the latest address message." Since SIP
   nodes have no obligation to respond to an INVITE request within 20
   seconds,  SIP interworking inarguably qualifies as such a situation.

   If the gateway supports this optional mechanism, then if its T11
   expires, it SHOULD send an early ACM (i.e., called party status set
   to "no indication") to prevent the expiration of the remote node's T7
   (where permitted by the ISUP variant).  See Section 8.2.3 for the
   value of the ACM parameters.

   If a "180 Ringing" message arrives subsequently, it SHOULD be sent in
   a CPG, as shown in Section 8.2.3.

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



(page 48 continued on part 3)

Next RFC Part