|
Network Working Group Request for Comments: 3398 Category: Standards Track |
G. Camarillo Ericsson A. B. Roach dynamicsoft J. Peterson NeuStar L. Ong Ciena December 2002 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (2002). All Rights Reserved.
This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
1. Introduction
2. Scope
3. Terminology
4. Scenarios
5. SIP Mechanisms Required
5.1 'Transparent' Transit of ISUP Messages
5.2 Understanding MIME Multipart Bodies
5.3 Transmission of DTMF Information
5.4 Reliable Transmission of Provisional Responses
5.5 Early Media
5.6 Mid-Call Transactions which do not change SIP state
5.7 Privacy Protection
5.8 CANCEL causes
6. Mapping
7. SIP to ISUP Mapping
7.1 SIP to ISUP Call flows
7.1.1 En-bloc Call Setup (no auto-answer)
7.1.2 Auto-answer call setup
7.1.3 ISUP T7 Expires
7.1.4 SIP Timeout
7.1.5 ISUP Setup Failure
7.1.6 Cause Present in ACM Message
7.1.7 Call Canceled by SIP
7.2 State Machine
7.2.1 INVITE received
7.2.1.1 INVITE to IAM procedures
7.2.2 ISUP T7 expires
7.2.3 CANCEL or BYE received
7.2.4 REL received
7.2.4.1 ISDN Cause Code to Status Code Mapping
7.2.5 Early ACM received
7.2.6 ACM received
7.2.7 CON or ANM Received
7.2.8 Timer T9 Expires
7.2.9 CPG Received
7.3 ACK received
8. ISUP to SIP Mapping
8.1 ISUP to SIP Call Flows
8.1.1 En-bloc call setup (non auto-answer)
8.1.2 Auto-answer call setup
8.1.3 SIP Timeout
8.1.4 ISUP T9 Expires
8.1.5 SIP Error Response
8.1.6 SIP Redirection
8.1.7 Call Canceled by ISUP
8.2 State Machine
8.2.1 Initial Address Message received
8.2.1.1 IAM to INVITE procedures
8.2.2 100 received
8.2.3 18x received
8.2.4 2xx received
8.2.5 3xx Received
8.2.6 4xx-6xx Received
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping
8.2.7 REL Received
8.2.8 ISUP T11 Expires
9. Suspend/Resume and Hold
9.1 SUS and RES
9.2 Hold (re-INVITE)
10. Normal Release of the Connection
10.1 SIP initiated release
10.2 ISUP initiated release
10.2.1 Caller hangs up
10.2.2 Callee hangs up (SUS)
11. ISUP Maintenance Messages
11.1 Reset messages
11.2 Blocking messages
11.3 Continuity Checks
12. Construction of Telephony URIs
12.1 ISUP format to tel URL mapping
12.2 tel URL to ISUP format mapping
13. Other ISUP flavors
13.1 Guidelines for sending other ISUP messages
14. Acronyms
15. Security Considerations
16. IANA Considerations
17. Acknowledgments
18. Normative References
19. Non-Normative References
Authors' Addresses
Full Copyright Statement
SIP [1] is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP. Telephone calls are considered a type of multimedia sessions where just audio is exchanged.
Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a level 4 protocol used in Signaling System No. 7 (SS7) networks. It typically runs over Message Transfer Part (MTP) although it can also run over IP (see SCTP [19]). ISUP is used for controlling telephone calls and for maintenance of the network (blocking circuits, resetting circuits etc.).
A module performing the mapping between these two protocols is usually referred to as Media Gateway Controller (MGC), although the terms 'softswitch' or 'call agent' are also sometimes used. An MGC has logical interfaces facing both networks, the network carrying ISUP and the network carrying SIP. The MGC also has some capabilities for controlling the voice path; there is typically a Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public Switched Telephone Network - PSTN) and with IP interfaces (Voice over IP - VoIP). The MGC and the MG can be merged together in one physical box or kept separate.
These MGCs are frequently used to bridge SIP and ISUP networks so that calls originating in the PSTN can reach IP telephone endpoints and vice versa. This is useful for cases in which PSTN calls need to take advantage of services in IP world, in which IP networks are used as transit networks for PSTN-PSTN calls, architectures in which calls originate on desktop 'softphones' but terminate at PSTN terminals, and many other similar next-generation telephone architectures.
This document describes logic and procedures which an MGC might use to implement the mapping between SIP and ISUP by illustrating the correspondences, at the message level and parameter level, between the protocols. It also describes the interplay between parallel state machines for these two protocols as a recommendation for implementers to synchronize protocol events in interworking architectures.
This document focuses on the translation of ISUP messages into SIP
messages, and the mapping of ISUP parameters into SIP headers. For
ISUP calls that traverse a SIP network, the purpose of translation is
to allow SIP elements such as proxy servers (which do not typically
understand ISUP) to make routing decisions based on ISUP criteria
such as the called party number. This document consequently provides
a SIP mapping only for those ISUP parameters which might be used by
intermediaries in the routing of SIP requests. As a side effect of
this approach, translation also increases the overall
interoperability by providing critical information about the call to
SIP endpoints that cannot understand encapsulated ISUP, or perhaps
which merely cannot understand the particular ISUP variant
encapsulated in a message.
This document also only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these messages neither have nor require any analog in SIP.
Messages indicating error or congestion situations in the PSTN (MTP- 3) and the recovery mechanisms used such as User Part Available and User Part Test ISUP messages are outside the scope of this document
There are several flavors of ISUP. International Telecommunication Union Telecommunication Standardization Sector (ITU-T) International ISUP [12] is used through this document; some differences with the American National Standards Institute (ANSI) [11] ISUP and the Telecommunication Technology Committee (TTC) ISUP are also outlined. ITU-T ISUP is used in this document because it is the most widely known of all the ISUP flavors. Due to the small number of fields
that map directly from ISUP to SIP, the signaling differences between ITU-T ISUP and specific national variants of ISUP will generally have little to no impact on the mapping. Note, however, that the ITU-T has not substantially standardized practices for Local Number Portability (LNP) since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. The number portability practices described in this document are presented as an optional mechanism.
Mapping of SIP headers to ISUP parameters in this document focuses largely on the mapping between the parameters found in the ISUP Initial Address Message (IAM) and the headers associated with the SIP INVITE message; both of these messages are used in their respective protocols to request the establishment of a call. Once an INVITE has been sent for a particular session, such headers as the To and From field become essentially fixed, and no further translation will be required during subsequent signaling, which is routed in accordance with Via and Route headers. Hence, the problem of parameter-to- header mapping in SIP-T is confined more or less to the IAM and the INVITE. Some additional detail is given in the population of parameters in the ISUP messages Address Complete Message (ACM) and Release Message (REL) based on SIP status codes.
This document describes when the media path associated with a SIP call is to be initialized, terminated, modified, etc., but it does not go into details such as how the initialization is performed or which protocols are used for that purpose.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant SIP implementations.
There are several scenarios where ISUP-SIP mapping takes place. The way the messages are generated is different depending on the scenario.
When there is a single MGC and the call is from a SIP phone to a PSTN phone, or vice versa, the MGC generates the ISUP messages based on the methods described in this document.
+-------------+ +-----+ +-------------+ | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | +-------------+ +-----+ +-------------+
The scenario where a call originates in the PSTN, goes into a SIP network and terminates in the PSTN again is known as "SIP bridging". SIP bridging should provide ISUP transparency between the PSTN switches handling the call. This is achieved by encapsulating the incoming ISUP messages in the body of the SIP messages (see [3]). In this case, the ISUP messages generated by the egress MGC are the ones present in the SIP body (possibly with some modifications; for example, if the called number in the request Uniform Resource Identifier - URI - is different from the one present in the ISUP due to SIP redirection, the ISUP message will need to be adjusted).
+------+ +-------------+ +-----+ +------------+ +------+ | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | +------+ +-------------+ +-----+ +------------+ +------+
SIP is used in the middle of both MGCs because the voice path has to be established through the IP network between both MGs; this structure also allows the call to take advantage of certain SIP services. ISUP messages in the SIP bodies provide further information (such as cause values and optional parameters) to the peer MGC.
In both scenarios, the ingress MGC places the incoming ISUP messages
in the SIP body by default. Note that this has security
implications; see Section 15. If the recipient of these messages
(typically a SIP User Agent Client/User Agent Server - UAC/UAS) does
not understand them, a negotiation using the SIP 'Accept' and
'Require' headers will take place and they will not be included in
the next SIP message exchange.
There can be a Signaling Gateway (SG) between the PSTN and the MGC. It encapsulates the ISUP messages over IP in a manner such as the one described in [19]. The mapping described in this document is not affected by the underlying transport protocol of ISUP.
Note that overlap dialing mechanisms (use of the Subsequent Address Message - SAM) are outside the scope of this document. This document assumes that gateways facing ISUP networks in which overlap dialing is used will implement timers to insure that all digits have been collected before an INVITE is transmitted to a SIP network.
In some instances, gateways may receive incomplete ISUP messages which indicate message segmentation due to excessive message length. Commonly these messages will be followed by a Segmentation Message (SGM) containing the remainder of the original ISUP message. An incomplete message may not contain sufficient parameters to allow for a proper mapping to SIP; similarly, encapsulating (see below) an incomplete ISUP message may be confusing to terminating gateways. Consequently, a gateway MUST wait until a complete ISUP message is received (which may involve waiting until one or more SGMs arrive) before sending any corresponding INVITE.
For a correct mapping between ISUP and SIP, some SIP mechanisms above and beyond those available in the base SIP specification are needed. These mechanisms are discussed below. If the SIP UAC/UAS involved in the call does not support them, it is still possible to proceed, but the behavior in the establishment of the call may be slightly different than that expected by the user (e.g., other party answers before receiving the ringback tone, user is not informed about the call being forwarded, etc.).
To allow gateways to take advantage of the full range of services afforded by the existing telephone network when placing calls from PSTN to PSTN across a SIP network, SIP messages MUST be capable of transporting ISUP payloads from gateway to gateway. The format for encapsulating these ISUP messages is defined in [3].
SIP user agents which do not understand ISUP are permitted to ignore these optional MIME bodies.
In most PSTN interworking situations, SIP message bodies will be required to carry session information (Session Description Protocol - SDP) in addition to ISUP and/or billing information.
PSTN interworking nodes MUST understand the MIME type of
"multipart/mixed" as defined in RFC2046 [4]. Clients express support
for this by including "multipart/mixed" in an "Accept" header.
How DTMF tones played by the user are transmitted by a gateway is completely orthogonal to how SIP and ISUP are interworked; however, as DTMF carriage is a component of a complete gatewaying solution some guidance is offered here.
Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is desirable (since out-of-band transmission alone would provide many challenges for synchronization of the media stream for tone re-insertion). This transmission MAY be performed as described in RFC2833 [5].
Provisional responses (in the 1xx class) are used in the transmission of call progress information. PSTN interworking in particular relies on these messages for control of the media channel and timing of call events.
When interworking with the PSTN, SIP messages MUST be sent reliably end-to-end; reliability of requests is guaranteed by the base protocol. One application-layer provisional reliability mechanism for responses is described in [18].
Early media denotes the capability to play media (audio for telephony) before a SIP session has been established (before a 2xx response code has been sent). For telephony, establishment of media in the backwards direction is desirable so that tones and announcements can be played, especially when interworking with a network that cannot signal call status out of band (such as a legacy MF network). In cases where interworking has not been encountered, use of early media is almost always undesirable since it consumes inter-machine trunk recourses to play media for which no revenue is collected. Note that since an INVITE almost always contains the SDP required to send media in the backwards direction, and requires that user agents prepare themselves to receive backwards media as soon as an INVITE transmitted, the baseline SIP protocol has enough support to enable rudimentary unidirectional early media systems. However, this mechanism has a number of limitations - for example, media streams offered in the SDP of the INVITE cannot be modified or declined, and bidirectional RTCP required for session maintenance cannot be established.
Therefore gateways MAY support more sophisticated early media systems as they come to be better understood. One mechanism that provides a way of initiating a fully-featured early media system is described in [20].
Note that in SIP networks not just switches but also user agents can generate the 18x response codes and initiate early backwards media, and that therefore some gateways may wish to enforce policies that restrict the use of backwards media from arbitrary user agents (see Section 15).
When interworking with the PSTN, there are situations when gateways will need to send messages to each other over SIP that do not correspond to any SIP operations.
In support of mid-call transactions and other ISUP events that do not correspond to existing SIP methods, SIP gateways MUST support the INFO method, defined in RFC2976 [6]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits.
Gateways MUST accept "405 Method Not Allowed" and "501 Not Implemented" as non-fatal responses to INFO requests - that is, any call in progress MUST NOT be torn down if a destination so rejects an INFO request sent by a gateway.
ISUP has a concept of presentation restriction - a mechanism by which a user can specify that they would not like their telephone number to be displayed to the person they are calling (presumably someone with Caller ID). When a gateway receives an ISUP request that requires presentation restriction, it must therefore shield the identity of the caller in some fashion.
The base SIP protocol supports a method of specifying that a user is anonymous. However, this system has a number of limitations - for example, it reveals the identity of the gateway itself, which could be a privacy-impacting disclosure. Therefore gateways MAY support more sophisticated privacy systems. One mechanism that provides a way of supporting fully-featured privacy negotiation (which interacts well with identity management systems) is described in [9B].
There is a way in ISUP to signal that you would like to discontinue an attempt to set up a call - the general-purpose REL is sent in the forwards direction. There is a similar concept in SIP - that of a CANCEL request that is sent in order to discontinue the establishment of a SIP dialog. For various reasons, however, CANCEL requests cannot contain message bodies, and therefore in order to carry the important information in the REL (the cause code) end-to-end in sip bridging cases, ISUP encapsulation cannot be used.
Ordinarily, this is not a big problem, because for practical purposes the only reason that a REL is ever issued to cancel a call setup attempt is that a user hangs up the phone while it is still ringing (which results in a "Normal clearing" cause code). However, under exceptional conditions, like catastrophic network failure, a REL may be sent with a different cause code, and it would be handy if a SIP network could carry the cause code end-to-end. Therefore gateways MAY support a mechanism for end-to-end delivery of such failure reasons. One mechanism that provides this capability is described in [9].
The mapping between ISUP and SIP is described using call flow diagrams and state machines. One state machine handles calls from SIP to ISUP and the second from ISUP to SIP. There are details, such as some retransmissions and some states (waiting for the Release Complete Message - RLC, waiting for SIP ACK etc.), that are not shown in the figures in order to make them easier to follow.
The boxes represent the different states of the gateway, and the arrows show changes in the state. The event that triggers the change in the state and the actions to take appear on the arrow: event / section describing the actions to take.
For example, 'INVITE / 7.2.1' indicates that an INVITE request has been received by the gateway, and the procedure upon reception is described in the section 7.2.1 of this document.
It is RECOMMENDED that gateways implement functional equivalence with the call flows detailed in Section 7.1 and Section 8.1. Deviations from these flows are permissible in support of national ISUP variants, or any of the conservative policies recommended in Section 15.
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the SIP network. "100 Trying" acknowledgements to INVITE requests are not displayed below although they are required in many architectures.
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."
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
Note that this flow is not supported in ANSI networks.
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
Note that REL can be received in any state; the handling is the same for each case (see Section 10).
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
When an INVITE request is received by the gateway, a "100 Trying" response MAY be sent back to the SIP network indicating that the gateway is handling the call.
The necessary hardware resources for the media stream MUST be reserved in the gateway when the INVITE is received, since an IAM message cannot be sent before the resource reservation (especially TCIC selection) takes place. Typically the resources consist of a time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources might also include any quality-of-service provisions (although no such practices are recommended in this document).
After sending the IAM the timer T7 is started. The default value of T7 is between 20 and 30 seconds. The gateway goes to the 'Trying' state.
This section details the mapping of the SIP headers in an INVITE message to the ISUP parameters in an Initial Address Message (IAM). A PSTN-SIP gateway is responsible for creating an IAM when it receives an INVITE.
Five mandatory parameters appear within the IAM message: the Called Party Number (CPN), the Nature of Connection Indicator (NCI), the Forward Call Indicators (FCI), the Calling Party's Category (CPC), and finally a parameter that indicates the desired bearer characteristics of the call - in some ISUP variants the Transmission Medium Requirement (TMR) is required, in others the User Service Information (USI) (or both). All IAM messages MUST contain these five parameters at a minimum. Thus, every gateway must have a means of populating each of those five parameters when an INVITE is received. Many of the values that will appear in these parameters (such as the NCI or USI) will most likely be the same for each IAM created by the gateway. Others (such as the CPN) will vary on a call-by-call basis; the gateway extracts information from the INVITE in order to properly populate these parameters.
There are also quite a few optional parameters that can appear in an IAM message; Q.763 [17] lists 29 in all. However, each of these parameters need not to be translated in order to achieve the goals of SIP-ISUP mapping. As is stated above, translation allows SIP network elements to understand the basic PSTN context of the session (who it is for, and so on) if they are not capable of deciphering any encapsulated ISUP. Parameters that are only meaningful to the PSTN will be carried through PSTN-SIP- PSTN networks via encapsulation -
translation is not necessary for these parameters. Of the aforementioned 29 optional parameters, only the following are immediately useful for translation: the Calling Party's Number (CIN, which is commonly present), Transit Network Selection (TNS), Carrier Identification Parameter (CIP, present in ANSI networks), Original Called Number (OCN), and the Generic Digits (known in some variants as the Generic Address Parameter (GAP)).
When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD attempt to make use of encapsulated ISUP (see [3]), if any, within the INVITE to assist in the formulation of outbound PSTN signaling, but SHOULD also heed the security considerations in Section 15. If possible, the gateway SHOULD reuse the values of each of the ISUP parameters of the encapsulated IAM as it formulates an IAM that it will send across its PSTN interface. In some cases, the gateway will be unable to make use of that ISUP - for example, if the gateway cannot understand the ISUP variant and must therefore ignore the encapsulated body. Even when there is comprehensible encapsulated ISUP, the relevant values of SIP header fields MUST 'overwrite' through the process of translation the parameter values that would have been set based on encapsulated ISUP. In other words, the updates to the critical session context parameters that are created in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases, over the encapsulated ISUP. This allows many basic services, including various sorts of call forwarding and redirection, to be implemented in the SIP network.
For example, if an INVITE arrives at a gateway with an encapsulated IAM with a CPN field indicating the telephone number +12025332699, but the Request-URI of the INVITE indicates 'tel:+15105550110', the gateway MUST use the telephone number in the Request-URI, rather than the one in the encapsulated IAM, when creating the IAM that the gateway will send to the PSTN. Further details of how SIP header fields are translated into ISUP parameters follow.
Gateways MUST be provisioned with default values for mandatory ISUP parameters that cannot be derived from translation(such as the NCI or TMR parameters) for those cases in which no encapsulated ISUP is present. The FCI parameter MUST also have a default, as only the 'M' bit of the default may be overwritten during the process of translation if the optional number portability translation mechanisms described below are used.
The first step in the translation of the fields of an INVITE message to the parameters of an IAM is the inspection of the Request-URI.
If the optional number portability practices are supported by the gateway, then the following steps related to handling of the 'npdi' and 'rn' parameters of the Request-URI should be followed.
If there is no 'npdi=yes' field within the Request-URI, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
If the 'npdi=yes' field exists in the Request-URI, then the FCI parameter bit for 'number translated' within the IAM MUST reflect that a number portability dip has been performed.
If in addition to the 'npdi=yes' field there is no 'rn=' field present, then the main telephone number in the tel URL MUST be converted to ISUP format (see Section 12) and used to populate the CPN parameter. This indicates that a portability dip took place, but that the called party's number was not ported.
If in addition to the 'npdi=yes' field an 'rn=' field is present, then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format and used to populate the CPN. The main telephone number in the tel URL MUST be converted to ISUP format and used to populate the Generic Digits Parameter (or GAP in ANSI). In some other ISUP variants, the number given in the 'rn=' field would instead be prepended to the main telephone number (with or without a prefix or separator) and the combined result MUST be used to populate the CPN. Once the 'rn=' and 'npdi=' parameters have been translation, the number portability translation practices are complete.
The following mandatory translation practices are performed after number portability translations, if any.
If number portability practices are not supported by the gateway, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
If the primary telephone number in the Request-URI and that of the To header are at variance, then the To header SHOULD be used to populate an OCN parameter. Otherwise the To header SHOULD be ignored.
Some optional translation procedures are provided for carrier-based routing. If the 'cic=' parameter is present in the Request-URI, the gateway SHOULD consult local policy to make sure that it is appropriate to transmit this Carrier Identification Code (CIC, not to
be confused with the MTP3 'circuit identification code') in the IAM; if the gateway supports many independent trunks, it may need to choose a particular trunk that points to the carrier identified by the CIC, or a tandem through which that carrier is reachable. Policies for such trunks (based on the preferences of the carriers with which the trunks are associated and the ISUP variant in use) SHOULD dictate whether the CIP or TNS parameter is used to carry the CIC. In the absence of any pre-arranged policies, the TNS should be used when the CPN parameter is in an international format (i.e., the tel URL portion of the Request-URI is preceded by a '+', which will generate a CPN in international format), and (where supported) the CIP should be used in other cases.
When a SIP call has been routed to a gateway, then the Request-URI will most likely contain a tel URL (or a SIP URI with a tel URL user portion) - SIP-ISUP gateways that receive Request-URIs that do not contain valid telephone numbers SHOULD reject such requests with an appropriate response code. Gateways SHOULD however continue to process requests with a From header field that does not contain a telephone number, as will sometimes be the case if a call originated at a SIP phone that employs a SIP URI user@host convention. The CIN parameter SHOULD be omitted from the outbound IAM if the From field is unusable. Note that as an alternative, gateway implementers MAY consider some non-standard way of mapping particular SIP URIs to telephone numbers.
When a gateway receives a message with (comprehensible) encapsulated ISUP, it MUST set the FCI indicator in the generated IAM so that all interworking-related bits have the same values as their counterparts in the encapsulated ISUP. In most cases, these indicators will state that no interworking was encountered, unless interworking has been encountered somewhere else in the call path. If usable encapsulated ISUP is not present in an INVITE received by the gateway, it is STRONGLY RECOMMENDED that the gateway set the Interworking Indicator bit of the FCI to 'no interworking' and the ISDN User Part Indicator to 'ISUP used all the way'; the gateway MAY also set the Originating Access indicator to 'Originating access non-ISDN' (generally, it is not safe to assume that SIP phones will support ISDN endpoint services, and the procedures in this document do not detail mappings to translate all such services).
Note that when 'interworking encountered' is set in the FCI parameter of the IAM, this indicates that ISUP is interworking with a network which is not capable of providing as many services as ISUP does. ISUP networks will therefore not employ certain features they otherwise normally would, including potentially the use of ISDN cause codes in failure conditions (as opposed to sending ACMs followed by audible announcements). If desired, gateway vendors MAY provide a
configurable option, usable at the discretion of service providers, that will signal in the FCI that interworking has been encountered (and that ISUP is not used all the way) when encapsulated ISUP is not present; however, doing so may significantly limit the efficiency and transparency of SIP-ISUP translation.
Claiming to be an ISDN node might make the callee request ISDN user to user services. Since user to user services 1 and 2 must be requested by the caller, they do not represent a problem (see [14]). User to user service 3 can be requested by the callee also. In non- SIP bridging situations, the MGC should be capable of rejecting this service request.
Since no response was received from the PSTN all the resources in the MG are released. A '504 Server Timeout' SHOULD be sent back to the SIP network. A REL message with cause value 102 (protocol error, recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can expect the PSTN to respond with RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
If a CANCEL or BYE request is received before a final SIP response has been sent, a '200 OK' MUST be sent to the SIP network to confirm the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE transaction. All the resources are released and a REL message SHOULD be sent to the PSTN with cause value 16 (normal clearing). Gateways can expect an RLC from the PSTN to be received indicating that the release sequence is complete.
In SIP bridging situations, a REL might be encapsulated in the body of a BYE request. Although BYE is usually mapped to cause code 16 (normal clearing), under exceptional circumstances the cause code in the REL message might be different. Therefore the Cause Indicator parameter of the encapsulated REL should be re-used in the REL sent to the PSTN.
Note that a BYE or CANCEL request may contain a Reason header that SHOULD be mapped to the Cause Indicator parameter (see Section 5.8). If a BYE contains both a Reason header and encapsulated ISUP, the value in the Reason header MUST be preferred.
All the resources in the gateway SHOULD be released before the gateway sends any REL message.
This section applies when a REL is received before a final SIP response has been sent. Typically, this condition arises when a call has been rejected by the PSTN.
Any gateway resources SHOULD be released immediately and an RLC MUST be sent to the ISUP network to indicate that the circuit is available for reuse.
If the INVITE that originated this transaction contained a legitimate and comprehensible encapsulated ISUP message (i.e., an IAM using a variant supported by the gateway, preferably with a digital signature), then encapsulated ISUP SHOULD be sent in the response to the INVITE when possible (since this suggests an ISUP-SIP-ISUP bridging case) - therefore, the REL message just received SHOULD be included in the body of the SIP response. The gateway SHOULD NOT return a response with encapsulated ISUP if the originator of the INVITE did not enclose ISUP itself.
Note that the receipt of certain maintenance messages in response to IAM such as Blocking Message (BLO) or Reset Message (RSC) (or their circuit group message equivalents) may also result in the teardown of calls in this phase of the state machine. Behavior for maintenance messages is given below in Section 11.
The use of the REL message in the SS7 network is very general, whereas SIP has a number of specific tools that, collectively, play the same role as REL - namely BYE, CANCEL, and the various status/response codes. An REL can be sent to tear down a call that is already in progress (BYE), to cancel a previously sent call setup request that has not yet been completed (CANCEL), or to reject a call setup request (IAM) that has just been received (corresponding to a SIP status code).
Note that it is not necessarily appropriate to map some ISDN cause codes to SIP messages because these cause codes are only meaningful to the ISUP interface of a gateway. A good example of this is cause code 44 "Request circuit or channel not available." 44 signifies that the CIC for which an IAM had been sent was believed by the receiving equipment to be in a state incompatible with a new call request - however, the appropriate behavior in this case is for the originating switch to re-send the IAM for a different CIC, not for the call to be torn down. Clearly, there is not (nor should there be) an SIP status code indicating that a new CIC should be selected - this matter is internal to the originating gateway. Hence receipt of cause code 44
should not result in any SIP status code being sent; effectively, the cause code is untranslatable.
If a cause value other than those listed below is received, the default response '500 Server internal error' SHOULD be used.
Finally, in addition to the ISDN Cause Code, the CAI parameter also contains a cause 'location' that gives some sense of which entity in the network was responsible for terminating the call (the most important distinction being between the user and the network). In most cases, the cause location does not affect the mapping to a SIP status code; some exceptions are noted below. A diagnostic field may also be present for some ISDN causes; this diagnostic will contain additional data pertaining to the termination of the call.
The following mapping values are RECOMMENDED:
Normal event
ISUP Cause value SIP response ---------------- ------------ 1 unallocated number 404 Not Found 2 no route to network 404 Not found 3 no route to destination 404 Not found 16 normal call clearing --- (*) 17 user busy 486 Busy here 18 no user responding 408 Request Timeout 19 no answer from the user 480 Temporarily unavailable 20 subscriber absent 480 Temporarily unavailable 21 call rejected 403 Forbidden (+) 22 number changed (w/o diagnostic) 410 Gone 22 number changed (w/ diagnostic) 301 Moved Permanently 23 redirection to new destination 410 Gone 26 non-selected user clearing 404 Not Found (=) 27 destination out of order 502 Bad Gateway 28 address incomplete 484 Address incomplete 29 facility rejected 501 Not implemented 31 normal unspecified 480 Temporarily unavailable
(*) ISDN Cause 16 will usually result in a BYE or CANCEL
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603)
(=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 'misrouted ported number'. Presumably, a number portability dip should have been performed by a prior network. Otherwise cause 26 is usually not used in ISUP procedures.
A REL with ISDN cause 22 (number changed) might contain information about a new number where the callee might be reachable in the diagnostic field. If the MGC is able to process this information it SHOULD be added to the SIP response (301) in a Contact header.
Resource unavailable
This kind of cause value indicates a temporary failure. A 'Retry- After' header MAY be added to the response if appropriate.
ISUP Cause value SIP response ---------------- ------------ 34 no circuit available 503 Service unavailable 38 network out of order 503 Service unavailable 41 temporary failure 503 Service unavailable 42 switching equipment congestion 503 Service unavailable 47 resource unavailable 503 Service unavailable
Service or option not available
This kind of cause value indicates that there is a problem with the request, rather than something that will resolve itself over time.
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
available
Service or option not available
ISUP Cause value SIP response ---------------- ------------ 65 bearer capability not implemented 488 Not Acceptable Here 70 only restricted digital avail 488 Not Acceptable Here 79 service or option not implemented 501 Not implemented
Invalid message
ISUP Cause value SIP response ---------------- ------------ 87 user not member of CUG 403 Forbidden 88 incompatible destination 503 Service unavailable
Protocol error
ISUP Cause value SIP response ---------------- ------------ 102 recovery of timer expiry 504 Gateway timeout 111 protocol error 500 Server internal error
Interworking
ISUP Cause value SIP response ---------------- ------------ 127 interworking unspecified 500 Server internal error
An ACM message is sent in certain situations to indicate that the call is in progress in order to satisfy ISUP timers, rather than to signify that the callee is being alerted. This occurs for example in mobile networks, where roaming can delay call setup significantly. The early ACM is sent before the user is alerted to reset T7 and start T9. An ACM is considered an 'early ACM' if the Called Party's Status Indicator is set to 00 (no indication).
After sending an early ACM, the ISUP network can be expected to indicate the further progress of the call by sending CPGs.
When an early ACM is received the gateway SHOULD send a 183 Session Progress response (see [1]) to the SIP network. In SIP bridging situations (where encapsulated ISUP was contained in the INVITE that initiated this call) the early ACM SHOULD also be included in the response body.
Note that sending 183 before a gateway has confirmation that the address is complete (ACM) creates known problems in SIP bridging cases, and it SHOULD NOT therefore be sent.
Most commonly, on receipt of an ACM a provisional response (in the 18x class) SHOULD be sent to the SIP network. If the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP, then the ACM received by the gateway SHOULD be encapsulated in the provisional response.
If the ACM contains a Backward Call Indicators parameter with a value of 'subscriber free', the gateway SHOULD send a '180 Ringing' response. When a 180 is sent, it is assumed, in the absence of any early media extension, that any necessary ringback tones will be
generated locally by the SIP user agent to which the gateway is responding (which may in turn be a gateway).
If the Backward Call Indicators (BCI) parameter of the ACM indicates that interworking has been encountered (generally designating that the ISUP network sending the ACM is interworking with a less sophisticated network which cannot report its status via out-of-band signaling), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message, and if possible a backwards media transmission SHOULD be initiated. Backwards media SHOULD also be transmitted if the Optional Backward Call Indicators parameter field for in-band media is set. For more information on early media (before 200 OK/ANM) see Section 5.5. After early media transmission has been initiated, the gateway SHOULD send a 183 Session Progress response code.
Gateways MAY have some means of ascertaining the disposition of in- band audio media; for example, a way of determining by inspecting signaling in some ISUP variants, or by listening to the audio, that ringing, or a busy tone, is being played over the circuit. Such gateways MAY elect to discard the media and send the corresponding response code (such as 180 or 486) in its stead. However, the implementation of such a gateway would entail overcoming a number of known challenges that are outside the scope of this document.
When they receive an ACM, switches in many ISUP networks start a timer known as "T9" which usually lasts between 90 seconds and 3 minutes (see [13]). When early media is being played, this timer permits the caller to hear backwards audio media (in the form ringback, tones or announcements) from a remote switch in the ISUP network for that period of time without incurring any charge for the connection. The nearest possible local ISUP exchange to the callee generates the ringback tone or voice announcements. If longer announcements have to be played, the network has to send an ANM, which initiates bidirectional media of indefinite duration. In common ISUP network practice, billing commences when the ANM is received. Some networks do not support timer T9.
When an ANM or CON message is received, the call has been answered and thus '200 OK' response SHOULD be sent to the SIP network. This 200 OK SHOULD contain an answer to the media offered in the INVITE. In SIP bridging situations (when the INVITE that initiated this call contained legitimate and comprehensible encapsulated ISUP), the ISUP message is included in the body of the 200 OK response. If it has not done so already, the gateway MUST establish a bidirectional media stream at this time.
When there is interworking with some legacy networks, it is possible for an ISUP switch to receive an ANM immediately after an early ACM (without CPG or any other backwards messaging), or without receiving any ACM at all (when an automaton answers the call). In this situation the SIP user will never have received a 18x provisional response, and consequently they will not hear any kind of ringtone before the callee answers. This may result in some clipping of the initial forward media from the caller (since forward media transmission cannot commence until SDP has been acquired from the destination). In ISDN (see [12]) this is solved by connecting the voice path backwards before sending the IAM.
The expiry of this timer (which is not used in all networks) signifies that an ANM has not arrived a significant period of time after alerting began (with the transmission of an ACM) for this call. Usually, this means that the callee's terminal has been alerted for many rings but has not been answered. It may also occur in interworking cases when the network is playing a status announcement (such as one indicating that a number is not in service) that has cycled several times. Whatever the cause of the protracted incomplete call, when this timer expires the call MUST be released. All of the gateway resources related to the media path SHOULD be released. A '480 Temporarily Unavailable' response code SHOULD be sent to the SIP network, and an REL message with cause value 19 (no answer from the user) SHOULD be sent to the ISUP network. The PSTN can be expected to respond with an RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
A CPG is a provisional message that can indicate progress, alerting or in-band information. If a CPG suggests that in-band information is available, the gateway SHOULD begin to transmit early media and cut through the unidirectional backwards media path.
In SIP bridging situations (when the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP), the CPG SHOULD be sent in the body of a particular 18x response, determined from the CPG Event Code as follows:
ISUP event code SIP response ---------------- ------------ 1 Alerting 180 Ringing 2 Progress 183 Session progress 3 In-band information 183 Session progress 4 Call forward; line busy 181 Call is being forwarded 5 Call forward; no reply 181 Call is being forwarded 6 Call forward; unconditional 181 Call is being forwarded - (no event code present) 183 Session progress
Note that if the CPG does not indicate "Alerting," the current state will not change.
At this stage, the call is fully connected and the conversation can take place. No ISUP message should be sent by the gateway when an ACK is received.
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".
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------------| |
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
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
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-----------| |
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
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------------| |
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------------| |
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 +------------>+
+-----------------------------+
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).
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:
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.
A 100 response SHOULD NOT trigger any PSTN interworking messages; it only serves the purpose of suppressing INVITE retransmissions.
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.
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.
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).
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.
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.
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).
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.
In ISDN networks, a user can generate a SUS (timer T2, user initiated) in order to unplug the terminal from the socket and plug it in another one. A RES is sent once the terminal has been reconnected and the T2 timer has not expired. SUS is also frequently used to signaling an on-hook state for a remote terminal before timers leading to the transmission of a REL message are sent (this is the more common case by far). While a call is suspended, no audio media is passed end-to-end.
When a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received. Putting the media on hold insures that bandwidth is conserved when no audio traffic needs to be transmitted.
If media suspension is appropriate, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to request that the far-end's transmission of the media stream be placed on hold. The subsequent reception of a RES from the PSTN SHOULD then trigger a re-INVITE that requests the resumption of the media stream. Note that the MGC may or may not elect to stop transmitting any media itself when it requests the cessation of far-end transmission.
If media suspension is not required by the MGC receiving the SUS from the PSTN, the SIP INFO [6] method MAY be used to transmit an encapsulated SUS rather than a re-INVITE. Note that the recipient of such an INFO request may be a simple SIP phone that does not understand ISUP (and would therefore take no action on receipt of this message); if a prospective destination for an INFO-encapsulated SUS has not used encapsulated ISUP in any messages it has previously sent, the gateway SHOULD NOT relay the INFO method, but rather should handle the SUS and the corresponding RES without signaling their arrival to the SIP network.
In any case, subsequent RES messages MUST be transmitted in the same method that was used for the corresponding SUS (i.e., if an INFO is used for a SUS, INFO should also be used for the subsequent RES).
Regardless of whether the INFO or re-INVITE mechanism is used to carry a SUS message, neither has any implication that the originating side will cease sending IP media. The recipient of an encapsulated SUS message MAY therefore elect to send a re-INVITE themselves to suspend media transmission from the MGC side if desired.
The following example uses the INVITE mechanism. Note that this flow is informative, not proscriptive; compliant gateways are free to implement functionally equivalent flows, as described in the preceding paragraphs.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
The handling of a network-initiated SUS immediately prior to call teardown is handled in Section 10.2.2.
After a call has been connected, a re-INVITE could be sent to a gateway from the SIP side in order to place the call on hold. This re-INVITE will have an SDP offer indicating that the originator of the re-INVITE no longer wishes to receive media.
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |
When such a re-INVITE is received, the gateway SHOULD send a CPG in order to express that the call has been placed on hold. The CPG SHOULD contain a Generic Notification Indicator (or, in ANSI networks, a Notification Indicator) with a value of 'remote hold'.
If, subsequent to the sending of the re-INVITE, the SIP side wishes to take the remote end off hold and begin receiving media again, it SHOULD repeat the flow above with an INVITE that contains an SDP offer with an appropriate media destination. The Generic Notification Indicator would in this instance have a value of 'remote retrieval' (or in some variants 'remote hold released').
Finally, note that a CPG with hold indicators may be received by a gateway from the PSTN. In the interests of conserving bandwidth, the gateway SHOULD stop sending media until the call is resumed and SHOULD send a re-INVITE to the SIP leg of the call requesting that the remote side stop sending media.
From the perspective of a gateway, either the SIP side or the ISUP side can release a call, regardless of which side initiated the call. Note that cancellation of a call setup request (either from the ISUP or SIP side) is discussed elsewhere in this document (in Section 8.2.7 and Section 7.2.3, respectively).
Gateways SHOULD implement functional equivalence with the flows in this section.