Network Working Group G. Camarillo Internet-Draft Ericsson Expires: December 30, 2002 A. Roach dynamicsoft J. Peterson NeuStar L. Ong Ciena July 1, 2002 ISUP to SIP Mapping draft-ietf-sipping-isup-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the ISDN User Part (ISUP) of 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). Camarillo, et al. Expires December 30, 2002 [Page 1] Internet-Draft ISUP to SIP Mapping July 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 4. SIP Mechanisms Required . . . . . . . . . . . . . . . . . 9 4.1 'Transparent' Transit of ISUP Messages . . . . . . . . . . 9 4.2 Understanding MIME Multipart Bodies . . . . . . . . . . . 9 4.3 Transmission of DTMF Information . . . . . . . . . . . . . 9 4.4 Reliable Transmission of Provisional Responses . . . . . . 9 4.5 Provisional Media Streams . . . . . . . . . . . . . . . . 10 4.6 Mid-Call Transactions which do not change SIP state . . . 10 5. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. SIP to ISUP Mapping . . . . . . . . . . . . . . . . . . . 12 6.1 Call flows . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1 En-bloc Call Setup (no auto-answer) . . . . . . . . . . . 12 6.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 13 6.1.3 ISUP T7 Expires . . . . . . . . . . . . . . . . . . . . . 14 6.1.4 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.5 ISUP Setup Failure . . . . . . . . . . . . . . . . . . . . 16 6.1.6 Cause Present in ACM Message . . . . . . . . . . . . . . . 17 6.1.7 Call Canceled by SIP . . . . . . . . . . . . . . . . . . . 18 6.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 19 6.2.1 INVITE received . . . . . . . . . . . . . . . . . . . . . 20 6.2.1.1 INVITE to IAM procedures . . . . . . . . . . . . . . . . . 20 6.2.2 ISUP T7 expires . . . . . . . . . . . . . . . . . . . . . 23 6.2.3 CANCEL or BYE received . . . . . . . . . . . . . . . . . . 23 6.2.4 REL received . . . . . . . . . . . . . . . . . . . . . . . 23 6.2.4.1 ISDN Cause Code to Status Code Mapping . . . . . . . . . . 24 6.2.5 Early ACM received . . . . . . . . . . . . . . . . . . . . 26 6.2.6 ACM received . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.7 CON or ANM Received . . . . . . . . . . . . . . . . . . . 28 6.2.8 Timer T9 Expires . . . . . . . . . . . . . . . . . . . . . 28 6.2.9 CPG Received . . . . . . . . . . . . . . . . . . . . . . . 28 6.3 ACK received . . . . . . . . . . . . . . . . . . . . . . . 28 7. ISUP to SIP Mapping . . . . . . . . . . . . . . . . . . . 29 7.1 Call Flows . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1.1 En-bloc call setup (non auto-answer) . . . . . . . . . . . 29 7.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 30 7.1.3 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 31 7.1.4 ISUP T9 Expires . . . . . . . . . . . . . . . . . . . . . 32 7.1.5 SIP Error Response . . . . . . . . . . . . . . . . . . . . 33 7.1.6 SIP Redirection . . . . . . . . . . . . . . . . . . . . . 34 7.1.7 Call Canceled by ISUP . . . . . . . . . . . . . . . . . . 35 7.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 36 7.2.1 Initial Address Message received . . . . . . . . . . . . . 37 7.2.1.1 IAM to INVITE procedures . . . . . . . . . . . . . . . . . 37 7.2.2 100 received . . . . . . . . . . . . . . . . . . . . . . . 38 Camarillo, et al. Expires December 30, 2002 [Page 2] Internet-Draft ISUP to SIP Mapping July 2002 7.2.3 18x received . . . . . . . . . . . . . . . . . . . . . . . 38 7.2.4 2xx received . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.5 3xx Received . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.6 4xx-6xx Received . . . . . . . . . . . . . . . . . . . . . 41 7.2.6.1 SIP Status Code to ISDN Cause Code Mapping . . . . . . . . 41 7.2.7 REL Received . . . . . . . . . . . . . . . . . . . . . . . 42 7.2.8 ISUP T11 Expires . . . . . . . . . . . . . . . . . . . . . 43 8. Suspend/Resume and Hold . . . . . . . . . . . . . . . . . 44 8.1 SUS and RES . . . . . . . . . . . . . . . . . . . . . . . 44 8.2 Hold (re-INVITE) . . . . . . . . . . . . . . . . . . . . . 45 9. Normal Release of the Connection . . . . . . . . . . . . . 46 9.1 SIP initiated . . . . . . . . . . . . . . . . . . . . . . 46 9.2 ISUP initiated . . . . . . . . . . . . . . . . . . . . . . 46 9.2.1 Caller hangs up . . . . . . . . . . . . . . . . . . . . . 46 9.2.2 Callee hangs up . . . . . . . . . . . . . . . . . . . . . 47 10. ISUP Maintenance Messages . . . . . . . . . . . . . . . . 48 10.1 Reset messages . . . . . . . . . . . . . . . . . . . . . . 48 10.2 Blocking messages . . . . . . . . . . . . . . . . . . . . 48 10.3 Continuity Checks . . . . . . . . . . . . . . . . . . . . 48 11. Construction of Telephony URIs . . . . . . . . . . . . . . 50 12. Other ISUP flavors . . . . . . . . . . . . . . . . . . . . 54 12.1 Guidelines to send other ISUP messages . . . . . . . . . . 54 13. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 56 14. Security Considerations . . . . . . . . . . . . . . . . . 57 15. IANA Considerations . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 61 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 62 References . . . . . . . . . . . . . . . . . . . . . . . . 59 References . . . . . . . . . . . . . . . . . . . . . . . . 60 B. Revision History . . . . . . . . . . . . . . . . . . . . . 63 Full Copyright Statement . . . . . . . . . . . . . . . . . 65 Camarillo, et al. Expires December 30, 2002 [Page 3] Internet-Draft ISUP to SIP Mapping July 2002 1. Introduction SIP [1] is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP. Telephone calls are considered a type of multimedia sessions where just audio is exchanged. ISUP [10] is a level 4 protocol used in SS7 networks. It typically runs over MTP although it can also run over IP (see SCTP [17]). 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 PSTN) and with IP interfaces (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. Camarillo, et al. Expires December 30, 2002 [Page 4] Internet-Draft ISUP to SIP Mapping July 2002 2. Scope This document focuses on the translation of ISUP messages into SIP messages, and the mapping of ISUP parameters into SIP headers. The purpose of translation in ISUP-SIP interworking is twofold: for ISUP calls that traverse a SIP network, translation allows SIP elements such as proxy servers to make routing decisions based on ISUP criteria such as the called party number; translation also provides critical information about the call to SIP endpoints that cannot understand encapsulated ISUP (or perhaps which merely cannot understand the particular ISUP variant in use). This document only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these message 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. ITU-T Q.767 International ISUP [8] is used through this document; some differences with ANSI [9] ISUP and TTC ISUP are outlined. ISUP Q.767 is used in this document because it is the least complex of all the ISUP flavors. Due to the small number of fields that map directly from ISUP to SIP, the signaling differences between Q.767 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 since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. 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 ACM and REL messages based on SIP status codes. This document describes when the media path associated with a SIP Camarillo, et al. Expires December 30, 2002 [Page 5] Internet-Draft ISUP to SIP Mapping July 2002 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. Camarillo, et al. Expires December 30, 2002 [Page 6] Internet-Draft ISUP to SIP Mapping July 2002 3. Scenarios There are several scenarios where ISUP-SIP mapping takes place. The way the messages are generated is different depending on the scenario. When there is a single MGC and the call is from a SIP phone to a PSTN phone, or vice versa, the MGC generates the ISUP messages based on the methods described in this document. +-------------+ +-----+ +-------------+ | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | +-------------+ +-----+ +-------------+ The scenario where a call originates in the PSTN, goes into a SIP network and terminates in the PSTN again is known as "SIP bridging". SIP bridging should provide ISUP transparency between the PSTN switches handling the call. This is achieved by encapsulating the incoming ISUP messages in the body of the SIP messages (see [2]). In this case, the ISUP messages generated by the egress MGC are the ones present in the SIP body (possibly with some modifications; for example, if the called number in the request URI is different from the one present in the ISUP due to SIP redirection, the ISUP message will need to be adjusted). +------+ +-------------+ +-----+ +------------+ +------+ | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | +------+ +-------------+ +-----+ +------------+ +------+ SIP is used in the middle of both MGCs because the voice path has to be established through the IP network between both MGs; this structure also allows the call to take advantage of certain SIP services. ISUP messages in the SIP bodies provide further information (such as cause values and optional parameters) to the peer MGC. In both scenarios, the ingress MGC places the incoming ISUP messages in the SIP body by default. Note that this has security implications; see Section 14. If the recipient of these messages (typically a SIP UAC/UAS) does not understand them a negotiation using the SIP `Accept' and `Require' headers will take place and they will not be included in the next SIP message exchange. There can be a 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 [17]. The mapping described in this document is not affected by the underlying transport protocol of ISUP. Camarillo, et al. Expires December 30, 2002 [Page 7] Internet-Draft ISUP to SIP Mapping July 2002 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. Camarillo, et al. Expires December 30, 2002 [Page 8] Internet-Draft ISUP to SIP Mapping July 2002 4. SIP Mechanisms Required 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.). 4.1 'Transparent' Transit of ISUP Messages To provide users the ability to take advantage of the full range of services afforded by the existing telephone network when placing calls from PSTN to PSTN across a SIP network, SIP messages will need to transport ISUP payloads from gateway to gateway. The format for encapsulating these ISUP messages is defined in [2]. SIP clients and servers which do not understand ISUP are permitted to ignore these optional MIME bodies. 4.2 Understanding MIME Multipart Bodies In most PSTN interworking situations, the SIP body will be required to carry session information (SDP) in addition to ISUP and/or billing information. PSTN interworking nodes should understand the MIME type of "multipart/mixed" as defined in RFC2046 [3]. Clients express support for this by including "multipart/mixed" in an "Accept" header. 4.3 Transmission of DTMF Information Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is desirable (since out-of-band transmission alone would provide many challenges for synchronization of the media stream for tone re-insertion). This transmission should be performed as described in RFC2833 [4] and is in all respects orthogonal to the mapping of ISUP and SIP. 4.4 Reliable Transmission of Provisional Responses Provisional responses 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 messages. Camarillo, et al. Expires December 30, 2002 [Page 9] Internet-Draft ISUP to SIP Mapping July 2002 PSTN interworking should occur over a reliable transport layer end- to-end. One application-layer provisional reliability mechanism is described in [16]. 4.5 Provisional Media Streams To allow the transmission of messages and tones before a final connection has been established, SIP nodes which interwork with the PSTN need to be able to establish temporary media connections during this period. MGCs should support the establishment of temporary provisional media streams using the 183 status code (described in [1]). A more detailed analysis of the problem of early media is given in [18]. 4.6 Mid-Call Transactions which do not change SIP state When interworking with PSTN, there are situations when PSTN nodes will need to send messages which do not correspond to any SIP operations to each other across a SIP network. The method for performing this transit will be in the INFO method, defined in RFC2976 [5]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits. Nodes which do serve as PSTN interworking points should accept "405 Method Not Allowed" and "501 Not Implemented" responses to INFO requests as non-fatal. Camarillo, et al. Expires December 30, 2002 [Page 10] Internet-Draft ISUP to SIP Mapping July 2002 5. Mapping The mapping between ISUP and SIP is described using call flow diagrams and state machines. One state machine handles calls from SIP to ISUP and the second from ISUP to SIP. There are details, such as some retransmissions and some states (waiting for RLC, waiting for ACK etc.), that are not shown in the figures in order to make them easier to follow. The boxes represent the different states of the gateway, and the arrows show changes in the state. The event that triggers the change in the state and the actions to take appear on the arrow: event / section describing the actions to take. For example, `INVITE / 6.2.1' indicates that an INVITE request has been received by the gateway, and the procedure upon reception is described in the section 6.2.1 of this document. Camarillo, et al. Expires December 30, 2002 [Page 11] Internet-Draft ISUP to SIP Mapping July 2002 6. SIP to ISUP Mapping 6.1 Call flows The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the SIP network. "100 Trying" acknowledgements to INVITE requests are not 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." 6.1.1 En-bloc Call Setup (no auto-answer) 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----------->| | 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. 3. The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message. 4. The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 6.2.5 and Section 6.2.6). and returned to the SIP node. This response may contain SDP to establish an early media stream (as shown in the diagram). If no SDP is present, the audio will be established in Camarillo, et al. Expires December 30, 2002 [Page 12] Internet-Draft ISUP to SIP Mapping July 2002 both directions after step 12. 5. If the ISUP variant permits, the remote ISUP node may issue a variety of CPG messages to indicate, for example, that the call is being forwarded. 6. Upon receipt of a CPG message, the gateway will map the event code to a SIP provisional response (see Section 6.2.9) and send it to the SIP node. 7. Once the PSTN user answers, an ANM message will be sent to the gateway. 8. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node. 9. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt. 6.1.2 Auto-answer call setup 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. 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. 3. Since the remote node is configured for automatic answering, it will send a CON message upon receipt of the IAM. (For ANSI, this message will be an ANM). 4. Upon receipt of the CON, the gateway will send a 200 message to the SIP node. Camarillo, et al. Expires December 30, 2002 [Page 13] Internet-Draft ISUP to SIP Mapping July 2002 5. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt. 6.1.3 ISUP T7 Expires SIP MGC/MG PSTN 1|---------INVITE---------->| | |<----------100------------| | | |------------IAM---------->|2 | |<=========Audio===========| | | *** T7 Expires *** | | ** MG Releases PSTN Trunk ** | 4|<----------504------------|------------REL---------->|3 5|-----------ACK----------->| | 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. The ISUP timer T7 is started at this point. 3. The ISUP timer T7 expires before receipt of an ACM or CON message, so a REL message is sent to cancel the call. 4. A gateway timeout message is sent back to the SIP node. 5. The SIP node, upon receiving an INVITE final response (504), will send an ACK to acknowledge receipt. Camarillo, et al. Expires December 30, 2002 [Page 14] Internet-Draft ISUP to SIP Mapping July 2002 6.1.4 SIP Timeout SIP MGC/MG PSTN 1|---------INVITE---------->| | |<----------100------------| | | |------------IAM---------->|2 | |<=========Audio===========| | |<-----------CON-----------|3 | |<=========Audio==========>| 4|<----------200------------| | | *** T1 Expires *** | | |<----------200------------| | | *** T1 Expires *** | | |<----------200------------| | | *** T1 Expires *** | | |<----------200------------| | | *** T1 Expires *** | | |<----------200------------| | | *** T1 Expires *** | | |<----------200------------| | | *** T1 Expires *** | | 5|<----------200------------| | | *** T1 Expires *** | | | ** MG Releases PSTN Trunk ** | 7|<----------BYE------------|------------REL---------->|6 | |<-----------RLC-----------|8 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. 3. Since the remote node is configured for automatic answering, it will send a CON message upon receipt of the IAM. In ANSI flows, rather than a CON an ANM (without ACM) would be sent. 4. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node and set SIP timer T1. 5. The response is retransmitted every time the SIP timer T1 expires. 6. After seven retransmissions, the call is torn down by sending a REL to the ISUP node, with a cause code of 102 (recover on timer expiry). Camarillo, et al. Expires December 30, 2002 [Page 15] Internet-Draft ISUP to SIP Mapping July 2002 7. A BYE is transmitted to the SIP node in an attempt to close the call. Further handling for this clean up is not shown, since the SIP node's state is not easily known in this scenario. 8. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message. 6.1.5 ISUP Setup Failure SIP MGC/MG PSTN 1|---------INVITE---------->| | |<----------100------------| | | |------------IAM---------->|2 | |<-----------REL-----------|3 | |------------RLC---------->|4 5|<----------4xx+-----------| | 6|-----------ACK----------->| | 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. 3. Since the remote ISUP node is unable to complete the call, it will send a REL. 4. The gateway releases the circuit and confirms that it is available for reuse by sending an RLC. 5. The gateway translates the cause code in the REL to a SIP error response (see Section 6.2.4) and sends it to the SIP node. 6. The SIP node sends an ACK to acknowledge receipt of the INVITE final response. Camarillo, et al. Expires December 30, 2002 [Page 16] Internet-Draft ISUP to SIP Mapping July 2002 6.1.6 Cause Present in ACM Message 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----------->| | 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. 3. Since the ISUP node is unable to complete the call and wants to generate the error tone/announcement itself, it sends an ACM with a cause code. The gateway starts an interwork timer. 4. Upon receipt of an ACM with cause (presence of the CAI parameter), the gateway will generate a 183 message towards the SIP node; this contains SDP to establish early media cut-through. 5. A final INVITE response, based on the cause code received in the earlier ACM message, is generated and sent to the SIP node to terminate the call. See Section 6.2.4.1 for the table which contains the mapping from cause code to SIP response. 6. Upon expiration of the interwork timer, a REL is sent towards the PSTN node to terminate the call. Note that the SIP node can also terminate the call by sending a CANCEL before the interwork timer expires. In this case, the signaling progresses as in Section 6.1.7. 7. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message. 8. The SIP node sends an ACK to acknowledge receipt of the INVITE final response. Camarillo, et al. Expires December 30, 2002 [Page 17] Internet-Draft ISUP to SIP Mapping July 2002 6.1.7 Call Canceled by SIP 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----------->| | 1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request. 2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. 3. The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message. 4. The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 6.2.5 and Section 6.2.6) and returned to the SIP node. This response may contain SDP to establish an early media stream. 5. To cancel the call before it is answered, the SIP node sends a CANCEL request. 6. The CANCEL request is confirmed with a 200 response. 7. Upon receipt of the CANCEL request, the gateway sends a REL message to terminate the ISUP call. 8. The gateway sends a "487 Call Cancelled" message to the SIP node to complete the INVITE transaction. 9. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message. 10. Upon receipt of the 487, the SIP node will confirm reception Camarillo, et al. Expires December 30, 2002 [Page 18] Internet-Draft ISUP to SIP Mapping July 2002 with an ACK. 6.2 State Machine Note that REL can be received in any state; the handling is the same for each case (see Section 9). +---------+ +----------------------->| Idle |<---------------------+ | +----+----+ | | | | | | INVITE/6.2.1 | | V | | T7/6.2.2 +-------------------------+ REL/6.2.4 | +<----------------+ Trying +------------>+ | +-+--------+------+-------+ | | CANCEL/6.2.3 | | | | | +<----------------+ | E.ACM/ | ACM/ | CON/ | | | 6.2.5 |6.2.6 | 6.2.7 | | V | | | | T9/6.2.8 +--------------+ | | | +<----------+ Not alerting | | | | | +-------+------+ | | | | CANCEL/6.2.3 | | | | | |<--------------+ | CPG/ | | | | | 6.2.9 | | | | V V | | | T9/6.2.8 +---------------+ | REL/6.2.4 | +<----------------+ Alerting |-|-------------------->| |<----------------+--+-----+------+ | | | CANCEL/6.2.3 | ^ | | | | CPG/ | | | ANM/ | | | 6.2.9 +--+ | 6.2.7 | | | V V | | +-------------------------+ REL/9.2 | | | Waiting for ACK |------------>| | +-------------+-----------+ | | | | | | ACK/6.2.10 | | V | | BYE/9.1 +-------------------------+ REL/9.2 | +<----------------+ Connected +------------>+ +-------------------------+ Camarillo, et al. Expires December 30, 2002 [Page 19] Internet-Draft ISUP to SIP Mapping July 2002 6.2.1 INVITE received When an INVITE request is received by the gateway, a "100 Trying" response should be sent back to the SIP network indicating that the MGC is handling the call. The resources for the media stream have to be reserved at this stage, since an IAM message cannot be sent before the resource reservation takes place. Typically the resources consist of a time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources might also include QoS or/and security provisions. Before sending the IAM the MG generally connects the backward media path. After sending the IAM the timer T7 is started. The default value of T7 is between 20 and 30 seconds. The MGC goes to the `Trying' state. 6.2.1.1 INVITE to IAM procedures 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. 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 must extract some 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 [15] 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 PSTN context of the session 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 Camarillo, et al. Expires December 30, 2002 [Page 20] Internet-Draft ISUP to SIP Mapping July 2002 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 [2]), if any, within the INVITE to assist in the formulation of outbound PSTN signaling. If possible, the gateway should reuse the values in the 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 encapsulated ISUP, the relevant values of SIP header fields must 'overwrite' the parameter values that would have been set based on encapsulated ISUP through the process of translation. 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 should 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 should use default values for mandatory ISUP parameters that are not derived from translation or encapsulation (such as the NCI or TMR parameters). The FCI parameter should also have a default, although its 'M' bit may be overwritten during the process of translation. First, the Request-URI should be inspected. If there is no 'npdi=yes' field within the Request-URI, then the main telephone number in the tel URL (the digits immediately following 'tel:') should be converted to ISUP format, following the procedure described in Section 11, and used to populate the CPN parameter. In ANSI networks, if the 'npdi=yes' field exists in the Request-URI, then the FCI parameter bit for 'number translated' within the IAM should 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 should be converted to ISUP format (see Section 11) and used to populate the CPN parameter. Camarillo, et al. Expires December 30, 2002 [Page 21] Internet-Draft ISUP to SIP Mapping July 2002 If in addition to the 'npdi=yes' field an 'rn=' field is present, then in ANSI networks the 'rn=' field should be converted to ISUP format and used to populate the CPN. The main telephone number in the tel URL should be converted to ISUP format and used to populate the Generic Digits Parameter (or GAP in ANSI). In some networks the number given in the 'rn=' field should be prepended to the main telephone number and the combined result should be used to populate the CPN. If main 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. 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)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) may dictate whether the CIP or TNS parameter should be used (although note that in non-ANSI networks the CIP will never be used). 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 NoA field of the CPN indicates that this is an international number), and the CIP should be used in other cases. If a SIP call has arrived at a gateway, then the Request-URI will most likely contain a tel URL (or a SIP URI with a tel URL user portion). However, if the call originated at a native IP endpoint such as a SIP phone, the From field may not reflect any telephone number - it may be a simple user@host construction. The CIN parameter should be omitted from the outbound IAM if the From field is unusable. Note that when the ISUP parameters regarding interworking are set in the Forward Call Indicators (FCI) parameter of the IAM , this indicates that ISDN is interworking with a network which is not capable of providing as many services as ISDN does. ISUP will therefore not employ certain features it otherwise normally uses. Thus, when ISUP feature transparency is available, `interworking encountered' must not be specified so that ISUP behaves normally. Therefore, when a gateway receives a message with (comprehensible) encapsulated ISUP, it should not set the 'interworking encountered' bit in the FCI, and it should set the 'ISUP all the way' bit. If usable encapsulated ISUP is not present in an INVITE received by the gateway, it may set the 'interworking encountered' bit as Camarillo, et al. Expires December 30, 2002 [Page 22] Internet-Draft ISUP to SIP Mapping July 2002 appropriate. 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 [12]). 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. 6.2.2 ISUP T7 expires Since no response was received from the PSTN all the resources in the MG are released. A `504 gateway timeout' is sent back to the SIP network. A REL message with cause value 102 (protocol error, recovery on timer expiry) is sent to the PSTN. The PSTN responds with RLC and the SIP network responds with an ACK indicating that the release sequence has been completed. 6.2.3 CANCEL or BYE received If a CANCEL or BYE request is received, a `200 OK' is sent to the SIP network to confirm the CANCEL or BYE; a 487 is also sent to terminate the INVITE transaction. All the resources are released and a REL message is sent to the PSTN with cause value 16 (normal clearing). A RLC from the PSTN is received indicating that the release sequence is complete. It is important that all the resources are released before the gateway sends any REL message. In SIP bridging situations, a REL might arrive in the CANCEL or BYE request body. This REL is sent to the PSTN. This applies when a CANCEL or a BYE is received before a final SIP response has been sent. 6.2.4 REL received This section applies every time that a REL is received before a final SIP response has been sent. The resources are released in the MG and a RLC is sent to the ISUP network to indicate that the circuit is available for reuse. If the INVITE originating this transaction contained an ISUP message in its body (such as an IAM), the MGC is handling a SIP bridging situation. Therefore, the REL message just received should be included in the body of the response. Camarillo, et al. Expires December 30, 2002 [Page 23] Internet-Draft ISUP to SIP Mapping July 2002 Note that the receipt of certain maintenance messages in response to IAM such as BLO or 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 10. 6.2.4.1 ISDN Cause Code to Status Code Mapping 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 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 status 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 (IAM) 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). If a cause value other than what is listed below is received, the default response `500 Server internal error' would be used. 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 Circuit Identification Code (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. Camarillo, et al. Expires December 30, 2002 [Page 24] Internet-Draft ISUP to SIP Mapping July 2002 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 302 Moved Temporarily 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. 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 parse this information it might be added to the SIP response (301) in a Contact header. Resource unavailable This kind of cause value indicates a non permanent situation. A `Retry-After' header may be added to the response. ISUP Cause value SIP response ---------------- ------------ 34 no circuit available 503 Service unavailable 38 network out of order 503 Service unavailable 41 temporary failure 503 Service unavailable 42 switching equipment congestion 503 Service unavailable 47 resource unavailable 503 Service unavailable Camarillo, et al. Expires December 30, 2002 [Page 25] Internet-Draft ISUP to SIP Mapping July 2002 Service or option not available This kind of cause value indicates a permanent situation. 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 501 Not implemented 79 service or option not implemented 501 Not implemented Invalid message ISUP Cause value SIP response ---------------- ------------ 87 user not member of CUG 503 Service unavailable 88 incompatible destination 503 Service unavailable 95 invalid message 503 Service unavailable Protocol error 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 6.2.5 Early ACM received This message is sent in certain situations for resetting the timers. In these cases this message indicates that the call is in progress but callee is not being alerted. This occurs for example in mobile networks, where roaming can take a long time. The early ACM is sent before the user is alerted to reset T7 and start T9. Camarillo, et al. Expires December 30, 2002 [Page 26] Internet-Draft ISUP to SIP Mapping July 2002 An ACM is considered an `early ACM' if the Called Party's Status Indicator is set to 00 (no indication). After receiving an early ACM the progress of the call is indicated by the network sending CPGs. When there is interworking with some old systems, it is possible to receive an ANM immediately after an early ACM (without CPG). In this situation the SIP user will not hear any kind of ringback tone before the callee answers. In ISDN (see [10]) this is solved by connecting the voice path backwards before sending the IAM. The MGC sends a 183 Session Progress (see [1]) to the SIP network with a media description inside. In SIP bridging situations the early ACM is included in the response body. Thus, the problem of missing the ring back tone is solved and the early ACM is transported transparently through the SIP network. 6.2.6 ACM received Upon reception of an ACM, in many networks timer T9 is started. T9 typically lasts between 90 seconds and 3 minutes (see [11]) . It allows the caller to hear announcements from the network for that period of time without being charged for the connection. If longer announcements have to be played the network has to send an ANM. When the ANM is sent the call begins being charged. Some networks do not support timer T9. The nearest local exchange to the callee generates the ringback tone and may send voice announcements. Usually on receipt of an ACM a `180 Ringing' is sent to the SIP network. It should generally contain a session description in order to allow SIP UAs to prevent clipping of initial callee media. The ringback tone or the proper announcements will be generated by the PSTN exchange, and not by the callers SIP UAC/UAS. If the Backwards Call Indicator (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 support cause codes), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message. In this case rather than a 180 status code, a 183 Session Progress message should be sent in order to allow pre-ANM media to flow in the backwards direction. In SIP bridging situations, the ACM is included in the body of the 180 response. Camarillo, et al. Expires December 30, 2002 [Page 27] Internet-Draft ISUP to SIP Mapping July 2002 6.2.7 CON or ANM Received A `200 OK' response is sent to the SIP network. In SIP bridging situations, the ISUP message is included in the body of the 200 OK response. This is also the point at which a two-way media stream will be established. 6.2.8 Timer T9 Expires This indicates that the ANM has not arrived in time specified. This results in the call being aborted. All the resources related to the media path are released. A `480 temporarily unavailable' is sent to the SIP network. A REL message with cause value 19 (no answer from the user) is sent to the ISUP part. The PSTN responds with RLC and the SIP network responds with an ACK indicating that the release sequence has been completed. 6.2.9 CPG Received A CPG can indicate progress, alerting or in-band information. If the CPG comes after an ACM, there is already a one-way voice path open, so there is no need of taking further action in the media path. In SIP bridging situations, the CPG is sent in the body of a 18x response, determined from the CPG event code. ISUP event code SIP response ---------------- ------------ 1 Alerting 180 Ringing 2 Progress 183 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. 6.3 ACK received At this stage, the call is connected and the conversation can take place. Camarillo, et al. Expires December 30, 2002 [Page 28] Internet-Draft ISUP to SIP Mapping July 2002 7. ISUP to SIP Mapping 7.1 Call Flows The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the PSTN network. "100 Trying" acknowledgements to INVITE requests are not explained, since their presence is optional. In these diagrams, all call 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." 7.1.1 En-bloc call setup (non auto-answer) SIP MGC/MG PSTN | |<-----------IAM-----------|1 | |==========Audio==========>| 2|<--------INVITE-----------| | |-----------100----------->| | 3|-----------18x----------->| | |==========Audio==========>| | | |=========================>| | |------------ACM---------->|4 5|-----------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." Camarillo, et al. Expires December 30, 2002 [Page 29] Internet-Draft ISUP to SIP Mapping July 2002 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 7.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. 7.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. Camarillo, et al. Expires December 30, 2002 [Page 30] Internet-Draft ISUP to SIP Mapping July 2002 7.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. Camarillo, et al. Expires December 30, 2002 [Page 31] Internet-Draft ISUP to SIP Mapping July 2002 6. The gateway also sends a CANCEL message to the SIP node to terminate any initiation attempts. 7. Upon receipt of the REL, the remote ISUP node will send an RLC to acknowledge. 7.1.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. Camarillo, et al. Expires December 30, 2002 [Page 32] Internet-Draft ISUP to SIP Mapping July 2002 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. 7.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 7.2.6.1. 6. The remote ISUP node confirms receipt of the REL message with an RLC message. Camarillo, et al. Expires December 30, 2002 [Page 33] Internet-Draft ISUP to SIP Mapping July 2002 7.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 instances 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 Camarillo, et al. Expires December 30, 2002 [Page 34] Internet-Draft ISUP to SIP Mapping July 2002 response of 180 or greater. 8. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message with an event code as indicated in Section 7.2.3. 9. 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. 7.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 7.2.3. Camarillo, et al. Expires December 30, 2002 [Page 35] Internet-Draft ISUP to SIP Mapping July 2002 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. 7.2 State Machine Note that REL may arrive in any state. Whenever this occurs, the actions in section Section 7.2.7. are taken. Not all of these transitions are shown in this diagram. Camarillo, et al. Expires December 30, 2002 [Page 36] Internet-Draft ISUP to SIP Mapping July 2002 +---------+ +----------------------->| 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 +------------>+ +-----------------------------+ 7.2.1 Initial Address Message received Upon the reception of an IAM, resources are reserved in the media gateway and it connects audio in the backwards direction (towards the caller). 7.2.1.1 IAM to INVITE procedures When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message will be created for transmission to the SIP network. This section details the process by which a gateway populates the INVITE based on parameters found within the IAM. The session context information discovered by the gateway in the IAM will be stored primarily in two URIs in the INVITE, one representing the originator of the session and the other the destination. The Camarillo, et al. Expires December 30, 2002 [Page 37] Internet-Draft ISUP to SIP Mapping July 2002 former will always appear in the From header (after it has been converted from ISUP format by the procedure described in Section 11), and the latter is almost always used for both the To header and the Request-URI. Once the location of the called party number has been determined, it should be translated into a tel URL through the mechanism described above. Some additional fields may need to be added to the tel URL after translation has been completed, namely: o If either the CIP (in ANSI networks) or TNS is present, the carrier identification code (CIC) should be extracted from the parameter and analyzed by the gateway. 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), a 'cic=' field with the value of the CIC should be appended to the tel URL. Note that the CIC should 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 [6]. In most cases, the resulting URI should be used in the To field and Request-URI sent by the gateway. However, if the OCN parameter is present in the IAM, the To field constructed from the translation of the OCN parameter, and hence the Request-URI and To field will be different. The construction of the From 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 containing a SIP URI without a user portion which communicates only the hostname of the gateway (e.g. 'sip:gw.level3.net'). 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 field. 7.2.2 100 received A 100 response does not trigger any PSTN interworking messages; it only serves the purpose of suppressing INVITE retransmissions. 7.2.3 18x received If no ACM has been sent yet and no ISUP is present in the 18x message body, then the ISUP message is generated according to the following table. Note that, if an early ACM is sent, the call enters state "Progressing" instead of state "Alerting." Camarillo, et al. Expires December 30, 2002 [Page 38] Internet-Draft ISUP to SIP Mapping July 2002 Response received Message sent by the MGC ----------------- ----------------------- 180 Ringing ACM 181 Call is being forwarded Early ACM and CPG, event=6 182 Queued ACM 183 Session progress message ACM If an ACM has already been sent and no ISUP is present in the 18x message body, an ISUP message is generated according to the following table. Response received Message sent by the MGC ----------------- ----------------------- 180 Ringing CPG, event = 1 (Alerting) 181 Call is being forwarded CPG, event = 6 (Forwarding) 182 Queued CPG, event = 2 (Progress) 183 Session progress message CPG, event = 2 (Progress) If the reception of a `180 Ringing' response without media description, the MG generates the ringback tone to be heard by the caller. If the MGC receives any 1xx response (except 100) with a session description present for media setup, it sets up the session being described. The call progress media (e.g. ringback tone or announcement) is generated by an entity downstream (in the SIP network or by a PSTN exchange in SIP bridging situations). If an ACM has not been sent yet, one is generated and sent. The mandatory parameters of the ACM are described below: Message type: ACM Backward Indicators Charge indicator: 10 charge Called party's status indicator: 01 subscriber free or 00 no indication (E.ACM) Called party's category indicator: 01 ordinary subscriber End-to-end method indicator: 00 no end-to-end method Interworking indicator: 0 no interworking End-to-end information indicator: 0 no end-to-end info ISDN user part indicator: 1 ISUP all the way Holding indicator: 0 no holding ISDN access indicator: 1 ISDN access Echo control device indicator: It depends on the call SCCP method indicator: 00 no indication The settings above assume that comprehensible encapsulated ISUP is Camarillo, et al. Expires December 30, 2002 [Page 39] Internet-Draft ISUP to SIP Mapping July 2002 present in the response. If no usable encapsulated ISUP is present, the gateway should set the 'interworking encountered' bit of the BCI, and should not set the ISDN user part indicator bit. In SIP bridging situations the MGC sends the ISUP message contained 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 therefore be avoided. 7.2.4 2xx received Response received Message sent by the MGC ----------------- ----------------------- 200 OK ANM, ACK After receiving a 200 OK response the MGC establishes a two-way voice path in the MG and it sends an ANM to the PSTN and an ACK to the SIP network. If the `200 OK' response arrives before the MGC has sent the ACM, a CON is sent instead of the ANM. In SIP bridging situations the MGC sends the ANM or the CON in the response body. 7.2.5 3xx Received When any 3xx response is received ,the MGC should try to contact the user using the `Contact' header or headers present in the response. These 3xx responses are typically sent by a re-direct server. This is a similar device to the HLR in mobile networks. It provides another address where the callee may be reached. A CPG message with an event code of 6 (Forwarding) may be sent to indicate that the call is proceeding. Note that some ISUP nodes may not support CPG before ACM, so this feature should be configurable. If the new location presented in the Contact header of a 3xx is best reachable (according to the gateway's routing policies) via the PSTN, the MGC sends a new IAM and from that moment on acts as a normal PSTN switch (no SIP involved). If the new location is best reachable using SIP, the MGC sends an INVITE with possibly a new IAM generated by the MGC in the message body. All redirection situations have to be treated very carefully because they involved special charging situations. In PSTN the caller Camarillo, et al. Expires December 30, 2002 [Page 40] Internet-Draft ISUP to SIP Mapping July 2002 typically pays the first dialog and the callee pays the second. 7.2.6 4xx-6xx Received The MGC releases the resources in the MG, send a REL to the PSTN with a cause value and send an ACK to the SIP network. An RLC arrives indicating that the release sequence is complete. 7.2.6.1 SIP Status Code to ISDN Cause Code Mapping 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. 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". 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 be translated to ISUP. Examples are flagged with (+) 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 (+) 480 Temporarily unavailable 18 No user responding Camarillo, et al. Expires December 30, 2002 [Page 41] Internet-Draft ISUP to SIP Mapping July 2002 481 Call/Transaction Does not Exist 41 Temporary Failure 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 488 Not Acceptable here --- by Warning header 500 Server internal error 41 Temporary failure 501 Not implemented 38 Network out of order 502 Bad gateway 38 Network out of order 503 Service unavailable 41 Temporary failure 504 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 authorize 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 assumes that sending '31 Normal, unspecified' will be sufficient by default for all currently assigned Warning codes. If the Warning code speaks to an unavailable bearer capability, cause code '64 Bearer Capability Not Implemented' could be a superior mapping. 7.2.7 REL Received The MGC should abort the establishment of the session. A CANCEL request has to be issued. A BYE is not used, since no final response has arrived from the SIP side. A 200 OK for the CANCEL arrives, and a 487 for the INVITE arrives. The MGC has to store state information for a certain period of time, since a 200 final response for the INVITE originally sent might arrive (even after the reception of the 200 OK for the CANCEL). In this situation, the MGC sends an ACK and then a BYE. Camarillo, et al. Expires December 30, 2002 [Page 42] Internet-Draft ISUP to SIP Mapping July 2002 In SIP bridging situations, the REL message may be included in the CANCEL message body. CANCEL requests are answered with a final response (such as 200 OK) by the first proxy. Therefore, the MGC does not know if the CANCEL has arrived to the end user (egress MGC in this scenario). Note that although end-to-end delivery of the CANCEL's payload is not guaranteed, since both sides of a PSTN connection issue REL messages, it will not result in a failure in the PSTN if this REL is never delivered. If, in a glare condition, a 200 OK response to the previously sent INVITE arrives after a CANCEL has been sent, the MGC sends an ACK and then a BYE with the REL in the message body. 7.2.8 ISUP T11 Expires In order to prevent the remote ISUP node's timer T7 from expiring, the gateway may choose to keep its own supervisory timer; ISUP defines this timer as T11. T11's duration is carefully chosen so that it will always be shorter than the T7 of any node to which the gateway is communicating. To clarify timer T11's relevance with respect to SIP interworking, Q.764 [10] 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's T11 expires, it will send an early ACM (i.e. called party status set to "no indication") to prevent the expiration of the remote node's T7. See Section 7.2.3 for the value of the ACM parameters. If a "180 Ringing" message arrives subsequently, it will be sent in a CPG, as shown in Section 7.2.3. See Section 7.1.3 for an example callflow that includes the expiration of T11. Camarillo, et al. Expires December 30, 2002 [Page 43] Internet-Draft ISUP to SIP Mapping July 2002 8. Suspend/Resume and Hold 8.1 SUS and RES 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. 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, it may be desirable to 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 should 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 would 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 [5] method can be used to transmit an encapsulated SUS rather than a re-INVITE. Subsequent RES messages should 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. All of the following examples use the INVITE mechanism. Camarillo, et al. Expires December 30, 2002 [Page 44] Internet-Draft ISUP to SIP Mapping July 2002 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 9.2.2. 8.2 Hold (re-INVITE) After a call has been connected, a re-INVITE may be sent to a gateway from the SIP side in order to place the call on hold. This re-INVITE will have an SDP 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 Call Progress Message (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 to begin receiving media again, it may repeat the flow above with an INVITE that contains an SDP with a reachable 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 may wish to stop sending media until the call is resume, and/or send a re-INVITE to the SIP leg of the call requesting that the remote side stop sending media. Camarillo, et al. Expires December 30, 2002 [Page 45] Internet-Draft ISUP to SIP Mapping July 2002 9. Normal Release of the Connection Either the SIP side or the ISUP side may release a call, regardless of which side initiated the call. 9.1 SIP initiated For a normal release of the call (reception of BYE), the MGC immediately sends a 200 response. It then releases the resources in the MG and sends an REL with a cause code of 16 (normal call clearing) to the PSTN. Release of resources is confirmed by the PSTN with a RLC. In SIP bridging situations, the REL contained in the BYE is sent to the PSTN. SIP MGC/MG PSTN 1|-----------BYE----------->| | | ** MG Releases IP Resources ** | 2|<----------200------------| | | ** MG Releases PSTN Trunk ** | | |------------REL---------->|3 | |<-----------RLC-----------|4 9.2 ISUP initiated If the release of the connection was caused by the reception of a REL, the REL is included in the BYE sent by the MGC. 9.2.1 Caller hangs up For a normal release of the call (reception of REL from the PSTN), the MGC first releases the resources in the MG and then confirms that they are ready for re-use by sending an RLC. The SIP connection is released by sending a BYE (which is confirmed with a 200). SIP MGC/MG PSTN | |<-----------REL-----------|1 | ** MG Releases PSTN Trunk ** | | |------------RLC---------->|2 3|<----------BYE------------| | | ** MG Releases IP Resources ** | 4|-----------200----------->| | Camarillo, et al. Expires December 30, 2002 [Page 46] Internet-Draft ISUP to SIP Mapping July 2002 9.2.2 Callee hangs up In analog PSTN, if the callee hangs up in the middle of a call, the local exchange sends a SUS instead of a REL and starts a timer (T6, SUS is network initiated). When the timer expires, the REL is sent. SIP MGC/MG PSTN | |<-----------SUS-----------|1 2|<--------INVITE-----------| | 3|-----------200----------->| | 4|<----------ACK------------| | | | *** T6 Expires *** | | |<-----------REL-----------|5 | ** MG Releases PSTN Trunk ** | | |------------RLC---------->|6 7|<----------BYE------------| | | ** MG Releases IP Resources ** | 8|-----------200----------->| | Camarillo, et al. Expires December 30, 2002 [Page 47] Internet-Draft ISUP to SIP Mapping July 2002 10. ISUP Maintenance Messages ISUP contains a set of messages used for maintenance purposes. They can be received during an ongoing call. There are basically two kinds of maintenance messages (apart from the continuity check): message for blocking circuits and messages for resetting circuits. 10.1 Reset messages Upon reception of a reset message for the circuit being used, the call has to be released. RSC messages are answered with RLC after resetting the circuit in the MG. GRS messages are answered with GRA after resetting all the circuits affected by the message. The MGC acts as if a REL had been received in order to release the connection on the SIP side. The session will be terminated. A BYE or a CANCEL are sent depending of the status of the call. 10.2 Blocking messages There are two kinds of blocking messages: maintenance oriented or hardware failure oriented. Maintenance oriented blocking messages indicates that the circuit has to be blocked for subsequent calls. Therefore, these messages do not affect any ongoing call. Hardware oriented blocking messages have to be treated as reset messages. The call is released. BLO is always maintenance oriented and it is answered by the MGC with BLA when the circuit is blocked. CGB messages have a "type indicator" inside the "circuit group supervision message type indicator". It indicates if the CGB is maintenance or hardware failure oriented. CGBs are answered with CGBAs. 10.3 Continuity Checks A continuity check is a test performed on a circuit that involves the reflection of a tone generated at the originating switch by a loopback at the destination switch. Two variants of the continuity check appear in ISUP: the implicit continuity check request within an IAM (in which case the continuity check takes place before call setup begins), and the explicit continuity check signaled by a Continuity Check Request (CCR) message. When a CCR is received by a PSTN-SIP gateway, the gateway should not send any SIP messages; the scope of the continuity check applies only to the PSTN trunks, not to any IP media paths. Camarillo, et al. Expires December 30, 2002 [Page 48] Internet-Draft ISUP to SIP Mapping July 2002 When an IAM with the Continuity Check Indicator flag set within the Nature of Connection Indicators (NCI) parameter is received, the gateway should process the continuity check before sending an INVITE message; if the continuity check fails (a COT with Continuity Indicator of 'failed' is received), then an INVITE should not be sent. Camarillo, et al. Expires December 30, 2002 [Page 49] Internet-Draft ISUP to SIP Mapping July 2002 11. Construction of Telephony URIs SIP proxy servers may route SIP messages on any signaling criteria desired by network administrators, but generally the Request-URI is the foremost routing criterion. The To and From headers are also frequently of interest in making routing decisions. SIP-ISUP mapping assumes that proxy servers are interested in at least these three fields of SIP messages, all of which contain URIs. SIP-ISUP mapping frequently requires the representation of telephone numbers in these URIs. In some instances these numbers will be presented first in ISUP messages, and SS7-SIP gateways will need to translate the ISUP formats of these numbers into SIP URIs. In other cases the reverse transformation will be required. The most common format used in SIP for the representation of telephone numbers is the tel URL [7]. The tel URL may constitute the entirety of a URI field in a SIP message, or it may appear as the user portion of a SIP URI. For example, a To field might appear as: To: tel:+17208881000 Or To: sip:+17208881000@level3.com Whether or not a particular gateway or endpoint should formulate URIs in the tel or SIP format is a matter of local administrative policy - if the presence of a host portion would aid the surrounding network in routing calls, the SIP format should be used. A gateway should accept either tel or SIP URIs from its peers. The '+' sign preceding the number in these examples indicates that the digits which follow constitute a fully-qualified E.164 [14] number; essentially, this means that a country code is provided before any national-specific area codes, exchange/city codes, or address codes. The absence of a '+' sign could mean that the number is nationally significant, or perhaps that a private dialing plan is in use. When the '+' sign is not present, but a telephone number is represented by the user portion of the URI, the SIP URI should may the optional ';user=phone' parameter; e.g. To: sip:83000@sip.example.net;user=phone However, it is highly recommended that only internationally significant E.164 numbers be passed between SIP-T gateways, especially when such gateways are in different regions or different administrative domains. In many if not most SIP-T networks, gateways Camarillo, et al. Expires December 30, 2002 [Page 50] Internet-Draft ISUP to SIP Mapping July 2002 are not responsible for end-to-end routing of SIP calls; practically speaking, gateways have no way of knowing if the call will terminate in a local or remote administrative domain and/or region, and hence gateways should always assume that calls require an international numbering plan. There is no guarantee that recipients of SIP signaling will be capable of understanding national dialing plans used by the originators of calls - if the originating gateway does not internationalize the signaling, the context in which the digits were dialed cannot be extrapolated by far-end network elements. In ISUP signaling, a telephone number appears in a common format that is used in several parameters, including the Called Party's Number (CPN) and Calling Party's Number (CIN); when it represents a calling party number it sports some additional information (detailed below). For the purposes of this document, we will refer to this format as 'ISUP format' - if the additional calling party information is present, the format shall be referred to as 'ISUP- calling format'. The format consists of a byte called the Nature of Address (NoA) indicator, followed by another byte which contains the Numbering Plan Indicator (NPI), both of which are prefixed to a variable-length series of bytes that contains the digits of the telephone number in binary coded decimal (BCD) format. In the calling party number case, the NPI's byte also contains bit fields which represent the caller's presentation preferences and the status of any call screening checks performed up until this point in the call. H G F E D C B A H G F E D C B A +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | NoA | | | NoA | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | NPI | spare | | | NPI |PrI|ScI| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | dig...| dig 1 | | dig...| dig 1 | | ... | | ... | | dig n | dig...| | dig n | dig...| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ISUP format ISUP calling format ISUP numbering formats The NPI field is generally set to the value 'ISDN (Telephony) numbering plan (Recommendation E.164)', but this does not mean that the digits which follow necessarily contain a country code; the NoA field dictates whether the telephone number is in a national or international format. When the represented number is not designated to be in an international format, the NoA generally provides information specific to the national dialing plan - based on this Camarillo, et al. Expires December 30, 2002 [Page 51] Internet-Draft ISUP to SIP Mapping July 2002 information one can usually determine how to convert the number in question into an international format. Note that if the NPI contains a value other than 'ISDN numbering plan', then the tel URL may not be suitable for carrying the address digits, and the handling for such calls is outside the scope of this document. Based on the above, conversion from ISUP format to a tel URL is as follows. First, provided that the NPI field indicates that the telephone number format uses E.164, the NoA should be consulted. If the NoA indicates that the number is an international number, then the telephone number digits should be appended unmodified to a 'tel:+' string. If the NoA has the value 'national (significant) number', then a country code must be prefixed to the telephone number digits before they are committed to a tel URL; if the gateway performing this conversion interconnects with switches homed to several different country codes, presumably the appropriate country code should be chosen based on the originating switch. If the NoA has the value 'subscriber number', both a country code and any other numbering components necessary for the numbering plan in question (such as area codes or city codes) may need to be added in order for the number to be internationally significant - however, such procedures vary greatly from country to country, and hence they cannot be specified in detail here. Only if a country or network- specific value is used for the NoA should a tel URL not include a '+' sign; in these cases, gateways should simply copy the provided digits into the tel URL and append a 'user=phone' parameter if a SIP URI format is used. Any non-standard or proprietary mechanisms used to communicate further context for the call in ISUP are outside the scope of this document. If a nationally-specific parameter is present that allows for the transmission of the calling party's name (such as the Generic Name Parameter in ANSI), then generally, if presentation is not restricted, this information should be used to populate the display- name portion of the From field. If ISUP calling format is used rather than ISUP format, then two additional pieces of information must be taken into account: presentation indicators and screening indicators. If the presentation indicators are set to 'presentation restricted', then a special URI should be created by the gateway which communicates to the far end that the caller's identity has been elided. This URI should be a SIP URI with the hostname of the gateway but with a display name of 'Anonymous' username of 'restricted', e.g.: From: Anonymous As further general-purpose privacy mechanisms are developed for the Camarillo, et al. Expires December 30, 2002 [Page 52] Internet-Draft ISUP to SIP Mapping July 2002 SIP protocol, they may also be used to protect the identity of a caller. If presentation is set to 'address unavailable', then gateways should treat the IAM as if the CIN parameter was omitted. Screening indicators should not be translated, as they are only meaningful end- to-end. Conversion from tel URLs to ISUP format is simpler. If the URI is in international format, then the gateway should consult the leading country code of the URI. If the country code is local to the gateway (the gateway has one or more trunks that point to switches which are homed to the country code in question), the gateway should set the NoA to reflect 'national (significant) number' and strip the country code from the URI before populating the digits field. If the country code is not local to the gateway, the gateway should set the NoA to 'international number' and retain the country code. In either case the NPI should be set to 'ISDN numbering plan'. If the URI is not in international format, the gateway should attempt to treat the telephone number within the URI as if it were appropriate to its national or network-specific dialing plan; if doing so gives rise to internal gateway errors, then this condition is most likely best handled with appropriate SIP status codes (e.g. 484). When converting from a tel URL to ISUP calling format, the procedure is identical to that described in the preceding paragraphs, but additionally, the presentation indicator should be set to 'presentation allowed' and the screening indicator to 'network provided', unless some service provider policy or user profile specifically disallows presentation. Camarillo, et al. Expires December 30, 2002 [Page 53] Internet-Draft ISUP to SIP Mapping July 2002 12. Other ISUP flavors Other flavors of ISUP different than Q.767 [8] have more parameters and more features. Some of the parameters have more possible values and provide more information about the status of the call. The Circuit Query Message (CQM) and Circuit Query Response (CQR) are used in many ISUP variants. These messages have no analog in SIP, although receipt of a CQR may cause state reconciliation if the originating and destination switches have become desynchronized; as states are reconciled some calls may be dropped, which may cause SIP or ISUP messages to be sent. However, differences in the message flows are more important. In ANSI [9] ISUP, there is no CON message; an ANM is sent instead (with no ACM). In call forwarding situations, CPGs can be sent before the ACM is sent. SAMs are never used; `en bloc' signaling is always used. The ANSI Exit Message (EXM) should not result in any SIP signaling in gateways. ANSI also uses the Circuit Reservation Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of its interworking procedures - in the event that an MGC does receive a CRM, a CRA should be sent in return (in some implementations, transmissions of a CRA could conceivably be based on a resource reservation system); after a CRA is sent, the MGC should wait for a subsequent IAM and process it normally. Any further circuit reservation mechanism is outside the scope of this document. Although receipt of a Confusion (CFN) message is an indication of a protocol error, no SIP message should be sent on receipt of a CFN - the CFN should be handled internally by the gateway (usually by retransmission of the packet to which the CFN responded). Only if this fails repeatedly should this cause a SIP error condition to arise. In TTC ISUP CPGs can be sent before the ACM is sent. Messages such as CHG can be sent between ACM and ANM. `En bloc' signaling is always used and there is no T9 timer. 12.1 Guidelines to send other ISUP messages Some ISUP flavors send more messages than the ones described in this document. It is good to follow some guidelines to transport these ISUP messages inside SIP bodies. From the caller to the callee ISUP messages should be encapsulated (see [2]) inside INFO messages, even if the INVITE transaction is still not finished. Note that SIP does not ensure that INFO requests are delivered in order. Therefore, an egress gateway might process Camarillo, et al. Expires December 30, 2002 [Page 54] Internet-Draft ISUP to SIP Mapping July 2002 first an INFO request that was sent after another INFO request. This issue, however, does not represent an important problem since it is not likely to happen and its effects are negligible in most of the situations. The Information (INF) message and Information Response (INR) are examples of messages that should be encapsulated within an INFO. Gateway implementors might also consider building systems that wait for each INFO transaction to complete before initiating a new INFO transaction. From the callee to the caller, if an INR is received by a gateway before the call has been answered (i.e. ANM is received) it should be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it must be encapsulated in a provisional 1xx response). Similarly an INF is received on the originating side (probably in response to an INR) before a 200 has been received should be carried within an INFO. In order for this mechanism to function properly in the forward direction, any necessary Contact or To-tag must have appeared in a previous provisional response or the message might not be correctly routed to its destination. As such all SIP-T gateways should send provisional responses with a Contact header and any necessary tags in order to enable proper routing of new requests issued before a final response has been received. When the INVITE transaction is finished INFO requests should be used also in this direction. Camarillo, et al. Expires December 30, 2002 [Page 55] Internet-Draft ISUP to SIP Mapping July 2002 13. Acronyms ACK Acknowledgment ACM Address Complete Message ANM Answer Message ANSI American National Standards Institute BLA Blocking ACK message BLO Blocking Message CGB Circuit Group Blocking Message CGBA Circuit Group Blocking ACK Message CHG Charging Information Message CON Connect Message CPG Call Progress Message CUG Closed User Group GRA Circuit Group Reset ACK Message GRS Circuit Group Reset Message HLR Home Location Register IAM Initial Address Message IETF Internet Engineering Task Force IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part ITU-T International Telecommunication Union Telecommunication Standardization Sector MG Media Gateway MGC Media Gateway Controller MTP Message Transfer Part REL Release Message RES Resume Message RLC Release Complete Message RTP Real-time Transport Protocol SCCP Signaling Connection Control Part SG Signaling Gateway SIP Session Initiation Protocol SS7 Signaling System No. 7 SUS Suspend Message TTC Telecommunication Technology Committee UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol VoIP Voice over IP Camarillo, et al. Expires December 30, 2002 [Page 56] Internet-Draft ISUP to SIP Mapping July 2002 14. Security Considerations The transit of encapsulated ISUP within SIP bodies may provide may opportunities for abuse and fraud. In particular, SIP users may be able to interpret "private" (i.e. caller-id-blocked) numbers by examining the ISUP. Similarly, if care is not taken, SIP clients would be able to send ISUP messages into the SS7 network with invalid calling line identification and spoofed billing numbers. For these reasons, it is absolutely necessary that any ISUP sent through an IP network be strongly encrypted and authenticated. The keys used for encryption should not be static, to prevent replay attacks. A challenge-response model is recommended. As an extra layer of security, it is recommended that ISUP be sent and received only to and from nodes that are known to have an established trust relationship with the gateway. Camarillo, et al. Expires December 30, 2002 [Page 57] Internet-Draft ISUP to SIP Mapping July 2002 15. IANA Considerations This document introduces no new considerations for IANA. Camarillo, et al. Expires December 30, 2002 [Page 58] Internet-Draft ISUP to SIP Mapping July 2002 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [2] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [6] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of Number Portability and Freephone Service", draft-yu-tel-url-04 (work in progress), November 2001. [7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. Camarillo, et al. Expires December 30, 2002 [Page 59] Internet-Draft ISUP to SIP Mapping July 2002 Non-normative References [8] International Telecommunications Union, "Application of the ISDN user part of CCITT Signaling System No. 7 for international ISDN interconnection", ITU-T Q.767, February 1991, . [9] American National Standards Institute, "Signaling System No. 7; ISDN User Part", ANSI T1.113, January 1995, . [10] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 1999, . [11] International Telecommunications Union, "Abnormal conditions - Special release", ITU-T Q.118, September 1997, . [12] International Telecommunications Union, "Specifications of Signaling System No. 7 - ISDN supplementary services", ITU-T Q.737, June 1997, . [13] International Telecommunications Union, "Usage of cause location in the Digital Subscriber Signaling System No. 1 and the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998, . [14] International Telecommunications Union, "The international public telecommunications numbering plan", ITU-T E.164, May 1997, . [15] International Telecommunications Union, "Formats and codes of the ISDN User Part of Signaling System No. 7", ITU-T Q.763, December 1999, . [16] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", draft-ietf-sip-100rel-06 (work in progress), February 2002. [17] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, October 2000. [18] Rosenberg, J., "The SIP UPDATE Method", draft-ietf-sip-update- 02 (work in progress), March 2002. Camarillo, et al. Expires December 30, 2002 [Page 60] Internet-Draft ISUP to SIP Mapping July 2002 Authors' Addresses Gonzalo Camarillo Ericsson Advanced Signalling Research Center FIN-02420 Jorvas Finland Phone: +358 9 299 3371 EMail: Gonzalo.Camarillo@Ericsson.com URI: http://www.ericsson.com/ Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA EMail: adam@dynamicsoft.com URI: sip:adam@dynamicsoft.com Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA EMail: lyOng@ciena.com URI: http://www.ciena.com/ Camarillo, et al. Expires December 30, 2002 [Page 61] Internet-Draft ISUP to SIP Mapping July 2002 Appendix A. Acknowledgments The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du and John Elwell for their help and feedback on this document. Camarillo, et al. Expires December 30, 2002 [Page 62] Internet-Draft ISUP to SIP Mapping July 2002 Appendix B. Revision History Changes from draft-ietf-sip-isup-00: - Merged draft-jfp-sip-isup-header-00 into this draft - Removed overlap signaling component (now draft-ietf-sip-overlap- 00) - Adjusted cause code to status code mappings Changes from draft-ietf-sip-isup-01: - Added procedures for placing calls on hold - Generalized language and procedures for LNP, removing ANSI bias - Fixed usage of 'user=phone' - Added handling for Segmentation Message in ISUP - Updated SUS/RES handling to use INFO consistently (rather than 183) Changes from draft-ietf-sip-isup-02: - Fixed some more ANSI-specific references (GNI, screening) - Fixed timer expiry cause code values (6.2.2) - Removed some bis04 incompatibilities (6.2.10) - Added motivational text to abstract and introduction Changes from draft-ietf-sip-isup-03: - Added provision for SUS/RES over INFO method - Fixed ANSI CRM/CRA behavior - Corrected a few status code conflicts - Righted many nits (thanks Igor!) Changes from draft-ietf-sipping-isup-00: - Removed PRACK from call flows Camarillo, et al. Expires December 30, 2002 [Page 63] Internet-Draft ISUP to SIP Mapping July 2002 - Some updating to bring language in parity with bis - Various nits Changes from draft-ietf-sipping-isup-01: - Minor editorial corrections. - Updated references from RFC 2543 to RFC 3261. - Split normative and non-normative references. Changes from draft-ietf-sipping-isup-02: - Strengthened language about overwriting parameters. - Improved text on interworking indicators in FCI/BCI - Various nits Camarillo, et al. Expires December 30, 2002 [Page 64] Internet-Draft ISUP to SIP Mapping July 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo, et al. Expires December 30, 2002 [Page 65]