idnits 2.17.1 draft-ietf-sipping-isup-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1671 has weird spacing: '...any 3xx respo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8098 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '14' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2833 (ref. '6') (Obsoleted by RFC 4733, RFC 4734) ** Obsolete normative reference: RFC 2976 (ref. '9') (Obsoleted by RFC 6086) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2960 (ref. '13') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-08) exists of draft-yu-tel-url-03 -- Possible downref: Normative reference to a draft: ref. '15' ** Obsolete normative reference: RFC 2806 (ref. '16') (Obsoleted by RFC 3966) -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' ** Obsolete normative reference: RFC 2633 (ref. '19') (Obsoleted by RFC 3851) -- Possible downref: Normative reference to a draft: ref. '20' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: August 2, 2002 A. Roach 5 dynamicsoft 6 J. Peterson 7 NeuStar 8 L. Ong 9 Ciena 10 February 2002 12 ISUP to SIP Mapping 13 draft-ietf-sipping-isup-01 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 2, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 This document describes a way to perform the mapping between two 45 signaling protocols: the Session Initiation Protocol (SIP) and the 46 ISDN User Part (ISUP) of SS7. This mechanism might be implemented 47 when using SIP in an environment where part of the call involves 48 interworking with the Public Switched Telephone Network (PSTN). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4. SIP Mechanisms Required . . . . . . . . . . . . . . . . . 9 56 4.1 'Transparent' Transit of ISUP Messages . . . . . . . . . . 9 57 4.2 Understanding MIME Multipart Bodies . . . . . . . . . . . 9 58 4.3 Transmission of DTMF Information . . . . . . . . . . . . . 9 59 4.4 Reliable Transmission of Provisional Responses . . . . . . 9 60 4.5 Provisional Media Streams . . . . . . . . . . . . . . . . 10 61 4.6 Mid-Call Transactions which do not change SIP state . . . 10 62 5. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6. SIP to ISUP Mapping . . . . . . . . . . . . . . . . . . . 12 64 6.1 Call flows . . . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1.1 En-bloc Call Setup (no auto-answer) . . . . . . . . . . . 12 66 6.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 13 67 6.1.3 ISUP T7 Expires . . . . . . . . . . . . . . . . . . . . . 14 68 6.1.4 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 15 69 6.1.5 ISUP Setup Failure . . . . . . . . . . . . . . . . . . . . 16 70 6.1.6 Cause Present in ACM Message . . . . . . . . . . . . . . . 17 71 6.1.7 Call Canceled by SIP . . . . . . . . . . . . . . . . . . . 18 72 6.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 19 73 6.2.1 INVITE received . . . . . . . . . . . . . . . . . . . . . 20 74 6.2.1.1 INVITE to IAM procedures . . . . . . . . . . . . . . . . . 20 75 6.2.2 ISUP T7 expires . . . . . . . . . . . . . . . . . . . . . 22 76 6.2.3 CANCEL or BYE received . . . . . . . . . . . . . . . . . . 23 77 6.2.4 REL received . . . . . . . . . . . . . . . . . . . . . . . 23 78 6.2.4.1 ISDN Cause Code to Status Code Mapping . . . . . . . . . . 23 79 6.2.5 Early ACM received . . . . . . . . . . . . . . . . . . . . 26 80 6.2.6 ACM received . . . . . . . . . . . . . . . . . . . . . . . 27 81 6.2.7 CON or ANM Received . . . . . . . . . . . . . . . . . . . 27 82 6.2.8 Timer T9 Expires . . . . . . . . . . . . . . . . . . . . . 27 83 6.2.9 CPG Received . . . . . . . . . . . . . . . . . . . . . . . 28 84 6.3 ACK received . . . . . . . . . . . . . . . . . . . . . . . 28 85 7. ISUP to SIP Mapping . . . . . . . . . . . . . . . . . . . 29 86 7.1 Call Flows . . . . . . . . . . . . . . . . . . . . . . . . 29 87 7.1.1 En-bloc call setup (non auto-answer) . . . . . . . . . . . 29 88 7.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 30 89 7.1.3 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 31 90 7.1.4 ISUP T9 Expires . . . . . . . . . . . . . . . . . . . . . 32 91 7.1.5 SIP Error Response . . . . . . . . . . . . . . . . . . . . 33 92 7.1.6 SIP Redirection . . . . . . . . . . . . . . . . . . . . . 34 93 7.1.7 Call Canceled by ISUP . . . . . . . . . . . . . . . . . . 35 94 7.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 36 95 7.2.1 Initial Address Message received . . . . . . . . . . . . . 37 96 7.2.1.1 IAM to INVITE procedures . . . . . . . . . . . . . . . . . 37 97 7.2.2 100 received . . . . . . . . . . . . . . . . . . . . . . . 39 98 7.2.3 18x received . . . . . . . . . . . . . . . . . . . . . . . 39 99 7.2.4 2xx received . . . . . . . . . . . . . . . . . . . . . . . 40 100 7.2.5 3xx Received . . . . . . . . . . . . . . . . . . . . . . . 41 101 7.2.6 4xx-6xx Received . . . . . . . . . . . . . . . . . . . . . 41 102 7.2.6.1 SIP Status Code to ISDN Cause Code Mapping . . . . . . . . 41 103 7.2.7 REL Received . . . . . . . . . . . . . . . . . . . . . . . 43 104 7.2.8 ISUP T11 Expires . . . . . . . . . . . . . . . . . . . . . 43 105 8. Suspend/Resume and Hold . . . . . . . . . . . . . . . . . 45 106 8.1 SUS and RES . . . . . . . . . . . . . . . . . . . . . . . 45 107 8.2 Hold (re-INVITE) . . . . . . . . . . . . . . . . . . . . . 46 108 9. Normal Release of the Connection . . . . . . . . . . . . . 47 109 9.1 SIP initiated . . . . . . . . . . . . . . . . . . . . . . 47 110 9.2 ISUP initiated . . . . . . . . . . . . . . . . . . . . . . 47 111 9.2.1 Caller hangs up . . . . . . . . . . . . . . . . . . . . . 47 112 9.2.2 Callee hangs up . . . . . . . . . . . . . . . . . . . . . 48 113 10. ISUP Maintenance Messages . . . . . . . . . . . . . . . . 49 114 10.1 Reset messages . . . . . . . . . . . . . . . . . . . . . . 49 115 10.2 Blocking messages . . . . . . . . . . . . . . . . . . . . 49 116 10.3 Continuity Checks . . . . . . . . . . . . . . . . . . . . 49 117 11. Construction of Telephony URIs . . . . . . . . . . . . . . 51 118 12. Other ISUP flavors . . . . . . . . . . . . . . . . . . . . 55 119 12.1 Guidelines to send other ISUP messages . . . . . . . . . . 55 120 13. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 57 121 14. Security Considerations . . . . . . . . . . . . . . . . . 58 122 15. IANA Considerations . . . . . . . . . . . . . . . . . . . 59 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 61 124 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 63 125 References . . . . . . . . . . . . . . . . . . . . . . . . 60 126 B. Revision History . . . . . . . . . . . . . . . . . . . . . 64 127 Full Copyright Statement . . . . . . . . . . . . . . . . . 66 129 1. Introduction 131 SIP [1] is an application layer protocol for establishing, 132 terminating and modifying multimedia sessions. It is typically 133 carried over IP. Telephone calls are considered a type of multimedia 134 sessions where just audio is exchanged. 136 ISUP [10] is a level 4 protocol used in SS7 networks. It typically 137 runs over MTP although it can also run over IP (see SCTP [13]). ISUP 138 is used for controlling telephone calls and for maintenance of the 139 network (blocking circuits, resetting circuits etc.). 141 A module performing the mapping between these two protocols is 142 usually referred to as Media Gateway Controller (MGC), although the 143 terms 'softswitch' or 'call agent' are also sometimes used. An MGC 144 has logical interfaces facing both networks, the network carrying 145 ISUP and the network carrying SIP. The MGC also has some 146 capabilities for controlling the voice path; there is typically a 147 Media Gateway (MG) with E1/T1 trunking interfaces (voice from PSTN) 148 and with IP interfaces (VoIP). The MGC and the MG can be merged 149 together in one physical box or kept separate. 151 These MGCs are frequently used to bridge SIP and ISUP networks so 152 that calls originating in the PSTN can reach IP telephone endpoints 153 and vice versa. This is useful for cases in which PSTN calls need to 154 take advantage of services in IP world, in which IP networks are used 155 as transit networks for PSTN-PSTN calls, architectures in which calls 156 originate on desktop 'softphones' but terminate at PSTN terminals, 157 and many other similar next-generation telephone architectures. 159 This document describes logic and procedures which an MGC might use 160 to implement the mapping between SIP and ISUP by illustrating the 161 correspondences, at the message level and parameter level, between 162 the protocols. It also describes the interplay between parallel 163 state machines for these two protocols as a recommendation for 164 implementers to synchronize protocol events in interworking 165 architectures. 167 2. Scope 169 This document focuses on the translation of ISUP messages into SIP 170 messages, and the mapping of ISUP parameters into SIP headers. The 171 purpose of translation in ISUP-SIP interworking is twofold: for ISUP 172 calls that traverse a SIP network, translation allows SIP elements 173 such as proxy servers to make routing decisions based on ISUP 174 criteria such as the called party number; translation also provides 175 critical information about the call to SIP endpoints that cannot 176 understand encapsulated ISUP (or perhaps which merely cannot 177 understand the particular ISUP variant in use). 179 This document only takes into account the call functionality of ISUP. 180 Maintenance messages dealing with PSTN trunks are treated only as far 181 as they affect the control of an ongoing call; otherwise these 182 message neither have nor require any analog in SIP. 184 Messages indicating error or congestion situations in the PSTN (MTP- 185 3) and the recovery mechanisms used such as User Part Available and 186 User Part Test ISUP messages are outside the scope of this document 188 There are several flavors of ISUP. ITU-T Q.767 International ISUP 189 [2] is used through this document; some differences with ANSI [3] 190 ISUP and TTC ISUP are outlined. ISUP Q.767 is used in this document 191 because it is the least complex of all the ISUP flavors. Due to the 192 small number of fields that map directly from ISUP to SIP, the 193 signaling differences between Q.767 and specific national variants of 194 ISUP will generally have little to no impact on the mapping. Note, 195 however, that the ITU-T has not substantially standardized practices 196 for Local Number Portability since portability tends to be grounded 197 in national numbering plan practices, and that consequently LNP must 198 be described on a virtually per-nation basis. 200 Mapping of SIP headers to ISUP parameters in this document focuses 201 largely on the mapping between the parameters found in the ISUP 202 Initial Address Message (IAM) and the headers associated with the SIP 203 INVITE message; both of these messages are used in their respective 204 protocols to request the establishment of a call. Once an INVITE has 205 been sent for a particular session, such headers as the To and From 206 field become essentially fixed, and no further translation will be 207 required during subsequent signaling, which is routed in accordance 208 with Via and Route headers. Hence, the problem of parameter-to- 209 header mapping in SIP-T is confined more or less to the IAM and the 210 INVITE. Some additional detail is given in the population of 211 parameters in the ISUP ACM and REL messages based on SIP status 212 codes. 214 This document describes when the media path associated with a SIP 215 call is to be initialized, terminated, modified, etc., but it does 216 not go into details such as how the initialization is performed or 217 which protocols are used for that purpose. 219 3. Scenarios 221 There are several scenarios where ISUP-SIP mapping takes place. The 222 way the messages are generated is different depending on the 223 scenario. 225 When there is a single MGC and the call is from a SIP phone to a PSTN 226 phone, or vice versa, the MGC generates the ISUP messages based on 227 the methods described in this document. 229 +-------------+ +-----+ +-------------+ 230 | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | 231 +-------------+ +-----+ +-------------+ 233 The scenario where a call originates in the PSTN, goes into a SIP 234 network and terminates in the PSTN again is known as "SIP bridging". 235 SIP bridging should provide ISUP transparency between the PSTN 236 switches handling the call. This is achieved by encapsulating the 237 incoming ISUP messages in the body of the SIP messages (see [4]). In 238 this case, the ISUP messages generated by the egress MGC are the ones 239 present in the SIP body (possibly with some modifications; for 240 example, if the called number in the request URI is different from 241 the one present in the ISUP due to SIP redirection, the ISUP message 242 will need to be adjusted). 244 +------+ +-------------+ +-----+ +------------+ +------+ 245 | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 246 +------+ +-------------+ +-----+ +------------+ +------+ 248 SIP is used in the middle of both MGCs because the voice path has to 249 be established through the IP network between both MGs; this 250 structure also allows the call to take advantage of certain SIP 251 services. ISUP messages in the SIP bodies provide further 252 information (such as cause values and optional parameters) to the 253 peer MGC. 255 In both scenarios, the ingress MGC places the incoming ISUP messages 256 in the SIP body by default. Note that this has security 257 implications; see Section 14. If the recipient of these messages 258 (typically a SIP UAC/UAS) does not understand them a negotiation 259 using the SIP `Accept' and `Require' headers will take place and they 260 will not be included in the next SIP message exchange. 262 There can be a Signaling Gateway (SG) between the PSTN and the MGC. 263 It encapsulates the ISUP messages over IP in a manner such as the one 264 described in [13]. The mapping described in this document is not 265 affected by the underlying transport protocol of ISUP. 267 Note that overlap dialing mechanisms (use of the Subsequent Address 268 Message, SAM) are outside the scope of this document. This document 269 assumes that gateways facing ISUP networks in which overlap dialing 270 is used will implement timers to insure that all digits have been 271 collected before an INVITE is transmitted to a SIP network. 273 In some instances, gateways may receive incomplete ISUP messages 274 which indicate message segmentation due to excessive message length. 275 Commonly these messages will be followed by a Segmentation Message 276 (SGM) containing the remainder of the original ISUP message. An 277 incomplete message may not contain sufficient parameters to allow for 278 a proper mapping to SIP; similarly, encapsulating (see below) an 279 incomplete ISUP message may be confusing to terminating gateways. 280 Consequently, a gateway must wait until a complete ISUP message is 281 received (which may involve waiting until one or more SGMs arrive) 282 before sending any corresponding INVITE. 284 4. SIP Mechanisms Required 286 For a correct mapping between ISUP and SIP, some SIP mechanisms above 287 and beyond those available in the base SIP specification are needed. 288 These mechanisms are discussed below. If the SIP UAC/UAS involved in 289 the call does not support them, it is still possible to proceed, but 290 the behavior in the establishment of the call may be slightly 291 different than that expected by the user (e.g. other party answers 292 before receiving the ringback tone, user is not informed about the 293 call being forwarded, etc.). 295 4.1 'Transparent' Transit of ISUP Messages 297 To provide users the ability to take advantage of the full range of 298 services afforded by the existing telephone network when placing 299 calls from PSTN to PSTN across a SIP network, SIP messages will need 300 to carry ISUP payloads from gateway to gateway. The format for 301 carrying these messages is defined in [4]. 303 SIP clients and servers which do not understand ISUP are permitted to 304 ignore these (and other) optional MIME bodies. 306 4.2 Understanding MIME Multipart Bodies 308 In most PSTN interworking situations, the SIP body will be required 309 to carry session information (SDP) in addition to ISUP and/or billing 310 information. 312 PSTN interworking nodes should understand the MIME type of 313 "multipart/mixed" as defined in RFC2046 [5]. Clients express support 314 for this by including "multipart/mixed" in an "Accept" header. 316 4.3 Transmission of DTMF Information 318 Since the codec selected for voice transmission may not be ideally 319 suited for carrying DTMF information, a symbolic method of 320 transmitting this information in-band is desirable (since out-of-band 321 transmission alone would provide many challenges for synchronization 322 of the media stream for tone re-insertion). This transmission should 323 be performed as described in RFC2833 [6] and is in all respects 324 orthogonal to the mapping of ISUP and SIP. 326 4.4 Reliable Transmission of Provisional Responses 328 Provisional responses are used in the transmission of call progress 329 information. PSTN interworking in particular relies on these 330 messages for control of the media channel and timing of messages. 332 PSTN interworking should occur over a reliable transport layer end- 333 to-end. One application-layer provisional reliability mechanism is 334 described in [7]. 336 4.5 Provisional Media Streams 338 To allow the transmission of messages and tones before a final 339 connection has been established, SIP nodes which interwork with the 340 PSTN need to be able to establish temporary media connections during 341 this period. 343 MGCs should support the establishment of temporary provisional media 344 streams using the 183 status code (described in [8]). A more 345 detailed analysis of the problem of early media is given in [20]. 347 4.6 Mid-Call Transactions which do not change SIP state 349 When interworking with PSTN, there are situations when PSTN nodes 350 will need to send messages which do not correspond to any SIP 351 operations to each other across a SIP network. 353 The method for performing this transit will be in the INFO method, 354 defined in RFC2976 [9]. 356 Nodes which do serve as PSTN interworking points should accept "405 357 Method Not Allowed" and "501 Not Implemented" responses to INFO 358 requests as non-fatal. 360 5. Mapping 362 The mapping between ISUP and SIP is described using call flow 363 diagrams and state machines. One state machine handles calls from 364 SIP to ISUP and the second from ISUP to SIP. There are details, such 365 as some retransmissions and some states (waiting for RLC, waiting for 366 ACK etc.), that are not shown in the figures in order to make them 367 easier to follow. 369 The boxes represent the different states of the gateway, and the 370 arrows show changes in the state. The event that triggers the change 371 in the state and the actions to take appear on the arrow: event / 372 section describing the actions to take. 374 For example, `INVITE / 6.2.1' indicates that an INVITE request has 375 been received by the gateway, and the procedure upon reception is 376 described in the section 6.2.1 of this document. 378 6. SIP to ISUP Mapping 380 6.1 Call flows 382 The following call flows illustrate the order of messages in typical 383 success and error cases when setting up a call initiated from the SIP 384 network. "100 Trying" acknowledgements to INVITE requests are not 385 displayed below although they are required in many architectures. 387 In these diagrams, all call signaling (SIP, ISUP) is going to and 388 from the MGC; media handling (e.g. audio cut-through, trunk freeing) 389 is being performed by the MG, under the control of the MGC. For the 390 purpose of simplicity, these are shown as a single node, labeled 391 "MGC/MG." 393 6.1.1 En-bloc Call Setup (no auto-answer) 395 SIP MGC/MG PSTN 396 1|---------INVITE---------->| | 397 |<----------100------------| | 398 | |------------IAM---------->|2 399 | |<=========Audio===========| 400 | |<-----------ACM-----------|3 401 4|<----------18x------------| | 402 |<=========Audio===========| | 403 | |<-----------CPG-----------|5 404 6|<----------18x------------| | 405 | |<-----------ANM-----------|7 406 | |<=========Audio==========>| 407 8|<----------200------------| | 408 |<=========Audio==========>| | 409 9|-----------ACK----------->| | 411 1. When a SIP user wishes to begin a session with a PSTN user, the 412 SIP node issues an INVITE request. 414 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 415 message and sends it to the ISUP network. 417 3. The remote ISUP node indicates that the address is sufficient to 418 set up a call by sending back an ACM message. 420 4. The "called party status" code in the ACM message is mapped to a 421 SIP provisional response (as described in Section 6.2.5 and 422 Section 6.2.6). and returned to the SIP node. This response may 423 contain SDP to establish an early media stream (as shown in the 424 diagram). If no SDP is present, the audio will be established in 425 both directions after step 12. 427 5. If the ISUP variant permits, the remote ISUP node may issue a 428 variety of CPG messages to indicate, for example, that the call 429 is being forwarded. 431 6. Upon receipt of a CPG message, the gateway will map the event 432 code to a SIP provisional response (see Section 6.2.9) and send 433 it to the SIP node. 435 7. Once the PSTN user answers, an ANM message will be sent to the 436 gateway. 438 8. Upon receipt of the ANM, the gateway will send a 200 message to 439 the SIP node. 441 9. The SIP node, upon receiving an INVITE final response (200), will 442 send an ACK to acknowledge receipt. 444 6.1.2 Auto-answer call setup 446 SIP MGC/MG PSTN 447 1|---------INVITE---------->| | 448 |<----------100------------| | 449 | |------------IAM---------->|2 450 | |<=========Audio===========| 451 | |<-----------CON-----------|3 452 | |<=========Audio==========>| 453 4|<----------200------------| | 454 |<=========Audio==========>| | 455 5|-----------ACK----------->| | 457 Note that this flow is not supported in ANSI networks. 459 1. When a SIP user wishes to begin a session with a PSTN user, the 460 SIP node issues an INVITE request. 462 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 463 message and sends it to the ISUP network. 465 3. Since the remote node is configured for automatic answering, it 466 will send a CON message upon receipt of the IAM. (For ANSI, this 467 message will be an ANM). 469 4. Upon receipt of the CON, the gateway will send a 200 message to 470 the SIP node. 472 5. The SIP node, upon receiving an INVITE final response (200), will 473 send an ACK to acknowledge receipt. 475 6.1.3 ISUP T7 Expires 477 SIP MGC/MG PSTN 478 1|---------INVITE---------->| | 479 |<----------100------------| | 480 | |------------IAM---------->|2 481 | |<=========Audio===========| 482 | | *** T7 Expires *** | 483 | ** MG Releases PSTN Trunk ** | 484 4|<----------504------------|------------REL---------->|3 485 5|-----------ACK----------->| | 487 1. When a SIP user wishes to begin a session with a PSTN user, the 488 SIP node issues an INVITE request. 490 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 491 message and sends it to the ISUP network. The ISUP timer T7 is 492 started at this point. 494 3. The ISUP timer T7 expires before receipt of an ACM or CON 495 message, so a REL message is sent to cancel the call. 497 4. A gateway timeout message is sent back to the SIP node. 499 5. The SIP node, upon receiving an INVITE final response (504), will 500 send an ACK to acknowledge receipt. 502 6.1.4 SIP Timeout 504 SIP MGC/MG PSTN 505 1|---------INVITE---------->| | 506 |<----------100------------| | 507 | |------------IAM---------->|2 508 | |<=========Audio===========| 509 | |<-----------CON-----------|3 510 | |<=========Audio==========>| 511 4|<----------200------------| | 512 | *** T1 Expires *** | | 513 |<----------200------------| | 514 | *** T1 Expires *** | | 515 |<----------200------------| | 516 | *** T1 Expires *** | | 517 |<----------200------------| | 518 | *** T1 Expires *** | | 519 |<----------200------------| | 520 | *** T1 Expires *** | | 521 |<----------200------------| | 522 | *** T1 Expires *** | | 523 5|<----------200------------| | 524 | *** T1 Expires *** | | 525 | ** MG Releases PSTN Trunk ** | 526 7|<----------BYE------------|------------REL---------->|6 527 | |<-----------RLC-----------|8 529 1. When a SIP user wishes to begin a session with a PSTN user, the 530 SIP node issues an INVITE request. 532 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 533 message and sends it to the ISUP network. 535 3. Since the remote node is configured for automatic answering, it 536 will send a CON message upon receipt of the IAM. In ANSI flows, 537 rather than a CON an ANM (without ACM) would be sent. 539 4. Upon receipt of the ANM, the gateway will send a 200 message to 540 the SIP node and set SIP timer T1. 542 5. The response is retransmitted every time the SIP timer T1 543 expires. 545 6. After seven retransmissions, the call is torn down by sending a 546 REL to the ISUP node, with a cause code of 102 (recover on timer 547 expiry). 549 7. A BYE is transmitted to the SIP node in an attempt to close the 550 call. Further handling for this clean up is not shown, since the 551 SIP node's state is not easily known in this scenario. 553 8. Upon receipt of the REL message, the remote ISUP node will reply 554 with an RLC message. 556 6.1.5 ISUP Setup Failure 558 SIP MGC/MG PSTN 559 1|---------INVITE---------->| | 560 |<----------100------------| | 561 | |------------IAM---------->|2 562 | |<-----------REL-----------|3 563 | |------------RLC---------->|4 564 5|<----------4xx+-----------| | 565 6|-----------ACK----------->| | 567 1. When a SIP user wishes to begin a session with a PSTN user, the 568 SIP node issues an INVITE request. 570 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 571 message and sends it to the ISUP network. 573 3. Since the remote ISUP node is unable to complete the call, it 574 will send a REL. 576 4. The gateway releases the circuit and confirms that it is 577 available for reuse by sending an RLC. 579 5. The gateway translates the cause code in the REL to a SIP error 580 response (see Section 6.2.4) and sends it to the SIP node. 582 6. The SIP node sends an ACK to acknowledge receipt of the INVITE 583 final response. 585 6.1.6 Cause Present in ACM Message 587 SIP MGC/MG PSTN 588 1|---------INVITE---------->| | 589 |<----------100------------| | 590 | |------------IAM---------->|2 591 | |<=========Audio===========| 592 | |<---ACM with cause code---|3 593 4|<------183 with SDP-------| | 594 |<=========Audio===========| | 595 ** Interwork timer expires ** 596 5|<----------4xx+-----------| | 597 | |------------REL---------->|6 598 | |<-----------RLC-----------|7 599 8|-----------ACK----------->| | 601 1. When a SIP user wishes to begin a session with a PSTN user, the 602 SIP node issues an INVITE request. 604 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 605 message and sends it to the ISUP network. 607 3. Since the ISUP node is unable to complete the call and wants to 608 generate the error tone/announcement itself, it sends an ACM with 609 a cause code. The gateway starts an interwork timer. 611 4. Upon receipt of an ACM with cause (presence of the CAI 612 parameter), the gateway will generate a 183 message towards the 613 SIP node; this contains SDP to establish early media cut-through. 615 5. A final INVITE response, based on the cause code received in the 616 earlier ACM message, is generated and sent to the SIP node to 617 terminate the call. See Section 6.2.4.1 for the table which 618 contains the mapping from cause code to SIP response. 620 6. Upon expiration of the interwork timer, a REL is sent towards the 621 PSTN node to terminate the call. Note that the SIP node can also 622 terminate the call by sending a CANCEL before the interwork timer 623 expires. In this case, the signaling progresses as in Section 624 6.1.7. 626 7. Upon receipt of the REL message, the remote ISUP node will reply 627 with an RLC message. 629 8. The SIP node sends an ACK to acknowledge receipt of the INVITE 630 final response. 632 6.1.7 Call Canceled by SIP 634 SIP MGC/MG PSTN 635 1|---------INVITE---------->| | 636 |<----------100------------| | 637 | |------------IAM---------->|2 638 | |<=========Audio===========| 639 | |<-----------ACM-----------|3 640 4|<----------18x------------| | 641 |<=========Audio===========| | 642 | ** MG Releases IP Resources ** | 643 5|----------CANCEL--------->| | 644 6|<----------200------------| | 645 | ** MG Releases PSTN Trunk ** | 646 | |------------REL---------->|7 647 8|<----------487------------| | 648 | |<-----------RLC-----------|9 649 10|-----------ACK----------->| | 651 1. When a SIP user wishes to begin a session with a PSTN user, the 652 SIP node issues an INVITE request. 654 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 655 message and sends it to the ISUP network. 657 3. The remote ISUP node indicates that the address is sufficient to 658 set up a call by sending back an ACM message. 660 4. The "called party status" code in the ACM message is mapped to a 661 SIP provisional response (as described in Section 6.2.5 and 662 Section 6.2.6) and returned to the SIP node. This response may 663 contain SDP to establish an early media stream. 665 5. To cancel the call before it is answered, the SIP node sends a 666 CANCEL request. 668 6. The CANCEL request is confirmed with a 200 response. 670 7. Upon receipt of the CANCEL request, the gateway sends a REL 671 message to terminate the ISUP call. 673 8. The gateway sends a "487 Call Cancelled" message to the SIP node 674 to complete the INVITE transaction. 676 9. Upon receipt of the REL message, the remote ISUP node will reply 677 with an RLC message. 679 10. Upon receipt of the 487, the SIP node will confirm reception 680 with an ACK. 682 6.2 State Machine 684 Note that REL can be received in any state; the handling is the same 685 for each case (see Section 9). 687 +---------+ 688 +----------------------->| Idle |<---------------------+ 689 | +----+----+ | 690 | | | 691 | | INVITE/6.2.1 | 692 | V | 693 | T7/6.2.2 +-------------------------+ REL/6.2.4 | 694 +<----------------+ Trying +------------>+ 695 | +-+--------+------+-------+ | 696 | CANCEL/6.2.3 | | | | | 697 +<----------------+ | E.ACM/ | ACM/ | CON/ | 698 | | 6.2.5 |6.2.6 | 6.2.7 | 699 | V | | | 700 | T9/6.2.8 +--------------+ | | | 701 +<----------+ Not alerting | | | | 702 | +-------+------+ | | | 703 | CANCEL/6.2.3 | | | | | 704 |<--------------+ | CPG/ | | | 705 | | 6.2.9 | | | 706 | V V | | 707 | T9/6.2.8 +---------------+ | REL/6.2.4 | 708 +<----------------+ Alerting |-|-------------------->| 709 |<----------------+--+-----+------+ | | 710 | CANCEL/6.2.3 | ^ | | | 711 | CPG/ | | | ANM/ | | 712 | 6.2.9 +--+ | 6.2.7 | | 713 | V V | 714 | +-------------------------+ REL/9.2 | 715 | | Waiting for ACK |------------>| 716 | +-------------+-----------+ | 717 | | | 718 | | ACK/6.2.10 | 719 | V | 720 | BYE/9.1 +-------------------------+ REL/9.2 | 721 +<----------------+ Connected +------------>+ 722 +-------------------------+ 724 6.2.1 INVITE received 726 When an INVITE request is received by the gateway, a "100 Trying" 727 response should be sent back to the SIP network indicating that the 728 MGC is handling the call. 730 The resources for the media stream have to be reserved at this stage, 731 since an IAM message cannot be sent before the resource reservation 732 takes place. Typically the resources consist of a time slot in an 733 E1/T1 and an RTP/UDP port on the IP side. Resources might also 734 include QoS or/and security provisions. Before sending the IAM the 735 MG generally connects the backward media path. 737 After sending the IAM the timer T7 is started. The default value of 738 T7 is between 20 and 30 seconds. The MGC goes to the `Trying' state. 740 6.2.1.1 INVITE to IAM procedures 742 This section details the mapping of the SIP headers in an INVITE 743 message to the ISUP parameters in an IAM. 745 Five mandatory parameters appear within the IAM message: the Called 746 Party Number (CPN), the Nature of Connection Indicator (NCI), the 747 Forward Call Indicators (FCI), the Calling Party's Category (CPC), 748 and finally a parameter that indicates the desired bearer 749 characteristics of the call - in some ISUP variants the Transmission 750 Medium Requirement (TMR) is required, in others the User Service 751 Information (USI) (or both). 753 There are quite a few optional parameters that can appear in an IAM 754 message; Q.763 [18] lists 29 in all. However, each of these 755 parameters need not to be translated in order to achieve the goals of 756 SIP-ISUP mapping. As is stated above, translation allows SIP network 757 elements to understand the PSTN context of the session if they are 758 not capable of deciphering any encapsulated ISUP. Parameters that 759 are only meaningful to the PSTN will be carried through PSTN-SIP- 760 PSTN networks via encapsulation - translation is not necessary for 761 these parameters. Of the aforementioned 29 optional parameters, only 762 the following are immediately useful for translation: the Calling 763 Party's Number (CIN, which is commonly present), Transit Network 764 Selection (TNS), Carrier Identification Parameter (CIP, present in 765 ANSI networks), Original Called Number (OCN), and the Generic Digits 766 (known in some variants as the Generic Address Parameter (GAP)). 768 When a SIP INVITE arrives at a PSTN gateway, the gateway should 769 attempt to make use of any encapsulated ISUP (see [4]) to assist in 770 the formulation of outbound PSTN signaling. However, three 771 conditions can complicate this process: 773 o There is no ISUP encapsulated in the SIP INVITE - the SIP INVITE 774 originated at a device other than an ISUP-SIP gateway. 776 o There is encapsulated ISUP, but the gateway cannot understand the 777 ISUP variant and therefore the ISUP must be discarded. 779 o There is encapsulated ISUP, but there is more recent session 780 context information available in the SIP headers, and consequently 781 the SIP headers must 'overwrite' the encapsulated ISUP. 783 In all of these cases translation must be performed. Gateways should 784 use default values for mandatory ISUP parameters that are not derived 785 from translation or encapsulation (such as the NCI or TMR 786 parameters). The FCI parameter should also have a default, although 787 its 'M' bit may be overwritten during the process of translation. 789 First, the Request-URI should be inspected. 791 If there is no 'npdi=yes' field within the Request-URI, then the main 792 telephone number in the tel URL (the digits immediately following 793 'tel:') should be converted to ISUP format, following the procedure 794 described in Section 11, and used to populate the CPN parameter. 796 In ANSI networks, if the 'npdi=yes' field exists in the Request-URI, 797 then the FCI parameter bit for 'number translated' within the IAM 798 should reflect that a number portability dip has been performed. 800 If in addition to the 'npdi=yes' field there is no 'rn=' field 801 present, then the main telephone number in the tel URL should be 802 converted to ISUP format (see Section 11) and used to populate the 803 CPN parameter. 805 If in addition to the 'npdi=yes' field an 'rn=' field is present, 806 then in ANSI networks the 'rn=' field should be converted to ISUP 807 format and used to populate the CPN. The main telephone number in 808 the tel URL should be converted to ISUP format and used to populate 809 the Generic Digits Parameter (or GAP in ANSI). In some networks the 810 number given in the 'rn=' field should be prepended to the main 811 telephone number and the combined result should be used to populate 812 the CPN. 814 If main telephone number in the Request-URI and that of the To header 815 are at variance, then the To header should be used to populate an OCN 816 parameter. Otherwise the To header should be ignored. 818 If the 'cic=' parameter is present in the Request-URI, the gateway 819 should consult local policy to make sure that it is appropriate to 820 transmit this Carrier Identification Code in the IAM. If the gateway 821 supports many independent trunks, it may need to choose a particular 822 trunk that points to the carrier identified by the CIC, or a tandem 823 through which that carrier is reachable. Policies for such trunks 824 (based on the preferences of the carriers with which the trunks are 825 associated) may dictate whether the CIP or TNS parameter should be 826 used (although note that in non-ANSI networks the CIP will never be 827 used). In the absence of any pre-arranged policies, the TNS should 828 be used when the CPN parameter is in an international format (i.e. 829 the NoA field of the CPN indicates that this is an international 830 number), and the CIP should be used in other cases. 832 If a SIP call has arrived at a gateway, then the Request-URI will 833 most likely contain a tel URL (or a SIP URI with a tel URL user 834 portion). However, if the call originated at a native IP endpoint 835 such as a SIP phone, the From field may not reflect any telephone 836 number - it may be a simple user@host construction. The CIN 837 parameter should be omitted from the outbound IAM if the From field 838 is unusable. 840 Note that when the ISUP parameters regarding interworking are set in 841 the Forward Call Indicators (FCI) parameter of the IAM , this 842 indicates that ISDN is interworking with a network which is not 843 capable of providing as many services as ISDN does. ISUP will 844 therefore not employ certain features it otherwise normally uses. 846 Thus, `interworking encountered' must not be specified so that ISUP 847 behaves normally. SIP is considered as an SS7 network and a SIP 848 phone is considered as ISDN access since the SIP network is supposed 849 to provide at least as many services as ISUP. 851 Claiming to be an ISDN node might make the callee request ISDN user 852 to user services. Since user to user services 1 and 2 must be 853 requested by the caller, they do not represent a problem (see [12]). 854 User to user service 3 can be requested by the callee also. In non- 855 SIP bridging situations, the MGC should be capable of rejecting this 856 service request. 858 6.2.2 ISUP T7 expires 860 Since no response was received from the PSTN all the resources in the 861 MG are released. A `504 gateway timeout' is sent back to the SIP 862 network. A REL message with cause value 102 (protocol error, 863 recovery on timer expiry) is sent to the PSTN. The PSTN responds 864 with RLC and the SIP network responds with an ACK indicating that the 865 release sequence has been completed. 867 6.2.3 CANCEL or BYE received 869 If a CANCEL or BYE request is received, a `200 OK' is sent to the SIP 870 network to confirm the CANCEL or BYE; a 487 is also sent to terminate 871 the INVITE transaction. All the resources are released and a REL 872 message is sent to the PSTN with cause value 16 (normal clearing). A 873 RLC from the PSTN is received indicating that the release sequence is 874 complete. 876 It is important that all the resources are released before the 877 gateway sends any REL message. 879 In SIP bridging situations, a REL might arrive in the CANCEL or BYE 880 request body. This REL is sent to the PSTN. 882 This applies when a CANCEL or a BYE is received before a final SIP 883 response has been sent. 885 6.2.4 REL received 887 This section applies every time that a REL is received before a final 888 SIP response has been sent. 890 The resources are released in the MG and a RLC is sent to the ISUP 891 network to indicate that the circuit is available for reuse. 893 If the INVITE originating this transaction contained an ISUP message 894 in its body (such as an IAM), the MGC is handling a SIP bridging 895 situation. Therefore, the REL message just received should be 896 included in the body of the response. 898 Note that the receipt of certain maintenance messages in response to 899 IAM such as BLO or RSC (or their circuit group message equivalents) 900 may also result in the teardown of calls in this phase of the state 901 machine. Behavior for maintenance messages is given below in Section 902 10. 904 6.2.4.1 ISDN Cause Code to Status Code Mapping 906 In addition to the ISDN Cause Code, the CAI parameter also contains a 907 cause 'location' that gives some sense of which entity in the network 908 was responsible for terminating the call (the most important 909 distinction being between the user and the network). In most cases, 910 the cause location does not affect the mapping to a SIP status code; 911 some exceptions are noted below. A diagnostic field may also be 912 present for some ISDN causes; this diagnostic will contain additional 913 data pertaining to the termination of the call. 915 The use of the REL message in the SS7 network is very general, 916 whereas SIP has a number of specific tools that, collectively, play 917 the same role as REL - namely BYE, CANCEL, and the status codes. An 918 REL can be sent to tear down a call that is already in progress 919 (BYE), to cancel a previously sent call setup request (IAM) that has 920 not yet been completed (CANCEL), or to reject a call setup request 921 (IAM) that has just been received (corresponding to a SIP status 922 code). 924 If a cause value other than what is listed below is received, the 925 default response `500 Server internal error' would be used. 927 Note that it is not necessarily appropriate to map some ISDN cause 928 codes to SIP messages because these cause codes are only meaningful 929 to the ISUP interface of a gateway. A good example of this is cause 930 code 44 "Request circuit or channel not available." 44 signifies that 931 the Circuit Identification Code (CIC) for which an IAM had been sent 932 was believed by the receiving equipment to be in a state incompatible 933 with a new call request - however, the appropriate behavior in this 934 case is for the originating switch to re-send the IAM for a different 935 CIC, not for the call to be torn down. Clearly, there is not (nor 936 should there be) an SIP status code indicating that a new CIC should 937 be selected - this matter is internal to the originating gateway. 938 Hence receipt of cause code 44 should not result in any SIP status 939 code being sent; effectively, the cause code is untranslatable. 941 Normal event 943 ISUP Cause value SIP response 944 ---------------- ------------ 945 1 unallocated number 404 Not Found 946 2 no route to network 404 Not found 947 3 no route to destination 404 Not found 948 16 normal call clearing --- (*) 949 17 user busy 486 Busy here 950 18 no user responding 408 Request Timeout 951 19 no answer from the user 480 Temporarily unavailable 952 20 subscriber absent 480 Temporarily unavailable 953 21 call rejected 403 Forbidden (+) 954 22 number changed (w/o diagnostic) 410 Gone 955 22 number changed (w/ diagnostic) 301 Moved Permanently 956 23 redirection to new destination 302 Moved Temporarily 957 26 non-selected user clearing 404 Not Found (=) 958 27 destination out of order 502 Bad Gateway 959 28 address incomplete 484 Address incomplete 960 29 facility rejected 501 Not implemented 961 31 normal unspecified 480 Temporarily unavailable 963 (*) ISDN Cause 16 will usually result in a BYE or CANCEL 965 (+) If the cause location is 'user' than the 6xx code could be given 966 rather than the 4xx code (i.e. 403 becomes 603) 968 (=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 969 'misrouted ported number'. Presumably, a number portability dip 970 should have been performed by a prior network. 972 A REL with ISDN cause 22 (number changed) might contain information 973 about a new number where the callee might be reachable in the 974 diagnostic field. If the MGC is able to parse this information it 975 might be added to the SIP response (301) in a Contact header. 977 Resource unavailable 979 This kind of cause value indicates a non permanent situation. A 980 `Retry-After' header may be added to the response. 982 ISUP Cause value SIP response 983 ---------------- ------------ 984 34 no circuit available 503 Service unavailable 985 38 network out of order 503 Service unavailable 986 41 temporary failure 503 Service unavailable 987 42 switching equipment congestion 503 Service unavailable 988 47 resource unavailable 503 Service unavailable 990 Service or option not available 992 This kind of cause value indicates a permanent situation. 994 ISUP Cause value SIP response 995 ---------------- ------------ 996 55 incoming calls barred within CUG 403 Forbidden 997 57 bearer capability not authorized 403 Forbidden 998 58 bearer capability not presently 503 Service unavailable 999 available 1001 Service or option not available 1003 ISUP Cause value SIP response 1004 ---------------- ------------ 1005 65 bearer capability not implemented 501 Not implemented 1006 79 service or option not implemented 501 Not implemented 1008 Invalid message 1009 ISUP Cause value SIP response 1010 ---------------- ------------ 1011 87 user not member of CUG 503 Service unavailable 1012 88 incompatible destination 503 Service unavailable 1013 95 invalid message 503 Service unavailable 1015 Protocol error 1017 ISUP Cause value SIP response 1018 ---------------- ------------ 1019 102 recovery of timer expiry 504 Gateway timeout 1020 111 protocol error 500 Server internal error 1022 Interworking 1024 ISUP Cause value SIP response 1025 ---------------- ------------ 1026 127 interworking unspecified 500 Server internal error 1028 6.2.5 Early ACM received 1030 This message is sent in certain situations for resetting the timers. 1031 In these cases this message indicates that the call is in progress 1032 but callee is not being alerted. This occurs for example in mobile 1033 networks, where roaming can take a long time. The early ACM is sent 1034 before the user is alerted to reset T7 and start T9. 1036 An ACM is considered an `early ACM' if the Called Party's Status 1037 Indicator is set to 00 (no indication). 1039 After receiving an early ACM the progress of the call is indicated by 1040 the network sending CPGs. 1042 When there is interworking with some old systems, it is possible to 1043 receive an ANM immediately after an early ACM (without CPG). In this 1044 situation the SIP user will not hear any kind of ringback tone before 1045 the callee answers. In ISDN (see [10]) this is solved by connecting 1046 the voice path backwards before sending the IAM. 1048 The MGC sends a 183 Session Progress (see [8]) to the SIP network 1049 with a media description inside. In SIP bridging situations the 1050 early ACM is included in the response body. Thus, the problem of 1051 missing the ring back tone is solved and the early ACM is transported 1052 transparently through the SIP network. 1054 6.2.6 ACM received 1056 Upon reception of an ACM timer T9 is started. T9 typically lasts 1057 between 90 seconds and 3 minutes (see [11]) . It allows the caller 1058 to hear announcements from the network for that period of time 1059 without being charged for the connection. If longer announcements 1060 have to be played the network has to send an ANM. When the ANM is 1061 sent the call begins being charged. 1063 The nearest local exchange to the callee generates the ringback tone 1064 and may send voice announcements. 1066 Usually on receipt of an ACM a `180 Ringing' is sent to the SIP 1067 network. It should generally contain a session description in order 1068 to allow SIP UAs to prevent clipping of initial callee media. The 1069 ringback tone or the proper announcements will be generated by the 1070 PSTN exchange, and not by the callers SIP UAC/UAS. 1072 If the Backwards Call Indicator (BCI) parameter of the ACM indicates 1073 that interworking has been encountered (generally designating that 1074 the ISUP network sending the ACM is interworking with a less 1075 sophisticated network which cannot support cause codes), then there 1076 may be in-band announcements of call status such as an audible busy 1077 tone or caller intercept message. In this case rather than a 180 1078 status code, a 183 Session Progress message should be sent in order 1079 to allow pre-ANM media to flow in the backwards direction. 1081 In SIP bridging situations, the ACM is included in the body of the 1082 180 response. 1084 6.2.7 CON or ANM Received 1086 A `200 OK' response is sent to the SIP network. In SIP bridging 1087 situations, the ISUP message is included in the body of the 200 OK 1088 response. This is also the point at which a two-way media stream 1089 will be established. 1091 6.2.8 Timer T9 Expires 1093 This indicates that the ANM has not arrived in time specified. This 1094 results in the call being aborted. All the resources related to the 1095 media path are released. A `480 temporarily unavailable' is sent to 1096 the SIP network. A REL message with cause value 19 (no answer from 1097 the user) is sent to the ISUP part. The PSTN responds with RLC and 1098 the SIP network responds with an ACK indicating that the release 1099 sequence has been completed. 1101 6.2.9 CPG Received 1103 A CPG can indicate progress, alerting or in-band information. If the 1104 CPG comes after an ACM, there is already a one-way voice path open, 1105 so there is no need of taking further action in the media path. 1107 In SIP bridging situations, the CPG is sent in the body of a 18x 1108 response, determined from the CPG event code. 1110 ISUP event code SIP response 1111 ---------------- ------------ 1112 1 Alerting 180 Ringing 1113 2 Progress 183 Call progress 1114 3 In-band information 183 Call progress 1115 4 Call forward; line busy 181 Call is being forwarded 1116 5 Call forward; no reply 181 Call is being forwarded 1117 6 Call forward; unconditional 181 Call is being forwarded 1118 - (no event code present) 183 Call progress 1120 Note that, if the CPG does not indicate "Alerting," the current state 1121 will not change. 1123 6.3 ACK received 1125 At this stage, the call is connected and the conversation can take 1126 place. 1128 7. ISUP to SIP Mapping 1130 7.1 Call Flows 1132 The following call flows illustrate the order of messages in typical 1133 success and error cases when setting up a call initiated from the 1134 PSTN network. "100 Trying" acknowledgements to INVITE requests are 1135 not explained, since their presence is optional. 1137 In these diagrams, all call signaling (SIP, ISUP) is going to and 1138 from the MGC; media handling (e.g. audio cut-through, trunk freeing) 1139 is being performed by the MG, under the control of the MGC. For the 1140 purpose of simplicity, these are shown as a single node, labeled 1141 "MGC/MG." 1143 7.1.1 En-bloc call setup (non auto-answer) 1145 SIP MGC/MG PSTN 1146 | |<-----------IAM-----------|1 1147 | |==========Audio==========>| 1148 2|<--------INVITE-----------| | 1149 |-----------100----------->| | 1150 3|-----------18x----------->| | 1151 |==========Audio==========>| | 1152 | |=========================>| 1153 | |------------ACM---------->|4 1154 5|-----------18x----------->| | 1155 | |------------CPG---------->|6 1156 7|-----------200-(I)------->| | 1157 |<=========Audio==========>| | 1158 | |------------ANM---------->|8 1159 | |<=========Audio==========>| 1160 9|<----------ACK------------| | 1162 1. When a PSTN user wishes to begin a session with a SIP user, the 1163 PSTN network generates an IAM message towards the gateway. 1165 2. Upon receipt of the IAM message, the gateway generates an INVITE 1166 message, and sends it to an appropriate SIP node. 1168 3. When an event signifying that the call has sufficient addressing 1169 information occurs, the SIP node will generate a provisional 1170 response of 180 or greater. 1172 4. Upon receipt of a provisional response of 180 or greater, the 1173 gateway will generate an ACM message. If the response is not 1174 180, the ACM will carry a "called party status" value of "no 1175 indication." 1177 5. The SIP node may use further provisional messages to indicate 1178 call progress. 1180 6. After an ACM has been sent, all provisional responses will 1181 translate into ISUP CPG messages as indicated in Section 7.2.3. 1183 7. When the SIP node answers the call, it will send a 200 OK 1184 message. 1186 8. Upon receipt of the 200 OK message, the gateway will send an ANM 1187 message towards the ISUP node. 1189 9. The gateway will send an ACK to the SIP node to acknowledge 1190 receipt of the INVITE final response. 1192 7.1.2 Auto-answer call setup 1194 SIP MGC/MG PSTN 1195 | |<-----------IAM-----------|1 1196 | |==========Audio==========>| 1197 2|<--------INVITE-----------| | 1198 3|-----------200----------->| | 1199 |<=========Audio==========>| | 1200 | |------------CON---------->|4 1201 | |<=========Audio==========>| 1202 5|<----------ACK------------| | 1204 1. When a PSTN user wishes to begin a session with a SIP user, the 1205 PSTN network generates an IAM message towards the gateway. 1207 2. Upon receipt of the IAM message, the gateway generates an INVITE 1208 message, and sends it to an appropriate SIP node based on called 1209 number analysis. 1211 3. Since the SIP node is set up to automatically answer the call, it 1212 will send a 200 OK message. 1214 4. Upon receipt of the 200 OK message, the gateway will send a CON 1215 message towards the ISUP node. 1217 5. The gateway will send an ACK to the SIP node to acknowledge 1218 receipt of the INVITE final response. 1220 7.1.3 SIP Timeout 1222 SIP MGC/MG PSTN 1223 | |<-----------IAM-----------|1 1224 | |==========Audio==========>| 1225 2|<--------INVITE-----------| | 1226 | *** T1 Expires *** | | 1227 3|<--------INVITE-----------| | 1228 | *** T1 Expires *** | | 1229 |<--------INVITE-----------| | 1230 | | *** T11 Expires *** | 1231 | |------------ACM---------->|4 1232 | *** T1 Expires *** | | 1233 |<--------INVITE-----------| | 1234 | *** T1 Expires *** | | 1235 |<--------INVITE-----------| | 1236 | *** T1 Expires *** | | 1237 |<--------INVITE-----------| | 1238 | *** T1 Expires *** | | 1239 |<--------INVITE-----------| | 1240 | *** T1 Expires *** | | 1241 | ** MG Releases PSTN Trunk ** | 1242 | |------------REL---------->|5 1243 6|<--------CANCEL-----------| | 1244 | |<-----------RLC-----------|7 1246 1. When a PSTN user wishes to begin a session with a SIP user, the 1247 PSTN network generates an IAM message towards the gateway. 1249 2. Upon receipt of the IAM message, the gateway generates an INVITE 1250 message, and sends it to an appropriate SIP node based on called 1251 number analysis. The ISUP timer T11 and SIP timer T1 are set at 1252 this time. 1254 3. The INVITE message will continue to be sent to the SIP node each 1255 time the timer T1 expires. The SIP standard specifies that 1256 INVITE transmission will be performed 7 times if no response is 1257 received. 1259 4. When T11 expires, an ACM message will be sent to the ISUP node to 1260 prevent the call from being torn down by the remote node's ISUP 1261 T7. This ACM contains a `Called Party Status' value of `no 1262 indication.' 1264 5. Once the maximum number of INVITE requests has been sent, the 1265 gateway will send a REL (cause code 18) to the ISUP node to 1266 terminate the call. 1268 6. The gateway also sends a CANCEL message to the SIP node to 1269 terminate any initiation attempts. 1271 7. Upon receipt of the REL, the remote ISUP node will send an RLC to 1272 acknowledge. 1274 7.1.4 ISUP T9 Expires 1276 SIP MGC/MG PSTN 1277 | |<-----------IAM-----------|1 1278 | |==========Audio==========>| 1279 2|<--------INVITE-----------| | 1280 | *** T1 Expires *** | | 1281 3|<--------INVITE-----------| | 1282 | *** T1 Expires *** | | 1283 |<--------INVITE-----------| | 1284 | | *** T11 Expires *** | 1285 | |------------ACM---------->|4 1286 | *** T1 Expires *** | | 1287 |<--------INVITE-----------| | 1288 | *** T1 Expires *** | | 1289 |<--------INVITE-----------| | 1290 | *** T1 Expires *** | | 1291 |<--------INVITE-----------| | 1292 | | *** T9 Expires *** | 1293 | ** MG Releases PSTN Trunk ** | 1294 | |<-----------REL-----------|5 1295 | |------------RLC---------->|6 1296 7|<--------CANCEL-----------| | 1298 1. When a PSTN user wishes to begin a session with a SIP user, the 1299 PSTN network generates an IAM message towards the gateway. 1301 2. Upon receipt of the IAM message, the gateway generates an INVITE 1302 message, and sends it to an appropriate SIP node based on called 1303 number analysis. The ISUP timer T11 and SIP timer T1 are set at 1304 this time. 1306 3. The INVITE message will continue to be sent to the SIP node each 1307 time the timer T1 expires. The SIP standard specifies that 1308 INVITE transmission will be performed 7 times if no response is 1309 received. Since SIP T1 starts at 1/2 second or more and doubles 1310 each time it is retransmitted, it will be at least a minute 1311 before SIP times out the INVITE request; since SIP T1 is allowed 1312 to be larger than 500 ms initially, it is possible that 7 x SIP 1313 T1 will be longer than ISUP T11 + ISUP T9. 1315 4. When T11 expires, an ACM message will be sent to the ISUP node to 1316 prevent the call from being torn down by the remote node's ISUP 1317 T7. This ACM contains a `Called Party Status' value of `no 1318 indication.' 1320 5. When ISUP T9 in the remote PSTN node expires, it will send a REL. 1322 6. Upon receipt of the REL, the gateway will send an RLC to 1323 acknowledge. 1325 7. The REL will trigger a CANCEL request, which gets sent to the SIP 1326 node. 1328 7.1.5 SIP Error Response 1330 SIP MGC/MG PSTN 1331 | |<-----------IAM-----------|1 1332 | |==========Audio==========>| 1333 2|<--------INVITE-----------| | 1334 3|-----------4xx+---------->| | 1335 4|<----------ACK------------| | 1336 | ** MG Releases PSTN Trunk ** | 1337 | |------------REL---------->|5 1338 | |<-----------RLC-----------|6 1340 1. When a PSTN user wishes to begin a session with a SIP user, the 1341 PSTN network generates an IAM message towards the gateway. 1343 2. Upon receipt of the IAM message, the gateway generates an INVITE 1344 message, and sends it to an appropriate SIP node based on called 1345 number analysis. 1347 3. The SIP node indicates an error condition by replying with a 1348 response with a code of 400 or greater. 1350 4. The gateway sends an ACK message to acknowledge receipt of the 1351 INVITE final response. 1353 5. An ISUP REL message is generated from the SIP code, as specified 1354 in Section 7.2.6.1. 1356 6. The remote ISUP node confirms receipt of the REL message with an 1357 RLC message. 1359 7.1.6 SIP Redirection 1361 SIP node 1 MGC/MG PSTN 1362 | |<-----------IAM-----------|1 1363 | |==========Audio==========>| 1364 2|<--------INVITE-----------| | 1365 3|-----------3xx+---------->| | 1366 | |------------CPG---------->|4 1367 5|<----------ACK------------| | 1368 | | 1369 | | 1370 SIP node 2 | | 1371 6|<--------INVITE-----------| | 1372 7|-----------18x----------->| | 1373 |<=========Audio===========| | 1374 | |------------ACM---------->|8 1375 9|-----------200-(I)------->| | 1376 |<=========Audio==========>| | 1377 | |------------ANM---------->|10 1378 | |<=========Audio==========>| 1379 11|<----------ACK------------| | 1381 1. When a PSTN user wishes to begin a session with a SIP user, the 1382 PSTN network generates an IAM message towards the gateway. 1384 2. Upon receipt of the IAM message, the gateway generates an INVITE 1385 message, and sends it to an appropriate SIP node based on called 1386 number analysis. 1388 3. The SIP node indicates that the resource which the user is 1389 attempting to contact is at a different location by sending a 1390 3xx message. In this instances we assume the Contact URL 1391 specifies a valid URL reachable by a VoIP SIP call. 1393 4. The gateway sends a CPG with event indication that the call is 1394 being forwarded upon receipt of the 3xx message. Note that this 1395 translation should be able to be disabled by configuration, as 1396 some ISUP nodes do not support receipt of CPG messages before 1397 ACM messages. 1399 5. The gateway acknowledges receipt of the INVITE final response by 1400 sending an ACK message to the SIP node. 1402 6. The gateway re-sends the INVITE message to the address indicated 1403 in the Contact: field of the 3xx message. 1405 7. When an event signifying that the call has sufficient addressing 1406 information occurs, the SIP node will generate a provisional 1407 response of 180 or greater. 1409 8. Upon receipt of a provisional response of 180 or greater, the 1410 gateway will generate an ACM message with an event code as 1411 indicated in Section 7.2.3. 1413 9. When the SIP node answers the call, it will send a 200 OK 1414 message. 1416 10. Upon receipt of the 200 OK message, the gateway will send an ANM 1417 message towards the ISUP node. 1419 11. The gateway will send an ACK to the SIP node to acknowledge 1420 receipt of the INVITE final response. 1422 7.1.7 Call Canceled by ISUP 1424 SIP MGC/MG PSTN 1425 | |<-----------IAM-----------|1 1426 | |==========Audio==========>| 1427 2|<--------INVITE-----------| | 1428 3|-----------18x----------->| | 1429 |==========Audio==========>| | 1430 | |------------ACM---------->|4 1431 | ** MG Releases PSTN Trunk ** | 1432 | |<-----------REL-----------|5 1433 | |------------RLC---------->|6 1434 7|<---------CANCEL----------| | 1435 | ** MG Releases IP Resources ** | 1436 8|-----------200----------->| | 1437 9|-----------487----------->| | 1438 10|<----------ACK------------| | 1440 1. When a PSTN user wishes to begin a session with a SIP user, the 1441 PSTN network generates an IAM message towards the gateway. 1443 2. Upon receipt of the IAM message, the gateway generates an INVITE 1444 message, and sends it to an appropriate SIP node based on called 1445 number analysis. 1447 3. When an event signifying that the call has sufficient addressing 1448 information occurs, the SIP node will generate a provisional 1449 response of 180 or greater. 1451 4. Upon receipt of a provisional response of 180 or greater, the 1452 gateway will generate an ACM message with an event code as 1453 indicated in Section 7.2.3. 1455 5. If the calling party hangs up before the SIP node answers the 1456 call, a REL message will be generated. 1458 6. The gateway frees the PSTN circuit and indicates that it is 1459 available for reuse by sending an RLC. 1461 7. Upon receipt of a REL message before an INVITE final response, 1462 the gateway will send a CANCEL towards the SIP node. 1464 8. Upon receipt of the CANCEL, the SIP node will send a 200 1465 response. 1467 9. The remote SIP node will send a "487 Call Cancelled" to complete 1468 the INVITE transaction. 1470 10. The gateway will send an ACK to the SIP node to acknowledge 1471 receipt of the INVITE final response. 1473 7.2 State Machine 1475 Note that REL may arrive in any state. Whenever this occurs, the 1476 actions in section Section 7.2.7. are taken. Not all of these 1477 transitions are shown in this diagram. 1479 +---------+ 1480 +----------------------->| Idle |<---------------------+ 1481 | +----+----+ | 1482 | | | 1483 | | IAM/7.2.1 | 1484 | V | 1485 | REL/7.2.7 +-------------------------+ 400+/7.2.6 | 1486 +<----------------+ Trying |------------>| 1487 | +-+--------+------+-------+ | 1488 | | | | | 1489 | | T11/ | 18x/ | 200/ | 1490 | | 7.2.8 |7.2.3 | 7.2.4 | 1491 | V | | | 1492 | REL/7.2.7 +--------------+ | | 400+/7.2.6 | 1493 |<----------| Progressing |-|------|-------------------->| 1494 | +--+----+------+ | | | 1495 | | | | | | 1496 | 200/ | | 18x/ | | | 1497 | 7.2.4 | | 7.2.3 | | | 1498 | | V V | | 1499 | REL/7.2.7 | +---------------+ | 400+/7.2.6 | 1500 |<-------------|--| Alerting |-|-------------------->| 1501 | | +--------+------+ | | 1502 | | | | | 1503 | | | 200/ | | 1504 | | | 7.2.4 | | 1505 | V V V | 1506 | BYE/9.1 +-----------------------------+ REL/9.2 | 1507 +<------------+ Connected +------------>+ 1508 +-----------------------------+ 1510 7.2.1 Initial Address Message received 1512 Upon the reception of an IAM, resources are reserved in the media 1513 gateway and it connects audio in the backwards direction (towards the 1514 caller). 1516 7.2.1.1 IAM to INVITE procedures 1518 When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message will 1519 be created for transmission to the SIP network. This section details 1520 the process by which a gateway populates the INVITE based on 1521 parameters found within the IAM. 1523 The session context information discovered by the gateway in the IAM 1524 will be stored primarily in two URIs in the INVITE, one representing 1525 the originator of the session and the other the destination. The 1526 former will always appear in the From header (after it has been 1527 converted from ISUP format by the procedure described in Section 11), 1528 and the latter is almost always used for both the To header and the 1529 Request-URI. 1531 The construction of destination URI begins with determining which 1532 ISUP parameter currently contains the called party number. Usually, 1533 this will be the CPN parameter. However, if the destination number 1534 has been ported (see [15]) and a dip to the relevant LNP database has 1535 already been performed, then the called party number will, in some 1536 ISUP variants including ANSI, in fact appear in the Generic Digits 1537 Parameter or GAP. Generally in such variants the 'number translated' 1538 bit of the FCI parameter should be consulted to determine whether the 1539 called party number is in the CPN parameter or the GAP parameter. In 1540 other variants, if a portability dip has been performed the routing 1541 number may be founded prepended to the called party number in the CPN 1542 parameter. 1544 Once the location of the called party number has been determined, it 1545 should be translated into a tel URL through the mechanism described 1546 above. Some additional fields may need to be added to the tel URL 1547 after translation has been completed, namely: 1549 o If (in ANSI networks) the FCI 'number translated' bit indicated 1550 that an LNP dip had been performed, or (in other variants) if a 1551 routing number has been prepended to the CPN, then an 'npdi=yes' 1552 field must be appended to the tel URL. If the routing number is 1553 not present in the CPN, then if a Generic Digits Parameter (or GAP 1554 in ANSI) is present in the IAM, then the contents of the CPN 1555 should be translated from ISUP format (as described above) and 1556 copied into an 'rn=' field which must be appended to the tel URL. 1557 Note that Location Routing Numbers (LRNs) stored in CPN for calls 1558 to ported numbers are necessarily national in scope, and 1559 consequently they will not be preceded by a '+' in the 'rn=' 1560 field. For further information on these tel URL fields see [15]. 1562 o If either the CIP (in ANSI networks) or TNS is present, the 1563 carrier identification code (CIC) should be extracted from the 1564 parameter and analyzed by the gateway. If doing so is in keeping 1565 with local policy (i.e. provided that the CIC does not indicate 1566 the network which owns the gateway or some similar condition), a 1567 'cic=' field with the value of the CIC should be appended to the 1568 tel URL. Note that the CIC should be prefixed with the country 1569 code used or implied in the called party number, so that CIC 1570 '5062' becomes, in the United States, '+1-5062'. For further 1571 information on the 'cic=' tel URL field see [15]. 1573 In most cases, the resulting URI should be used in the To field and 1574 Request-URI sent by the gateway. However, if the OCN parameter is 1575 present in the IAM, the To field constructed from the translation of 1576 the OCN parameter, and hence the Request-URI and To field will be 1577 different. 1579 The construction of the From field is dependent on the presence of a 1580 CIN parameter. If the CIN is not present, then the gateway should 1581 create a dummy From header containing a SIP URI without a user 1582 portion which communicates only the hostname of the gateway (e.g. 1583 'sip:gw.level3.net'). If the CIN is available, then it should be 1584 translated (in accordance with the procedure described above) into a 1585 tel URL which should populate the From field. 1587 7.2.2 100 received 1589 A 100 response does not trigger any PSTN interworking messages; it 1590 only serves the purpose of suppressing INVITE retransmissions. 1592 7.2.3 18x received 1594 If no ACM has been sent yet and no ISUP is present in the 18x message 1595 body, and ISUP message is generated according to the following table. 1596 Note that, if an early ACM is sent, the call enters state 1597 "Progressing" instead of state "Alerting." 1599 Response received Message sent by the MGC 1600 ----------------- ----------------------- 1601 180 Ringing ACM 1602 181 Call is being forwarded Early ACM and CPG, event=6 1603 182 Queued ACM 1604 183 Session progress message ACM 1606 If an ACM has already been sent and no ISUP is present in the 18x 1607 message body, an ISUP message is generated according to the following 1608 table. 1610 Response received Message sent by the MGC 1611 ----------------- ----------------------- 1612 180 Ringing CPG, event = 1 (Alerting) 1613 181 Call is being forwarded CPG, event = 6 (Forwarding) 1614 182 Queued CPG, event = 2 (Progress) 1615 183 Session progress message CPG, event = 2 (Progress) 1617 If the reception of a `180 Ringing' response without media 1618 description, the MG generates the ringback tone to be heard by the 1619 caller. 1621 If the MGC receives any 1xx response (except 100) with a session 1622 description present for media setup, it sets up the session being 1623 described. The call progress media (e.g. ringback tone or 1624 announcement) is generated by an entity downstream (in the SIP 1625 network or by a PSTN exchange in SIP bridging situations). 1627 If an ACM has not been sent yet, one is generated and sent. The 1628 mandatory parameters of the ACM are described below: 1630 Message type: ACM 1632 Backward Indicators 1633 Charge indicator: 10 charge 1634 Called party's status indicator: 01 subscriber free or 1635 00 no indication (E.ACM) 1636 Called party's category indicator: 01 ordinary subscriber 1637 End-to-end method indicator: 00 no end-to-end method 1638 Interworking indicator: 0 no interworking 1639 End-to-end information indicator: 0 no end-to-end info 1640 ISDN user part indicator: 1 ISUP all the way 1641 Holding indicator: 0 no holding 1642 ISDN access indicator: 1 ISDN access 1643 Echo control device indicator: It depends on the call 1644 SCCP method indicator: 00 no indication 1646 In SIP bridging situations the MGC sends the ISUP message contained 1647 in the response body. 1649 Note that sending 183 before a gateway has confirmation that the 1650 address is complete (ACM) creates known problems in SIP bridging 1651 cases, and it should therefore be avoided. 1653 7.2.4 2xx received 1655 Response received Message sent by the MGC 1656 ----------------- ----------------------- 1657 200 OK ANM, ACK 1659 After receiving a 200 OK response the MGC establishes a two-way voice 1660 path in the MG and it sends an ANM to the PSTN and an ACK to the SIP 1661 network. 1663 If the `200 OK' response arrives before the MGC has sent the ACM, a 1664 CON is sent instead of the ANM. 1666 In SIP bridging situations the MGC sends the ANM or the CON in the 1667 response body. 1669 7.2.5 3xx Received 1671 When any 3xx response is received ,the MGC should try to contact the 1672 user using the `Contact' header or headers present in the response. 1673 These 3xx responses are typically sent by a re-direct server. This 1674 is a similar device to the HLR in mobile networks. It provides 1675 another address where the callee may be reached. 1677 A CPG message with an event code of 6 (Forwarding) may be sent to 1678 indicate that the call is proceeding. Note that some ISUP nodes may 1679 not support CPG before ACM, so this feature should be configurable. 1681 If the new location presented in the Contact header of a 3xx is best 1682 reachable (according to the gateway's routing policies) via the PSTN, 1683 the MGC sends a new IAM and from that moment on acts as a normal PSTN 1684 switch (no SIP involved). If the new location is best reachable 1685 using SIP, the MGC sends an INVITE with possibly a new IAM generated 1686 by the MGC in the message body. 1688 All redirection situations have to be treated very carefully because 1689 they involved special charging situations. In PSTN the caller 1690 typically pays the first dialog and the callee pays the second. 1692 7.2.6 4xx-6xx Received 1694 The MGC releases the resources in the MG, send a REL to the PSTN with 1695 a cause value and send an ACK to the SIP network. An RLC arrives 1696 indicating that the release sequence is complete. 1698 7.2.6.1 SIP Status Code to ISDN Cause Code Mapping 1700 By default, the cause location associated with the CAI parameter 1701 should be encoded such that 6xx codes are given the location 'user', 1702 whereas 4xx and 5xx codes are given a 'network' location. Exceptions 1703 are marked below. 1705 Any SIP status codes not listed below (associated with SIP 1706 extensions, versions of SIP subsequent to the issue of this document, 1707 or simply omitted) should be mapping to cause code 31 "Normal, 1708 unspecified". 1710 Just as there are certain ISDN cause codes that are ISUP-specific and 1711 have no corollary SIP action, so there are SIP status codes that 1712 should not be translated to ISUP. Examples are flagged with (+) 1713 below. 1715 Response received Cause value in the REL 1716 ----------------- ---------------------- 1717 400 Bad Request 41 Temporary Failure 1718 401 Unauthorized 21 Call rejected (*) 1719 402 Payment required 21 Call rejected 1720 403 Forbidden 21 Call rejected 1721 404 Not found 1 Unallocated number 1722 405 Method not allowed 63 Service or option 1723 unavailable 1724 406 Not acceptable 79 Service/option not 1725 implemented 1726 407 Proxy authentication required 21 Call rejected (*) 1727 408 Request timeout 102 Recovery on timer expiry 1728 410 Gone 22 Number changed 1729 (w/o diagnostic) 1730 413 Request Entity too long 127 Interworking (+) 1731 414 Request-URI too long 127 Interworking (+) 1732 415 Unsupported media type 79 Service/option not 1733 implemented (+) 1734 416 Unsupported URI Scheme 127 Interworking (+) 1735 420 Bad extension 127 Interworking (+) 1736 421 Extension Required 127 Interworking (+) 1737 480 Temporarily unavailable 18 No user responding 1738 481 Call/Transaction Does not Exist 41 Temporary Failure 1739 483 Too many hops 25 Exchange - routing error 1740 484 Address incomplete 28 Invalid Number Format (+) 1741 485 Ambiguous 1 Unallocated number 1742 486 Busy here 17 User busy 1743 488 Not Acceptable here --- by Warning header 1744 500 Server internal error 41 Temporary failure 1745 501 Not implemented 38 Network out of order 1746 502 Bad gateway 38 Network out of order 1747 503 Service unavailable 41 Temporary failure 1748 504 Server time-out 102 Recovery on timer expiry 1749 504 Version Not Supported 127 Interworking (+) 1750 513 Message Too Large 127 Interworking (+) 1751 600 Busy everywhere 17 User busy 1752 603 Decline 21 Call rejected 1753 604 Does not exist anywhere 1 Unallocated number 1754 606 Not acceptable --- by Warning header 1756 (*) In some cases, it may be possible for a SIP gateway to provide 1757 credentials to the SIP UAS that is rejecting an INVITE due to 1758 authorization failure. If the gateway can authenticate itself, then 1759 obviously it should do so and proceed with the call; only if the 1760 gateway cannot authorize itself should cause code 21 be sent. 1762 (+) If at all possible, a SIP gateway should respond to these 1763 protocol errors by remedying unacceptable behavior and attempting to 1764 re-originate the session. Only if this proves impossible should the 1765 SIP gateway fail the ISUP half of the call. 1767 When the Warning header is present in a SIP 606 or 488 message, there 1768 may be specific ISDN cause code mappings appropriate to the Warning 1769 code. This document assumes that sending '31 Normal, unspecified' 1770 will be sufficient for all currently assigned Warning codes. 1772 7.2.7 REL Received 1774 The MGC should abort the establishment of the session. A CANCEL 1775 request has to be issued. A BYE is not used, since no final response 1776 has arrived from the SIP side. A 200 OK for the CANCEL arrives, and 1777 a 487 for the INVITE arrives. 1779 The MGC has to store state information for a certain period of time, 1780 since a 200 final response for the INVITE originally sent might 1781 arrive (even after the reception of the 200 OK for the CANCEL). In 1782 this situation, the MGC sends an ACK and then a BYE. 1784 In SIP bridging situations, the REL message may be included in the 1785 CANCEL message body. CANCEL requests are answered with a final 1786 response (such as 200 OK) by the first proxy. Therefore, the MGC 1787 does not know if the CANCEL has arrived to the end user (egress MGC 1788 in this scenario). Note that although end-to-end delivery of the 1789 CANCEL's payload is not guaranteed, since both sides of a PSTN 1790 connection issue REL messages, it will not result in a failure in the 1791 PSTN if this REL is never delivered. If, in a glare condition, a 200 1792 OK response to the previously sent INVITE arrives after a CANCEL has 1793 been sent, the MGC sends an ACK and then a BYE with the REL in the 1794 message body. 1796 7.2.8 ISUP T11 Expires 1798 In order to prevent the remote ISUP node's timer T7 from expiring, 1799 the gateway may choose to keep its own supervisory timer; ISUP 1800 defines this timer as T11. T11's duration is carefully chosen so 1801 that it will always be shorter than the T7 of any node to which the 1802 gateway is communicating. 1804 To clarify timer T11's relevance with respect to SIP interworking, 1805 Q.764 [10] explains its use as: "If in normal operation, a delay in 1806 the receipt of an address complete signal from the succeeding network 1807 is expected, the last common channel signaling exchange will 1808 originate and send an address complete message 15 to 20 seconds 1809 [timer (T11)] after receiving the latest address message." Since SIP 1810 nodes have no obligation to respond to an INVITE request within 20 1811 seconds, SIP interworking inarguably qualifies as such a situation. 1813 If the gateway's T11 expires, it will send an early ACM (i.e. called 1814 party status set to "no indication") to prevent the expiration of the 1815 remote node's T7. See Section 7.2.3 for the value of the ACM 1816 parameters. 1818 If a "180 Ringing" message arrives subsequently, it will be sent in a 1819 CPG, as shown in Section 7.2.3. 1821 See Section 7.1.3 for an example callflow that includes the 1822 expiration of T11. 1824 8. Suspend/Resume and Hold 1826 8.1 SUS and RES 1828 In ISDN networks, a user can generate a SUS (timer T2, user 1829 initiated) in order to unplug the terminal from the socket and plug 1830 it in another one. A RES is sent once the terminal has been 1831 reconnected and the T2 timer has not expired. SUS is also frequently 1832 used to signaling an on-hook state for a remote terminal before 1833 timers leading to the transmission of a REL message are sent. While 1834 a call is suspended, no audio media is passed end-to-end. 1836 When a SUS is sent for a call that has a SIP leg, it may be desirable 1837 to suspend IP media transmission until a RES is received. Putting 1838 the media on hold insures that bandwidth is conserved when no audio 1839 traffic needs to be transmitted. 1841 If media suspension is appropriate, then when a SUS arrives from the 1842 PSTN, the MGC should send an INVITE to request that the far-end's 1843 transmission of the media stream be placed on hold. The subsequent 1844 reception of a RES from the PSTN would then trigger a re-INVITE that 1845 requests the resumption of the media stream. Note that the MGC may 1846 or may not elect to stop transmitting any media itself when it 1847 requests the cessation of far-end transmission. 1849 If media suspension is not required by the MGC receiving the SUS from 1850 the PSTN, the SIP INFO [9] method can be used to transmit an 1851 encapsulated SUS rather than a re-INVITE. Subsequent RES messages 1852 should be transmitted in the same method that was used for the 1853 corresponding SUS (i.e. if an INFO is used for a SUS, INFO should 1854 also be used for the subsequent RES). 1856 Regardless of whether the INFO or re-INVITE mechanism is used to 1857 carry a SUS message, neither has any implication that the originating 1858 side will cease sending IP media. The recipient of an encapsulated 1859 SUS message may therefore elect to send a re-INVITE themselves to 1860 suspend media transmission from the MGC side if desired. 1862 In SIP bridging situations, the SUS and RES messages can be 1863 transferred in the body of the INVITE. 1865 SIP MGC/MG PSTN 1866 | |<-----------SUS-----------|1 1867 2|<--------INVITE-----------| | 1868 3|-----------200----------->| | 1869 4|<----------ACK------------| | 1870 | |<-----------RES-----------|5 1871 6|<--------INVITE-----------| | 1872 7|-----------200----------->| | 1873 8|<----------ACK------------| | 1875 The handling of a network-initiated SUS immediately prior to call 1876 teardown is handled in Section 9.2.2. 1878 8.2 Hold (re-INVITE) 1880 After a call has been connected, a re-INVITE may be sent to a gateway 1881 from the SIP side in order to place the call on hold. This re-INVITE 1882 will have an SDP indicating that the originator of the re-INVITE no 1883 longer wishes to receive media. 1885 SIP MGC/MG PSTN 1886 1|---------INVITE---------->| | 1887 | |------------CPG---------->|2 1888 3|-----------200----------->| | 1889 4|<----------ACK------------| | 1891 When such a re-INVITE is received, the gateway should send a Call 1892 Progress Message (CPG) in order to express that the call has been 1893 placed on hold. The CPG should contain a Generic Notification 1894 Indicator (or, in ANSI networks, a Notification Indicator) with a 1895 value of 'remote hold'. 1897 If subsequent to the sending of the re-INVITE the SIP side wishes to 1898 take the remote end off hold, and to begin receiving media again, it 1899 may repeat the flow above with an INVITE that contains an SDP with a 1900 reachable media destination. The Generic Notification Indicator 1901 would in this instance have a value of 'remote retrieval' (or in some 1902 variants 'remote hold released'). 1904 Finally, note that a CPG with hold indicators may be received by a 1905 gateway from the PSTN. In the interests of conserving bandwidth, the 1906 gateway may wish to stop sending media until the call is resume, 1907 and/or send a re-INVITE to the SIP leg of the call requesting that 1908 the remote side stop sending media. 1910 9. Normal Release of the Connection 1912 Either the SIP side or the ISUP side may release a call, regardless 1913 of which side initiated the call. 1915 9.1 SIP initiated 1917 For a normal release of the call (reception of BYE), the MGC 1918 immediately sends a 200 response. It then releases the resources in 1919 the MG and sends an REL with a cause code of 16 (normal call 1920 clearing) to the PSTN. Release of resources is confirmed by the PSTN 1921 with a RLC. 1923 In SIP bridging situations, the REL contained in the BYE is sent to 1924 the PSTN. 1926 SIP MGC/MG PSTN 1927 1|-----------BYE----------->| | 1928 | ** MG Releases IP Resources ** | 1929 2|<----------200------------| | 1930 | ** MG Releases PSTN Trunk ** | 1931 | |------------REL---------->|3 1932 | |<-----------RLC-----------|4 1934 9.2 ISUP initiated 1936 If the release of the connection was caused by the reception of a 1937 REL, the REL is included in the BYE sent by the MGC. 1939 9.2.1 Caller hangs up 1941 For a normal release of the call (reception of REL from the PSTN), 1942 the MGC first releases the resources in the MG and then confirms that 1943 they are ready for re-use by sending an RLC. The SIP connection is 1944 released by sending a BYE (which is confirmed with a 200). 1946 SIP MGC/MG PSTN 1947 | |<-----------REL-----------|1 1948 | ** MG Releases PSTN Trunk ** | 1949 | |------------RLC---------->|2 1950 3|<----------BYE------------| | 1951 | ** MG Releases IP Resources ** | 1952 4|-----------200----------->| | 1954 9.2.2 Callee hangs up 1956 In analog PSTN, if the callee hangs up in the middle of a call, the 1957 local exchange sends a SUS instead of a REL and starts a timer (T6, 1958 SUS is network initiated). When the timer expires, the REL is sent. 1960 SIP MGC/MG PSTN 1961 | |<-----------SUS-----------|1 1962 2|<--------INVITE-----------| | 1963 3|-----------200----------->| | 1964 4|<----------ACK------------| | 1965 | | *** T6 Expires *** | 1966 | |<-----------REL-----------|5 1967 | ** MG Releases PSTN Trunk ** | 1968 | |------------RLC---------->|6 1969 7|<----------BYE------------| | 1970 | ** MG Releases IP Resources ** | 1971 8|-----------200----------->| | 1973 10. ISUP Maintenance Messages 1975 ISUP contains a set of messages used for maintenance purposes. They 1976 can be received during an ongoing call. There are basically two 1977 kinds of maintenance messages (apart from the continuity check): 1978 message for blocking circuits and messages for resetting circuits. 1980 10.1 Reset messages 1982 Upon reception of a reset message for the circuit being used, the 1983 call has to be released. RSC messages are answered with RLC after 1984 resetting the circuit in the MG. GRS messages are answered with GRA 1985 after resetting all the circuits affected by the message. 1987 The MGC acts as if a REL had been received in order to release the 1988 connection on the SIP side. The session will be terminated. A BYE 1989 or a CANCEL are sent depending of the status of the call. 1991 10.2 Blocking messages 1993 There are two kinds of blocking messages: maintenance oriented or 1994 hardware failure oriented. Maintenance oriented blocking messages 1995 indicates that the circuit has to be blocked for subsequent calls. 1996 Therefore, these messages do not affect any ongoing call. 1998 Hardware oriented blocking messages have to be treated as reset 1999 messages. The call is released. 2001 BLO is always maintenance oriented and it is answered by the MGC with 2002 BLA when the circuit is blocked. CGB messages have a "type 2003 indicator" inside the "circuit group supervision message type 2004 indicator". It indicates if the CGB is maintenance or hardware 2005 failure oriented. CGBs are answered with CGBAs. 2007 10.3 Continuity Checks 2009 A continuity check is a test performed on a circuit that involves the 2010 reflection of a tone generated at the originating switch by a 2011 loopback at the destination switch. Two variants of the continuity 2012 check appear in ISUP: the implicit continuity check request within an 2013 IAM (in which case the continuity check takes place before call setup 2014 begins), and the explicit continuity check signaled by a Continuity 2015 Check Request (CCR) message. 2017 When a CCR is received by a PSTN-SIP gateway, the gateway should not 2018 send any SIP messages; the scope of the continuity check applies only 2019 to the PSTN trunks, not to any IP media paths. 2021 When an IAM with the Continuity Check Indicator flag set within the 2022 Nature of Connection Indicators (NCI) parameter is received, the 2023 gateway should process the continuity check before sending an INVITE 2024 message; if the continuity check fails (a COT with Continuity 2025 Indicator of 'failed' is received), then an INVITE should not be 2026 sent. 2028 11. Construction of Telephony URIs 2030 SIP proxy servers may route SIP messages on any signaling criteria 2031 desired by network administrators, but generally the Request-URI is 2032 the foremost routing criterion. The To and From headers are also 2033 frequently of interest in making routing decisions. SIP-ISUP mapping 2034 assumes that proxy servers are interested in at least these three 2035 fields of SIP messages, all of which contain URIs. 2037 SIP-ISUP mapping frequently requires the representation of telephone 2038 numbers in these URIs. In some instances these numbers will be 2039 presented first in ISUP messages, and SS7-SIP gateways will need to 2040 translate the ISUP formats of these numbers into SIP URIs. In other 2041 cases the reverse transformation will be required. 2043 The most common format used in SIP for the representation of 2044 telephone numbers is the tel URL [16]. The tel URL may constitute 2045 the entirety of a URI field in a SIP message, or it may appear as the 2046 user portion of a SIP URI. For example, a To field might appear as: 2048 To: tel:+17208881000 2050 Or 2052 To: sip:+17208881000@level3.com 2054 Whether or not a particular gateway or endpoint should formulate URIs 2055 in the tel or SIP format is a matter of local administrative policy - 2056 if the presence of a host portion would aid the surrounding network 2057 in routing calls, the SIP format should be used. A gateway should 2058 accept either tel or SIP URIs from its peers. 2060 The '+' sign preceding the number in these examples indicates that 2061 the digits which follow constitute a fully-qualified E.164 [17] 2062 number; essentially, this means that a country code is provided 2063 before any national-specific area codes, exchange/city codes, or 2064 address codes. The absence of a '+' sign could mean that the number 2065 is nationally significant, or perhaps that a private dialing plan is 2066 in use. When the '+' sign is not present, but a telephone number is 2067 represented by the user portion of the URI, the SIP URI should may 2068 the optional ';user=phone' parameter; e.g. 2070 To: sip:83000@sip.example.net;user=phone 2072 However, it is highly recommended that only internationally 2073 significant E.164 numbers be passed between SIP-T gateways, 2074 especially when such gateways are in different regions or different 2075 administrative domains. In many if not most SIP-T networks, gateways 2076 are not responsible for end-to-end routing of SIP calls; practically 2077 speaking, gateways have no way of knowing if the call will terminate 2078 in a local or remote administrative domain and/or region, and hence 2079 gateways should always assume that calls require an international 2080 numbering plan. There is no guarantee that recipients of SIP 2081 signaling will be capable of understanding national dialing plans 2082 used by the originators of calls - if the originating gateway does 2083 not internationalize the signaling, the context in which the digits 2084 were dialed cannot be extrapolated by far-end network elements. 2086 In ISUP signaling, a telephone number appears in a common format that 2087 is used in several parameters, including the Called Party's Number 2088 (CPN) and Calling Party's Number (CIN); when it represents a calling 2089 party number it sports some additional information (detailed below). 2090 For the purposes of this document, we will refer to this format as 2091 'ISUP format' - if the additional calling party information is 2092 present, the format shall be referred to as 'ISUP- calling format'. 2093 The format consists of a byte called the Nature of Address (NoA) 2094 indicator, followed by another byte which contains the Numbering Plan 2095 Indicator (NPI), both of which are prefixed to a variable-length 2096 series of bytes that contains the digits of the telephone number in 2097 binary coded decimal (BCD) format. In the calling party number case, 2098 the NPI's byte also contains bit fields which represent the caller's 2099 presentation preferences and the status of any call screening checks 2100 performed up until this point in the call. 2102 H G F E D C B A H G F E D C B A 2103 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2104 | | NoA | | | NoA | 2105 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2106 | | NPI | spare | | | NPI |PrI|ScI| 2107 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2108 | dig...| dig 1 | | dig...| dig 1 | 2109 | ... | | ... | 2110 | dig n | dig...| | dig n | dig...| 2111 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2113 ISUP format ISUP calling format 2115 ISUP numbering formats 2117 The NPI field is generally set to the value 'ISDN (Telephony) 2118 numbering plan (Recommendation E.164)', but this does not mean that 2119 the digits which follow necessarily contain a country code; the NoA 2120 field dictates whether the telephone number is in a national or 2121 international format. When the represented number is not designated 2122 to be in an international format, the NoA generally provides 2123 information specific to the national dialing plan - based on this 2124 information one can usually determine how to convert the number in 2125 question into an international format. Note that if the NPI contains 2126 a value other than 'ISDN numbering plan', then the tel URL may not be 2127 suitable for carrying the address digits, and the handling for such 2128 calls is outside the scope of this document. 2130 Based on the above, conversion from ISUP format to a tel URL is as 2131 follows. First, provided that the NPI field indicates that the 2132 telephone number format uses E.164, the NoA should be consulted. If 2133 the NoA indicates that the number is an international number, then 2134 the telephone number digits should be appended unmodified to a 2135 'tel:+' string. If the NoA has the value 'national (significant) 2136 number', then a country code must be prefixed to the telephone number 2137 digits before they are committed to a tel URL; if the gateway 2138 performing this conversion interconnects with switches homed to 2139 several different country codes, presumably the appropriate country 2140 code should be chosen based on the originating switch. If the NoA 2141 has the value 'subscriber number', both a country code and any other 2142 numbering components necessary for the numbering plan in question 2143 (such as area codes or city codes) may need to be added in order for 2144 the number to be internationally significant - however, such 2145 procedures vary greatly from country to country, and hence they 2146 cannot be specified in detail here. Only if a country or network- 2147 specific value is used for the NoA should a tel URL not include a '+' 2148 sign; in these cases, gateways should simply copy the provided digits 2149 into the tel URL and append a 'user=phone' parameter if a SIP URI 2150 format is used. Any non-standard or proprietary mechanisms used to 2151 communicate further context for the call in ISUP are outside the 2152 scope of this document. 2154 If a nationally-specific parameter is present that allows for the 2155 transmission of the calling party's name (such as the Generic Name 2156 Parameter in ANSI), then generally, if presentation is not 2157 restricted, this information should be used to populate the display- 2158 name portion of the From field. 2160 If ISUP calling format is used rather than ISUP format, then two 2161 additional pieces of information must be taken into account: 2162 presentation indicators and screening indicators. If the 2163 presentation indicators are set to 'presentation restricted', then a 2164 special URI should be created by the gateway which communicates to 2165 the far end that the caller's identity has been elided. This URI 2166 should be a SIP URI with the hostname of the gateway but with a 2167 display name of 'Anonymous' username of 'restricted', e.g.: 2169 From: Anonymous 2171 As further general-purpose privacy mechanisms are developed for the 2172 SIP protocol, they may also be used to protect the identity of a 2173 caller. 2175 If presentation is set to 'address unavailable', then gateways should 2176 treat the IAM as if the CIN parameter was omitted. Screening 2177 indicators should not be translated, as they are only meaningful end- 2178 to-end. 2180 Conversion from tel URLs to ISUP format is simpler. If the URI is in 2181 international format, then the gateway should consult the leading 2182 country code of the URI. If the country code is local to the gateway 2183 (the gateway has one or more trunks that point to switches which are 2184 homed to the country code in question), the gateway should set the 2185 NoA to reflect 'national (significant) number' and strip the country 2186 code from the URI before populating the digits field. If the country 2187 code is not local to the gateway, the gateway should set the NoA to 2188 'international number' and retain the country code. In either case 2189 the NPI should be set to 'ISDN numbering plan'. 2191 If the URI is not in international format, the gateway should attempt 2192 to treat the telephone number within the URI as if it were 2193 appropriate to its national or network-specific dialing plan; if 2194 doing so gives rise to internal gateway errors, then this condition 2195 is most likely best handled with appropriate SIP status codes (e.g. 2196 484). 2198 When converting from a tel URL to ISUP calling format, the procedure 2199 is identical to that described in the preceding paragraphs, but 2200 additionally, the presentation indicator should be set to 2201 'presentation allowed' and the screening indicator to 'network 2202 provided', unless some service provider policy or user profile 2203 specifically disallows presentation. 2205 12. Other ISUP flavors 2207 Other flavors of ISUP different than Q.767 [2] have more parameters 2208 and more features. Some of the parameters have more possible values 2209 and provide more information about the status of the call. 2211 The Circuit Query Message (CQM) and Circuit Query Response (CQR) are 2212 used in many ISUP variants. These messages have no analog in SIP, 2213 although receipt of a CQR may cause state reconciliation if the 2214 originating and destination switches have become desynchronized; as 2215 states are reconciled some calls may be dropped, which may cause SIP 2216 or ISUP messages to be sent. 2218 However, differences in the message flows are more important. In 2219 ANSI [3] ISUP, there is no CON message; an ANM is sent instead (with 2220 no ACM). In call forwarding situations, CPGs can be sent before the 2221 ACM is sent. SAMs are never used; `en bloc' signaling is always 2222 used. The ANSI Exit Message (EXM) should not result in any SIP 2223 signaling in gateways. ANSI also uses the Circuit Reservation 2224 Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of 2225 its interworking procedures - in the event that an MGC does receive a 2226 CRM, a CRA should be sent in return (in some implementations, 2227 transmissions of a CRA could conceivably be based on a resource 2228 reservation system); after a CRA is sent, the MGC should wait for a 2229 subsequent IAM and process it normally. Any further circuit 2230 reservation mechanism is outside the scope of this document. 2232 Although receipt of a Confusion (CFN) message is an indication of a 2233 protocol error, no SIP message should be sent on receipt of a CFN - 2234 the CFN should be handled internally by the gateway (usually by 2235 retransmission of the packet to which the CFN responded). Only if 2236 this fails repeatedly should this cause a SIP error condition to 2237 arise. 2239 In TTC ISUP CPGs can be sent before the ACM is sent. Messages such 2240 as CHG can be sent between ACM and ANM. `En bloc' signaling is 2241 always used and there is no T9 timer. 2243 12.1 Guidelines to send other ISUP messages 2245 Some ISUP flavors send more messages than the ones described in this 2246 document. It is good to follow some guidelines to transport these 2247 ISUP messages inside SIP bodies. 2249 From the caller to the callee ISUP messages should be encapsulated 2250 (see [4]) inside INFO messages, even if the INVITE transaction is 2251 still not finished. Note that SIP does not ensure that INFO requests 2252 are delivered in order. Therefore, an egress gateway might process 2253 first an INFO request that was sent after another INFO request. This 2254 issue, however, does not represent an important problem since it is 2255 not likely to happen and its effects are negligible in most of the 2256 situations. The Information (INF) message and Information Response 2257 (INR) are examples of messages that should be encapsulated within an 2258 INFO. 2260 From the callee to the caller, if an INR is received by a gateway 2261 before the call has been answered (i.e. ANM is received) it should 2262 be encapsulated in an INFO, provided that this will not be the first 2263 SIP message sent in the backwards direction (in which case it must be 2264 encapsulated in a provisional 1xx response). Similarly an INF is 2265 received on the originating side (probably in response to an INR) 2266 before a 200 has been received should be carried within an INFO. In 2267 order for this mechanism to function properly in the forward 2268 direction, any necessary Contact or To-tag must have appeared in a 2269 previous provisional response or the message might not be correctly 2270 routed to its destination. As such all SIP-T gateways should send 2271 provisional responses with a Contact header and any necessary tags in 2272 order to enable proper routing of new requests issued before a final 2273 response has been received. 2275 ISUP messages from the callee to the caller should be sent inside 2276 provisional responses. SIP ensures that provisional responses 2277 transmitted reliably are delivered in order. When the INVITE 2278 transaction is finished INFO requests should be used also in this 2279 direction. 2281 13. Acronyms 2283 ACK Acknowledgment 2284 ACM Address Complete Message 2285 ANM Answer Message 2286 ANSI American National Standards Institute 2287 BLA Blocking ACK message 2288 BLO Blocking Message 2289 CGB Circuit Group Blocking Message 2290 CGBA Circuit Group Blocking ACK Message 2291 CHG Charging Information Message 2292 CON Connect Message 2293 CPG Call Progress Message 2294 CUG Closed User Group 2295 GRA Circuit Group Reset ACK Message 2296 GRS Circuit Group Reset Message 2297 HLR Home Location Register 2298 IAM Initial Address Message 2299 IETF Internet Engineering Task Force 2300 IP Internet Protocol 2301 ISDN Integrated Services Digital Network 2302 ISUP ISDN User Part 2303 ITU-T International Telecommunication Union 2304 Telecommunication Standardization Sector 2305 MG Media Gateway 2306 MGC Media Gateway Controller 2307 MTP Message Transfer Part 2308 REL Release Message 2309 RES Resume Message 2310 RLC Release Complete Message 2311 RTP Real-time Transport Protocol 2312 SCCP Signaling Connection Control Part 2313 SG Signaling Gateway 2314 SIP Session Initiation Protocol 2315 SS7 Signaling System No. 7 2316 SUS Suspend Message 2317 TTC Telecommunication Technology Committee 2318 UAC User Agent Client 2319 UAS User Agent Server 2320 UDP User Datagram Protocol 2321 VoIP Voice over IP 2323 14. Security Considerations 2325 The transit of encapsulated ISUP within SIP bodies may provide may 2326 opportunities for abuse and fraud. In particular, SIP users may be 2327 able to interpret "private" (i.e. caller-id-blocked) numbers by 2328 examining the ISUP. Similarly, if care is not taken, SIP clients 2329 would be able to send ISUP messages into the SS7 network with invalid 2330 calling line identification and spoofed billing numbers. 2332 For these reasons, it is absolutely necessary that any ISUP sent 2333 through an IP network be strongly encrypted and authenticated. The 2334 keys used for encryption should not be static, to prevent replay 2335 attacks. A challenge-response model is recommended. As an extra 2336 layer of security, it is recommended that ISUP be sent and received 2337 only to and from nodes that are known to have an established trust 2338 relationship with the gateway. 2340 15. IANA Considerations 2342 This document introduces no new considerations for IANA. 2344 References 2346 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 2347 "SIP: Session Initiation Protocol", RFC 2543, September 1999. 2349 [2] International Telecommunications Union, "Application of the 2350 ISDN user part of CCITT Signaling System No. 7 for 2351 international ISDN interconnection", ITU-T Q.767, February 2352 1991, . 2354 [3] American National Standards Institute, "Signaling System No. 7; 2355 ISDN User Part", ANSI T1.113, January 1995, 2356 . 2358 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 2359 Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG 2360 objects", RFC 3204, December 2001. 2362 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2363 Extensions (MIME) Part Two: Media Types", RFC 2046, November 2364 1996. 2366 [6] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 2367 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 2369 [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2370 Responses in SIP", draft-ietf-sip-100rel-06 (work in progress), 2371 February 2002. 2373 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2374 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2375 Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 2376 (work in progress), February 2002. 2378 [9] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 2380 [10] International Telecommunications Union, "Signaling System No. 2381 7; ISDN User Part Signaling procedures", ITU-T Q.764, September 2382 1997, . 2384 [11] International Telecommunications Union, "Abnormal conditions - 2385 Special release", ITU-T Q.118, September 1997, 2386 . 2388 [12] International Telecommunications Union, "Specifications of 2389 Signaling System No. 7 - ISDN supplementary services", ITU-T 2390 Q.737, June 1997, . 2392 [13] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, 2393 October 2000. 2395 [14] International Telecommunications Union, "Usage of cause 2396 location in the Digital Subscriber Signaling System No. 1 and 2397 the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 2398 1998, . 2400 [15] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of 2401 Number Portability and Freephone Service", draft-yu-tel-url-03 2402 (work in progress), November 2001. 2404 [16] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2405 2000. 2407 [17] International Telecommunications Union, "The international 2408 public telecommunications numbering plan", ITU-T E.164, May 2409 1997, . 2411 [18] International Telecommunications Union, "Formats and codes of 2412 the ISDN User Part of Signaling System No. 7", ITU-T Q.763, 2413 March 1993, . 2415 [19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2416 2633, June 1999. 2418 [20] Rosenberg, J., "SIP Early Media", draft-rosenberg-sip-early- 2419 media-00 (work in progress), July 2001. 2421 Authors' Addresses 2423 Gonzalo Camarillo 2424 Ericsson 2425 Advanced Signalling Research Center 2426 FIN-02420 Jorvas 2427 Finland 2429 Phone: +358 9 299 3371 2430 EMail: Gonzalo.Camarillo@Ericsson.com 2431 URI: http://www.ericsson.com/ 2432 Adam Roach 2433 dynamicsoft 2434 5100 Tennyson Parkway 2435 Suite 1200 2436 Plano, TX 75024 2437 USA 2439 EMail: adam@dynamicsoft.com 2440 URI: sip:adam@dynamicsoft.com 2442 Jon Peterson 2443 NeuStar, Inc. 2444 1800 Sutter St 2445 Suite 570 2446 Concord, CA 94520 2447 USA 2449 Phone: +1 925/363-8720 2450 EMail: jon.peterson@neustar.biz 2451 URI: http://www.neustar.biz/ 2453 Lyndon Ong 2454 Ciena 2455 10480 Ridgeview Court 2456 Cupertino, CA 95014 2457 USA 2459 EMail: lyOng@ciena.com 2460 URI: http://www.ciena.com/ 2462 Appendix A. Acknowledgments 2464 The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill 2465 Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, 2466 Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, 2467 Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan 2468 Van Geel, and Romel Khan for their help and feedback on this 2469 document. 2471 Appendix B. Revision History 2473 Changes from draft-ietf-sip-isup-00: 2475 - Merged draft-jfp-sip-isup-header-00 into this draft 2477 - Removed overlap signaling component (now draft-ietf-sip-overlap- 2478 00) 2480 - Adjusted cause code to status code mappings 2482 Changes from draft-ietf-sip-isup-01: 2484 - Added procedures for placing calls on hold 2486 - Generalized language and procedures for LNP, removing ANSI bias 2488 - Fixed usage of 'user=phone' 2490 - Added handling for Segmentation Message in ISUP 2492 - Updated SUS/RES handling to use INFO consistently (rather than 2493 183) 2495 Changes from draft-ietf-sip-isup-02: 2497 - Fixed some more ANSI-specific references (GNI, screening) 2499 - Fixed timer expiry cause code values (6.2.2) 2501 - Removed some bis04 incompatibilities (6.2.10) 2503 - Added motivational text to abstract and introduction 2505 Changes from draft-ietf-sip-isup-03: 2507 - Added provision for SUS/RES over INFO method 2509 - Fixed ANSI CRM/CRA behavior 2511 - Corrected a few status code conflicts 2513 - Righted many nits (thanks Igor!) 2515 Changes from draft-ietf-sipping-isup-00: 2517 - Removed PRACK from call flows 2518 - Some updating to bring language in parity with bis 2520 - Various nits 2522 Full Copyright Statement 2524 Copyright (C) The Internet Society (2002). All Rights Reserved. 2526 This document and translations of it may be copied and furnished to 2527 others, and derivative works that comment on or otherwise explain it 2528 or assist in its implementation may be prepared, copied, published 2529 and distributed, in whole or in part, without restriction of any 2530 kind, provided that the above copyright notice and this paragraph are 2531 included on all such copies and derivative works. However, this 2532 document itself may not be modified in any way, such as by removing 2533 the copyright notice or references to the Internet Society or other 2534 Internet organizations, except as needed for the purpose of 2535 developing Internet standards in which case the procedures for 2536 copyrights defined in the Internet Standards process must be 2537 followed, or as required to translate it into languages other than 2538 English. 2540 The limited permissions granted above are perpetual and will not be 2541 revoked by the Internet Society or its successors or assigns. 2543 This document and the information contained herein is provided on an 2544 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2545 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2546 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2547 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2548 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2550 Acknowledgement 2552 Funding for the RFC Editor function is currently provided by the 2553 Internet Society.