Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3398

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

Pages: 68
Proposed Standard
Errata
Part 2 of 3 – Pages 30 to 48
First   Prev   Next

Top   ToC   RFC3398 - Page 30   prevText

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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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   ToC   RFC3398 - 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 Section