RFC 3398
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
8. ISUP to SIP Mapping
8.1 ISUP to SIP Call Flows
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the PSTN network. "100 Trying" acknowledgements to INVITE requests are not depicted, since their presence is optional. In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG".
8.1.1 En-bloc call setup (non auto-answer)
SIP MGC/MG PSTN | |<-----------IAM-----------|1 | |==========Audio==========>| 2|<--------INVITE-----------| | |-----------100----------->| | 3|-----------18x----------->| | |==========Audio==========>| | | |=========================>| | |------------ACM---------->|4 5|-----------18x----------->| | | |------------CPG---------->|6 7|-----------200-(I)------->| | |<=========Audio==========>| | | |------------ANM---------->|8 | |<=========Audio==========>| 9|<----------ACK------------| | 1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway. 2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node. 3. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater. 4. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message. If the response is not 180, the ACM will carry a "called party status" value of "no indication." 5. The SIP node may use further provisional messages to indicate session progress. 6. After an ACM has been sent, all provisional responses will translate into ISUP CPG messages as indicated in Section 8.2.3. 7. When the SIP node answers the call, it will send a 200 OK message. 8. Upon receipt of the 200 OK message, the gateway will send an ANM message towards the ISUP node. 9. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
8.1.2 Auto-answer call setup
SIP MGC/MG PSTN | |<-----------IAM-----------|1 | |==========Audio==========>| 2|<--------INVITE-----------| | 3|-----------200----------->| | |<=========Audio==========>| | | |------------CON---------->|4 | |<=========Audio==========>| 5|<----------ACK------------| | 1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway. 2. Upon receipt of the IAM message, the gateway generates an INVITE message and sends it to an appropriate SIP node based on called number analysis. 3. Since the SIP node is set up to automatically answer the call, it will send a 200 OK message. 4. Upon receipt of the 200 OK message, the gateway will send a CON message towards the ISUP node. 5. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
8.1.3 SIP Timeout
SIP MGC/MG PSTN | |<-----------IAM-----------|1 | |==========Audio==========>| 2|<--------INVITE-----------| | | *** T1 Expires *** | | 3|<--------INVITE-----------| | | *** T1 Expires *** | | |<--------INVITE-----------| | | | *** T11 Expires *** | | |------------ACM---------->|4 | *** T1 Expires *** | | |<--------INVITE-----------| | | *** T1 Expires *** | | |<--------INVITE-----------| | | *** T1 Expires *** | | |<--------INVITE-----------| | | *** T1 Expires *** | | |<--------INVITE-----------| | | *** T1 Expires *** | | | ** MG Releases PSTN Trunk ** | | |------------REL---------->|5 6|<--------CANCEL-----------| | | |<-----------RLC-----------|7 1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway. 2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis. The ISUP timer T11 and SIP timer T1 are set at this time. 3. The INVITE message will continue to be sent to the SIP node each time the timer T1 expires. The SIP standard specifies that INVITE transmission will be performed 7 times if no response is received.
4. When T11 expires, an ACM message will be sent to the ISUP node to
prevent the call from being torn down by the remote node's ISUP
T7. This ACM contains a 'Called Party Status' value of 'no
indication.'
5. Once the maximum number of INVITE requests has been sent, the
gateway will send a REL (cause code 18) to the ISUP node to
terminate the call.
6. The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.
7. Upon receipt of the REL, the remote ISUP node will send an RLC to
acknowledge.
8.1.4 ISUP T9 Expires
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |
1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM message towards the gateway.
2. Upon receipt of the IAM message, the gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis. The ISUP timer T11 and SIP timer T1 are set at
this time.
3. The INVITE message will continue to be sent to the SIP node each
time the timer T1 expires. The SIP standard specifies that
INVITE transmission will be performed 7 times if no response is
received. Since SIP T1 starts at 1/2 second or more and doubles
each time it is retransmitted, it will be at least a minute
before SIP times out the INVITE request; since SIP T1 is allowed
to be larger than 500 ms initially, it is possible that 7 x SIP
T1 will be longer than ISUP T11 + ISUP T9.
4. When T11 expires, an ACM message will be sent to the ISUP node to
prevent the call from being torn down by the remote node's ISUP
T7. This ACM contains a 'Called Party Status' value of 'no
indication.'
5. When ISUP T9 in the remote PSTN node expires, it will send a REL.
6. Upon receipt of the REL, the gateway will send an RLC to
acknowledge.
7. The REL will trigger a CANCEL request, which gets sent to the SIP
node.
8.1.5 SIP Error Response
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM message towards the gateway.
2. Upon receipt of the IAM message, the gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis.
3. The SIP node indicates an error condition by replying with a
response with a code of 400 or greater.
4. The gateway sends an ACK message to acknowledge receipt of the
INVITE final response.
5. An ISUP REL message is generated from the SIP code, as specified
in Section 8.2.6.1.
6. The remote ISUP node confirms receipt of the REL message with an
RLC message.
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.
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.
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.
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).
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
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)
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:
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.
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
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.
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
(*) 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.
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)
