idnits 2.17.1 draft-ietf-sipping-isup-02.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 : ---------------------------------------------------------------------------- ** 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 1646 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 (May 31, 2002) is 7994 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: '13' is defined on line 2366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2833 (ref. '4') (Obsoleted by RFC 4733, RFC 4734) ** Obsolete normative reference: RFC 2976 (ref. '5') (Obsoleted by RFC 6086) == Outdated reference: A later version (-08) exists of draft-yu-tel-url-04 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2806 (ref. '7') (Obsoleted by RFC 3966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '17') (Obsoleted by RFC 4960) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: November 29, 2002 A. Roach 5 dynamicsoft 6 J. Peterson 7 NeuStar 8 L. Ong 9 Ciena 10 May 31, 2002 12 ISUP to SIP Mapping 13 draft-ietf-sipping-isup-02 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 November 29, 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 . . . . . . . . . . . . . . . . . . . . . . . 38 98 7.2.3 18x received . . . . . . . . . . . . . . . . . . . . . . . 38 99 7.2.4 2xx received . . . . . . . . . . . . . . . . . . . . . . . 40 100 7.2.5 3xx Received . . . . . . . . . . . . . . . . . . . . . . . 40 101 7.2.6 4xx-6xx Received . . . . . . . . . . . . . . . . . . . . . 40 102 7.2.6.1 SIP Status Code to ISDN Cause Code Mapping . . . . . . . . 41 103 7.2.7 REL Received . . . . . . . . . . . . . . . . . . . . . . . 42 104 7.2.8 ISUP T11 Expires . . . . . . . . . . . . . . . . . . . . . 43 105 8. Suspend/Resume and Hold . . . . . . . . . . . . . . . . . 44 106 8.1 SUS and RES . . . . . . . . . . . . . . . . . . . . . . . 44 107 8.2 Hold (re-INVITE) . . . . . . . . . . . . . . . . . . . . . 45 108 9. Normal Release of the Connection . . . . . . . . . . . . . 46 109 9.1 SIP initiated . . . . . . . . . . . . . . . . . . . . . . 46 110 9.2 ISUP initiated . . . . . . . . . . . . . . . . . . . . . . 46 111 9.2.1 Caller hangs up . . . . . . . . . . . . . . . . . . . . . 46 112 9.2.2 Callee hangs up . . . . . . . . . . . . . . . . . . . . . 47 113 10. ISUP Maintenance Messages . . . . . . . . . . . . . . . . 48 114 10.1 Reset messages . . . . . . . . . . . . . . . . . . . . . . 48 115 10.2 Blocking messages . . . . . . . . . . . . . . . . . . . . 48 116 10.3 Continuity Checks . . . . . . . . . . . . . . . . . . . . 48 117 11. Construction of Telephony URIs . . . . . . . . . . . . . . 50 118 12. Other ISUP flavors . . . . . . . . . . . . . . . . . . . . 54 119 12.1 Guidelines to send other ISUP messages . . . . . . . . . . 54 120 13. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 56 121 14. Security Considerations . . . . . . . . . . . . . . . . . 57 122 15. IANA Considerations . . . . . . . . . . . . . . . . . . . 58 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 61 124 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 62 125 References . . . . . . . . . . . . . . . . . . . . . . . . 59 126 References . . . . . . . . . . . . . . . . . . . . . . . . 60 127 B. Revision History . . . . . . . . . . . . . . . . . . . . . 63 128 Full Copyright Statement . . . . . . . . . . . . . . . . . 65 130 1. Introduction 132 SIP [1] is an application layer protocol for establishing, 133 terminating and modifying multimedia sessions. It is typically 134 carried over IP. Telephone calls are considered a type of multimedia 135 sessions where just audio is exchanged. 137 ISUP [10] is a level 4 protocol used in SS7 networks. It typically 138 runs over MTP although it can also run over IP (see SCTP [17]). ISUP 139 is used for controlling telephone calls and for maintenance of the 140 network (blocking circuits, resetting circuits etc.). 142 A module performing the mapping between these two protocols is 143 usually referred to as Media Gateway Controller (MGC), although the 144 terms 'softswitch' or 'call agent' are also sometimes used. An MGC 145 has logical interfaces facing both networks, the network carrying 146 ISUP and the network carrying SIP. The MGC also has some 147 capabilities for controlling the voice path; there is typically a 148 Media Gateway (MG) with E1/T1 trunking interfaces (voice from PSTN) 149 and with IP interfaces (VoIP). The MGC and the MG can be merged 150 together in one physical box or kept separate. 152 These MGCs are frequently used to bridge SIP and ISUP networks so 153 that calls originating in the PSTN can reach IP telephone endpoints 154 and vice versa. This is useful for cases in which PSTN calls need to 155 take advantage of services in IP world, in which IP networks are used 156 as transit networks for PSTN-PSTN calls, architectures in which calls 157 originate on desktop 'softphones' but terminate at PSTN terminals, 158 and many other similar next-generation telephone architectures. 160 This document describes logic and procedures which an MGC might use 161 to implement the mapping between SIP and ISUP by illustrating the 162 correspondences, at the message level and parameter level, between 163 the protocols. It also describes the interplay between parallel 164 state machines for these two protocols as a recommendation for 165 implementers to synchronize protocol events in interworking 166 architectures. 168 2. Scope 170 This document focuses on the translation of ISUP messages into SIP 171 messages, and the mapping of ISUP parameters into SIP headers. The 172 purpose of translation in ISUP-SIP interworking is twofold: for ISUP 173 calls that traverse a SIP network, translation allows SIP elements 174 such as proxy servers to make routing decisions based on ISUP 175 criteria such as the called party number; translation also provides 176 critical information about the call to SIP endpoints that cannot 177 understand encapsulated ISUP (or perhaps which merely cannot 178 understand the particular ISUP variant in use). 180 This document only takes into account the call functionality of ISUP. 181 Maintenance messages dealing with PSTN trunks are treated only as far 182 as they affect the control of an ongoing call; otherwise these 183 message neither have nor require any analog in SIP. 185 Messages indicating error or congestion situations in the PSTN (MTP- 186 3) and the recovery mechanisms used such as User Part Available and 187 User Part Test ISUP messages are outside the scope of this document 189 There are several flavors of ISUP. ITU-T Q.767 International ISUP 190 [8] is used through this document; some differences with ANSI [9] 191 ISUP and TTC ISUP are outlined. ISUP Q.767 is used in this document 192 because it is the least complex of all the ISUP flavors. Due to the 193 small number of fields that map directly from ISUP to SIP, the 194 signaling differences between Q.767 and specific national variants of 195 ISUP will generally have little to no impact on the mapping. Note, 196 however, that the ITU-T has not substantially standardized practices 197 for Local Number Portability since portability tends to be grounded 198 in national numbering plan practices, and that consequently LNP must 199 be described on a virtually per-nation basis. 201 Mapping of SIP headers to ISUP parameters in this document focuses 202 largely on the mapping between the parameters found in the ISUP 203 Initial Address Message (IAM) and the headers associated with the SIP 204 INVITE message; both of these messages are used in their respective 205 protocols to request the establishment of a call. Once an INVITE has 206 been sent for a particular session, such headers as the To and From 207 field become essentially fixed, and no further translation will be 208 required during subsequent signaling, which is routed in accordance 209 with Via and Route headers. Hence, the problem of parameter-to- 210 header mapping in SIP-T is confined more or less to the IAM and the 211 INVITE. Some additional detail is given in the population of 212 parameters in the ISUP ACM and REL messages based on SIP status 213 codes. 215 This document describes when the media path associated with a SIP 216 call is to be initialized, terminated, modified, etc., but it does 217 not go into details such as how the initialization is performed or 218 which protocols are used for that purpose. 220 3. Scenarios 222 There are several scenarios where ISUP-SIP mapping takes place. The 223 way the messages are generated is different depending on the 224 scenario. 226 When there is a single MGC and the call is from a SIP phone to a PSTN 227 phone, or vice versa, the MGC generates the ISUP messages based on 228 the methods described in this document. 230 +-------------+ +-----+ +-------------+ 231 | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | 232 +-------------+ +-----+ +-------------+ 234 The scenario where a call originates in the PSTN, goes into a SIP 235 network and terminates in the PSTN again is known as "SIP bridging". 236 SIP bridging should provide ISUP transparency between the PSTN 237 switches handling the call. This is achieved by encapsulating the 238 incoming ISUP messages in the body of the SIP messages (see [2]). In 239 this case, the ISUP messages generated by the egress MGC are the ones 240 present in the SIP body (possibly with some modifications; for 241 example, if the called number in the request URI is different from 242 the one present in the ISUP due to SIP redirection, the ISUP message 243 will need to be adjusted). 245 +------+ +-------------+ +-----+ +------------+ +------+ 246 | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 247 +------+ +-------------+ +-----+ +------------+ +------+ 249 SIP is used in the middle of both MGCs because the voice path has to 250 be established through the IP network between both MGs; this 251 structure also allows the call to take advantage of certain SIP 252 services. ISUP messages in the SIP bodies provide further 253 information (such as cause values and optional parameters) to the 254 peer MGC. 256 In both scenarios, the ingress MGC places the incoming ISUP messages 257 in the SIP body by default. Note that this has security 258 implications; see Section 14. If the recipient of these messages 259 (typically a SIP UAC/UAS) does not understand them a negotiation 260 using the SIP `Accept' and `Require' headers will take place and they 261 will not be included in the next SIP message exchange. 263 There can be a Signaling Gateway (SG) between the PSTN and the MGC. 264 It encapsulates the ISUP messages over IP in a manner such as the one 265 described in [17]. The mapping described in this document is not 266 affected by the underlying transport protocol of ISUP. 268 Note that overlap dialing mechanisms (use of the Subsequent Address 269 Message, SAM) are outside the scope of this document. This document 270 assumes that gateways facing ISUP networks in which overlap dialing 271 is used will implement timers to insure that all digits have been 272 collected before an INVITE is transmitted to a SIP network. 274 In some instances, gateways may receive incomplete ISUP messages 275 which indicate message segmentation due to excessive message length. 276 Commonly these messages will be followed by a Segmentation Message 277 (SGM) containing the remainder of the original ISUP message. An 278 incomplete message may not contain sufficient parameters to allow for 279 a proper mapping to SIP; similarly, encapsulating (see below) an 280 incomplete ISUP message may be confusing to terminating gateways. 281 Consequently, a gateway must wait until a complete ISUP message is 282 received (which may involve waiting until one or more SGMs arrive) 283 before sending any corresponding INVITE. 285 4. SIP Mechanisms Required 287 For a correct mapping between ISUP and SIP, some SIP mechanisms above 288 and beyond those available in the base SIP specification are needed. 289 These mechanisms are discussed below. If the SIP UAC/UAS involved in 290 the call does not support them, it is still possible to proceed, but 291 the behavior in the establishment of the call may be slightly 292 different than that expected by the user (e.g. other party answers 293 before receiving the ringback tone, user is not informed about the 294 call being forwarded, etc.). 296 4.1 'Transparent' Transit of ISUP Messages 298 To provide users the ability to take advantage of the full range of 299 services afforded by the existing telephone network when placing 300 calls from PSTN to PSTN across a SIP network, SIP messages will need 301 to carry ISUP payloads from gateway to gateway. The format for 302 carrying these messages is defined in [2]. 304 SIP clients and servers which do not understand ISUP are permitted to 305 ignore these (and other) optional MIME bodies. 307 4.2 Understanding MIME Multipart Bodies 309 In most PSTN interworking situations, the SIP body will be required 310 to carry session information (SDP) in addition to ISUP and/or billing 311 information. 313 PSTN interworking nodes should understand the MIME type of 314 "multipart/mixed" as defined in RFC2046 [3]. Clients express support 315 for this by including "multipart/mixed" in an "Accept" header. 317 4.3 Transmission of DTMF Information 319 Since the codec selected for voice transmission may not be ideally 320 suited for carrying DTMF information, a symbolic method of 321 transmitting this information in-band is desirable (since out-of-band 322 transmission alone would provide many challenges for synchronization 323 of the media stream for tone re-insertion). This transmission should 324 be performed as described in RFC2833 [4] and is in all respects 325 orthogonal to the mapping of ISUP and SIP. 327 4.4 Reliable Transmission of Provisional Responses 329 Provisional responses are used in the transmission of call progress 330 information. PSTN interworking in particular relies on these 331 messages for control of the media channel and timing of messages. 333 PSTN interworking should occur over a reliable transport layer end- 334 to-end. One application-layer provisional reliability mechanism is 335 described in [16]. 337 4.5 Provisional Media Streams 339 To allow the transmission of messages and tones before a final 340 connection has been established, SIP nodes which interwork with the 341 PSTN need to be able to establish temporary media connections during 342 this period. 344 MGCs should support the establishment of temporary provisional media 345 streams using the 183 status code (described in [1]). A more 346 detailed analysis of the problem of early media is given in [18]. 348 4.6 Mid-Call Transactions which do not change SIP state 350 When interworking with PSTN, there are situations when PSTN nodes 351 will need to send messages which do not correspond to any SIP 352 operations to each other across a SIP network. 354 The method for performing this transit will be in the INFO method, 355 defined in RFC2976 [5]. 357 Nodes which do serve as PSTN interworking points should accept "405 358 Method Not Allowed" and "501 Not Implemented" responses to INFO 359 requests as non-fatal. 361 5. Mapping 363 The mapping between ISUP and SIP is described using call flow 364 diagrams and state machines. One state machine handles calls from 365 SIP to ISUP and the second from ISUP to SIP. There are details, such 366 as some retransmissions and some states (waiting for RLC, waiting for 367 ACK etc.), that are not shown in the figures in order to make them 368 easier to follow. 370 The boxes represent the different states of the gateway, and the 371 arrows show changes in the state. The event that triggers the change 372 in the state and the actions to take appear on the arrow: event / 373 section describing the actions to take. 375 For example, `INVITE / 6.2.1' indicates that an INVITE request has 376 been received by the gateway, and the procedure upon reception is 377 described in the section 6.2.1 of this document. 379 6. SIP to ISUP Mapping 381 6.1 Call flows 383 The following call flows illustrate the order of messages in typical 384 success and error cases when setting up a call initiated from the SIP 385 network. "100 Trying" acknowledgements to INVITE requests are not 386 displayed below although they are required in many architectures. 388 In these diagrams, all call signaling (SIP, ISUP) is going to and 389 from the MGC; media handling (e.g. audio cut-through, trunk freeing) 390 is being performed by the MG, under the control of the MGC. For the 391 purpose of simplicity, these are shown as a single node, labeled 392 "MGC/MG." 394 6.1.1 En-bloc Call Setup (no auto-answer) 396 SIP MGC/MG PSTN 397 1|---------INVITE---------->| | 398 |<----------100------------| | 399 | |------------IAM---------->|2 400 | |<=========Audio===========| 401 | |<-----------ACM-----------|3 402 4|<----------18x------------| | 403 |<=========Audio===========| | 404 | |<-----------CPG-----------|5 405 6|<----------18x------------| | 406 | |<-----------ANM-----------|7 407 | |<=========Audio==========>| 408 8|<----------200------------| | 409 |<=========Audio==========>| | 410 9|-----------ACK----------->| | 412 1. When a SIP user wishes to begin a session with a PSTN user, the 413 SIP node issues an INVITE request. 415 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 416 message and sends it to the ISUP network. 418 3. The remote ISUP node indicates that the address is sufficient to 419 set up a call by sending back an ACM message. 421 4. The "called party status" code in the ACM message is mapped to a 422 SIP provisional response (as described in Section 6.2.5 and 423 Section 6.2.6). and returned to the SIP node. This response may 424 contain SDP to establish an early media stream (as shown in the 425 diagram). If no SDP is present, the audio will be established in 426 both directions after step 12. 428 5. If the ISUP variant permits, the remote ISUP node may issue a 429 variety of CPG messages to indicate, for example, that the call 430 is being forwarded. 432 6. Upon receipt of a CPG message, the gateway will map the event 433 code to a SIP provisional response (see Section 6.2.9) and send 434 it to the SIP node. 436 7. Once the PSTN user answers, an ANM message will be sent to the 437 gateway. 439 8. Upon receipt of the ANM, the gateway will send a 200 message to 440 the SIP node. 442 9. The SIP node, upon receiving an INVITE final response (200), will 443 send an ACK to acknowledge receipt. 445 6.1.2 Auto-answer call setup 447 SIP MGC/MG PSTN 448 1|---------INVITE---------->| | 449 |<----------100------------| | 450 | |------------IAM---------->|2 451 | |<=========Audio===========| 452 | |<-----------CON-----------|3 453 | |<=========Audio==========>| 454 4|<----------200------------| | 455 |<=========Audio==========>| | 456 5|-----------ACK----------->| | 458 Note that this flow is not supported in ANSI networks. 460 1. When a SIP user wishes to begin a session with a PSTN user, the 461 SIP node issues an INVITE request. 463 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 464 message and sends it to the ISUP network. 466 3. Since the remote node is configured for automatic answering, it 467 will send a CON message upon receipt of the IAM. (For ANSI, this 468 message will be an ANM). 470 4. Upon receipt of the CON, the gateway will send a 200 message to 471 the SIP node. 473 5. The SIP node, upon receiving an INVITE final response (200), will 474 send an ACK to acknowledge receipt. 476 6.1.3 ISUP T7 Expires 478 SIP MGC/MG PSTN 479 1|---------INVITE---------->| | 480 |<----------100------------| | 481 | |------------IAM---------->|2 482 | |<=========Audio===========| 483 | | *** T7 Expires *** | 484 | ** MG Releases PSTN Trunk ** | 485 4|<----------504------------|------------REL---------->|3 486 5|-----------ACK----------->| | 488 1. When a SIP user wishes to begin a session with a PSTN user, the 489 SIP node issues an INVITE request. 491 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 492 message and sends it to the ISUP network. The ISUP timer T7 is 493 started at this point. 495 3. The ISUP timer T7 expires before receipt of an ACM or CON 496 message, so a REL message is sent to cancel the call. 498 4. A gateway timeout message is sent back to the SIP node. 500 5. The SIP node, upon receiving an INVITE final response (504), will 501 send an ACK to acknowledge receipt. 503 6.1.4 SIP Timeout 505 SIP MGC/MG PSTN 506 1|---------INVITE---------->| | 507 |<----------100------------| | 508 | |------------IAM---------->|2 509 | |<=========Audio===========| 510 | |<-----------CON-----------|3 511 | |<=========Audio==========>| 512 4|<----------200------------| | 513 | *** T1 Expires *** | | 514 |<----------200------------| | 515 | *** T1 Expires *** | | 516 |<----------200------------| | 517 | *** T1 Expires *** | | 518 |<----------200------------| | 519 | *** T1 Expires *** | | 520 |<----------200------------| | 521 | *** T1 Expires *** | | 522 |<----------200------------| | 523 | *** T1 Expires *** | | 524 5|<----------200------------| | 525 | *** T1 Expires *** | | 526 | ** MG Releases PSTN Trunk ** | 527 7|<----------BYE------------|------------REL---------->|6 528 | |<-----------RLC-----------|8 530 1. When a SIP user wishes to begin a session with a PSTN user, the 531 SIP node issues an INVITE request. 533 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 534 message and sends it to the ISUP network. 536 3. Since the remote node is configured for automatic answering, it 537 will send a CON message upon receipt of the IAM. In ANSI flows, 538 rather than a CON an ANM (without ACM) would be sent. 540 4. Upon receipt of the ANM, the gateway will send a 200 message to 541 the SIP node and set SIP timer T1. 543 5. The response is retransmitted every time the SIP timer T1 544 expires. 546 6. After seven retransmissions, the call is torn down by sending a 547 REL to the ISUP node, with a cause code of 102 (recover on timer 548 expiry). 550 7. A BYE is transmitted to the SIP node in an attempt to close the 551 call. Further handling for this clean up is not shown, since the 552 SIP node's state is not easily known in this scenario. 554 8. Upon receipt of the REL message, the remote ISUP node will reply 555 with an RLC message. 557 6.1.5 ISUP Setup Failure 559 SIP MGC/MG PSTN 560 1|---------INVITE---------->| | 561 |<----------100------------| | 562 | |------------IAM---------->|2 563 | |<-----------REL-----------|3 564 | |------------RLC---------->|4 565 5|<----------4xx+-----------| | 566 6|-----------ACK----------->| | 568 1. When a SIP user wishes to begin a session with a PSTN user, the 569 SIP node issues an INVITE request. 571 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 572 message and sends it to the ISUP network. 574 3. Since the remote ISUP node is unable to complete the call, it 575 will send a REL. 577 4. The gateway releases the circuit and confirms that it is 578 available for reuse by sending an RLC. 580 5. The gateway translates the cause code in the REL to a SIP error 581 response (see Section 6.2.4) and sends it to the SIP node. 583 6. The SIP node sends an ACK to acknowledge receipt of the INVITE 584 final response. 586 6.1.6 Cause Present in ACM Message 588 SIP MGC/MG PSTN 589 1|---------INVITE---------->| | 590 |<----------100------------| | 591 | |------------IAM---------->|2 592 | |<=========Audio===========| 593 | |<---ACM with cause code---|3 594 4|<------183 with SDP-------| | 595 |<=========Audio===========| | 596 ** Interwork timer expires ** 597 5|<----------4xx+-----------| | 598 | |------------REL---------->|6 599 | |<-----------RLC-----------|7 600 8|-----------ACK----------->| | 602 1. When a SIP user wishes to begin a session with a PSTN user, the 603 SIP node issues an INVITE request. 605 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 606 message and sends it to the ISUP network. 608 3. Since the ISUP node is unable to complete the call and wants to 609 generate the error tone/announcement itself, it sends an ACM with 610 a cause code. The gateway starts an interwork timer. 612 4. Upon receipt of an ACM with cause (presence of the CAI 613 parameter), the gateway will generate a 183 message towards the 614 SIP node; this contains SDP to establish early media cut-through. 616 5. A final INVITE response, based on the cause code received in the 617 earlier ACM message, is generated and sent to the SIP node to 618 terminate the call. See Section 6.2.4.1 for the table which 619 contains the mapping from cause code to SIP response. 621 6. Upon expiration of the interwork timer, a REL is sent towards the 622 PSTN node to terminate the call. Note that the SIP node can also 623 terminate the call by sending a CANCEL before the interwork timer 624 expires. In this case, the signaling progresses as in Section 625 6.1.7. 627 7. Upon receipt of the REL message, the remote ISUP node will reply 628 with an RLC message. 630 8. The SIP node sends an ACK to acknowledge receipt of the INVITE 631 final response. 633 6.1.7 Call Canceled by SIP 635 SIP MGC/MG PSTN 636 1|---------INVITE---------->| | 637 |<----------100------------| | 638 | |------------IAM---------->|2 639 | |<=========Audio===========| 640 | |<-----------ACM-----------|3 641 4|<----------18x------------| | 642 |<=========Audio===========| | 643 | ** MG Releases IP Resources ** | 644 5|----------CANCEL--------->| | 645 6|<----------200------------| | 646 | ** MG Releases PSTN Trunk ** | 647 | |------------REL---------->|7 648 8|<----------487------------| | 649 | |<-----------RLC-----------|9 650 10|-----------ACK----------->| | 652 1. When a SIP user wishes to begin a session with a PSTN user, the 653 SIP node issues an INVITE request. 655 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 656 message and sends it to the ISUP network. 658 3. The remote ISUP node indicates that the address is sufficient to 659 set up a call by sending back an ACM message. 661 4. The "called party status" code in the ACM message is mapped to a 662 SIP provisional response (as described in Section 6.2.5 and 663 Section 6.2.6) and returned to the SIP node. This response may 664 contain SDP to establish an early media stream. 666 5. To cancel the call before it is answered, the SIP node sends a 667 CANCEL request. 669 6. The CANCEL request is confirmed with a 200 response. 671 7. Upon receipt of the CANCEL request, the gateway sends a REL 672 message to terminate the ISUP call. 674 8. The gateway sends a "487 Call Cancelled" message to the SIP node 675 to complete the INVITE transaction. 677 9. Upon receipt of the REL message, the remote ISUP node will reply 678 with an RLC message. 680 10. Upon receipt of the 487, the SIP node will confirm reception 681 with an ACK. 683 6.2 State Machine 685 Note that REL can be received in any state; the handling is the same 686 for each case (see Section 9). 688 +---------+ 689 +----------------------->| Idle |<---------------------+ 690 | +----+----+ | 691 | | | 692 | | INVITE/6.2.1 | 693 | V | 694 | T7/6.2.2 +-------------------------+ REL/6.2.4 | 695 +<----------------+ Trying +------------>+ 696 | +-+--------+------+-------+ | 697 | CANCEL/6.2.3 | | | | | 698 +<----------------+ | E.ACM/ | ACM/ | CON/ | 699 | | 6.2.5 |6.2.6 | 6.2.7 | 700 | V | | | 701 | T9/6.2.8 +--------------+ | | | 702 +<----------+ Not alerting | | | | 703 | +-------+------+ | | | 704 | CANCEL/6.2.3 | | | | | 705 |<--------------+ | CPG/ | | | 706 | | 6.2.9 | | | 707 | V V | | 708 | T9/6.2.8 +---------------+ | REL/6.2.4 | 709 +<----------------+ Alerting |-|-------------------->| 710 |<----------------+--+-----+------+ | | 711 | CANCEL/6.2.3 | ^ | | | 712 | CPG/ | | | ANM/ | | 713 | 6.2.9 +--+ | 6.2.7 | | 714 | V V | 715 | +-------------------------+ REL/9.2 | 716 | | Waiting for ACK |------------>| 717 | +-------------+-----------+ | 718 | | | 719 | | ACK/6.2.10 | 720 | V | 721 | BYE/9.1 +-------------------------+ REL/9.2 | 722 +<----------------+ Connected +------------>+ 723 +-------------------------+ 725 6.2.1 INVITE received 727 When an INVITE request is received by the gateway, a "100 Trying" 728 response should be sent back to the SIP network indicating that the 729 MGC is handling the call. 731 The resources for the media stream have to be reserved at this stage, 732 since an IAM message cannot be sent before the resource reservation 733 takes place. Typically the resources consist of a time slot in an 734 E1/T1 and an RTP/UDP port on the IP side. Resources might also 735 include QoS or/and security provisions. Before sending the IAM the 736 MG generally connects the backward media path. 738 After sending the IAM the timer T7 is started. The default value of 739 T7 is between 20 and 30 seconds. The MGC goes to the `Trying' state. 741 6.2.1.1 INVITE to IAM procedures 743 This section details the mapping of the SIP headers in an INVITE 744 message to the ISUP parameters in an IAM. 746 Five mandatory parameters appear within the IAM message: the Called 747 Party Number (CPN), the Nature of Connection Indicator (NCI), the 748 Forward Call Indicators (FCI), the Calling Party's Category (CPC), 749 and finally a parameter that indicates the desired bearer 750 characteristics of the call - in some ISUP variants the Transmission 751 Medium Requirement (TMR) is required, in others the User Service 752 Information (USI) (or both). 754 There are quite a few optional parameters that can appear in an IAM 755 message; Q.763 [15] lists 29 in all. However, each of these 756 parameters need not to be translated in order to achieve the goals of 757 SIP-ISUP mapping. As is stated above, translation allows SIP network 758 elements to understand the PSTN context of the session if they are 759 not capable of deciphering any encapsulated ISUP. Parameters that 760 are only meaningful to the PSTN will be carried through PSTN-SIP- 761 PSTN networks via encapsulation - translation is not necessary for 762 these parameters. Of the aforementioned 29 optional parameters, only 763 the following are immediately useful for translation: the Calling 764 Party's Number (CIN, which is commonly present), Transit Network 765 Selection (TNS), Carrier Identification Parameter (CIP, present in 766 ANSI networks), Original Called Number (OCN), and the Generic Digits 767 (known in some variants as the Generic Address Parameter (GAP)). 769 When a SIP INVITE arrives at a PSTN gateway, the gateway should 770 attempt to make use of any encapsulated ISUP (see [2]) to assist in 771 the formulation of outbound PSTN signaling. However, three 772 conditions can complicate this process: 774 o There is no ISUP encapsulated in the SIP INVITE - the SIP INVITE 775 originated at a device other than an ISUP-SIP gateway. 777 o There is encapsulated ISUP, but the gateway cannot understand the 778 ISUP variant and therefore the ISUP must be discarded. 780 o There is encapsulated ISUP, but there is more recent session 781 context information available in the SIP headers, and consequently 782 the SIP headers must 'overwrite' the encapsulated ISUP. 784 In all of these cases translation must be performed. Gateways should 785 use default values for mandatory ISUP parameters that are not derived 786 from translation or encapsulation (such as the NCI or TMR 787 parameters). The FCI parameter should also have a default, although 788 its 'M' bit may be overwritten during the process of translation. 790 First, the Request-URI should be inspected. 792 If there is no 'npdi=yes' field within the Request-URI, then the main 793 telephone number in the tel URL (the digits immediately following 794 'tel:') should be converted to ISUP format, following the procedure 795 described in Section 11, and used to populate the CPN parameter. 797 In ANSI networks, if the 'npdi=yes' field exists in the Request-URI, 798 then the FCI parameter bit for 'number translated' within the IAM 799 should reflect that a number portability dip has been performed. 801 If in addition to the 'npdi=yes' field there is no 'rn=' field 802 present, then the main telephone number in the tel URL should be 803 converted to ISUP format (see Section 11) and used to populate the 804 CPN parameter. 806 If in addition to the 'npdi=yes' field an 'rn=' field is present, 807 then in ANSI networks the 'rn=' field should be converted to ISUP 808 format and used to populate the CPN. The main telephone number in 809 the tel URL should be converted to ISUP format and used to populate 810 the Generic Digits Parameter (or GAP in ANSI). In some networks the 811 number given in the 'rn=' field should be prepended to the main 812 telephone number and the combined result should be used to populate 813 the CPN. 815 If main telephone number in the Request-URI and that of the To header 816 are at variance, then the To header should be used to populate an OCN 817 parameter. Otherwise the To header should be ignored. 819 If the 'cic=' parameter is present in the Request-URI, the gateway 820 should consult local policy to make sure that it is appropriate to 821 transmit this Carrier Identification Code in the IAM. If the gateway 822 supports many independent trunks, it may need to choose a particular 823 trunk that points to the carrier identified by the CIC, or a tandem 824 through which that carrier is reachable. Policies for such trunks 825 (based on the preferences of the carriers with which the trunks are 826 associated) may dictate whether the CIP or TNS parameter should be 827 used (although note that in non-ANSI networks the CIP will never be 828 used). In the absence of any pre-arranged policies, the TNS should 829 be used when the CPN parameter is in an international format (i.e. 830 the NoA field of the CPN indicates that this is an international 831 number), and the CIP should be used in other cases. 833 If a SIP call has arrived at a gateway, then the Request-URI will 834 most likely contain a tel URL (or a SIP URI with a tel URL user 835 portion). However, if the call originated at a native IP endpoint 836 such as a SIP phone, the From field may not reflect any telephone 837 number - it may be a simple user@host construction. The CIN 838 parameter should be omitted from the outbound IAM if the From field 839 is unusable. 841 Note that when the ISUP parameters regarding interworking are set in 842 the Forward Call Indicators (FCI) parameter of the IAM , this 843 indicates that ISDN is interworking with a network which is not 844 capable of providing as many services as ISDN does. ISUP will 845 therefore not employ certain features it otherwise normally uses. 847 Thus, `interworking encountered' must not be specified so that ISUP 848 behaves normally. SIP is considered as an SS7 network and a SIP 849 phone is considered as ISDN access since the SIP network is supposed 850 to provide at least as many services as ISUP. 852 Claiming to be an ISDN node might make the callee request ISDN user 853 to user services. Since user to user services 1 and 2 must be 854 requested by the caller, they do not represent a problem (see [12]). 855 User to user service 3 can be requested by the callee also. In non- 856 SIP bridging situations, the MGC should be capable of rejecting this 857 service request. 859 6.2.2 ISUP T7 expires 861 Since no response was received from the PSTN all the resources in the 862 MG are released. A `504 gateway timeout' is sent back to the SIP 863 network. A REL message with cause value 102 (protocol error, 864 recovery on timer expiry) is sent to the PSTN. The PSTN responds 865 with RLC and the SIP network responds with an ACK indicating that the 866 release sequence has been completed. 868 6.2.3 CANCEL or BYE received 870 If a CANCEL or BYE request is received, a `200 OK' is sent to the SIP 871 network to confirm the CANCEL or BYE; a 487 is also sent to terminate 872 the INVITE transaction. All the resources are released and a REL 873 message is sent to the PSTN with cause value 16 (normal clearing). A 874 RLC from the PSTN is received indicating that the release sequence is 875 complete. 877 It is important that all the resources are released before the 878 gateway sends any REL message. 880 In SIP bridging situations, a REL might arrive in the CANCEL or BYE 881 request body. This REL is sent to the PSTN. 883 This applies when a CANCEL or a BYE is received before a final SIP 884 response has been sent. 886 6.2.4 REL received 888 This section applies every time that a REL is received before a final 889 SIP response has been sent. 891 The resources are released in the MG and a RLC is sent to the ISUP 892 network to indicate that the circuit is available for reuse. 894 If the INVITE originating this transaction contained an ISUP message 895 in its body (such as an IAM), the MGC is handling a SIP bridging 896 situation. Therefore, the REL message just received should be 897 included in the body of the response. 899 Note that the receipt of certain maintenance messages in response to 900 IAM such as BLO or RSC (or their circuit group message equivalents) 901 may also result in the teardown of calls in this phase of the state 902 machine. Behavior for maintenance messages is given below in Section 903 10. 905 6.2.4.1 ISDN Cause Code to Status Code Mapping 907 In addition to the ISDN Cause Code, the CAI parameter also contains a 908 cause 'location' that gives some sense of which entity in the network 909 was responsible for terminating the call (the most important 910 distinction being between the user and the network). In most cases, 911 the cause location does not affect the mapping to a SIP status code; 912 some exceptions are noted below. A diagnostic field may also be 913 present for some ISDN causes; this diagnostic will contain additional 914 data pertaining to the termination of the call. 916 The use of the REL message in the SS7 network is very general, 917 whereas SIP has a number of specific tools that, collectively, play 918 the same role as REL - namely BYE, CANCEL, and the status codes. An 919 REL can be sent to tear down a call that is already in progress 920 (BYE), to cancel a previously sent call setup request (IAM) that has 921 not yet been completed (CANCEL), or to reject a call setup request 922 (IAM) that has just been received (corresponding to a SIP status 923 code). 925 If a cause value other than what is listed below is received, the 926 default response `500 Server internal error' would be used. 928 Note that it is not necessarily appropriate to map some ISDN cause 929 codes to SIP messages because these cause codes are only meaningful 930 to the ISUP interface of a gateway. A good example of this is cause 931 code 44 "Request circuit or channel not available." 44 signifies that 932 the Circuit Identification Code (CIC) for which an IAM had been sent 933 was believed by the receiving equipment to be in a state incompatible 934 with a new call request - however, the appropriate behavior in this 935 case is for the originating switch to re-send the IAM for a different 936 CIC, not for the call to be torn down. Clearly, there is not (nor 937 should there be) an SIP status code indicating that a new CIC should 938 be selected - this matter is internal to the originating gateway. 939 Hence receipt of cause code 44 should not result in any SIP status 940 code being sent; effectively, the cause code is untranslatable. 942 Normal event 944 ISUP Cause value SIP response 945 ---------------- ------------ 946 1 unallocated number 404 Not Found 947 2 no route to network 404 Not found 948 3 no route to destination 404 Not found 949 16 normal call clearing --- (*) 950 17 user busy 486 Busy here 951 18 no user responding 408 Request Timeout 952 19 no answer from the user 480 Temporarily unavailable 953 20 subscriber absent 480 Temporarily unavailable 954 21 call rejected 403 Forbidden (+) 955 22 number changed (w/o diagnostic) 410 Gone 956 22 number changed (w/ diagnostic) 301 Moved Permanently 957 23 redirection to new destination 302 Moved Temporarily 958 26 non-selected user clearing 404 Not Found (=) 959 27 destination out of order 502 Bad Gateway 960 28 address incomplete 484 Address incomplete 961 29 facility rejected 501 Not implemented 962 31 normal unspecified 480 Temporarily unavailable 964 (*) ISDN Cause 16 will usually result in a BYE or CANCEL 966 (+) If the cause location is 'user' than the 6xx code could be given 967 rather than the 4xx code (i.e. 403 becomes 603) 969 (=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 970 'misrouted ported number'. Presumably, a number portability dip 971 should have been performed by a prior network. 973 A REL with ISDN cause 22 (number changed) might contain information 974 about a new number where the callee might be reachable in the 975 diagnostic field. If the MGC is able to parse this information it 976 might be added to the SIP response (301) in a Contact header. 978 Resource unavailable 980 This kind of cause value indicates a non permanent situation. A 981 `Retry-After' header may be added to the response. 983 ISUP Cause value SIP response 984 ---------------- ------------ 985 34 no circuit available 503 Service unavailable 986 38 network out of order 503 Service unavailable 987 41 temporary failure 503 Service unavailable 988 42 switching equipment congestion 503 Service unavailable 989 47 resource unavailable 503 Service unavailable 991 Service or option not available 993 This kind of cause value indicates a permanent situation. 995 ISUP Cause value SIP response 996 ---------------- ------------ 997 55 incoming calls barred within CUG 403 Forbidden 998 57 bearer capability not authorized 403 Forbidden 999 58 bearer capability not presently 503 Service unavailable 1000 available 1002 Service or option not available 1004 ISUP Cause value SIP response 1005 ---------------- ------------ 1006 65 bearer capability not implemented 501 Not implemented 1007 79 service or option not implemented 501 Not implemented 1009 Invalid message 1010 ISUP Cause value SIP response 1011 ---------------- ------------ 1012 87 user not member of CUG 503 Service unavailable 1013 88 incompatible destination 503 Service unavailable 1014 95 invalid message 503 Service unavailable 1016 Protocol error 1018 ISUP Cause value SIP response 1019 ---------------- ------------ 1020 102 recovery of timer expiry 504 Gateway timeout 1021 111 protocol error 500 Server internal error 1023 Interworking 1025 ISUP Cause value SIP response 1026 ---------------- ------------ 1027 127 interworking unspecified 500 Server internal error 1029 6.2.5 Early ACM received 1031 This message is sent in certain situations for resetting the timers. 1032 In these cases this message indicates that the call is in progress 1033 but callee is not being alerted. This occurs for example in mobile 1034 networks, where roaming can take a long time. The early ACM is sent 1035 before the user is alerted to reset T7 and start T9. 1037 An ACM is considered an `early ACM' if the Called Party's Status 1038 Indicator is set to 00 (no indication). 1040 After receiving an early ACM the progress of the call is indicated by 1041 the network sending CPGs. 1043 When there is interworking with some old systems, it is possible to 1044 receive an ANM immediately after an early ACM (without CPG). In this 1045 situation the SIP user will not hear any kind of ringback tone before 1046 the callee answers. In ISDN (see [10]) this is solved by connecting 1047 the voice path backwards before sending the IAM. 1049 The MGC sends a 183 Session Progress (see [1]) to the SIP network 1050 with a media description inside. In SIP bridging situations the 1051 early ACM is included in the response body. Thus, the problem of 1052 missing the ring back tone is solved and the early ACM is transported 1053 transparently through the SIP network. 1055 6.2.6 ACM received 1057 Upon reception of an ACM, in many networks timer T9 is started. T9 1058 typically lasts between 90 seconds and 3 minutes (see [11]) . It 1059 allows the caller to hear announcements from the network for that 1060 period of time without being charged for the connection. If longer 1061 announcements have to be played the network has to send an ANM. When 1062 the ANM is sent the call begins being charged. Some networks do not 1063 support timer T9. 1065 The nearest local exchange to the callee generates the ringback tone 1066 and may send voice announcements. 1068 Usually on receipt of an ACM a `180 Ringing' is sent to the SIP 1069 network. It should generally contain a session description in order 1070 to allow SIP UAs to prevent clipping of initial callee media. The 1071 ringback tone or the proper announcements will be generated by the 1072 PSTN exchange, and not by the callers SIP UAC/UAS. 1074 If the Backwards Call Indicator (BCI) parameter of the ACM indicates 1075 that interworking has been encountered (generally designating that 1076 the ISUP network sending the ACM is interworking with a less 1077 sophisticated network which cannot support cause codes), then there 1078 may be in-band announcements of call status such as an audible busy 1079 tone or caller intercept message. In this case rather than a 180 1080 status code, a 183 Session Progress message should be sent in order 1081 to allow pre-ANM media to flow in the backwards direction. 1083 In SIP bridging situations, the ACM is included in the body of the 1084 180 response. 1086 6.2.7 CON or ANM Received 1088 A `200 OK' response is sent to the SIP network. In SIP bridging 1089 situations, the ISUP message is included in the body of the 200 OK 1090 response. This is also the point at which a two-way media stream 1091 will be established. 1093 6.2.8 Timer T9 Expires 1095 This indicates that the ANM has not arrived in time specified. This 1096 results in the call being aborted. All the resources related to the 1097 media path are released. A `480 temporarily unavailable' is sent to 1098 the SIP network. A REL message with cause value 19 (no answer from 1099 the user) is sent to the ISUP part. The PSTN responds with RLC and 1100 the SIP network responds with an ACK indicating that the release 1101 sequence has been completed. 1103 6.2.9 CPG Received 1105 A CPG can indicate progress, alerting or in-band information. If the 1106 CPG comes after an ACM, there is already a one-way voice path open, 1107 so there is no need of taking further action in the media path. 1109 In SIP bridging situations, the CPG is sent in the body of a 18x 1110 response, determined from the CPG event code. 1112 ISUP event code SIP response 1113 ---------------- ------------ 1114 1 Alerting 180 Ringing 1115 2 Progress 183 Call progress 1116 3 In-band information 183 Call progress 1117 4 Call forward; line busy 181 Call is being forwarded 1118 5 Call forward; no reply 181 Call is being forwarded 1119 6 Call forward; unconditional 181 Call is being forwarded 1120 - (no event code present) 183 Call progress 1122 Note that, if the CPG does not indicate "Alerting," the current state 1123 will not change. 1125 6.3 ACK received 1127 At this stage, the call is connected and the conversation can take 1128 place. 1130 7. ISUP to SIP Mapping 1132 7.1 Call Flows 1134 The following call flows illustrate the order of messages in typical 1135 success and error cases when setting up a call initiated from the 1136 PSTN network. "100 Trying" acknowledgements to INVITE requests are 1137 not explained, since their presence is optional. 1139 In these diagrams, all call signaling (SIP, ISUP) is going to and 1140 from the MGC; media handling (e.g. audio cut-through, trunk freeing) 1141 is being performed by the MG, under the control of the MGC. For the 1142 purpose of simplicity, these are shown as a single node, labeled 1143 "MGC/MG." 1145 7.1.1 En-bloc call setup (non auto-answer) 1147 SIP MGC/MG PSTN 1148 | |<-----------IAM-----------|1 1149 | |==========Audio==========>| 1150 2|<--------INVITE-----------| | 1151 |-----------100----------->| | 1152 3|-----------18x----------->| | 1153 |==========Audio==========>| | 1154 | |=========================>| 1155 | |------------ACM---------->|4 1156 5|-----------18x----------->| | 1157 | |------------CPG---------->|6 1158 7|-----------200-(I)------->| | 1159 |<=========Audio==========>| | 1160 | |------------ANM---------->|8 1161 | |<=========Audio==========>| 1162 9|<----------ACK------------| | 1164 1. When a PSTN user wishes to begin a session with a SIP user, the 1165 PSTN network generates an IAM message towards the gateway. 1167 2. Upon receipt of the IAM message, the gateway generates an INVITE 1168 message, and sends it to an appropriate SIP node. 1170 3. When an event signifying that the call has sufficient addressing 1171 information occurs, the SIP node will generate a provisional 1172 response of 180 or greater. 1174 4. Upon receipt of a provisional response of 180 or greater, the 1175 gateway will generate an ACM message. If the response is not 1176 180, the ACM will carry a "called party status" value of "no 1177 indication." 1179 5. The SIP node may use further provisional messages to indicate 1180 call progress. 1182 6. After an ACM has been sent, all provisional responses will 1183 translate into ISUP CPG messages as indicated in Section 7.2.3. 1185 7. When the SIP node answers the call, it will send a 200 OK 1186 message. 1188 8. Upon receipt of the 200 OK message, the gateway will send an ANM 1189 message towards the ISUP node. 1191 9. The gateway will send an ACK to the SIP node to acknowledge 1192 receipt of the INVITE final response. 1194 7.1.2 Auto-answer call setup 1196 SIP MGC/MG PSTN 1197 | |<-----------IAM-----------|1 1198 | |==========Audio==========>| 1199 2|<--------INVITE-----------| | 1200 3|-----------200----------->| | 1201 |<=========Audio==========>| | 1202 | |------------CON---------->|4 1203 | |<=========Audio==========>| 1204 5|<----------ACK------------| | 1206 1. When a PSTN user wishes to begin a session with a SIP user, the 1207 PSTN network generates an IAM message towards the gateway. 1209 2. Upon receipt of the IAM message, the gateway generates an INVITE 1210 message, and sends it to an appropriate SIP node based on called 1211 number analysis. 1213 3. Since the SIP node is set up to automatically answer the call, it 1214 will send a 200 OK message. 1216 4. Upon receipt of the 200 OK message, the gateway will send a CON 1217 message towards the ISUP node. 1219 5. The gateway will send an ACK to the SIP node to acknowledge 1220 receipt of the INVITE final response. 1222 7.1.3 SIP Timeout 1224 SIP MGC/MG PSTN 1225 | |<-----------IAM-----------|1 1226 | |==========Audio==========>| 1227 2|<--------INVITE-----------| | 1228 | *** T1 Expires *** | | 1229 3|<--------INVITE-----------| | 1230 | *** T1 Expires *** | | 1231 |<--------INVITE-----------| | 1232 | | *** T11 Expires *** | 1233 | |------------ACM---------->|4 1234 | *** T1 Expires *** | | 1235 |<--------INVITE-----------| | 1236 | *** T1 Expires *** | | 1237 |<--------INVITE-----------| | 1238 | *** T1 Expires *** | | 1239 |<--------INVITE-----------| | 1240 | *** T1 Expires *** | | 1241 |<--------INVITE-----------| | 1242 | *** T1 Expires *** | | 1243 | ** MG Releases PSTN Trunk ** | 1244 | |------------REL---------->|5 1245 6|<--------CANCEL-----------| | 1246 | |<-----------RLC-----------|7 1248 1. When a PSTN user wishes to begin a session with a SIP user, the 1249 PSTN network generates an IAM message towards the gateway. 1251 2. Upon receipt of the IAM message, the gateway generates an INVITE 1252 message, and sends it to an appropriate SIP node based on called 1253 number analysis. The ISUP timer T11 and SIP timer T1 are set at 1254 this time. 1256 3. The INVITE message will continue to be sent to the SIP node each 1257 time the timer T1 expires. The SIP standard specifies that 1258 INVITE transmission will be performed 7 times if no response is 1259 received. 1261 4. When T11 expires, an ACM message will be sent to the ISUP node to 1262 prevent the call from being torn down by the remote node's ISUP 1263 T7. This ACM contains a `Called Party Status' value of `no 1264 indication.' 1266 5. Once the maximum number of INVITE requests has been sent, the 1267 gateway will send a REL (cause code 18) to the ISUP node to 1268 terminate the call. 1270 6. The gateway also sends a CANCEL message to the SIP node to 1271 terminate any initiation attempts. 1273 7. Upon receipt of the REL, the remote ISUP node will send an RLC to 1274 acknowledge. 1276 7.1.4 ISUP T9 Expires 1278 SIP MGC/MG PSTN 1279 | |<-----------IAM-----------|1 1280 | |==========Audio==========>| 1281 2|<--------INVITE-----------| | 1282 | *** T1 Expires *** | | 1283 3|<--------INVITE-----------| | 1284 | *** T1 Expires *** | | 1285 |<--------INVITE-----------| | 1286 | | *** T11 Expires *** | 1287 | |------------ACM---------->|4 1288 | *** T1 Expires *** | | 1289 |<--------INVITE-----------| | 1290 | *** T1 Expires *** | | 1291 |<--------INVITE-----------| | 1292 | *** T1 Expires *** | | 1293 |<--------INVITE-----------| | 1294 | | *** T9 Expires *** | 1295 | ** MG Releases PSTN Trunk ** | 1296 | |<-----------REL-----------|5 1297 | |------------RLC---------->|6 1298 7|<--------CANCEL-----------| | 1300 1. When a PSTN user wishes to begin a session with a SIP user, the 1301 PSTN network generates an IAM message towards the gateway. 1303 2. Upon receipt of the IAM message, the gateway generates an INVITE 1304 message, and sends it to an appropriate SIP node based on called 1305 number analysis. The ISUP timer T11 and SIP timer T1 are set at 1306 this time. 1308 3. The INVITE message will continue to be sent to the SIP node each 1309 time the timer T1 expires. The SIP standard specifies that 1310 INVITE transmission will be performed 7 times if no response is 1311 received. Since SIP T1 starts at 1/2 second or more and doubles 1312 each time it is retransmitted, it will be at least a minute 1313 before SIP times out the INVITE request; since SIP T1 is allowed 1314 to be larger than 500 ms initially, it is possible that 7 x SIP 1315 T1 will be longer than ISUP T11 + ISUP T9. 1317 4. When T11 expires, an ACM message will be sent to the ISUP node to 1318 prevent the call from being torn down by the remote node's ISUP 1319 T7. This ACM contains a `Called Party Status' value of `no 1320 indication.' 1322 5. When ISUP T9 in the remote PSTN node expires, it will send a REL. 1324 6. Upon receipt of the REL, the gateway will send an RLC to 1325 acknowledge. 1327 7. The REL will trigger a CANCEL request, which gets sent to the SIP 1328 node. 1330 7.1.5 SIP Error Response 1332 SIP MGC/MG PSTN 1333 | |<-----------IAM-----------|1 1334 | |==========Audio==========>| 1335 2|<--------INVITE-----------| | 1336 3|-----------4xx+---------->| | 1337 4|<----------ACK------------| | 1338 | ** MG Releases PSTN Trunk ** | 1339 | |------------REL---------->|5 1340 | |<-----------RLC-----------|6 1342 1. When a PSTN user wishes to begin a session with a SIP user, the 1343 PSTN network generates an IAM message towards the gateway. 1345 2. Upon receipt of the IAM message, the gateway generates an INVITE 1346 message, and sends it to an appropriate SIP node based on called 1347 number analysis. 1349 3. The SIP node indicates an error condition by replying with a 1350 response with a code of 400 or greater. 1352 4. The gateway sends an ACK message to acknowledge receipt of the 1353 INVITE final response. 1355 5. An ISUP REL message is generated from the SIP code, as specified 1356 in Section 7.2.6.1. 1358 6. The remote ISUP node confirms receipt of the REL message with an 1359 RLC message. 1361 7.1.6 SIP Redirection 1363 SIP node 1 MGC/MG PSTN 1364 | |<-----------IAM-----------|1 1365 | |==========Audio==========>| 1366 2|<--------INVITE-----------| | 1367 3|-----------3xx+---------->| | 1368 | |------------CPG---------->|4 1369 5|<----------ACK------------| | 1370 | | 1371 | | 1372 SIP node 2 | | 1373 6|<--------INVITE-----------| | 1374 7|-----------18x----------->| | 1375 |<=========Audio===========| | 1376 | |------------ACM---------->|8 1377 9|-----------200-(I)------->| | 1378 |<=========Audio==========>| | 1379 | |------------ANM---------->|10 1380 | |<=========Audio==========>| 1381 11|<----------ACK------------| | 1383 1. When a PSTN user wishes to begin a session with a SIP user, the 1384 PSTN network generates an IAM message towards the gateway. 1386 2. Upon receipt of the IAM message, the gateway generates an INVITE 1387 message, and sends it to an appropriate SIP node based on called 1388 number analysis. 1390 3. The SIP node indicates that the resource which the user is 1391 attempting to contact is at a different location by sending a 1392 3xx message. In this instances we assume the Contact URL 1393 specifies a valid URL reachable by a VoIP SIP call. 1395 4. The gateway sends a CPG with event indication that the call is 1396 being forwarded upon receipt of the 3xx message. Note that this 1397 translation should be able to be disabled by configuration, as 1398 some ISUP nodes do not support receipt of CPG messages before 1399 ACM messages. 1401 5. The gateway acknowledges receipt of the INVITE final response by 1402 sending an ACK message to the SIP node. 1404 6. The gateway re-sends the INVITE message to the address indicated 1405 in the Contact: field of the 3xx message. 1407 7. When an event signifying that the call has sufficient addressing 1408 information occurs, the SIP node will generate a provisional 1409 response of 180 or greater. 1411 8. Upon receipt of a provisional response of 180 or greater, the 1412 gateway will generate an ACM message with an event code as 1413 indicated in Section 7.2.3. 1415 9. When the SIP node answers the call, it will send a 200 OK 1416 message. 1418 10. Upon receipt of the 200 OK message, the gateway will send an ANM 1419 message towards the ISUP node. 1421 11. The gateway will send an ACK to the SIP node to acknowledge 1422 receipt of the INVITE final response. 1424 7.1.7 Call Canceled by ISUP 1426 SIP MGC/MG PSTN 1427 | |<-----------IAM-----------|1 1428 | |==========Audio==========>| 1429 2|<--------INVITE-----------| | 1430 3|-----------18x----------->| | 1431 |==========Audio==========>| | 1432 | |------------ACM---------->|4 1433 | ** MG Releases PSTN Trunk ** | 1434 | |<-----------REL-----------|5 1435 | |------------RLC---------->|6 1436 7|<---------CANCEL----------| | 1437 | ** MG Releases IP Resources ** | 1438 8|-----------200----------->| | 1439 9|-----------487----------->| | 1440 10|<----------ACK------------| | 1442 1. When a PSTN user wishes to begin a session with a SIP user, the 1443 PSTN network generates an IAM message towards the gateway. 1445 2. Upon receipt of the IAM message, the gateway generates an INVITE 1446 message, and sends it to an appropriate SIP node based on called 1447 number analysis. 1449 3. When an event signifying that the call has sufficient addressing 1450 information occurs, the SIP node will generate a provisional 1451 response of 180 or greater. 1453 4. Upon receipt of a provisional response of 180 or greater, the 1454 gateway will generate an ACM message with an event code as 1455 indicated in Section 7.2.3. 1457 5. If the calling party hangs up before the SIP node answers the 1458 call, a REL message will be generated. 1460 6. The gateway frees the PSTN circuit and indicates that it is 1461 available for reuse by sending an RLC. 1463 7. Upon receipt of a REL message before an INVITE final response, 1464 the gateway will send a CANCEL towards the SIP node. 1466 8. Upon receipt of the CANCEL, the SIP node will send a 200 1467 response. 1469 9. The remote SIP node will send a "487 Call Cancelled" to complete 1470 the INVITE transaction. 1472 10. The gateway will send an ACK to the SIP node to acknowledge 1473 receipt of the INVITE final response. 1475 7.2 State Machine 1477 Note that REL may arrive in any state. Whenever this occurs, the 1478 actions in section Section 7.2.7. are taken. Not all of these 1479 transitions are shown in this diagram. 1481 +---------+ 1482 +----------------------->| Idle |<---------------------+ 1483 | +----+----+ | 1484 | | | 1485 | | IAM/7.2.1 | 1486 | V | 1487 | REL/7.2.7 +-------------------------+ 400+/7.2.6 | 1488 +<----------------+ Trying |------------>| 1489 | +-+--------+------+-------+ | 1490 | | | | | 1491 | | T11/ | 18x/ | 200/ | 1492 | | 7.2.8 |7.2.3 | 7.2.4 | 1493 | V | | | 1494 | REL/7.2.7 +--------------+ | | 400+/7.2.6 | 1495 |<----------| Progressing |-|------|-------------------->| 1496 | +--+----+------+ | | | 1497 | | | | | | 1498 | 200/ | | 18x/ | | | 1499 | 7.2.4 | | 7.2.3 | | | 1500 | | V V | | 1501 | REL/7.2.7 | +---------------+ | 400+/7.2.6 | 1502 |<-------------|--| Alerting |-|-------------------->| 1503 | | +--------+------+ | | 1504 | | | | | 1505 | | | 200/ | | 1506 | | | 7.2.4 | | 1507 | V V V | 1508 | BYE/9.1 +-----------------------------+ REL/9.2 | 1509 +<------------+ Connected +------------>+ 1510 +-----------------------------+ 1512 7.2.1 Initial Address Message received 1514 Upon the reception of an IAM, resources are reserved in the media 1515 gateway and it connects audio in the backwards direction (towards the 1516 caller). 1518 7.2.1.1 IAM to INVITE procedures 1520 When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message will 1521 be created for transmission to the SIP network. This section details 1522 the process by which a gateway populates the INVITE based on 1523 parameters found within the IAM. 1525 The session context information discovered by the gateway in the IAM 1526 will be stored primarily in two URIs in the INVITE, one representing 1527 the originator of the session and the other the destination. The 1528 former will always appear in the From header (after it has been 1529 converted from ISUP format by the procedure described in Section 11), 1530 and the latter is almost always used for both the To header and the 1531 Request-URI. 1533 Once the location of the called party number has been determined, it 1534 should be translated into a tel URL through the mechanism described 1535 above. Some additional fields may need to be added to the tel URL 1536 after translation has been completed, namely: 1538 o If either the CIP (in ANSI networks) or TNS is present, the 1539 carrier identification code (CIC) should be extracted from the 1540 parameter and analyzed by the gateway. If doing so is in keeping 1541 with local policy (i.e. provided that the CIC does not indicate 1542 the network which owns the gateway or some similar condition), a 1543 'cic=' field with the value of the CIC should be appended to the 1544 tel URL. Note that the CIC should be prefixed with the country 1545 code used or implied in the called party number, so that CIC 1546 '5062' becomes, in the United States, '+1-5062'. For further 1547 information on the 'cic=' tel URL field see [6]. 1549 In most cases, the resulting URI should be used in the To field and 1550 Request-URI sent by the gateway. However, if the OCN parameter is 1551 present in the IAM, the To field constructed from the translation of 1552 the OCN parameter, and hence the Request-URI and To field will be 1553 different. 1555 The construction of the From field is dependent on the presence of a 1556 CIN parameter. If the CIN is not present, then the gateway should 1557 create a dummy From header containing a SIP URI without a user 1558 portion which communicates only the hostname of the gateway (e.g. 1559 'sip:gw.level3.net'). If the CIN is available, then it should be 1560 translated (in accordance with the procedure described above) into a 1561 tel URL which should populate the From field. 1563 7.2.2 100 received 1565 A 100 response does not trigger any PSTN interworking messages; it 1566 only serves the purpose of suppressing INVITE retransmissions. 1568 7.2.3 18x received 1570 If no ACM has been sent yet and no ISUP is present in the 18x message 1571 body, and ISUP message is generated according to the following table. 1572 Note that, if an early ACM is sent, the call enters state 1573 "Progressing" instead of state "Alerting." 1574 Response received Message sent by the MGC 1575 ----------------- ----------------------- 1576 180 Ringing ACM 1577 181 Call is being forwarded Early ACM and CPG, event=6 1578 182 Queued ACM 1579 183 Session progress message ACM 1581 If an ACM has already been sent and no ISUP is present in the 18x 1582 message body, an ISUP message is generated according to the following 1583 table. 1585 Response received Message sent by the MGC 1586 ----------------- ----------------------- 1587 180 Ringing CPG, event = 1 (Alerting) 1588 181 Call is being forwarded CPG, event = 6 (Forwarding) 1589 182 Queued CPG, event = 2 (Progress) 1590 183 Session progress message CPG, event = 2 (Progress) 1592 If the reception of a `180 Ringing' response without media 1593 description, the MG generates the ringback tone to be heard by the 1594 caller. 1596 If the MGC receives any 1xx response (except 100) with a session 1597 description present for media setup, it sets up the session being 1598 described. The call progress media (e.g. ringback tone or 1599 announcement) is generated by an entity downstream (in the SIP 1600 network or by a PSTN exchange in SIP bridging situations). 1602 If an ACM has not been sent yet, one is generated and sent. The 1603 mandatory parameters of the ACM are described below: 1605 Message type: ACM 1607 Backward Indicators 1608 Charge indicator: 10 charge 1609 Called party's status indicator: 01 subscriber free or 1610 00 no indication (E.ACM) 1611 Called party's category indicator: 01 ordinary subscriber 1612 End-to-end method indicator: 00 no end-to-end method 1613 Interworking indicator: 0 no interworking 1614 End-to-end information indicator: 0 no end-to-end info 1615 ISDN user part indicator: 1 ISUP all the way 1616 Holding indicator: 0 no holding 1617 ISDN access indicator: 1 ISDN access 1618 Echo control device indicator: It depends on the call 1619 SCCP method indicator: 00 no indication 1621 In SIP bridging situations the MGC sends the ISUP message contained 1622 in the response body. 1624 Note that sending 183 before a gateway has confirmation that the 1625 address is complete (ACM) creates known problems in SIP bridging 1626 cases, and it should therefore be avoided. 1628 7.2.4 2xx received 1630 Response received Message sent by the MGC 1631 ----------------- ----------------------- 1632 200 OK ANM, ACK 1634 After receiving a 200 OK response the MGC establishes a two-way voice 1635 path in the MG and it sends an ANM to the PSTN and an ACK to the SIP 1636 network. 1638 If the `200 OK' response arrives before the MGC has sent the ACM, a 1639 CON is sent instead of the ANM. 1641 In SIP bridging situations the MGC sends the ANM or the CON in the 1642 response body. 1644 7.2.5 3xx Received 1646 When any 3xx response is received ,the MGC should try to contact the 1647 user using the `Contact' header or headers present in the response. 1648 These 3xx responses are typically sent by a re-direct server. This 1649 is a similar device to the HLR in mobile networks. It provides 1650 another address where the callee may be reached. 1652 A CPG message with an event code of 6 (Forwarding) may be sent to 1653 indicate that the call is proceeding. Note that some ISUP nodes may 1654 not support CPG before ACM, so this feature should be configurable. 1656 If the new location presented in the Contact header of a 3xx is best 1657 reachable (according to the gateway's routing policies) via the PSTN, 1658 the MGC sends a new IAM and from that moment on acts as a normal PSTN 1659 switch (no SIP involved). If the new location is best reachable 1660 using SIP, the MGC sends an INVITE with possibly a new IAM generated 1661 by the MGC in the message body. 1663 All redirection situations have to be treated very carefully because 1664 they involved special charging situations. In PSTN the caller 1665 typically pays the first dialog and the callee pays the second. 1667 7.2.6 4xx-6xx Received 1669 The MGC releases the resources in the MG, send a REL to the PSTN with 1670 a cause value and send an ACK to the SIP network. An RLC arrives 1671 indicating that the release sequence is complete. 1673 7.2.6.1 SIP Status Code to ISDN Cause Code Mapping 1675 By default, the cause location associated with the CAI parameter 1676 should be encoded such that 6xx codes are given the location 'user', 1677 whereas 4xx and 5xx codes are given a 'network' location. Exceptions 1678 are marked below. 1680 Any SIP status codes not listed below (associated with SIP 1681 extensions, versions of SIP subsequent to the issue of this document, 1682 or simply omitted) should be mapping to cause code 31 "Normal, 1683 unspecified". 1685 Just as there are certain ISDN cause codes that are ISUP-specific and 1686 have no corollary SIP action, so there are SIP status codes that 1687 should not be translated to ISUP. Examples are flagged with (+) 1688 below. 1690 Response received Cause value in the REL 1691 ----------------- ---------------------- 1692 400 Bad Request 41 Temporary Failure 1693 401 Unauthorized 21 Call rejected (*) 1694 402 Payment required 21 Call rejected 1695 403 Forbidden 21 Call rejected 1696 404 Not found 1 Unallocated number 1697 405 Method not allowed 63 Service or option 1698 unavailable 1699 406 Not acceptable 79 Service/option not 1700 implemented 1701 407 Proxy authentication required 21 Call rejected (*) 1702 408 Request timeout 102 Recovery on timer expiry 1703 410 Gone 22 Number changed 1704 (w/o diagnostic) 1705 413 Request Entity too long 127 Interworking (+) 1706 414 Request-URI too long 127 Interworking (+) 1707 415 Unsupported media type 79 Service/option not 1708 implemented (+) 1709 416 Unsupported URI Scheme 127 Interworking (+) 1710 420 Bad extension 127 Interworking (+) 1711 421 Extension Required 127 Interworking (+) 1712 480 Temporarily unavailable 18 No user responding 1713 481 Call/Transaction Does not Exist 41 Temporary Failure 1714 483 Too many hops 25 Exchange - routing error 1715 484 Address incomplete 28 Invalid Number Format (+) 1716 485 Ambiguous 1 Unallocated number 1717 486 Busy here 17 User busy 1718 488 Not Acceptable here --- by Warning header 1719 500 Server internal error 41 Temporary failure 1720 501 Not implemented 38 Network out of order 1721 502 Bad gateway 38 Network out of order 1722 503 Service unavailable 41 Temporary failure 1723 504 Server time-out 102 Recovery on timer expiry 1724 504 Version Not Supported 127 Interworking (+) 1725 513 Message Too Large 127 Interworking (+) 1726 600 Busy everywhere 17 User busy 1727 603 Decline 21 Call rejected 1728 604 Does not exist anywhere 1 Unallocated number 1729 606 Not acceptable --- by Warning header 1731 (*) In some cases, it may be possible for a SIP gateway to provide 1732 credentials to the SIP UAS that is rejecting an INVITE due to 1733 authorization failure. If the gateway can authenticate itself, then 1734 obviously it should do so and proceed with the call; only if the 1735 gateway cannot authorize itself should cause code 21 be sent. 1737 (+) If at all possible, a SIP gateway should respond to these 1738 protocol errors by remedying unacceptable behavior and attempting to 1739 re-originate the session. Only if this proves impossible should the 1740 SIP gateway fail the ISUP half of the call. 1742 When the Warning header is present in a SIP 606 or 488 message, there 1743 may be specific ISDN cause code mappings appropriate to the Warning 1744 code. This document assumes that sending '31 Normal, unspecified' 1745 will be sufficient for all currently assigned Warning codes. 1747 7.2.7 REL Received 1749 The MGC should abort the establishment of the session. A CANCEL 1750 request has to be issued. A BYE is not used, since no final response 1751 has arrived from the SIP side. A 200 OK for the CANCEL arrives, and 1752 a 487 for the INVITE arrives. 1754 The MGC has to store state information for a certain period of time, 1755 since a 200 final response for the INVITE originally sent might 1756 arrive (even after the reception of the 200 OK for the CANCEL). In 1757 this situation, the MGC sends an ACK and then a BYE. 1759 In SIP bridging situations, the REL message may be included in the 1760 CANCEL message body. CANCEL requests are answered with a final 1761 response (such as 200 OK) by the first proxy. Therefore, the MGC 1762 does not know if the CANCEL has arrived to the end user (egress MGC 1763 in this scenario). Note that although end-to-end delivery of the 1764 CANCEL's payload is not guaranteed, since both sides of a PSTN 1765 connection issue REL messages, it will not result in a failure in the 1766 PSTN if this REL is never delivered. If, in a glare condition, a 200 1767 OK response to the previously sent INVITE arrives after a CANCEL has 1768 been sent, the MGC sends an ACK and then a BYE with the REL in the 1769 message body. 1771 7.2.8 ISUP T11 Expires 1773 In order to prevent the remote ISUP node's timer T7 from expiring, 1774 the gateway may choose to keep its own supervisory timer; ISUP 1775 defines this timer as T11. T11's duration is carefully chosen so 1776 that it will always be shorter than the T7 of any node to which the 1777 gateway is communicating. 1779 To clarify timer T11's relevance with respect to SIP interworking, 1780 Q.764 [10] explains its use as: "If in normal operation, a delay in 1781 the receipt of an address complete signal from the succeeding network 1782 is expected, the last common channel signaling exchange will 1783 originate and send an address complete message 15 to 20 seconds 1784 [timer (T11)] after receiving the latest address message." Since SIP 1785 nodes have no obligation to respond to an INVITE request within 20 1786 seconds, SIP interworking inarguably qualifies as such a situation. 1788 If the gateway's T11 expires, it will send an early ACM (i.e. called 1789 party status set to "no indication") to prevent the expiration of the 1790 remote node's T7. See Section 7.2.3 for the value of the ACM 1791 parameters. 1793 If a "180 Ringing" message arrives subsequently, it will be sent in a 1794 CPG, as shown in Section 7.2.3. 1796 See Section 7.1.3 for an example callflow that includes the 1797 expiration of T11. 1799 8. Suspend/Resume and Hold 1801 8.1 SUS and RES 1803 In ISDN networks, a user can generate a SUS (timer T2, user 1804 initiated) in order to unplug the terminal from the socket and plug 1805 it in another one. A RES is sent once the terminal has been 1806 reconnected and the T2 timer has not expired. SUS is also frequently 1807 used to signaling an on-hook state for a remote terminal before 1808 timers leading to the transmission of a REL message are sent. While 1809 a call is suspended, no audio media is passed end-to-end. 1811 When a SUS is sent for a call that has a SIP leg, it may be desirable 1812 to suspend IP media transmission until a RES is received. Putting 1813 the media on hold insures that bandwidth is conserved when no audio 1814 traffic needs to be transmitted. 1816 If media suspension is appropriate, then when a SUS arrives from the 1817 PSTN, the MGC should send an INVITE to request that the far-end's 1818 transmission of the media stream be placed on hold. The subsequent 1819 reception of a RES from the PSTN would then trigger a re-INVITE that 1820 requests the resumption of the media stream. Note that the MGC may 1821 or may not elect to stop transmitting any media itself when it 1822 requests the cessation of far-end transmission. 1824 If media suspension is not required by the MGC receiving the SUS from 1825 the PSTN, the SIP INFO [5] method can be used to transmit an 1826 encapsulated SUS rather than a re-INVITE. Subsequent RES messages 1827 should be transmitted in the same method that was used for the 1828 corresponding SUS (i.e. if an INFO is used for a SUS, INFO should 1829 also be used for the subsequent RES). 1831 Regardless of whether the INFO or re-INVITE mechanism is used to 1832 carry a SUS message, neither has any implication that the originating 1833 side will cease sending IP media. The recipient of an encapsulated 1834 SUS message may therefore elect to send a re-INVITE themselves to 1835 suspend media transmission from the MGC side if desired. 1837 All of the following examples use the INVITE mechanism. 1839 SIP MGC/MG PSTN 1840 | |<-----------SUS-----------|1 1841 2|<--------INVITE-----------| | 1842 3|-----------200----------->| | 1843 4|<----------ACK------------| | 1844 | |<-----------RES-----------|5 1845 6|<--------INVITE-----------| | 1846 7|-----------200----------->| | 1847 8|<----------ACK------------| | 1849 The handling of a network-initiated SUS immediately prior to call 1850 teardown is handled in Section 9.2.2. 1852 8.2 Hold (re-INVITE) 1854 After a call has been connected, a re-INVITE may be sent to a gateway 1855 from the SIP side in order to place the call on hold. This re-INVITE 1856 will have an SDP indicating that the originator of the re-INVITE no 1857 longer wishes to receive media. 1859 SIP MGC/MG PSTN 1860 1|---------INVITE---------->| | 1861 | |------------CPG---------->|2 1862 3|-----------200----------->| | 1863 4|<----------ACK------------| | 1865 When such a re-INVITE is received, the gateway should send a Call 1866 Progress Message (CPG) in order to express that the call has been 1867 placed on hold. The CPG should contain a Generic Notification 1868 Indicator (or, in ANSI networks, a Notification Indicator) with a 1869 value of 'remote hold'. 1871 If subsequent to the sending of the re-INVITE the SIP side wishes to 1872 take the remote end off hold, and to begin receiving media again, it 1873 may repeat the flow above with an INVITE that contains an SDP with a 1874 reachable media destination. The Generic Notification Indicator 1875 would in this instance have a value of 'remote retrieval' (or in some 1876 variants 'remote hold released'). 1878 Finally, note that a CPG with hold indicators may be received by a 1879 gateway from the PSTN. In the interests of conserving bandwidth, the 1880 gateway may wish to stop sending media until the call is resume, 1881 and/or send a re-INVITE to the SIP leg of the call requesting that 1882 the remote side stop sending media. 1884 9. Normal Release of the Connection 1886 Either the SIP side or the ISUP side may release a call, regardless 1887 of which side initiated the call. 1889 9.1 SIP initiated 1891 For a normal release of the call (reception of BYE), the MGC 1892 immediately sends a 200 response. It then releases the resources in 1893 the MG and sends an REL with a cause code of 16 (normal call 1894 clearing) to the PSTN. Release of resources is confirmed by the PSTN 1895 with a RLC. 1897 In SIP bridging situations, the REL contained in the BYE is sent to 1898 the PSTN. 1900 SIP MGC/MG PSTN 1901 1|-----------BYE----------->| | 1902 | ** MG Releases IP Resources ** | 1903 2|<----------200------------| | 1904 | ** MG Releases PSTN Trunk ** | 1905 | |------------REL---------->|3 1906 | |<-----------RLC-----------|4 1908 9.2 ISUP initiated 1910 If the release of the connection was caused by the reception of a 1911 REL, the REL is included in the BYE sent by the MGC. 1913 9.2.1 Caller hangs up 1915 For a normal release of the call (reception of REL from the PSTN), 1916 the MGC first releases the resources in the MG and then confirms that 1917 they are ready for re-use by sending an RLC. The SIP connection is 1918 released by sending a BYE (which is confirmed with a 200). 1920 SIP MGC/MG PSTN 1921 | |<-----------REL-----------|1 1922 | ** MG Releases PSTN Trunk ** | 1923 | |------------RLC---------->|2 1924 3|<----------BYE------------| | 1925 | ** MG Releases IP Resources ** | 1926 4|-----------200----------->| | 1928 9.2.2 Callee hangs up 1930 In analog PSTN, if the callee hangs up in the middle of a call, the 1931 local exchange sends a SUS instead of a REL and starts a timer (T6, 1932 SUS is network initiated). When the timer expires, the REL is sent. 1934 SIP MGC/MG PSTN 1935 | |<-----------SUS-----------|1 1936 2|<--------INVITE-----------| | 1937 3|-----------200----------->| | 1938 4|<----------ACK------------| | 1939 | | *** T6 Expires *** | 1940 | |<-----------REL-----------|5 1941 | ** MG Releases PSTN Trunk ** | 1942 | |------------RLC---------->|6 1943 7|<----------BYE------------| | 1944 | ** MG Releases IP Resources ** | 1945 8|-----------200----------->| | 1947 10. ISUP Maintenance Messages 1949 ISUP contains a set of messages used for maintenance purposes. They 1950 can be received during an ongoing call. There are basically two 1951 kinds of maintenance messages (apart from the continuity check): 1952 message for blocking circuits and messages for resetting circuits. 1954 10.1 Reset messages 1956 Upon reception of a reset message for the circuit being used, the 1957 call has to be released. RSC messages are answered with RLC after 1958 resetting the circuit in the MG. GRS messages are answered with GRA 1959 after resetting all the circuits affected by the message. 1961 The MGC acts as if a REL had been received in order to release the 1962 connection on the SIP side. The session will be terminated. A BYE 1963 or a CANCEL are sent depending of the status of the call. 1965 10.2 Blocking messages 1967 There are two kinds of blocking messages: maintenance oriented or 1968 hardware failure oriented. Maintenance oriented blocking messages 1969 indicates that the circuit has to be blocked for subsequent calls. 1970 Therefore, these messages do not affect any ongoing call. 1972 Hardware oriented blocking messages have to be treated as reset 1973 messages. The call is released. 1975 BLO is always maintenance oriented and it is answered by the MGC with 1976 BLA when the circuit is blocked. CGB messages have a "type 1977 indicator" inside the "circuit group supervision message type 1978 indicator". It indicates if the CGB is maintenance or hardware 1979 failure oriented. CGBs are answered with CGBAs. 1981 10.3 Continuity Checks 1983 A continuity check is a test performed on a circuit that involves the 1984 reflection of a tone generated at the originating switch by a 1985 loopback at the destination switch. Two variants of the continuity 1986 check appear in ISUP: the implicit continuity check request within an 1987 IAM (in which case the continuity check takes place before call setup 1988 begins), and the explicit continuity check signaled by a Continuity 1989 Check Request (CCR) message. 1991 When a CCR is received by a PSTN-SIP gateway, the gateway should not 1992 send any SIP messages; the scope of the continuity check applies only 1993 to the PSTN trunks, not to any IP media paths. 1995 When an IAM with the Continuity Check Indicator flag set within the 1996 Nature of Connection Indicators (NCI) parameter is received, the 1997 gateway should process the continuity check before sending an INVITE 1998 message; if the continuity check fails (a COT with Continuity 1999 Indicator of 'failed' is received), then an INVITE should not be 2000 sent. 2002 11. Construction of Telephony URIs 2004 SIP proxy servers may route SIP messages on any signaling criteria 2005 desired by network administrators, but generally the Request-URI is 2006 the foremost routing criterion. The To and From headers are also 2007 frequently of interest in making routing decisions. SIP-ISUP mapping 2008 assumes that proxy servers are interested in at least these three 2009 fields of SIP messages, all of which contain URIs. 2011 SIP-ISUP mapping frequently requires the representation of telephone 2012 numbers in these URIs. In some instances these numbers will be 2013 presented first in ISUP messages, and SS7-SIP gateways will need to 2014 translate the ISUP formats of these numbers into SIP URIs. In other 2015 cases the reverse transformation will be required. 2017 The most common format used in SIP for the representation of 2018 telephone numbers is the tel URL [7]. The tel URL may constitute the 2019 entirety of a URI field in a SIP message, or it may appear as the 2020 user portion of a SIP URI. For example, a To field might appear as: 2022 To: tel:+17208881000 2024 Or 2026 To: sip:+17208881000@level3.com 2028 Whether or not a particular gateway or endpoint should formulate URIs 2029 in the tel or SIP format is a matter of local administrative policy - 2030 if the presence of a host portion would aid the surrounding network 2031 in routing calls, the SIP format should be used. A gateway should 2032 accept either tel or SIP URIs from its peers. 2034 The '+' sign preceding the number in these examples indicates that 2035 the digits which follow constitute a fully-qualified E.164 [14] 2036 number; essentially, this means that a country code is provided 2037 before any national-specific area codes, exchange/city codes, or 2038 address codes. The absence of a '+' sign could mean that the number 2039 is nationally significant, or perhaps that a private dialing plan is 2040 in use. When the '+' sign is not present, but a telephone number is 2041 represented by the user portion of the URI, the SIP URI should may 2042 the optional ';user=phone' parameter; e.g. 2044 To: sip:83000@sip.example.net;user=phone 2046 However, it is highly recommended that only internationally 2047 significant E.164 numbers be passed between SIP-T gateways, 2048 especially when such gateways are in different regions or different 2049 administrative domains. In many if not most SIP-T networks, gateways 2050 are not responsible for end-to-end routing of SIP calls; practically 2051 speaking, gateways have no way of knowing if the call will terminate 2052 in a local or remote administrative domain and/or region, and hence 2053 gateways should always assume that calls require an international 2054 numbering plan. There is no guarantee that recipients of SIP 2055 signaling will be capable of understanding national dialing plans 2056 used by the originators of calls - if the originating gateway does 2057 not internationalize the signaling, the context in which the digits 2058 were dialed cannot be extrapolated by far-end network elements. 2060 In ISUP signaling, a telephone number appears in a common format that 2061 is used in several parameters, including the Called Party's Number 2062 (CPN) and Calling Party's Number (CIN); when it represents a calling 2063 party number it sports some additional information (detailed below). 2064 For the purposes of this document, we will refer to this format as 2065 'ISUP format' - if the additional calling party information is 2066 present, the format shall be referred to as 'ISUP- calling format'. 2067 The format consists of a byte called the Nature of Address (NoA) 2068 indicator, followed by another byte which contains the Numbering Plan 2069 Indicator (NPI), both of which are prefixed to a variable-length 2070 series of bytes that contains the digits of the telephone number in 2071 binary coded decimal (BCD) format. In the calling party number case, 2072 the NPI's byte also contains bit fields which represent the caller's 2073 presentation preferences and the status of any call screening checks 2074 performed up until this point in the call. 2076 H G F E D C B A H G F E D C B A 2077 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2078 | | NoA | | | NoA | 2079 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2080 | | NPI | spare | | | NPI |PrI|ScI| 2081 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2082 | dig...| dig 1 | | dig...| dig 1 | 2083 | ... | | ... | 2084 | dig n | dig...| | dig n | dig...| 2085 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2087 ISUP format ISUP calling format 2089 ISUP numbering formats 2091 The NPI field is generally set to the value 'ISDN (Telephony) 2092 numbering plan (Recommendation E.164)', but this does not mean that 2093 the digits which follow necessarily contain a country code; the NoA 2094 field dictates whether the telephone number is in a national or 2095 international format. When the represented number is not designated 2096 to be in an international format, the NoA generally provides 2097 information specific to the national dialing plan - based on this 2098 information one can usually determine how to convert the number in 2099 question into an international format. Note that if the NPI contains 2100 a value other than 'ISDN numbering plan', then the tel URL may not be 2101 suitable for carrying the address digits, and the handling for such 2102 calls is outside the scope of this document. 2104 Based on the above, conversion from ISUP format to a tel URL is as 2105 follows. First, provided that the NPI field indicates that the 2106 telephone number format uses E.164, the NoA should be consulted. If 2107 the NoA indicates that the number is an international number, then 2108 the telephone number digits should be appended unmodified to a 2109 'tel:+' string. If the NoA has the value 'national (significant) 2110 number', then a country code must be prefixed to the telephone number 2111 digits before they are committed to a tel URL; if the gateway 2112 performing this conversion interconnects with switches homed to 2113 several different country codes, presumably the appropriate country 2114 code should be chosen based on the originating switch. If the NoA 2115 has the value 'subscriber number', both a country code and any other 2116 numbering components necessary for the numbering plan in question 2117 (such as area codes or city codes) may need to be added in order for 2118 the number to be internationally significant - however, such 2119 procedures vary greatly from country to country, and hence they 2120 cannot be specified in detail here. Only if a country or network- 2121 specific value is used for the NoA should a tel URL not include a '+' 2122 sign; in these cases, gateways should simply copy the provided digits 2123 into the tel URL and append a 'user=phone' parameter if a SIP URI 2124 format is used. Any non-standard or proprietary mechanisms used to 2125 communicate further context for the call in ISUP are outside the 2126 scope of this document. 2128 If a nationally-specific parameter is present that allows for the 2129 transmission of the calling party's name (such as the Generic Name 2130 Parameter in ANSI), then generally, if presentation is not 2131 restricted, this information should be used to populate the display- 2132 name portion of the From field. 2134 If ISUP calling format is used rather than ISUP format, then two 2135 additional pieces of information must be taken into account: 2136 presentation indicators and screening indicators. If the 2137 presentation indicators are set to 'presentation restricted', then a 2138 special URI should be created by the gateway which communicates to 2139 the far end that the caller's identity has been elided. This URI 2140 should be a SIP URI with the hostname of the gateway but with a 2141 display name of 'Anonymous' username of 'restricted', e.g.: 2143 From: Anonymous 2145 As further general-purpose privacy mechanisms are developed for the 2146 SIP protocol, they may also be used to protect the identity of a 2147 caller. 2149 If presentation is set to 'address unavailable', then gateways should 2150 treat the IAM as if the CIN parameter was omitted. Screening 2151 indicators should not be translated, as they are only meaningful end- 2152 to-end. 2154 Conversion from tel URLs to ISUP format is simpler. If the URI is in 2155 international format, then the gateway should consult the leading 2156 country code of the URI. If the country code is local to the gateway 2157 (the gateway has one or more trunks that point to switches which are 2158 homed to the country code in question), the gateway should set the 2159 NoA to reflect 'national (significant) number' and strip the country 2160 code from the URI before populating the digits field. If the country 2161 code is not local to the gateway, the gateway should set the NoA to 2162 'international number' and retain the country code. In either case 2163 the NPI should be set to 'ISDN numbering plan'. 2165 If the URI is not in international format, the gateway should attempt 2166 to treat the telephone number within the URI as if it were 2167 appropriate to its national or network-specific dialing plan; if 2168 doing so gives rise to internal gateway errors, then this condition 2169 is most likely best handled with appropriate SIP status codes (e.g. 2170 484). 2172 When converting from a tel URL to ISUP calling format, the procedure 2173 is identical to that described in the preceding paragraphs, but 2174 additionally, the presentation indicator should be set to 2175 'presentation allowed' and the screening indicator to 'network 2176 provided', unless some service provider policy or user profile 2177 specifically disallows presentation. 2179 12. Other ISUP flavors 2181 Other flavors of ISUP different than Q.767 [8] have more parameters 2182 and more features. Some of the parameters have more possible values 2183 and provide more information about the status of the call. 2185 The Circuit Query Message (CQM) and Circuit Query Response (CQR) are 2186 used in many ISUP variants. These messages have no analog in SIP, 2187 although receipt of a CQR may cause state reconciliation if the 2188 originating and destination switches have become desynchronized; as 2189 states are reconciled some calls may be dropped, which may cause SIP 2190 or ISUP messages to be sent. 2192 However, differences in the message flows are more important. In 2193 ANSI [9] ISUP, there is no CON message; an ANM is sent instead (with 2194 no ACM). In call forwarding situations, CPGs can be sent before the 2195 ACM is sent. SAMs are never used; `en bloc' signaling is always 2196 used. The ANSI Exit Message (EXM) should not result in any SIP 2197 signaling in gateways. ANSI also uses the Circuit Reservation 2198 Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of 2199 its interworking procedures - in the event that an MGC does receive a 2200 CRM, a CRA should be sent in return (in some implementations, 2201 transmissions of a CRA could conceivably be based on a resource 2202 reservation system); after a CRA is sent, the MGC should wait for a 2203 subsequent IAM and process it normally. Any further circuit 2204 reservation mechanism is outside the scope of this document. 2206 Although receipt of a Confusion (CFN) message is an indication of a 2207 protocol error, no SIP message should be sent on receipt of a CFN - 2208 the CFN should be handled internally by the gateway (usually by 2209 retransmission of the packet to which the CFN responded). Only if 2210 this fails repeatedly should this cause a SIP error condition to 2211 arise. 2213 In TTC ISUP CPGs can be sent before the ACM is sent. Messages such 2214 as CHG can be sent between ACM and ANM. `En bloc' signaling is 2215 always used and there is no T9 timer. 2217 12.1 Guidelines to send other ISUP messages 2219 Some ISUP flavors send more messages than the ones described in this 2220 document. It is good to follow some guidelines to transport these 2221 ISUP messages inside SIP bodies. 2223 From the caller to the callee ISUP messages should be encapsulated 2224 (see [2]) inside INFO messages, even if the INVITE transaction is 2225 still not finished. Note that SIP does not ensure that INFO requests 2226 are delivered in order. Therefore, an egress gateway might process 2227 first an INFO request that was sent after another INFO request. This 2228 issue, however, does not represent an important problem since it is 2229 not likely to happen and its effects are negligible in most of the 2230 situations. The Information (INF) message and Information Response 2231 (INR) are examples of messages that should be encapsulated within an 2232 INFO. Gateway implementors might also consider building systems that 2233 wait for each INFO transaction to complete before initiating a new 2234 INFO transaction. 2236 From the callee to the caller, if an INR is received by a gateway 2237 before the call has been answered (i.e. ANM is received) it should 2238 be encapsulated in an INFO, provided that this will not be the first 2239 SIP message sent in the backwards direction (in which case it must be 2240 encapsulated in a provisional 1xx response). Similarly an INF is 2241 received on the originating side (probably in response to an INR) 2242 before a 200 has been received should be carried within an INFO. In 2243 order for this mechanism to function properly in the forward 2244 direction, any necessary Contact or To-tag must have appeared in a 2245 previous provisional response or the message might not be correctly 2246 routed to its destination. As such all SIP-T gateways should send 2247 provisional responses with a Contact header and any necessary tags in 2248 order to enable proper routing of new requests issued before a final 2249 response has been received. 2251 When the INVITE transaction is finished INFO requests should be used 2252 also in this direction. 2254 13. Acronyms 2256 ACK Acknowledgment 2257 ACM Address Complete Message 2258 ANM Answer Message 2259 ANSI American National Standards Institute 2260 BLA Blocking ACK message 2261 BLO Blocking Message 2262 CGB Circuit Group Blocking Message 2263 CGBA Circuit Group Blocking ACK Message 2264 CHG Charging Information Message 2265 CON Connect Message 2266 CPG Call Progress Message 2267 CUG Closed User Group 2268 GRA Circuit Group Reset ACK Message 2269 GRS Circuit Group Reset Message 2270 HLR Home Location Register 2271 IAM Initial Address Message 2272 IETF Internet Engineering Task Force 2273 IP Internet Protocol 2274 ISDN Integrated Services Digital Network 2275 ISUP ISDN User Part 2276 ITU-T International Telecommunication Union 2277 Telecommunication Standardization Sector 2278 MG Media Gateway 2279 MGC Media Gateway Controller 2280 MTP Message Transfer Part 2281 REL Release Message 2282 RES Resume Message 2283 RLC Release Complete Message 2284 RTP Real-time Transport Protocol 2285 SCCP Signaling Connection Control Part 2286 SG Signaling Gateway 2287 SIP Session Initiation Protocol 2288 SS7 Signaling System No. 7 2289 SUS Suspend Message 2290 TTC Telecommunication Technology Committee 2291 UAC User Agent Client 2292 UAS User Agent Server 2293 UDP User Datagram Protocol 2294 VoIP Voice over IP 2296 14. Security Considerations 2298 The transit of encapsulated ISUP within SIP bodies may provide may 2299 opportunities for abuse and fraud. In particular, SIP users may be 2300 able to interpret "private" (i.e. caller-id-blocked) numbers by 2301 examining the ISUP. Similarly, if care is not taken, SIP clients 2302 would be able to send ISUP messages into the SS7 network with invalid 2303 calling line identification and spoofed billing numbers. 2305 For these reasons, it is absolutely necessary that any ISUP sent 2306 through an IP network be strongly encrypted and authenticated. The 2307 keys used for encryption should not be static, to prevent replay 2308 attacks. A challenge-response model is recommended. As an extra 2309 layer of security, it is recommended that ISUP be sent and received 2310 only to and from nodes that are known to have an established trust 2311 relationship with the gateway. 2313 15. IANA Considerations 2315 This document introduces no new considerations for IANA. 2317 Normative References 2319 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2320 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2321 Session Initiation Protocol", RFC 3261, May 2002. 2323 [2] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 2324 Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG 2325 objects", RFC 3204, December 2001. 2327 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2328 Extensions (MIME) Part Two: Media Types", RFC 2046, November 2329 1996. 2331 [4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 2332 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 2334 [5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 2336 [6] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of 2337 Number Portability and Freephone Service", draft-yu-tel-url-04 2338 (work in progress), November 2001. 2340 [7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2341 2000. 2343 Non-normative References 2345 [8] International Telecommunications Union, "Application of the 2346 ISDN user part of CCITT Signaling System No. 7 for 2347 international ISDN interconnection", ITU-T Q.767, February 2348 1991, . 2350 [9] American National Standards Institute, "Signaling System No. 7; 2351 ISDN User Part", ANSI T1.113, January 1995, 2352 . 2354 [10] International Telecommunications Union, "Signaling System No. 2355 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 2356 1999, . 2358 [11] International Telecommunications Union, "Abnormal conditions - 2359 Special release", ITU-T Q.118, September 1997, 2360 . 2362 [12] International Telecommunications Union, "Specifications of 2363 Signaling System No. 7 - ISDN supplementary services", ITU-T 2364 Q.737, June 1997, . 2366 [13] International Telecommunications Union, "Usage of cause 2367 location in the Digital Subscriber Signaling System No. 1 and 2368 the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 2369 1998, . 2371 [14] International Telecommunications Union, "The international 2372 public telecommunications numbering plan", ITU-T E.164, May 2373 1997, . 2375 [15] International Telecommunications Union, "Formats and codes of 2376 the ISDN User Part of Signaling System No. 7", ITU-T Q.763, 2377 December 1999, . 2379 [16] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2380 Responses in SIP", draft-ietf-sip-100rel-06 (work in progress), 2381 February 2002. 2383 [17] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, 2384 October 2000. 2386 [18] Rosenberg, J., "The SIP UPDATE Method", draft-ietf-sip-update- 2387 02 (work in progress), March 2002. 2389 Authors' Addresses 2391 Gonzalo Camarillo 2392 Ericsson 2393 Advanced Signalling Research Center 2394 FIN-02420 Jorvas 2395 Finland 2397 Phone: +358 9 299 3371 2398 EMail: Gonzalo.Camarillo@Ericsson.com 2399 URI: http://www.ericsson.com/ 2401 Adam Roach 2402 dynamicsoft 2403 5100 Tennyson Parkway 2404 Suite 1200 2405 Plano, TX 75024 2406 USA 2408 EMail: adam@dynamicsoft.com 2409 URI: sip:adam@dynamicsoft.com 2411 Jon Peterson 2412 NeuStar, Inc. 2413 1800 Sutter St 2414 Suite 570 2415 Concord, CA 94520 2416 USA 2418 Phone: +1 925/363-8720 2419 EMail: jon.peterson@neustar.biz 2420 URI: http://www.neustar.biz/ 2422 Lyndon Ong 2423 Ciena 2424 10480 Ridgeview Court 2425 Cupertino, CA 95014 2426 USA 2428 EMail: lyOng@ciena.com 2429 URI: http://www.ciena.com/ 2431 Appendix A. Acknowledgments 2433 The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill 2434 Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, 2435 Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, 2436 Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan 2437 Van Geel, Romel Khan, Mike Hammer, Mike Pierce and Roland Jesske for 2438 their help and feedback on this document. 2440 Appendix B. Revision History 2442 Changes from draft-ietf-sip-isup-00: 2444 - Merged draft-jfp-sip-isup-header-00 into this draft 2446 - Removed overlap signaling component (now draft-ietf-sip-overlap- 2447 00) 2449 - Adjusted cause code to status code mappings 2451 Changes from draft-ietf-sip-isup-01: 2453 - Added procedures for placing calls on hold 2455 - Generalized language and procedures for LNP, removing ANSI bias 2457 - Fixed usage of 'user=phone' 2459 - Added handling for Segmentation Message in ISUP 2461 - Updated SUS/RES handling to use INFO consistently (rather than 2462 183) 2464 Changes from draft-ietf-sip-isup-02: 2466 - Fixed some more ANSI-specific references (GNI, screening) 2468 - Fixed timer expiry cause code values (6.2.2) 2470 - Removed some bis04 incompatibilities (6.2.10) 2472 - Added motivational text to abstract and introduction 2474 Changes from draft-ietf-sip-isup-03: 2476 - Added provision for SUS/RES over INFO method 2478 - Fixed ANSI CRM/CRA behavior 2480 - Corrected a few status code conflicts 2482 - Righted many nits (thanks Igor!) 2484 Changes from draft-ietf-sipping-isup-00: 2486 - Removed PRACK from call flows 2487 - Some updating to bring language in parity with bis 2489 - Various nits 2491 Changes from draft-ietf-sipping-isup-01: 2493 - Minor editorial corrections. 2495 - Updated references from RFC 2543 to RFC 3261. 2497 - Split normative and non-normative references. 2499 Full Copyright Statement 2501 Copyright (C) The Internet Society (2002). All Rights Reserved. 2503 This document and translations of it may be copied and furnished to 2504 others, and derivative works that comment on or otherwise explain it 2505 or assist in its implementation may be prepared, copied, published 2506 and distributed, in whole or in part, without restriction of any 2507 kind, provided that the above copyright notice and this paragraph are 2508 included on all such copies and derivative works. However, this 2509 document itself may not be modified in any way, such as by removing 2510 the copyright notice or references to the Internet Society or other 2511 Internet organizations, except as needed for the purpose of 2512 developing Internet standards in which case the procedures for 2513 copyrights defined in the Internet Standards process must be 2514 followed, or as required to translate it into languages other than 2515 English. 2517 The limited permissions granted above are perpetual and will not be 2518 revoked by the Internet Society or its successors or assigns. 2520 This document and the information contained herein is provided on an 2521 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2522 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2523 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2524 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2525 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2527 Acknowledgement 2529 Funding for the RFC Editor function is currently provided by the 2530 Internet Society.