idnits 2.17.1 draft-ietf-sipping-isup-05.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 21 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1784 has weird spacing: '...o field and R...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 2002) is 7927 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: '15' is defined on line 2815, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2833 (ref. '5') (Obsoleted by RFC 4733, RFC 4734) ** Obsolete normative reference: RFC 2976 (ref. '6') (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 2806 (ref. '7') (Obsoleted by RFC 3966) ** Obsolete normative reference: RFC 2916 (ref. '8') (Obsoleted by RFC 3761) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '19') (Obsoleted by RFC 4960) == Outdated reference: A later version (-08) exists of draft-yu-tel-url-04 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: December 30, 2002 A. Roach 5 dynamicsoft 6 J. Peterson 7 NeuStar 8 L. Ong 9 Ciena 10 July 2002 12 ISUP to SIP Mapping 13 draft-ietf-sipping-isup-05 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 December 30, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 55 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5. SIP Mechanisms Required . . . . . . . . . . . . . . . . . 10 57 5.1 'Transparent' Transit of ISUP Messages . . . . . . . . . . 10 58 5.2 Understanding MIME Multipart Bodies . . . . . . . . . . . 10 59 5.3 Transmission of DTMF Information . . . . . . . . . . . . . 10 60 5.4 Reliable Transmission of Provisional Responses . . . . . . 11 61 5.5 Early Media . . . . . . . . . . . . . . . . . . . . . . . 11 62 5.6 Mid-Call Transactions which do not change SIP state . . . 11 63 5.7 Privacy Protection . . . . . . . . . . . . . . . . . . . . 12 64 5.8 CANCEL causes . . . . . . . . . . . . . . . . . . . . . . 12 65 6. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 7. SIP to ISUP Mapping . . . . . . . . . . . . . . . . . . . 15 67 7.1 SIP to ISUP Call flows . . . . . . . . . . . . . . . . . . 15 68 7.1.1 En-bloc Call Setup (no auto-answer) . . . . . . . . . . . 15 69 7.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 16 70 7.1.3 ISUP T7 Expires . . . . . . . . . . . . . . . . . . . . . 17 71 7.1.4 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 18 72 7.1.5 ISUP Setup Failure . . . . . . . . . . . . . . . . . . . . 19 73 7.1.6 Cause Present in ACM Message . . . . . . . . . . . . . . . 20 74 7.1.7 Call Canceled by SIP . . . . . . . . . . . . . . . . . . . 21 75 7.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 22 76 7.2.1 INVITE received . . . . . . . . . . . . . . . . . . . . . 23 77 7.2.1.1 INVITE to IAM procedures . . . . . . . . . . . . . . . . . 23 78 7.2.2 ISUP T7 expires . . . . . . . . . . . . . . . . . . . . . 27 79 7.2.3 CANCEL or BYE received . . . . . . . . . . . . . . . . . . 27 80 7.2.4 REL received . . . . . . . . . . . . . . . . . . . . . . . 27 81 7.2.4.1 ISDN Cause Code to Status Code Mapping . . . . . . . . . . 28 82 7.2.5 Early ACM received . . . . . . . . . . . . . . . . . . . . 31 83 7.2.6 ACM received . . . . . . . . . . . . . . . . . . . . . . . 31 84 7.2.7 CON or ANM Received . . . . . . . . . . . . . . . . . . . 32 85 7.2.8 Timer T9 Expires . . . . . . . . . . . . . . . . . . . . . 32 86 7.2.9 CPG Received . . . . . . . . . . . . . . . . . . . . . . . 33 87 7.3 ACK received . . . . . . . . . . . . . . . . . . . . . . . 33 88 8. ISUP to SIP Mapping . . . . . . . . . . . . . . . . . . . 34 89 8.1 ISUP to SIP Call Flows . . . . . . . . . . . . . . . . . . 34 90 8.1.1 En-bloc call setup (non auto-answer) . . . . . . . . . . . 34 91 8.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 35 92 8.1.3 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 36 93 8.1.4 ISUP T9 Expires . . . . . . . . . . . . . . . . . . . . . 37 94 8.1.5 SIP Error Response . . . . . . . . . . . . . . . . . . . . 38 95 8.1.6 SIP Redirection . . . . . . . . . . . . . . . . . . . . . 39 96 8.1.7 Call Canceled by ISUP . . . . . . . . . . . . . . . . . . 40 97 8.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 41 98 8.2.1 Initial Address Message received . . . . . . . . . . . . . 42 99 8.2.1.1 IAM to INVITE procedures . . . . . . . . . . . . . . . . . 42 100 8.2.2 100 received . . . . . . . . . . . . . . . . . . . . . . . 44 101 8.2.3 18x received . . . . . . . . . . . . . . . . . . . . . . . 44 102 8.2.4 2xx received . . . . . . . . . . . . . . . . . . . . . . . 46 103 8.2.5 3xx Received . . . . . . . . . . . . . . . . . . . . . . . 46 104 8.2.6 4xx-6xx Received . . . . . . . . . . . . . . . . . . . . . 47 105 8.2.6.1 SIP Status Code to ISDN Cause Code Mapping . . . . . . . . 47 106 8.2.7 REL Received . . . . . . . . . . . . . . . . . . . . . . . 49 107 8.2.8 ISUP T11 Expires . . . . . . . . . . . . . . . . . . . . . 49 108 9. Suspend/Resume and Hold . . . . . . . . . . . . . . . . . 51 109 9.1 SUS and RES . . . . . . . . . . . . . . . . . . . . . . . 51 110 9.2 Hold (re-INVITE) . . . . . . . . . . . . . . . . . . . . . 52 111 10. Normal Release of the Connection . . . . . . . . . . . . . 53 112 10.1 SIP initiated release . . . . . . . . . . . . . . . . . . 53 113 10.2 ISUP initiated release . . . . . . . . . . . . . . . . . . 53 114 10.2.1 Caller hangs up . . . . . . . . . . . . . . . . . . . . . 53 115 10.2.2 Callee hangs up (SUS) . . . . . . . . . . . . . . . . . . 54 116 11. ISUP Maintenance Messages . . . . . . . . . . . . . . . . 55 117 11.1 Reset messages . . . . . . . . . . . . . . . . . . . . . . 55 118 11.2 Blocking messages . . . . . . . . . . . . . . . . . . . . 55 119 11.3 Continuity Checks . . . . . . . . . . . . . . . . . . . . 56 120 12. Construction of Telephony URIs . . . . . . . . . . . . . . 57 121 12.1 ISUP format to tel URL mapping . . . . . . . . . . . . . . 59 122 12.2 tel URL to ISUP format mapping . . . . . . . . . . . . . . 60 123 13. Other ISUP flavors . . . . . . . . . . . . . . . . . . . . 61 124 13.1 Guidelines for sending other ISUP messages . . . . . . . . 61 125 14. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 63 126 15. Security Considerations . . . . . . . . . . . . . . . . . 64 127 16. IANA Considerations . . . . . . . . . . . . . . . . . . . 67 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 70 129 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 130 References . . . . . . . . . . . . . . . . . . . . . . . . 68 131 References . . . . . . . . . . . . . . . . . . . . . . . . 69 132 B. Revision History . . . . . . . . . . . . . . . . . . . . . 72 133 Full Copyright Statement . . . . . . . . . . . . . . . . . 75 135 1. Introduction 137 SIP [1] is an application layer protocol for establishing, 138 terminating and modifying multimedia sessions. It is typically 139 carried over IP. Telephone calls are considered a type of multimedia 140 sessions where just audio is exchanged. 142 ISUP [12] is a level 4 protocol used in SS7 networks. It typically 143 runs over MTP although it can also run over IP (see SCTP [19]). ISUP 144 is used for controlling telephone calls and for maintenance of the 145 network (blocking circuits, resetting circuits etc.). 147 A module performing the mapping between these two protocols is 148 usually referred to as Media Gateway Controller (MGC), although the 149 terms 'softswitch' or 'call agent' are also sometimes used. An MGC 150 has logical interfaces facing both networks, the network carrying 151 ISUP and the network carrying SIP. The MGC also has some 152 capabilities for controlling the voice path; there is typically a 153 Media Gateway (MG) with E1/T1 trunking interfaces (voice from PSTN) 154 and with IP interfaces (VoIP). The MGC and the MG can be merged 155 together in one physical box or kept separate. 157 These MGCs are frequently used to bridge SIP and ISUP networks so 158 that calls originating in the PSTN can reach IP telephone endpoints 159 and vice versa. This is useful for cases in which PSTN calls need to 160 take advantage of services in IP world, in which IP networks are used 161 as transit networks for PSTN-PSTN calls, architectures in which calls 162 originate on desktop 'softphones' but terminate at PSTN terminals, 163 and many other similar next-generation telephone architectures. 165 This document describes logic and procedures which an MGC might use 166 to implement the mapping between SIP and ISUP by illustrating the 167 correspondences, at the message level and parameter level, between 168 the protocols. It also describes the interplay between parallel 169 state machines for these two protocols as a recommendation for 170 implementers to synchronize protocol events in interworking 171 architectures. 173 2. Scope 175 This document focuses on the translation of ISUP messages into SIP 176 messages, and the mapping of ISUP parameters into SIP headers. For 177 ISUP calls that traverse a SIP network, the purpose of translation is 178 to allow SIP elements such as proxy servers (which do not typically 179 understand ISUP) to make routing decisions based on ISUP criteria 180 such as the called party number. This document consequently provides 181 a SIP mapping only for those ISUP parameters which might be used by 182 intermediaries in the routing of SIP requests. As a side effect of 183 this approach, translation also increases the overall 184 interoperability by providing critical information about the call to 185 SIP endpoints that cannot understand encapsulated ISUP, or perhaps 186 which merely cannot understand the particular ISUP variant 187 encapsulated in a message. 189 This document also only takes into account the call functionality of 190 ISUP. Maintenance messages dealing with PSTN trunks are treated only 191 as far as they affect the control of an ongoing call; otherwise these 192 message neither have nor require any analog in SIP. 194 Messages indicating error or congestion situations in the PSTN (MTP- 195 3) and the recovery mechanisms used such as User Part Available and 196 User Part Test ISUP messages are outside the scope of this document 198 There are several flavors of ISUP. ITU-T Q.767 International ISUP 199 [10] is used through this document; some differences with ANSI [11] 200 ISUP and TTC ISUP are outlined. ISUP Q.767 is used in this document 201 because it is the least complex of all the ISUP flavors. Due to the 202 small number of fields that map directly from ISUP to SIP, the 203 signaling differences between Q.767 and specific national variants of 204 ISUP will generally have little to no impact on the mapping. Note, 205 however, that the ITU-T has not substantially standardized practices 206 for Local Number Portability since portability tends to be grounded 207 in national numbering plan practices, and that consequently LNP must 208 be described on a virtually per-nation basis. The number portability 209 practices described in this document are presented as an optional 210 mechanism. 212 Mapping of SIP headers to ISUP parameters in this document focuses 213 largely on the mapping between the parameters found in the ISUP 214 Initial Address Message (IAM) and the headers associated with the SIP 215 INVITE message; both of these messages are used in their respective 216 protocols to request the establishment of a call. Once an INVITE has 217 been sent for a particular session, such headers as the To and From 218 field become essentially fixed, and no further translation will be 219 required during subsequent signaling, which is routed in accordance 220 with Via and Route headers. Hence, the problem of parameter-to- 221 header mapping in SIP-T is confined more or less to the IAM and the 222 INVITE. Some additional detail is given in the population of 223 parameters in the ISUP ACM and REL messages based on SIP status 224 codes. 226 This document describes when the media path associated with a SIP 227 call is to be initialized, terminated, modified, etc., but it does 228 not go into details such as how the initialization is performed or 229 which protocols are used for that purpose. 231 3. Terminology 233 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 234 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 235 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 236 described in RFC2119 [2] and indicate requirement levels for 237 compliant SIP implementations. 239 4. Scenarios 241 There are several scenarios where ISUP-SIP mapping takes place. The 242 way the messages are generated is different depending on the 243 scenario. 245 When there is a single MGC and the call is from a SIP phone to a PSTN 246 phone, or vice versa, the MGC generates the ISUP messages based on 247 the methods described in this document. 249 +-------------+ +-----+ +-------------+ 250 | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | 251 +-------------+ +-----+ +-------------+ 253 The scenario where a call originates in the PSTN, goes into a SIP 254 network and terminates in the PSTN again is known as "SIP bridging". 255 SIP bridging should provide ISUP transparency between the PSTN 256 switches handling the call. This is achieved by encapsulating the 257 incoming ISUP messages in the body of the SIP messages (see [3]). In 258 this case, the ISUP messages generated by the egress MGC are the ones 259 present in the SIP body (possibly with some modifications; for 260 example, if the called number in the request URI is different from 261 the one present in the ISUP due to SIP redirection, the ISUP message 262 will need to be adjusted). 264 +------+ +-------------+ +-----+ +------------+ +------+ 265 | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 266 +------+ +-------------+ +-----+ +------------+ +------+ 268 SIP is used in the middle of both MGCs because the voice path has to 269 be established through the IP network between both MGs; this 270 structure also allows the call to take advantage of certain SIP 271 services. ISUP messages in the SIP bodies provide further 272 information (such as cause values and optional parameters) to the 273 peer MGC. 275 In both scenarios, the ingress MGC places the incoming ISUP messages 276 in the SIP body by default. Note that this has security 277 implications; see Section 15. If the recipient of these messages 278 (typically a SIP UAC/UAS) does not understand them a negotiation 279 using the SIP `Accept' and `Require' headers will take place and they 280 will not be included in the next SIP message exchange. 282 There can be a Signaling Gateway (SG) between the PSTN and the MGC. 283 It encapsulates the ISUP messages over IP in a manner such as the one 284 described in [19]. The mapping described in this document is not 285 affected by the underlying transport protocol of ISUP. 287 Note that overlap dialing mechanisms (use of the Subsequent Address 288 Message, SAM) are outside the scope of this document. This document 289 assumes that gateways facing ISUP networks in which overlap dialing 290 is used will implement timers to insure that all digits have been 291 collected before an INVITE is transmitted to a SIP network. 293 In some instances, gateways may receive incomplete ISUP messages 294 which indicate message segmentation due to excessive message length. 295 Commonly these messages will be followed by a Segmentation Message 296 (SGM) containing the remainder of the original ISUP message. An 297 incomplete message may not contain sufficient parameters to allow for 298 a proper mapping to SIP; similarly, encapsulating (see below) an 299 incomplete ISUP message may be confusing to terminating gateways. 300 Consequently, a gateway MUST wait until a complete ISUP message is 301 received (which may involve waiting until one or more SGMs arrive) 302 before sending any corresponding INVITE. 304 5. SIP Mechanisms Required 306 For a correct mapping between ISUP and SIP, some SIP mechanisms above 307 and beyond those available in the base SIP specification are needed. 308 These mechanisms are discussed below. If the SIP UAC/UAS involved in 309 the call does not support them, it is still possible to proceed, but 310 the behavior in the establishment of the call may be slightly 311 different than that expected by the user (e.g. other party answers 312 before receiving the ringback tone, user is not informed about the 313 call being forwarded, etc.). 315 5.1 'Transparent' Transit of ISUP Messages 317 To allow gateways to take advantage of the full range of services 318 afforded by the existing telephone network when placing calls from 319 PSTN to PSTN across a SIP network, SIP messages MUST be capable of 320 transporting ISUP payloads from gateway to gateway. The format for 321 encapsulating these ISUP messages is defined in [3]. 323 SIP user agents which do not understand ISUP are permitted to ignore 324 these optional MIME bodies. 326 5.2 Understanding MIME Multipart Bodies 328 In most PSTN interworking situations, SIP message bodies will be 329 required to carry session information (SDP) in addition to ISUP 330 and/or billing information. 332 PSTN interworking nodes MUST understand the MIME type of 333 "multipart/mixed" as defined in RFC2046 [4]. Clients express support 334 for this by including "multipart/mixed" in an "Accept" header. 336 5.3 Transmission of DTMF Information 338 How DTMF tones played by the user are transmitted by a gateway is 339 completely orthogonal to how SIP and ISUP are interworked; however, 340 as DTMF carriage is a component of a complete gatewaying solution 341 some guidance is offered here. 343 Since the codec selected for voice transmission may not be ideally 344 suited for carrying DTMF information, a symbolic method of 345 transmitting this information in-band is desirable (since out-of-band 346 transmission alone would provide many challenges for synchronization 347 of the media stream for tone re-insertion). This transmission MAY be 348 performed as described in RFC2833 [5]. 350 5.4 Reliable Transmission of Provisional Responses 352 Provisional responses (in the 1xx class) are used in the transmission 353 of call progress information. PSTN interworking in particular relies 354 on these messages for control of the media channel and timing of call 355 events. 357 When interworking with the PSTN, SIP messages MUST be sent reliably 358 end-to-end; reliability of requests is guaranteed by the base 359 protocol. One application-layer provisional reliability mechanism 360 for responses is described in [18]. 362 5.5 Early Media 364 Early media denotes the capability to play media (audio for 365 telephony) before a SIP session has been established (before a 2xx 366 response code has been sent). For telephony, establishment of media 367 in the backwards direction is desirable so that tones and 368 announcements can be played, especially when interworking with a 369 network that cannot signal call status out of band (such as a legacy 370 MF network). In cases where interworking has not been encountered, 371 use of early media is almost always undesirable since it consumes 372 inter-machine trunk recourses to play media for which no revenue is 373 collected. Note that since an INVITE almost always contains the SDP 374 required to send media in the backwards direction, and requires that 375 user agents prepare themselves to receive backwards media as soon as 376 an INVITE transmitted, the baseline SIP protocol has enough support 377 to enable rudimentary unidirectional early media systems. However, 378 this mechanism has a number of limitations - for example, media 379 streams offered in the SDP of the INVITE cannot be modified or 380 declined, and bidirectional RTCP required for session maintenance 381 cannot be established. 383 Therefore gateways MAY support more sophisticated early media systems 384 as they come to be better understood. One mechanism that provides a 385 way of initiating a fully-featured early media system is described in 386 [20]. 388 Note that in SIP networks not just switches but also user agents can 389 generate the 18x response codes and initiate early backwards media, 390 and that therefore some gateways may wish to enforce policies that 391 restrict the use of backwards media from arbitrary user agents (see 392 Section 15). 394 5.6 Mid-Call Transactions which do not change SIP state 396 When interworking with the PSTN, there are situations when gateways 397 will need to send messages to each other over SIP that do not 398 correspond to any SIP operations. 400 In support of mid-call transactions and other ISUP events that do not 401 correspond to existing SIP methods, SIP gateways MUST support the 402 INFO method, defined in RFC2976 [6]. Note that this document does 403 not prescribe or endorse the use of INFO to carry DTMF digits. 405 Gateways MUST accept "405 Method Not Allowed" and "501 Not 406 Implemented" as non-fatal responses to INFO requests - that is, any 407 call in progress MUST NOT be torn down if a destination so rejects an 408 INFO request sent by a gateway. 410 5.7 Privacy Protection 412 ISUP has a concept of presentation restriction - a mechanism by which 413 a user can specify that they would not like their telephone number to 414 be displayed to the person they are calling (presumably someone with 415 Caller ID). When a gateway receives an request ISUP that requires 416 presentation restriction, it must therefore shield the identity of 417 the caller in some fashion. 419 The base SIP protocol supports a method of specifying that a user is 420 anonymous. However, this system has a number of limitations - for 421 example, it reveals the identity of the gateway itself, which could 422 be a privacy-impacting disclosure. Therefore gateways MAY support 423 more sophisticated privacy systems. One mechanism that provides a 424 way of supporting fully-featured privacy negotiation (which interacts 425 well with identity management systems) is described in [20]. 427 5.8 CANCEL causes 429 There is a way in ISUP to signal that you like to discontinue an 430 attempt to set up a call - the general-purpose RELease message is 431 sent in the forwards direction. There is a similar concept in SIP - 432 that of a CANCEL request that is sent in order to discontinue the 433 establishment of a SIP dialog. For various reasons, however, CANCEL 434 requests cannot contain message bodies, and therefore in order to 435 carry the important information in the REL (the cause code) end-to- 436 end in sip bridging cases, ISUP encapsulation cannot be used. 438 Ordinarily, this is not a big problem, because for practical purposes 439 the only reason that a REL is ever issued to cancel a call setup 440 attempt is that a user hangs up the phone while it is still ringing 441 (which results in a "Normal clearing" cause code). However, under 442 exceptions conditions, like catastrophic network failure, a REL may 443 be sent with a different cause code, and it would be handy if a SIP 444 network could carry the cause code end-to-end. Therefore gateways 445 MAY support a mechanism for end-to-end delivery of such failure 446 reasons. One mechanism that provides this capability is described in 447 [9]. 449 6. Mapping 451 The mapping between ISUP and SIP is described using call flow 452 diagrams and state machines. One state machine handles calls from 453 SIP to ISUP and the second from ISUP to SIP. There are details, such 454 as some retransmissions and some states (waiting for RLC, waiting for 455 ACK etc.), that are not shown in the figures in order to make them 456 easier to follow. 458 The boxes represent the different states of the gateway, and the 459 arrows show changes in the state. The event that triggers the change 460 in the state and the actions to take appear on the arrow: event / 461 section describing the actions to take. 463 For example, `INVITE / 7.2.1' indicates that an INVITE request has 464 been received by the gateway, and the procedure upon reception is 465 described in the section 7.2.1 of this document. 467 It is RECOMMENDED that gateways implement functional equivalence with 468 the call flows detailed in Section 7.1 and Section 8.1. Deviations 469 from these flows are permissible in support of national ISUP 470 variants, or any of the conservative policies recommended in Section 471 15. 473 7. SIP to ISUP Mapping 475 7.1 SIP to ISUP Call flows 477 The following call flows illustrate the order of messages in typical 478 success and error cases when setting up a call initiated from the SIP 479 network. "100 Trying" acknowledgements to INVITE requests are not 480 displayed below although they are required in many architectures. 482 In these diagrams, all call signaling (SIP, ISUP) is going to and 483 from the MGC; media handling (e.g. audio cut-through, trunk freeing) 484 is being performed by the MG, under the control of the MGC. For the 485 purpose of simplicity, these are shown as a single node, labeled 486 "MGC/MG." 488 7.1.1 En-bloc Call Setup (no auto-answer) 490 SIP MGC/MG PSTN 491 1|---------INVITE---------->| | 492 |<----------100------------| | 493 | |------------IAM---------->|2 494 | |<=========Audio===========| 495 | |<-----------ACM-----------|3 496 4|<----------18x------------| | 497 |<=========Audio===========| | 498 | |<-----------CPG-----------|5 499 6|<----------18x------------| | 500 | |<-----------ANM-----------|7 501 | |<=========Audio==========>| 502 8|<----------200------------| | 503 |<=========Audio==========>| | 504 9|-----------ACK----------->| | 506 1. When a SIP user wishes to begin a session with a PSTN user, the 507 SIP node issues an INVITE request. 509 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 510 message and sends it to the ISUP network. 512 3. The remote ISUP node indicates that the address is sufficient to 513 set up a call by sending back an ACM message. 515 4. The "called party status" code in the ACM message is mapped to a 516 SIP provisional response (as described in Section 7.2.5 and 517 Section 7.2.6). and returned to the SIP node. This response may 518 contain SDP to establish an early media stream (as shown in the 519 diagram). If no SDP is present, the audio will be established in 520 both directions after step 8. 522 5. If the ISUP variant permits, the remote ISUP node may issue a 523 variety of CPG messages to indicate, for example, that the call 524 is being forwarded. 526 6. Upon receipt of a CPG message, the gateway will map the event 527 code to a SIP provisional response (see Section 7.2.9) and send 528 it to the SIP node. 530 7. Once the PSTN user answers, an ANM message will be sent to the 531 gateway. 533 8. Upon receipt of the ANM, the gateway will send a 200 message to 534 the SIP node. 536 9. The SIP node, upon receiving an INVITE final response (200), will 537 send an ACK to acknowledge receipt. 539 7.1.2 Auto-answer call setup 541 SIP MGC/MG PSTN 542 1|---------INVITE---------->| | 543 |<----------100------------| | 544 | |------------IAM---------->|2 545 | |<=========Audio===========| 546 | |<-----------CON-----------|3 547 | |<=========Audio==========>| 548 4|<----------200------------| | 549 |<=========Audio==========>| | 550 5|-----------ACK----------->| | 552 Note that this flow is not supported in ANSI networks. 554 1. When a SIP user wishes to begin a session with a PSTN user, the 555 SIP node issues an INVITE request. 557 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 558 message and sends it to the ISUP network. 560 3. Since the remote node is configured for automatic answering, it 561 will send a CON message upon receipt of the IAM. (For ANSI, this 562 message will be an ANM). 564 4. Upon receipt of the CON, the gateway will send a 200 message to 565 the SIP node. 567 5. The SIP node, upon receiving an INVITE final response (200), will 568 send an ACK to acknowledge receipt. 570 7.1.3 ISUP T7 Expires 572 SIP MGC/MG PSTN 573 1|---------INVITE---------->| | 574 |<----------100------------| | 575 | |------------IAM---------->|2 576 | |<=========Audio===========| 577 | | *** T7 Expires *** | 578 | ** MG Releases PSTN Trunk ** | 579 4|<----------504------------|------------REL---------->|3 580 5|-----------ACK----------->| | 582 1. When a SIP user wishes to begin a session with a PSTN user, the 583 SIP node issues an INVITE request. 585 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 586 message and sends it to the ISUP network. The ISUP timer T7 is 587 started at this point. 589 3. The ISUP timer T7 expires before receipt of an ACM or CON 590 message, so a REL message is sent to cancel the call. 592 4. A gateway timeout message is sent back to the SIP node. 594 5. The SIP node, upon receiving an INVITE final response (504), will 595 send an ACK to acknowledge receipt. 597 7.1.4 SIP Timeout 599 SIP MGC/MG PSTN 600 1|---------INVITE---------->| | 601 |<----------100------------| | 602 | |------------IAM---------->|2 603 | |<=========Audio===========| 604 | |<-----------CON-----------|3 605 | |<=========Audio==========>| 606 4|<----------200------------| | 607 | *** T1 Expires *** | | 608 |<----------200------------| | 609 | *** T1 Expires *** | | 610 |<----------200------------| | 611 | *** T1 Expires *** | | 612 |<----------200------------| | 613 | *** T1 Expires *** | | 614 |<----------200------------| | 615 | *** T1 Expires *** | | 616 |<----------200------------| | 617 | *** T1 Expires *** | | 618 5|<----------200------------| | 619 | *** T1 Expires *** | | 620 | ** MG Releases PSTN Trunk ** | 621 7|<----------BYE------------|------------REL---------->|6 622 | |<-----------RLC-----------|8 624 1. When a SIP user wishes to begin a session with a PSTN user, the 625 SIP node issues an INVITE request. 627 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 628 message and sends it to the ISUP network. 630 3. Since the remote node is configured for automatic answering, it 631 will send a CON message upon receipt of the IAM. In ANSI flows, 632 rather than a CON an ANM (without ACM) would be sent. 634 4. Upon receipt of the ANM, the gateway will send a 200 message to 635 the SIP node and set SIP timer T1. 637 5. The response is retransmitted every time the SIP timer T1 638 expires. 640 6. After seven retransmissions, the call is torn down by sending a 641 REL to the ISUP node, with a cause code of 102 (recover on timer 642 expiry). 644 7. A BYE is transmitted to the SIP node in an attempt to close the 645 call. Further handling for this clean up is not shown, since the 646 SIP node's state is not easily known in this scenario. 648 8. Upon receipt of the REL message, the remote ISUP node will reply 649 with an RLC message. 651 7.1.5 ISUP Setup Failure 653 SIP MGC/MG PSTN 654 1|---------INVITE---------->| | 655 |<----------100------------| | 656 | |------------IAM---------->|2 657 | |<-----------REL-----------|3 658 | |------------RLC---------->|4 659 5|<----------4xx+-----------| | 660 6|-----------ACK----------->| | 662 1. When a SIP user wishes to begin a session with a PSTN user, the 663 SIP node issues an INVITE request. 665 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 666 message and sends it to the ISUP network. 668 3. Since the remote ISUP node is unable to complete the call, it 669 will send a REL. 671 4. The gateway releases the circuit and confirms that it is 672 available for reuse by sending an RLC. 674 5. The gateway translates the cause code in the REL to a SIP error 675 response (see Section 7.2.4) and sends it to the SIP node. 677 6. The SIP node sends an ACK to acknowledge receipt of the INVITE 678 final response. 680 7.1.6 Cause Present in ACM Message 682 SIP MGC/MG PSTN 683 1|---------INVITE---------->| | 684 |<----------100------------| | 685 | |------------IAM---------->|2 686 | |<=========Audio===========| 687 | |<---ACM with cause code---|3 688 4|<------183 with SDP-------| | 689 |<=========Audio===========| | 690 ** Interwork timer expires ** 691 5|<----------4xx+-----------| | 692 | |------------REL---------->|6 693 | |<-----------RLC-----------|7 694 8|-----------ACK----------->| | 696 1. When a SIP user wishes to begin a session with a PSTN user, the 697 SIP node issues an INVITE request. 699 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 700 message and sends it to the ISUP network. 702 3. Since the ISUP node is unable to complete the call and wants to 703 generate the error tone/announcement itself, it sends an ACM with 704 a cause code. The gateway starts an interwork timer. 706 4. Upon receipt of an ACM with cause (presence of the CAI 707 parameter), the gateway will generate a 183 message towards the 708 SIP node; this contains SDP to establish early media cut-through. 710 5. A final INVITE response, based on the cause code received in the 711 earlier ACM message, is generated and sent to the SIP node to 712 terminate the call. See Section 7.2.4.1 for the table which 713 contains the mapping from cause code to SIP response. 715 6. Upon expiration of the interwork timer, a REL is sent towards the 716 PSTN node to terminate the call. Note that the SIP node can also 717 terminate the call by sending a CANCEL before the interwork timer 718 expires. In this case, the signaling progresses as in Section 719 7.1.7. 721 7. Upon receipt of the REL message, the remote ISUP node will reply 722 with an RLC message. 724 8. The SIP node sends an ACK to acknowledge receipt of the INVITE 725 final response. 727 7.1.7 Call Canceled by SIP 729 SIP MGC/MG PSTN 730 1|---------INVITE---------->| | 731 |<----------100------------| | 732 | |------------IAM---------->|2 733 | |<=========Audio===========| 734 | |<-----------ACM-----------|3 735 4|<----------18x------------| | 736 |<=========Audio===========| | 737 | ** MG Releases IP Resources ** | 738 5|----------CANCEL--------->| | 739 6|<----------200------------| | 740 | ** MG Releases PSTN Trunk ** | 741 | |------------REL---------->|7 742 8|<----------487------------| | 743 | |<-----------RLC-----------|9 744 10|-----------ACK----------->| | 746 1. When a SIP user wishes to begin a session with a PSTN user, the 747 SIP node issues an INVITE request. 749 2. Upon receipt of an INVITE request, the gateway maps it to an IAM 750 message and sends it to the ISUP network. 752 3. The remote ISUP node indicates that the address is sufficient to 753 set up a call by sending back an ACM message. 755 4. The "called party status" code in the ACM message is mapped to a 756 SIP provisional response (as described in Section 7.2.5 and 757 Section 7.2.6) and returned to the SIP node. This response may 758 contain SDP to establish an early media stream. 760 5. To cancel the call before it is answered, the SIP node sends a 761 CANCEL request. 763 6. The CANCEL request is confirmed with a 200 response. 765 7. Upon receipt of the CANCEL request, the gateway sends a REL 766 message to terminate the ISUP call. 768 8. The gateway sends a "487 Call Cancelled" message to the SIP node 769 to complete the INVITE transaction. 771 9. Upon receipt of the REL message, the remote ISUP node will reply 772 with an RLC message. 774 10. Upon receipt of the 487, the SIP node will confirm reception 775 with an ACK. 777 7.2 State Machine 779 Note that REL can be received in any state; the handling is the same 780 for each case (see Section 10). 782 +---------+ 783 +----------------------->| Idle |<---------------------+ 784 | +----+----+ | 785 | | | 786 | | INVITE/6.2.1 | 787 | V | 788 | T7/6.2.2 +-------------------------+ REL/6.2.4 | 789 +<----------------+ Trying +------------>+ 790 | +-+--------+------+-------+ | 791 | CANCEL/6.2.3 | | | | | 792 +<----------------+ | E.ACM/ | ACM/ | CON/ANM | 793 | | 6.2.5 |6.2.6 | 6.2.7 | 794 | V | | | 795 | T9/6.2.8 +--------------+ | | | 796 +<----------+ Not alerting | | | | 797 | +-------+------+ | | | 798 | CANCEL/6.2.3 | | | | | 799 |<--------------+ | CPG/ | | | 800 | | 6.2.9 | | | 801 | V V | | 802 | T9/6.2.8 +---------------+ | REL/6.2.4 | 803 +<----------------+ Alerting |-|-------------------->| 804 |<----------------+--+-----+------+ | | 805 | CANCEL/6.2.3 | ^ | | | 806 | CPG/ | | | ANM/ | | 807 | 6.2.9 +--+ | 6.2.7 | | 808 | V V | 809 | +-------------------------+ REL/9.2 | 810 | | Waiting for ACK |------------>| 811 | +-------------+-----------+ | 812 | | | 813 | | ACK/6.2.10 | 814 | V | 815 | BYE/9.1 +-------------------------+ REL/9.2 | 816 +<----------------+ Connected +------------>+ 817 +-------------------------+ 819 7.2.1 INVITE received 821 When an INVITE request is received by the gateway, a "100 Trying" 822 response MAY be sent back to the SIP network indicating that the 823 gateway is handling the call. 825 The necessary hardware resources for the media stream MUST be 826 reserved in the gateway when the INVITE is received, since an IAM 827 message cannot be sent before the resource reservation (especially 828 TCIC selection) takes place. Typically the resources consist of a 829 time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources 830 might also include any quality-of-service provisions (although no 831 such practices are recommended in this draft). Before sending an IAM 832 the gateway SHOULD connect the backward media path (unless provider 833 policy dictates that doing so is unsafe; see Section 15). 835 After sending the IAM the timer T7 is started. The default value of 836 T7 is between 20 and 30 seconds. The gateway goes to the `Trying' 837 state. 839 7.2.1.1 INVITE to IAM procedures 841 This section details the mapping of the SIP headers in an INVITE 842 message to the ISUP parameters in an Initial Address Message (IAM). 843 A PSTN-SIP gateway is responsible for creating an IAM when it 844 receives an INVITE. 846 Five mandatory parameters appear within the IAM message: the Called 847 Party Number (CPN), the Nature of Connection Indicator (NCI), the 848 Forward Call Indicators (FCI), the Calling Party's Category (CPC), 849 and finally a parameter that indicates the desired bearer 850 characteristics of the call - in some ISUP variants the Transmission 851 Medium Requirement (TMR) is required, in others the User Service 852 Information (USI) (or both). All IAM messages MUST contain these 853 five parameters at a minimum. Thus, every gateway must have a means 854 of populating each of those five parameters when an INVITE is 855 received. Many of the values that will appear in these parameters 856 (such as the NCI or USI) will most likely be the same for each IAM 857 created by the gateway. Others (such as the CPN) will vary on a 858 call-by-call basis; the gateway extracts information from the INVITE 859 in order to properly populate these parameters. 861 There are also quite a few optional parameters that can appear in an 862 IAM message; Q.763 [17] lists 29 in all. However, each of these 863 parameters need not to be translated in order to achieve the goals of 864 SIP-ISUP mapping. As is stated above, translation allows SIP network 865 elements to understand the basic PSTN context of the session (who it 866 is for, and so on) if they are not capable of deciphering any 867 encapsulated ISUP. Parameters that are only meaningful to the PSTN 868 will be carried through PSTN-SIP- PSTN networks via encapsulation - 869 translation is not necessary for these parameters. Of the 870 aforementioned 29 optional parameters, only the following are 871 immediately useful for translation: the Calling Party's Number (CIN, 872 which is commonly present), Transit Network Selection (TNS), Carrier 873 Identification Parameter (CIP, present in ANSI networks), Original 874 Called Number (OCN), and the Generic Digits (known in some variants 875 as the Generic Address Parameter (GAP)). 877 When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD 878 attempt to make use of encapsulated ISUP (see [3]), if any, within 879 the INVITE to assist in the formulation of outbound PSTN signaling. 880 If possible, the gateway SHOULD reuse the values of each of the ISUP 881 parameters of the encapsulated IAM as it formulates an IAM that it 882 will send across its PSTN interface. In some cases, the gateway will 883 be unable to make use of that ISUP - for example, if the gateway 884 cannot understand the ISUP variant and must therefore ignore the 885 encapsulated body. Even when there is comprehensible encapsulated 886 ISUP, the relevant values of SIP header fields MUST 'overwrite' 887 through the process of translation the parameter values that would 888 have been set based on encapsulated ISUP. In other words, the 889 updates to the critical session context parameters that are created 890 in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases, 891 over the encapsulated ISUP. This allows many basic services, 892 including various sorts of call forwarding and redirection, to be 893 implemented in the SIP network. 895 For example, if an INVITE arrives at a gateway with an encapsulated 896 IAM with a CPN field indicating the telephone number +12025332699, 897 but the Request-URI of the INVITE indicates 'tel:+15105550110', the 898 gateway MUST use the telephone number in the Request-URI, rather than 899 the one in the encapsulated IAM, when creating the IAM that the 900 gateway will send to the PSTN. Further details of how SIP header 901 fields are translated into ISUP parameters follow. 903 Gateways MUST be provisioned with default values for mandatory ISUP 904 parameters that cannot derived from translation(such as the NCI or 905 TMR parameters) for those cases in which no encapsulated ISUP is 906 present. The FCI parameter MUST also have a default, as only the 'M' 907 bit of the default may be overwritten during the process of 908 translation if the optional number portability translation mechanisms 909 described below are used. 911 The first step in the translation of the fields of an INVITE message 912 to the parameters of an IAM is the inspection of the Request-URI. 914 If the optional number portability practices are supported by the 915 gateway, then the following steps related to handling of the 'npdi' 916 and 'rn' parameters of the Request-URI should be followed. 918 If there is no 'npdi=yes' field within the Request-URI, then the 919 primary telephone number in the tel URL (the digits immediately 920 following 'tel:') MUST be converted to ISUP format, following the 921 procedures described in Section 12, and used to populate the CPN 922 parameter. 924 If the 'npdi=yes' field exists in the Request-URI, then the FCI 925 parameter bit for 'number translated' within the IAM MUST reflect 926 that a number portability dip has been performed. 928 If in addition to the 'npdi=yes' field there is no 'rn=' field 929 present, then the main telephone number in the tel URL MUST be 930 converted to ISUP format (see Section 12) and used to populate the 931 CPN parameter. This indicates that a portability dip took place, but 932 that the called party's number was not ported. 934 If in addition to the 'npdi=yes' field an 'rn=' field is present, 935 then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format 936 and used to populate the CPN. The main telephone number in the tel 937 URL MUST be converted to ISUP format and used to populate the Generic 938 Digits Parameter (or GAP in ANSI). In some other ISUP variants, the 939 number given in the 'rn=' field is instead be prepended to the main 940 telephone number (with or without a prefix or separator) and the 941 combined result MUST be used to populate the CPN. Once the 'rn=' and 942 'npdi=' parameters have been translation, the number portability 943 translation practices are complete. 945 The following mandatory translation practices are performed after 946 number portability translations, if any. 948 If number portability practices are not supported by the gateway, 949 then the primary telephone number in the tel URL (the digits 950 immediately following 'tel:') MUST be converted to ISUP format, 951 following the procedures described in Section 12, and used to 952 populate the CPN parameter. 954 If primary telephone number in the Request-URI and that of the To 955 header are at variance, then the To header SHOULD be used to populate 956 an OCN parameter. Otherwise the To header SHOULD be ignored. 958 Some optional translation procedures are provided for carrier-based 959 routing. If the 'cic=' parameter is present in the Request-URI, the 960 gateway SHOULD consult local policy to make sure that it is 961 appropriate to transmit this Carrier Identification Code (CIC, not to 962 be confused with the MTP3 'circuit identification code') in the IAM - 963 if the gateway supports many independent trunks, it may need to 964 choose a particular trunk that points to the carrier identified by 965 the CIC, or a tandem through which that carrier is reachable. 966 Policies for such trunks (based on the preferences of the carriers 967 with which the trunks are associated and the ISUP variant in use) 968 SHOULD dictate whether the CIP or TNS parameter is used to carry the 969 CIC. In the absence of any pre-arranged policies, the TNS should be 970 used when the CPN parameter is in an international format (i.e. the 971 tel URL portion of the Request-URI is preceded by a '+', which will 972 generate a CPN in international format), and (where supported) the 973 CIP should be used in other cases. 975 When a SIP call has been routed to a gateway, then the Request-URI 976 will most likely contain a tel URL (or a SIP URI with a tel URL user 977 portion) - SIP-ISUP gateways that receive Request-URIs that do not 978 contain telephone numbers SHOULD reject such requests with an 979 appropriate response code. Gateways SHOULD however continue to 980 process requests with a From header field that does not contain a 981 telephone number, as will sometimes be the case if a call originated 982 at a SIP phone that employs a SIP URI user@host convention. The CIN 983 parameter SHOULD be omitted from the outbound IAM if the From field 984 is unusable. Note that as an alternative gateways implementers MAY 985 consider some non-standard way of mapping particular SIP URIs to 986 telephone numbers. 988 When a gateway receives a message with (comprehensible) encapsulated 989 ISUP, it MUST set the value of the FCI indicator parameter that is 990 present in the message for all bits in the parameter related to 991 interworking (unless interworking has been encountered somewhere else 992 in the call path, these indicators will most likely state that no 993 interworking was encountered). If usable encapsulated ISUP is not 994 present in an INVITE received by the gateway, it is RECOMMENDED that 995 the set the 'interworking encountered' bit of the FCI to 996 'interworking encountered' and set the two ISDN access parameters, 997 the ISDN User Part Indicator and the Originating Access indicator, to 998 state that ISDN is not available for the entire call path (values of 999 'ISDN not used all the way' and 'Originating access non-ISDN', 1000 respectively). 1002 Note that when the ISUP parameters regarding interworking are set in 1003 the Forward Call Indicators (FCI) parameter of the IAM, this 1004 indicates that ISDN is interworking with a network which is not 1005 capable of providing as many services as ISDN does. ISUP will 1006 therefore not employ certain features it otherwise normally uses. 1007 Gateway vendors therefore MAY provide a configurable option, usable 1008 at the discretion of service providers, that when encapsulated will 1009 signal in the FCI that no interworking has been encountered. When 1010 ISUP feature transparency is available, `interworking encountered' 1011 MUST NOT be specified so that ISUP behaves normally. 1013 Claiming to be an ISDN node might make the callee request ISDN user 1014 to user services. Since user to user services 1 and 2 must be 1015 requested by the caller, they do not represent a problem (see [14]). 1016 User to user service 3 can be requested by the callee also. In non- 1017 SIP bridging situations, the MGC should be capable of rejecting this 1018 service request. 1020 7.2.2 ISUP T7 expires 1022 Since no response was received from the PSTN all the resources in the 1023 MG are released. A `504 Server Timeout' SHOULD be sent back to the 1024 SIP network. A REL message with cause value 102 (protocol error, 1025 recovery on timer expiry) SHOULD sent to the PSTN. Gateways can 1026 expect the PSTN to respond with RLC and the SIP network to respond 1027 with an ACK indicating that the release sequence has been completed. 1029 7.2.3 CANCEL or BYE received 1031 If a CANCEL or BYE request is received before a final SIP response 1032 has been sent, a `200 OK' MUST be sent to the SIP network to confirm 1033 the CANCEL or BYE; a 487 MUST also sent to terminate the INVITE 1034 transaction. All the resources are released and a REL message SHOULD 1035 be sent to the PSTN with cause value 16 (normal clearing). Gateways 1036 can expect an RLC from the PSTN to be received indicating that the 1037 release sequence is complete. 1039 In SIP bridging situations, a REL might be encapsulated in the body 1040 of a BYE request. Although BYE is usually mapped to cause code 16 1041 (normal clearing), under exceptional circumstances the cause code in 1042 the REL message might be different. Therefore the Cause Indicator 1043 parameter of the encapsulated REL should be re-used in the REL sent 1044 to the PSTN. 1046 Note that a BYE or CANCEL request may contain a Reason header that 1047 SHOULD be mapped to the Cause Indicator parameter (see Section 5.8). 1048 If a BYE contains both a Reason header and encapsulated ISUP, the 1049 value in the Reason header MUST be preferred. 1051 All the resources in the gateway SHOULD released before the gateway 1052 sends any REL message. 1054 7.2.4 REL received 1056 This section applies when a REL is received before a final SIP 1057 response has been sent. Typically, this condition arises when a call 1058 has been rejected by the PSTN. 1060 Any gateway resources SHOULD be released immediately and an RLC MUST 1061 be sent to the ISUP network to indicate that the circuit is available 1062 for reuse. 1064 If the INVITE that originated this transaction contained a legitimate 1065 and comprehensible encapsulated ISUP message (i.e. an IAM using a 1066 variant supported by the gateway, preferably with a digital 1067 signature), then encapsulated ISUP SHOULD be sent in the response to 1068 the INVITE when possible (since this suggests an ISUP-SIP-ISUP 1069 bridging case) - therefore, the REL message just received SHOULD be 1070 included in the body of the SIP response. The gateway SHOULD NOT 1071 return a response with encapsulated ISUP if the originator of the 1072 INVITE did not enclose ISUP itself. 1074 Note that the receipt of certain maintenance messages in response to 1075 IAM such as BLO or RSC (or their circuit group message equivalents) 1076 may also result in the teardown of calls in this phase of the state 1077 machine. Behavior for maintenance messages is given below in Section 1078 11. 1080 7.2.4.1 ISDN Cause Code to Status Code Mapping 1082 The use of the REL message in the SS7 network is very general, 1083 whereas SIP has a number of specific tools that, collectively, play 1084 the same role as REL - namely BYE, CANCEL, and the various 1085 status/response codes. An REL can be sent to tear down a call that 1086 is already in progress (BYE), to cancel a previously sent call setup 1087 request that has not yet been completed (CANCEL), or to reject a call 1088 setup request (IAM) that has just been received (corresponding to a 1089 SIP status code). 1091 Note that it is not necessarily appropriate to map some ISDN cause 1092 codes to SIP messages because these cause codes are only meaningful 1093 to the ISUP interface of a gateway. A good example of this is cause 1094 code 44 "Request circuit or channel not available." 44 signifies that 1095 the Circuit Identification Code (CIC) for which an IAM had been sent 1096 was believed by the receiving equipment to be in a state incompatible 1097 with a new call request - however, the appropriate behavior in this 1098 case is for the originating switch to re-send the IAM for a different 1099 CIC, not for the call to be torn down. Clearly, there is not (nor 1100 should there be) an SIP status code indicating that a new CIC should 1101 be selected - this matter is internal to the originating gateway. 1102 Hence receipt of cause code 44 should not result in any SIP status 1103 code being sent; effectively, the cause code is untranslatable. 1105 If a cause value other than those listed below is received, the 1106 default response `500 Server internal error' SHOULD be used. 1108 Finally, in addition to the ISDN Cause Code, the CAI parameter also 1109 contains a cause 'location' that gives some sense of which entity in 1110 the network was responsible for terminating the call (the most 1111 important distinction being between the user and the network). In 1112 most cases, the cause location does not affect the mapping to a SIP 1113 status code; some exceptions are noted below. A diagnostic field may 1114 also be present for some ISDN causes; this diagnostic will contain 1115 additional data pertaining to the termination of the call. 1117 The following mapping values are RECOMMENDED: 1119 Normal event 1121 ISUP Cause value SIP response 1122 ---------------- ------------ 1123 1 unallocated number 404 Not Found 1124 2 no route to network 404 Not found 1125 3 no route to destination 404 Not found 1126 16 normal call clearing --- (*) 1127 17 user busy 486 Busy here 1128 18 no user responding 408 Request Timeout 1129 19 no answer from the user 480 Temporarily unavailable 1130 20 subscriber absent 480 Temporarily unavailable 1131 21 call rejected 403 Forbidden (+) 1132 22 number changed (w/o diagnostic) 410 Gone 1133 22 number changed (w/ diagnostic) 301 Moved Permanently 1134 23 redirection to new destination 410 Gone 1135 26 non-selected user clearing 404 Not Found (=) 1136 27 destination out of order 502 Bad Gateway 1137 28 address incomplete 484 Address incomplete 1138 29 facility rejected 501 Not implemented 1139 31 normal unspecified 480 Temporarily unavailable 1141 (*) ISDN Cause 16 will usually result in a BYE or CANCEL 1143 (+) If the cause location is 'user' than the 6xx code could be given 1144 rather than the 4xx code (i.e. 403 becomes 603) 1146 (=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 1147 'misrouted ported number'. Presumably, a number portability dip 1148 should have been performed by a prior network. Otherwise cause 26 is 1149 usually not used in ISUP procedures. 1151 A REL with ISDN cause 22 (number changed) might contain information 1152 about a new number where the callee might be reachable in the 1153 diagnostic field. If the MGC is able to process this information it 1154 SHOULD be added to the SIP response (301) in a Contact header. 1156 Resource unavailable 1158 This kind of cause value indicates a temporary failure. A `Retry- 1159 After' header MAY be added to the response if appropriate. 1161 ISUP Cause value SIP response 1162 ---------------- ------------ 1163 34 no circuit available 503 Service unavailable 1164 38 network out of order 503 Service unavailable 1165 41 temporary failure 503 Service unavailable 1166 42 switching equipment congestion 503 Service unavailable 1167 47 resource unavailable 503 Service unavailable 1169 Service or option not available 1171 This kind of cause value indicates that there is a problem with the 1172 request, rather something that will resolved itself over time. 1174 ISUP Cause value SIP response 1175 ---------------- ------------ 1176 55 incoming calls barred within CUG 403 Forbidden 1177 57 bearer capability not authorized 403 Forbidden 1178 58 bearer capability not presently 503 Service unavailable 1179 available 1181 Service or option not available 1183 ISUP Cause value SIP response 1184 ---------------- ------------ 1185 65 bearer capability not implemented 488 Not Acceptable Here 1186 70 only restricted digital avail 488 Not Acceptable Here 1187 79 service or option not implemented 501 Not implemented 1189 Invalid message 1191 ISUP Cause value SIP response 1192 ---------------- ------------ 1193 87 user not member of CUG 403 Forbidden 1194 88 incompatible destination 503 Service unavailable 1196 Protocol error 1198 ISUP Cause value SIP response 1199 ---------------- ------------ 1200 102 recovery of timer expiry 504 Gateway timeout 1201 111 protocol error 500 Server internal error 1203 Interworking 1204 ISUP Cause value SIP response 1205 ---------------- ------------ 1206 127 interworking unspecified 500 Server internal error 1208 7.2.5 Early ACM received 1210 An ACM message is sent in certain situations to indicate that the 1211 call is in progress in order to satisfy ISUP timers, rather than to 1212 signify that the callee is being alerted. This occurs for example in 1213 mobile networks, where roaming can delay call setup significantly. 1214 The early ACM is sent before the user is alerted to reset T7 and 1215 start T9. An ACM is considered an `early ACM' if the Called Party's 1216 Status Indicator is set to 00 (no indication). 1218 After sending an early ACM, the ISUP network can be expected to 1219 indicate the further progress of the call by sending CPGs. 1221 When an early ACM is received the gateway SHOULD send a 183 Session 1222 Progress response (see [1]) to the SIP network. In SIP bridging 1223 situations (where encapsulated ISUP was contained in the INVITE that 1224 initiated this call) the early ACM SHOULD also be included in the 1225 response body. 1227 Note that sending 183 before a gateway has confirmation that the 1228 address is complete (ACM) creates known problems in SIP bridging 1229 cases, and it SHOULD NOT therefore be sent. 1231 7.2.6 ACM received 1233 Most commonly, on receipt of an ACM a `180 Ringing' SHOULD be sent to 1234 the SIP network. If the INVITE that initiated this session contained 1235 legitimate and comprehensible encapsulated ISUP, then the ACM 1236 received by the gateway SHOULD be encapsulated in the 180 response. 1238 When it transmits a 180, the gateway also MAY begin to transmit early 1239 media in order to offer special announcements and tones played by the 1240 PSTN. If the Backwards Call Indicator (BCI) parameter of the ACM 1241 indicates that interworking has been encountered (generally 1242 designating that the ISUP network sending the ACM is interworking 1243 with a less sophisticated network which cannot report its status via 1244 out-of-band signaling), then there may be in-band announcements of 1245 call status such as an audible busy tone or caller intercept message, 1246 and if possible an early media transmission SHOULD be initiation. 1247 Early media SHOULD also be transmitted sent if the Optional Backwards 1248 Call Indicator parameter field for in-band media is set. For more 1249 information on early media see Section 5.5. 1251 When a 180 is sent without any early media, it is assumed that any 1252 necessary ringback tones will be generated by the SIP user agent to 1253 which the gateway is responding. 1255 When they receive an ACM, switches in many ISUP networks start a 1256 timer known as "T9" which usually lasts between 90 seconds and 3 1257 minutes (see [13]). When early media is being played, this timer 1258 permits the caller to hear backwards audio media (in the form 1259 ringback, tones or announcements) from a remote switch in the ISUP 1260 network for that period of time without incurring any charge for the 1261 connection. The nearest possible local ISUP exchange to the callee 1262 generates the ringback tone or voice announcements. If longer 1263 announcements have to be played, the network has to send an ANM, 1264 which initiates bidirectional media of indefinite duration. In 1265 common ISUP network practice, billing commences when the ANM is 1266 received. Some networks do not support timer T9. 1268 7.2.7 CON or ANM Received 1270 When an ANM or CON message is received, the call has been answered 1271 and thus `200 OK' response SHOULD be sent to the SIP network. This 1272 200 OK SHOULD contain an answer to the media offered in the INVITE. 1273 In SIP bridging situations (when the INVITE that initiated this call 1274 contained legitimate and comprehensible encapsulated ISUP), the ISUP 1275 message is included in the body of the 200 OK response. If it has 1276 not done so already, the gateway MUST establish a bidirectional media 1277 stream at this time. 1279 When there is interworking with some legacy networks, it is possible 1280 for an ISUP switch to receive an ANM immediately after an early ACM 1281 (without CPG or any other backwards messaging), or without receiving 1282 any ACM at all (when an automaton answers the call). In this 1283 situation the SIP user will never have received a 18x provisional 1284 response, and consequently they will not hear any kind of ringtone 1285 before the callee answers. This may result in some clipping of the 1286 initial forward media from the caller (since forward media 1287 transmission cannot commence until SDP has been acquired from the 1288 destination). In ISDN (see [12]) this is solved by connecting the 1289 voice path backwards before sending the IAM. 1291 7.2.8 Timer T9 Expires 1293 The expiry of this timer (which is not used in all networks) 1294 signifies that an ANM has not arrived a significant period of time 1295 after alerting began (with the transmission of an ACM) for this call. 1296 Usually, this means that the callee's terminal has been alerted for 1297 many rings but has not been answered. It may also occur in 1298 interworking cases when the network is playing a status announcement 1299 (such as one indicating that a number is not in service) that has 1300 cycled several times. Whatever the cause of the protracted 1301 incomplete call, when this timer expires the call MUST be released. 1302 All of the gateway resources related to the media path SHOULD be 1303 released. A `480 Temporarily Unavailable' response code SHOULD be 1304 sent to the SIP network, and an REL message with cause value 19 (no 1305 answer from the user) SHOULD be sent to the ISUP network. The PSTN 1306 can be expected to respond with an RLC and the SIP network to respond 1307 with an ACK indicating that the release sequence has been completed. 1309 7.2.9 CPG Received 1311 A CPG is a provisional message that can indicate progress, alerting 1312 or in-band information. If a CPG suggests that in-band information 1313 is available, the gateway SHOULD begin to transmit early media and 1314 cut through the unidirectional backwards media path. 1316 In SIP bridging situations (when the INVITE that initiated this 1317 session contained legitimate and comprehensible encapsulated ISUP), 1318 the CPG SHOULD be sent in the body of a particular 18x response, 1319 determined from the CPG Event Code as follows: 1321 ISUP event code SIP response 1322 ---------------- ------------ 1323 1 Alerting 180 Ringing 1324 2 Progress 183 Session progress 1325 3 In-band information 183 Session progress 1326 4 Call forward; line busy 181 Call is being forwarded 1327 5 Call forward; no reply 181 Call is being forwarded 1328 6 Call forward; unconditional 181 Call is being forwarded 1329 - (no event code present) 183 Session progress 1331 Note that, if the CPG does not indicate "Alerting," the current state 1332 will not change. 1334 7.3 ACK received 1336 At this stage, the call is fully connected and the conversation can 1337 take place. No ISUP message should be sent by the gateway when an 1338 ACK is received. 1340 8. ISUP to SIP Mapping 1342 8.1 ISUP to SIP Call Flows 1344 The following call flows illustrate the order of messages in typical 1345 success and error cases when setting up a call initiated from the 1346 PSTN network. "100 Trying" acknowledgements to INVITE requests are 1347 not depicted, since their presence is optional. 1349 In these diagrams, all call signaling (SIP, ISUP) is going to and 1350 from the MGC; media handling (e.g. audio cut-through, trunk freeing) 1351 is being performed by the MG, under the control of the MGC. For the 1352 purpose of simplicity, these are shown as a single node, labeled 1353 "MGC/MG." 1355 8.1.1 En-bloc call setup (non auto-answer) 1357 SIP MGC/MG PSTN 1358 | |<-----------IAM-----------|1 1359 | |==========Audio==========>| 1360 2|<--------INVITE-----------| | 1361 |-----------100----------->| | 1362 3|-----------18x----------->| | 1363 |==========Audio==========>| | 1364 | |=========================>| 1365 | |------------ACM---------->|4 1366 5|-----------18x----------->| | 1367 | |------------CPG---------->|6 1368 7|-----------200-(I)------->| | 1369 |<=========Audio==========>| | 1370 | |------------ANM---------->|8 1371 | |<=========Audio==========>| 1372 9|<----------ACK------------| | 1374 1. When a PSTN user wishes to begin a session with a SIP user, the 1375 PSTN network generates an IAM message towards the gateway. 1377 2. Upon receipt of the IAM message, the gateway generates an INVITE 1378 message, and sends it to an appropriate SIP node. 1380 3. When an event signifying that the call has sufficient addressing 1381 information occurs, the SIP node will generate a provisional 1382 response of 180 or greater. 1384 4. Upon receipt of a provisional response of 180 or greater, the 1385 gateway will generate an ACM message. If the response is not 1386 180, the ACM will carry a "called party status" value of "no 1387 indication." 1389 5. The SIP node may use further provisional messages to indicate 1390 session progress. 1392 6. After an ACM has been sent, all provisional responses will 1393 translate into ISUP CPG messages as indicated in Section 8.2.3. 1395 7. When the SIP node answers the call, it will send a 200 OK 1396 message. 1398 8. Upon receipt of the 200 OK message, the gateway will send an ANM 1399 message towards the ISUP node. 1401 9. The gateway will send an ACK to the SIP node to acknowledge 1402 receipt of the INVITE final response. 1404 8.1.2 Auto-answer call setup 1406 SIP MGC/MG PSTN 1407 | |<-----------IAM-----------|1 1408 | |==========Audio==========>| 1409 2|<--------INVITE-----------| | 1410 3|-----------200----------->| | 1411 |<=========Audio==========>| | 1412 | |------------CON---------->|4 1413 | |<=========Audio==========>| 1414 5|<----------ACK------------| | 1416 1. When a PSTN user wishes to begin a session with a SIP user, the 1417 PSTN network generates an IAM message towards the gateway. 1419 2. Upon receipt of the IAM message, the gateway generates an INVITE 1420 message, and sends it to an appropriate SIP node based on called 1421 number analysis. 1423 3. Since the SIP node is set up to automatically answer the call, it 1424 will send a 200 OK message. 1426 4. Upon receipt of the 200 OK message, the gateway will send a CON 1427 message towards the ISUP node. 1429 5. The gateway will send an ACK to the SIP node to acknowledge 1430 receipt of the INVITE final response. 1432 8.1.3 SIP Timeout 1434 SIP MGC/MG PSTN 1435 | |<-----------IAM-----------|1 1436 | |==========Audio==========>| 1437 2|<--------INVITE-----------| | 1438 | *** T1 Expires *** | | 1439 3|<--------INVITE-----------| | 1440 | *** T1 Expires *** | | 1441 |<--------INVITE-----------| | 1442 | | *** T11 Expires *** | 1443 | |------------ACM---------->|4 1444 | *** T1 Expires *** | | 1445 |<--------INVITE-----------| | 1446 | *** T1 Expires *** | | 1447 |<--------INVITE-----------| | 1448 | *** T1 Expires *** | | 1449 |<--------INVITE-----------| | 1450 | *** T1 Expires *** | | 1451 |<--------INVITE-----------| | 1452 | *** T1 Expires *** | | 1453 | ** MG Releases PSTN Trunk ** | 1454 | |------------REL---------->|5 1455 6|<--------CANCEL-----------| | 1456 | |<-----------RLC-----------|7 1458 1. When a PSTN user wishes to begin a session with a SIP user, the 1459 PSTN network generates an IAM message towards the gateway. 1461 2. Upon receipt of the IAM message, the gateway generates an INVITE 1462 message, and sends it to an appropriate SIP node based on called 1463 number analysis. The ISUP timer T11 and SIP timer T1 are set at 1464 this time. 1466 3. The INVITE message will continue to be sent to the SIP node each 1467 time the timer T1 expires. The SIP standard specifies that 1468 INVITE transmission will be performed 7 times if no response is 1469 received. 1471 4. When T11 expires, an ACM message will be sent to the ISUP node to 1472 prevent the call from being torn down by the remote node's ISUP 1473 T7. This ACM contains a `Called Party Status' value of `no 1474 indication.' 1476 5. Once the maximum number of INVITE requests has been sent, the 1477 gateway will send a REL (cause code 18) to the ISUP node to 1478 terminate the call. 1480 6. The gateway also sends a CANCEL message to the SIP node to 1481 terminate any initiation attempts. 1483 7. Upon receipt of the REL, the remote ISUP node will send an RLC to 1484 acknowledge. 1486 8.1.4 ISUP T9 Expires 1488 SIP MGC/MG PSTN 1489 | |<-----------IAM-----------|1 1490 | |==========Audio==========>| 1491 2|<--------INVITE-----------| | 1492 | *** T1 Expires *** | | 1493 3|<--------INVITE-----------| | 1494 | *** T1 Expires *** | | 1495 |<--------INVITE-----------| | 1496 | | *** T11 Expires *** | 1497 | |------------ACM---------->|4 1498 | *** T1 Expires *** | | 1499 |<--------INVITE-----------| | 1500 | *** T1 Expires *** | | 1501 |<--------INVITE-----------| | 1502 | *** T1 Expires *** | | 1503 |<--------INVITE-----------| | 1504 | | *** T9 Expires *** | 1505 | ** MG Releases PSTN Trunk ** | 1506 | |<-----------REL-----------|5 1507 | |------------RLC---------->|6 1508 7|<--------CANCEL-----------| | 1510 1. When a PSTN user wishes to begin a session with a SIP user, the 1511 PSTN network generates an IAM message towards the gateway. 1513 2. Upon receipt of the IAM message, the gateway generates an INVITE 1514 message, and sends it to an appropriate SIP node based on called 1515 number analysis. The ISUP timer T11 and SIP timer T1 are set at 1516 this time. 1518 3. The INVITE message will continue to be sent to the SIP node each 1519 time the timer T1 expires. The SIP standard specifies that 1520 INVITE transmission will be performed 7 times if no response is 1521 received. Since SIP T1 starts at 1/2 second or more and doubles 1522 each time it is retransmitted, it will be at least a minute 1523 before SIP times out the INVITE request; since SIP T1 is allowed 1524 to be larger than 500 ms initially, it is possible that 7 x SIP 1525 T1 will be longer than ISUP T11 + ISUP T9. 1527 4. When T11 expires, an ACM message will be sent to the ISUP node to 1528 prevent the call from being torn down by the remote node's ISUP 1529 T7. This ACM contains a `Called Party Status' value of `no 1530 indication.' 1532 5. When ISUP T9 in the remote PSTN node expires, it will send a REL. 1534 6. Upon receipt of the REL, the gateway will send an RLC to 1535 acknowledge. 1537 7. The REL will trigger a CANCEL request, which gets sent to the SIP 1538 node. 1540 8.1.5 SIP Error Response 1542 SIP MGC/MG PSTN 1543 | |<-----------IAM-----------|1 1544 | |==========Audio==========>| 1545 2|<--------INVITE-----------| | 1546 3|-----------4xx+---------->| | 1547 4|<----------ACK------------| | 1548 | ** MG Releases PSTN Trunk ** | 1549 | |------------REL---------->|5 1550 | |<-----------RLC-----------|6 1552 1. When a PSTN user wishes to begin a session with a SIP user, the 1553 PSTN network generates an IAM message towards the gateway. 1555 2. Upon receipt of the IAM message, the gateway generates an INVITE 1556 message, and sends it to an appropriate SIP node based on called 1557 number analysis. 1559 3. The SIP node indicates an error condition by replying with a 1560 response with a code of 400 or greater. 1562 4. The gateway sends an ACK message to acknowledge receipt of the 1563 INVITE final response. 1565 5. An ISUP REL message is generated from the SIP code, as specified 1566 in Section 8.2.6.1. 1568 6. The remote ISUP node confirms receipt of the REL message with an 1569 RLC message. 1571 8.1.6 SIP Redirection 1573 SIP node 1 MGC/MG PSTN 1574 | |<-----------IAM-----------|1 1575 | |==========Audio==========>| 1576 2|<--------INVITE-----------| | 1577 3|-----------3xx+---------->| | 1578 | |------------CPG---------->|4 1579 5|<----------ACK------------| | 1580 | | 1581 | | 1582 SIP node 2 | | 1583 6|<--------INVITE-----------| | 1584 7|-----------18x----------->| | 1585 |<=========Audio===========| | 1586 | |------------ACM---------->|8 1587 9|-----------200-(I)------->| | 1588 |<=========Audio==========>| | 1589 | |------------ANM---------->|10 1590 | |<=========Audio==========>| 1591 11|<----------ACK------------| | 1593 1. When a PSTN user wishes to begin a session with a SIP user, the 1594 PSTN network generates an IAM message towards the gateway. 1596 2. Upon receipt of the IAM message, the gateway generates an INVITE 1597 message, and sends it to an appropriate SIP node based on called 1598 number analysis. 1600 3. The SIP node indicates that the resource which the user is 1601 attempting to contact is at a different location by sending a 1602 3xx message. In this instances we assume the Contact URL 1603 specifies a valid URL reachable by a VoIP SIP call. 1605 4. The gateway sends a CPG with event indication that the call is 1606 being forwarded upon receipt of the 3xx message. Note that this 1607 translation should be able to be disabled by configuration, as 1608 some ISUP nodes do not support receipt of CPG messages before 1609 ACM messages. 1611 5. The gateway acknowledges receipt of the INVITE final response by 1612 sending an ACK message to the SIP node. 1614 6. The gateway re-sends the INVITE message to the address indicated 1615 in the Contact: field of the 3xx message. 1617 7. When an event signifying that the call has sufficient addressing 1618 information occurs, the SIP node will generate a provisional 1619 response of 180 or greater. 1621 8. Upon receipt of a provisional response of 180 or greater, the 1622 gateway will generate an ACM message with an event code as 1623 indicated in Section 8.2.3. 1625 9. When the SIP node answers the call, it will send a 200 OK 1626 message. 1628 10. Upon receipt of the 200 OK message, the gateway will send an ANM 1629 message towards the ISUP node. 1631 11. The gateway will send an ACK to the SIP node to acknowledge 1632 receipt of the INVITE final response. 1634 8.1.7 Call Canceled by ISUP 1636 SIP MGC/MG PSTN 1637 | |<-----------IAM-----------|1 1638 | |==========Audio==========>| 1639 2|<--------INVITE-----------| | 1640 3|-----------18x----------->| | 1641 |==========Audio==========>| | 1642 | |------------ACM---------->|4 1643 | ** MG Releases PSTN Trunk ** | 1644 | |<-----------REL-----------|5 1645 | |------------RLC---------->|6 1646 7|<---------CANCEL----------| | 1647 | ** MG Releases IP Resources ** | 1648 8|-----------200----------->| | 1649 9|-----------487----------->| | 1650 10|<----------ACK------------| | 1652 1. When a PSTN user wishes to begin a session with a SIP user, the 1653 PSTN network generates an IAM message towards the gateway. 1655 2. Upon receipt of the IAM message, the gateway generates an INVITE 1656 message, and sends it to an appropriate SIP node based on called 1657 number analysis. 1659 3. When an event signifying that the call has sufficient addressing 1660 information occurs, the SIP node will generate a provisional 1661 response of 180 or greater. 1663 4. Upon receipt of a provisional response of 180 or greater, the 1664 gateway will generate an ACM message with an event code as 1665 indicated in Section 8.2.3. 1667 5. If the calling party hangs up before the SIP node answers the 1668 call, a REL message will be generated. 1670 6. The gateway frees the PSTN circuit and indicates that it is 1671 available for reuse by sending an RLC. 1673 7. Upon receipt of a REL message before an INVITE final response, 1674 the gateway will send a CANCEL towards the SIP node. 1676 8. Upon receipt of the CANCEL, the SIP node will send a 200 1677 response. 1679 9. The remote SIP node will send a "487 Call Cancelled" to complete 1680 the INVITE transaction. 1682 10. The gateway will send an ACK to the SIP node to acknowledge 1683 receipt of the INVITE final response. 1685 8.2 State Machine 1687 Note that REL may arrive in any state. Whenever this occurs, the 1688 actions in section Section 8.2.7. are taken. Not all of these 1689 transitions are shown in this diagram. 1691 +---------+ 1692 +----------------------->| Idle |<---------------------+ 1693 | +----+----+ | 1694 | | | 1695 | | IAM/7.2.1 | 1696 | V | 1697 | REL/7.2.7 +-------------------------+ 400+/7.2.6 | 1698 +<----------------+ Trying |------------>| 1699 | +-+--------+------+-------+ | 1700 | | | | | 1701 | | T11/ | 18x/ | 200/ | 1702 | | 7.2.8 |7.2.3 | 7.2.4 | 1703 | V | | | 1704 | REL/7.2.7 +--------------+ | | 400+/7.2.6 | 1705 |<----------| Progressing |-|------|-------------------->| 1706 | +--+----+------+ | | | 1707 | | | | | | 1708 | 200/ | | 18x/ | | | 1709 | 7.2.4 | | 7.2.3 | | | 1710 | | V V | | 1711 | REL/7.2.7 | +---------------+ | 400+/7.2.6 | 1712 |<-------------|--| Alerting |-|-------------------->| 1713 | | +--------+------+ | | 1714 | | | | | 1715 | | | 200/ | | 1716 | | | 7.2.4 | | 1717 | V V V | 1718 | BYE/9.1 +-----------------------------+ REL/9.2 | 1719 +<------------+ Connected +------------>+ 1720 +-----------------------------+ 1722 8.2.1 Initial Address Message received 1724 Upon receipt of an IAM, the gateway SHOULD reserve appropriate 1725 internal resources (DSPs and the like) necessary for handling the IP 1726 side of the call. It MAY make any necessary preparations to connect 1727 audio in the backwards direction (towards the caller). 1729 8.2.1.1 IAM to INVITE procedures 1731 When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message MUST 1732 be created for transmission to the SIP network. This section details 1733 the process by which a gateway populates the fields of the INVITE 1734 based on parameters found within the IAM. 1736 The context of the call setup request read by the gateway in the IAM 1737 will be mapped primarily to two URIs in the INVITE, one representing 1738 the originator of the session and the other its destination. The 1739 former will always appear in the From header (after it has been 1740 converted from ISUP format by the procedure described in Section 12), 1741 and the latter is almost always used for both the To header and the 1742 Request-URI. 1744 Once the address of the called party number has been read from the 1745 IAM, it SHOULD be translated into a destination tel URL that will 1746 serve as the Request-URI of the INVITE. Alternatively, a gateway MAY 1747 first attempt an ENUM [8] query to resolve the called party number to 1748 a URI. Some additional ISUP fields MAY be added to the tel URL after 1749 translation has been completed, namely: 1751 o If the gateway supports carrier-based routing (which is optional 1752 in this specification), it SHOULD ascertain if either the CIP (in 1753 ANSI networks) or TNS parameter is present in the IAM. If a value 1754 is present, the carrier identification code (CIC) SHOULD be 1755 extracted from the given parameter and analyzed by the gateway. A 1756 'cic=' field with the value of the CIC SHOULD be appended to the 1757 destination tel URL, if doing so is in keeping with local policy 1758 (i.e. provided that the CIC does not indicate the network which 1759 owns the gateway or some similar condition). Note that if it is 1760 created, the 'cic=' parameter MUST be prefixed with the country 1761 code used or implied in the called party number, so that CIC 1762 '5062' becomes, in the United States, '+1-5062'. For further 1763 information on the 'cic=' tel URL field see [21]. 1765 o If the gateway supports number portability-based routing (which is 1766 optional in this specification), then the gateway will need to 1767 look at a few other fields. To correctly map he FCI 'number 1768 translated' bit indicating that an LNP dip had been performed in 1769 the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL. 1770 If a GAP is present in the IAM, then the contents of the CPN (the 1771 Location Routing Number, or LRN) SHOULD be translated from ISUP 1772 format (as described in Section 12) and copied into an 'rn=' field 1773 which must be appended to the tel URL, whereas the GAP itself 1774 should be translated to ISUP format and used to populate the 1775 primary telephone number field of the tel URL. Note that in some 1776 national numbering plans, both the LRN and the dialed number may 1777 be stored in the CPN parameter, in which case they must be 1778 separately out into separate fields to be stored in the tel URL. 1779 Note that LRNs are necessarily national in scope, and consequently 1780 they MUST NOT be preceded by a '+' in the 'rn=' field. For 1781 further information on these tel URL fields see [21]. 1783 In most cases, the resulting destination tel URL SHOULD be used in 1784 both the To field and Request-URI sent by the gateway. However, if 1785 the OCN parameter is present in the IAM, the To field SHOULD be 1786 constructed from the translation (from ISUP format following Section 1787 12 of the OCN parameter, and hence the Request-URI and To field MAY 1788 be different. 1790 The construction of the From header field is dependent on the 1791 presence of a CIN parameter. If the CIN is not present, then the 1792 gateway SHOULD create a dummy From header field containing a SIP URI 1793 without a user portion which communicates only the hostname of the 1794 gateway (e.g. 'sip:gw.sipcarrier.com). If the CIN is available, 1795 then it SHOULD be translated (in accordance with the procedure 1796 described above) into a tel URL which should populate the From header 1797 field. In either case, local policy or requests for presentation 1798 restriction (see Section 12.1) MAY result in a different value for 1799 the From header field. 1801 8.2.2 100 received 1803 A 100 response SHOULD NOT trigger any PSTN interworking messages; it 1804 only serves the purpose of suppressing INVITE retransmissions. 1806 8.2.3 18x received 1808 Upon receipt of a 18x provisional response, if no ACM has been sent 1809 and no legitimate and comprehensible ISUP is present in the 18x 1810 message body, then the ISUP message SHOULD be generated according to 1811 the following table. Note that, if an early ACM is sent, the call 1812 MUST enter state "Progressing" instead of state "Alerting." 1814 Response received Message sent by the MGC 1815 ----------------- ----------------------- 1816 180 Ringing ACM 1817 181 Call is being forwarded Early ACM and CPG, event=6 1818 182 Queued ACM 1819 183 Session progress message ACM 1821 If an ACM has already been sent and no ISUP is present in the 18x 1822 message body, an ISUP message SHOULD be generated according to the 1823 following table. 1825 Response received Message sent by the MGC 1826 ----------------- ----------------------- 1827 180 Ringing CPG, event = 1 (Alerting) 1828 181 Call is being forwarded CPG, event = 6 (Forwarding) 1829 182 Queued CPG, event = 2 (Progress) 1830 183 Session progress message CPG, event = 2 (Progress) 1832 Upon receipt of a 18x response without any SDP, the gateway SHOULD 1833 generates the ringback tone to be heard by the caller on the PSTN 1834 side (unless the gateway knows that ringback will be provided by some 1835 other device on the PSTN side). 1837 Note however that a gateway might receive media at any time after it 1838 has transmitted an SDP offer that it has sent in an INVITE. 1839 Therefore the gateway MUST be prepared to play this media to the 1840 caller on the PSTN side (ceasing any ringback tone that it may have 1841 begun to generate). Note that the gateway may also receive SDP 1842 offers for an early media session, see Section 5.5. 1844 When an ACM is sent, the mandatory Backward Call Indicator parameter 1845 must be set, as well as any optional parameters as gateway policy 1846 dictates. If legitimate and comprehensible ISUP is present in the 1847 18x response, the gateway SHOULD re-use the appropriate parameters 1848 ISUP message contained in the response body, including the value of 1849 the Backwards Call Indicators parameter as it formulates an message 1850 that it will send across its PSTN interface. In the absence of a 1851 usable encapsulated ACM, the BCI parameter should be set as follows: 1853 Message type: ACM 1855 Backward Call Indicators 1856 Charge indicator: 10 charge 1857 Called party's status indicator: 01 subscriber free or 1858 00 no indication (E.ACM) 1859 Called party's category indicator: 01 ordinary subscriber 1860 End-to-end method indicator: 00 no end-to-end method 1861 Interworking indicator: 1 interworking encountered 1862 End-to-end information indicator: 0 no end-to-end info 1863 ISDN user part indicator: 0 ISUP not used all the way 1864 Holding indicator: 0 no holding 1865 ISDN access indicator: 0 No ISDN access 1866 Echo control device indicator: It depends on the call 1867 SCCP method indicator: 00 no indication 1869 Note that when the ISUP parameters regarding interworking are set in 1870 the Backwards Call Indicators parameter of the ACM, this indicates 1871 that ISDN is interworking with a network which is not capable of 1872 providing as many services as ISDN does. ISUP will therefore not 1873 employ certain features it otherwise normally uses. Gateway vendors 1874 therefore MAY provide a configurable option, usable at the discretion 1875 of service providers when they require additional ISUP services, that 1876 even in the absence of encapsulated ISUP will signal in the BCI that 1877 no interworking has been encountered. 1879 8.2.4 2xx received 1881 Response received Message sent by the MGC 1882 ----------------- ----------------------- 1883 200 OK ANM, ACK 1885 After receiving a 200 OK response the gateway MUST establish a 1886 directional media path in the gateway and send an ANM to the PSTN as 1887 well as an ACK to the SIP network. 1889 If the 200 OK response arrives before the gateway has sent an ACM, a 1890 CON is sent instead of the ANM, in those ISUP variants that support 1891 the CON message. 1893 When a legitimate and comprehensible ANM is encapsulated in the 200 1894 OK response, the gateway SHOULD re-use any relevant ISUP parameters 1895 in the ANM it sends to the PSTN. 1897 Note that gateways may sometimes receive 200 OK responses for 1898 requests other than INVITE (for example, those used in managing 1899 provisional responses, or the INFO method). The procedures described 1900 in this section apply only to 200 OK responses received as a result 1901 of sending an INVITE. The gateway SHOULD NOT send any PSTN messages 1902 if it receives a 200 OK in response to non-INVITE requests it has 1903 sent. 1905 8.2.5 3xx Received 1907 When any 3xx response (a redirection) is received, the gateway SHOULD 1908 try to reach the destination by sending one or more new call setup 1909 requests using URIs found in any Contact header field(s) present in 1910 the response, as is mandated in the base SIP specification. Such 3xx 1911 responses are typically sent by a redirect server, and can be thought 1912 of as similar to a location register in mobile PSTN networks. 1914 If a particular URI presented in the Contact header of a 3xx is best 1915 reachable (according to the gateway's routing policies) via the PSTN, 1916 the gateway SHOULD send a new IAM and from that moment on acts as a 1917 normal PSTN switch (no SIP involved) - usually this will be the case 1918 when the URI in the Contact header is a tel URL, one that the gateway 1919 cannot reach locally and one for which there is no ENUM mapping. 1920 Alternatively, the gateway MAY send a REL message to the PSTN with a 1921 redirection indicator (23) and a diagnostic field corresponding to 1922 the telephone number in the URI. If however the new location is best 1923 reachable using SIP (if the URI in the Contact header contains no 1924 telephone number at all), the MGC SHOULD send a new INVITE with a 1925 Request-URI possibly a new IAM generated by the MGC in the message 1926 body. 1928 While it is exploring a long list of Contact header fields with SIP 1929 requests, a gateway MAY send a CPG message with an event code of 6 1930 (Forwarding) to the PSTN in order to indicate that the call is 1931 proceeding (where permitted by the ISUP variant in question). 1933 All redirection situations have to be treated very carefully because 1934 they involved special charging situations. In PSTN the caller 1935 typically pays for the first leg (to the gateway) and the callee pays 1936 the second (from the forwarding switch to the destination). 1938 8.2.6 4xx-6xx Received 1940 When a response code of 400 or greater is received by the gateway, 1941 then the INVITE previously sent by the gateway has been rejected. 1942 Under most circumstances the gateway SHOULD release the resources in 1943 the gateway, send a REL to the PSTN with a cause value and send an 1944 ACK to the SIP network. Some specific circumstances are identified 1945 below in which a gateway MAY attempt to rectify a SIP-specific 1946 problem communicated by a status code without releasing the call by 1947 retrying the request. When a REL is sent to the PSTN, the gateway 1948 expects the arrival of an RLC indicating that the release sequence is 1949 complete. 1951 8.2.6.1 SIP Status Code to ISDN Cause Code Mapping 1953 When an REL message is generated upon a SIP rejection response, the 1954 Cause Indicator (CAI) parameter any encapsulated ISUP REL in the SIP 1955 response SHOULD be used in the REL generated by the gateway. If no 1956 encapsulated ISUP is present, the mapping below between status code 1957 and cause codes are RECOMMENDED. 1959 Any SIP status codes not listed below (associated with SIP 1960 extensions, versions of SIP subsequent to the issue of this document, 1961 or simply omitted) should be mapping to cause code 31 "Normal, 1962 unspecified". These mappings cover only responses - note that the 1963 BYE and CANCEL requests, which are also used to tear down a dialog, 1964 SHOULD be mapped to 16 "Normal clearing" under most circumstances 1965 (although see Section 5.8). 1967 By default, the cause location associated with the CAI parameter 1968 should be encoded such that 6xx codes are given the location 'user', 1969 whereas 4xx and 5xx codes are given a 'network' location. Exceptions 1970 are marked below. 1972 Just as there are certain ISDN cause codes that are ISUP-specific and 1973 have no corollary SIP action, so there are SIP status codes that 1974 should not simply be translated to ISUP - some SIP-specific action 1975 should be attempted first. See the note on the (+) tag below. 1977 Response received Cause value in the REL 1978 ----------------- ---------------------- 1979 400 Bad Request 41 Temporary Failure 1980 401 Unauthorized 21 Call rejected (*) 1981 402 Payment required 21 Call rejected 1982 403 Forbidden 21 Call rejected 1983 404 Not found 1 Unallocated number 1984 405 Method not allowed 63 Service or option 1985 unavailable 1986 406 Not acceptable 79 Service/option not 1987 implemented (+) 1988 407 Proxy authentication required 21 Call rejected (*) 1989 408 Request timeout 102 Recovery on timer expiry 1990 410 Gone 22 Number changed 1991 (w/o diagnostic) 1992 413 Request Entity too long 127 Interworking (+) 1993 414 Request-URI too long 127 Interworking (+) 1994 415 Unsupported media type 79 Service/option not 1995 implemented (+) 1996 416 Unsupported URI Scheme 127 Interworking (+) 1997 420 Bad extension 127 Interworking (+) 1998 421 Extension Required 127 Interworking (+) 1999 423 Interval Too Brief 127 Interworking (+) 2000 480 Temporarily unavailable 18 No user responding 2001 481 Call/Transaction Does not Exist 41 Temporary Failure 2002 482 Loop Detected 25 Exchange - routing error 2003 483 Too many hops 25 Exchange - routing error 2004 484 Address incomplete 28 Invalid Number Format (+) 2005 485 Ambiguous 1 Unallocated number 2006 486 Busy here 17 User busy 2007 487 Request Terminated --- (no mapping) 2008 488 Not Acceptable here --- by Warning header 2009 500 Server internal error 41 Temporary failure 2010 501 Not implemented 79 Not implemented, unspecified 2011 502 Bad gateway 38 Network out of order 2012 503 Service unavailable 41 Temporary failure 2013 504 Server time-out 102 Recovery on timer expiry 2014 504 Version Not Supported 127 Interworking (+) 2015 513 Message Too Large 127 Interworking (+) 2016 600 Busy everywhere 17 User busy 2017 603 Decline 21 Call rejected 2018 604 Does not exist anywhere 1 Unallocated number 2019 606 Not acceptable --- by Warning header 2021 (*) In some cases, it may be possible for a SIP gateway to provide 2022 credentials to the SIP UAS that is rejecting an INVITE due to 2023 authorization failure. If the gateway can authenticate itself, then 2024 obviously it SHOULD do so and proceed with the call; only if the 2025 gateway cannot authenticate itself should cause code 21 be sent. 2027 (+) If at all possible, a SIP gateway SHOULD respond to these 2028 protocol errors by remedying unacceptable behavior and attempting to 2029 re-originate the session. Only if this proves impossible should the 2030 SIP gateway fail the ISUP half of the call. 2032 When the Warning header is present in a SIP 606 or 488 message, there 2033 may be specific ISDN cause code mappings appropriate to the Warning 2034 code. This document recommends that '31 Normal, unspecified' SHOULD 2035 by default be used for most currently assigned Warning codes. If the 2036 Warning code speaks to an unavailable bearer capability, cause code 2037 '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping. 2039 8.2.7 REL Received 2041 This circumstance generally arises when the user on the PSTN side 2042 hands up before the call has been answered - the gateway therefore 2043 aborts the establishment of the session. A CANCEL request MUST be 2044 issued (a BYE is not used, since no final response has arrived from 2045 the SIP side). A 200 OK for the CANCEL can be expected by the 2046 gateway, and finally a 487 for the INVITE arrives (which the gateway 2047 ACKs in turn). 2049 The gateway SHOULD store state information related to this dialog for 2050 a certain period of time, since a 200 final response for the INVITE 2051 originally sent might arrive (even after the reception of the 200 OK 2052 for the CANCEL). In this situation, the gateway MUST send an ACK 2053 followed by an appropriate BYE request. 2055 In SIP bridging situations, the REL message cannot be encapsulated in 2056 a CANCEL message (since CANCEL cannot have a message body). Usually, 2057 the REL message will contain a CAI value of 16 "Normal clearing". If 2058 the value is other than a 16, the gateway MAY wish to use some other 2059 means of communicating the cause value (see Section 5.8). 2061 8.2.8 ISUP T11 Expires 2063 In order to prevent the remote ISUP node's timer T7 from expiring, 2064 the gateway MAY to keep its own supervisory timer; ISUP defines this 2065 timer as T11. T11's duration is carefully chosen so that it will 2066 always be shorter than the T7 of any node to which the gateway is 2067 communicating. 2069 To clarify timer T11's relevance with respect to SIP interworking, 2070 Q.764 [12] explains its use as: "If in normal operation, a delay in 2071 the receipt of an address complete signal from the succeeding network 2072 is expected, the last common channel signaling exchange will 2073 originate and send an address complete message 15 to 20 seconds 2074 [timer (T11)] after receiving the latest address message." Since SIP 2075 nodes have no obligation to respond to an INVITE request within 20 2076 seconds, SIP interworking inarguably qualifies as such a situation. 2078 If the gateway supports this optional mechanism, then if its T11 2079 expires, it SHOULD send an early ACM (i.e. called party status set 2080 to "no indication") to prevent the expiration of the remote node's T7 2081 (where permitted by the ISUP variant). See Section 8.2.3 for the 2082 value of the ACM parameters. 2084 If a "180 Ringing" message arrives subsequently, it SHOULD be sent in 2085 a CPG, as shown in Section 8.2.3. 2087 See Section 8.1.3 for an example callflow that includes the 2088 expiration of T11. 2090 9. Suspend/Resume and Hold 2092 9.1 SUS and RES 2094 In ISDN networks, a user can generate a SUS (timer T2, user 2095 initiated) in order to unplug the terminal from the socket and plug 2096 it in another one. A RES is sent once the terminal has been 2097 reconnected and the T2 timer has not expired. SUS is also frequently 2098 used to signaling an on-hook state for a remote terminal before 2099 timers leading to the transmission of a REL message are sent (this is 2100 the more common case by far). While a call is suspended, no audio 2101 media is passed end-to-end. 2103 When a SUS is sent for a call that has a SIP leg, a gateway MAY 2104 suspend IP media transmission until a RES is received. Putting the 2105 media on hold insures that bandwidth is conserved when no audio 2106 traffic needs to be transmitted. 2108 If media suspension is appropriate, then when a SUS arrives from the 2109 PSTN, the MGC MAY send an INVITE to request that the far-end's 2110 transmission of the media stream be placed on hold. The subsequent 2111 reception of a RES from the PSTN SHOULD then trigger a re-INVITE that 2112 requests the resumption of the media stream. Note that the MGC may 2113 or may not elect to stop transmitting any media itself when it 2114 requests the cessation of far-end transmission. 2116 If media suspension is not required by the MGC receiving the SUS from 2117 the PSTN, the SIP INFO [6] method MAY be used to transmit an 2118 encapsulated SUS rather than a re-INVITE. Note that the recipient of 2119 such an INFO request may be a simple SIP phone does not understand 2120 ISUP (and would therefore take no action on receipt of this message); 2121 if a prospective destination for an INFO-encapsulated SUS has not 2122 used encapsulated ISUP in any messages it has previously sent, the 2123 gateway SHOULD NOT relay the INFO method, but rather should handle 2124 the SUS and the corresponding RES without signaling their arrival to 2125 the SIP network. 2127 In any case, subsequent RES messages MUST be transmitted in the same 2128 method that was used for the corresponding SUS (i.e. if an INFO is 2129 used for a SUS, INFO should also be used for the subsequent RES). 2131 Regardless of whether the INFO or re-INVITE mechanism is used to 2132 carry a SUS message, neither has any implication that the originating 2133 side will cease sending IP media. The recipient of an encapsulated 2134 SUS message MAY therefore elect to send a re-INVITE themselves to 2135 suspend media transmission from the MGC side if desired. 2137 The following example uses the INVITE mechanism. Compliant gateways 2138 MAY implement functional equivalence with this flows in accordance 2139 with the language above. 2141 SIP MGC/MG PSTN 2142 | |<-----------SUS-----------|1 2143 2|<--------INVITE-----------| | 2144 3|-----------200----------->| | 2145 4|<----------ACK------------| | 2146 | |<-----------RES-----------|5 2147 6|<--------INVITE-----------| | 2148 7|-----------200----------->| | 2149 8|<----------ACK------------| | 2151 The handling of a network-initiated SUS immediately prior to call 2152 teardown is handled in Section 10.2.2. 2154 9.2 Hold (re-INVITE) 2156 After a call has been connected, a re-INVITE could be sent to a 2157 gateway from the SIP side in order to place the call on hold. This 2158 re-INVITE will have an SDP offer indicating that the originator of 2159 the re-INVITE no longer wishes to receive media. 2161 SIP MGC/MG PSTN 2162 1|---------INVITE---------->| | 2163 | |------------CPG---------->|2 2164 3|<----------200------------| | 2165 4|-----------ACK----------->| | 2167 When such a re-INVITE is received, the gateway SHOULD send a Call 2168 Progress Message (CPG) in order to express that the call has been 2169 placed on hold. The CPG SHOULD contain a Generic Notification 2170 Indicator (or, in ANSI networks, a Notification Indicator) with a 2171 value of 'remote hold'. 2173 If subsequent to the sending of the re-INVITE the SIP side wishes to 2174 take the remote end off hold, and to begin receiving media again, it 2175 SHOULD repeat the flow above with an INVITE that contains an SDP 2176 offer with an appropriate media destination. The Generic 2177 Notification Indicator would in this instance have a value of 'remote 2178 retrieval' (or in some variants 'remote hold released'). 2180 Finally, note that a CPG with hold indicators may be received by a 2181 gateway from the PSTN. In the interests of conserving bandwidth, the 2182 gateway SHOULD stop sending media until the call is resumed, and 2183 SHOULD send a re-INVITE to the SIP leg of the call requesting that 2184 the remote side stop sending media. 2186 10. Normal Release of the Connection 2188 From the perspective of a gateway, either the SIP side or the ISUP 2189 side can release a call, regardless of which side initiated the call. 2190 Note that cancellation of a call setup request (either from the ISUP 2191 or SIP side) is discussed elsewhere in this document (in Section 2192 8.2.7 and Section 7.2.3, respectively). 2194 Gateways SHOULD implement functional equivalence with the flows in 2195 this section. 2197 10.1 SIP initiated release 2199 For a normal termination of the dialog (receipt of a BYE request), 2200 the gateway MUST immediately send a 200 response. The gateway then 2201 MUST release any media resources in the gateway (DSPs, TCIC locks, 2202 and so on) and send an REL with a cause code of 16 (normal call 2203 clearing) to the PSTN. Release of resources is confirmed by the PSTN 2204 side with an RLC message. 2206 In SIP bridging situations, the cause code of any REL encapsulated in 2207 the BYE request SHOULD be re-used in any REL that the gateway sends 2208 to the PSTN. 2210 SIP MGC/MG PSTN 2211 1|-----------BYE----------->| | 2212 | ** MG Releases IP Resources ** | 2213 2|<----------200------------| | 2214 | ** MG Releases PSTN Trunk ** | 2215 | |------------REL---------->|3 2216 | |<-----------RLC-----------|4 2218 10.2 ISUP initiated release 2220 If the release of the connection was caused by the reception of a 2221 REL, the REL SHOULD be encapsulated in the BYE sent by the gateway. 2222 Whether the caller or callee hangs up first, the gateway SHOULD 2223 release any internal resources used in support of the call and then 2224 MUST confirm that the circuit is ready for re-use by sending an RLC. 2226 10.2.1 Caller hangs up 2228 When the caller hangs up, the SIP dialog MUST be terminated by 2229 sending a BYE request (which is confirmed with a 200). 2231 SIP MGC/MG PSTN 2232 | |<-----------REL-----------|1 2233 | ** MG Releases PSTN Trunk ** | 2234 | |------------RLC---------->|2 2235 3|<----------BYE------------| | 2236 | ** MG Releases IP Resources ** | 2237 4|-----------200----------->| | 2239 10.2.2 Callee hangs up (SUS) 2241 In some PSTN scenarios, if the callee hangs up in the middle of a 2242 call, the local exchange sends a SUS instead of a REL and starts a 2243 timer (T6, SUS is network initiated). When the timer expires, the 2244 REL is sent. The necessitates a slightly different SIP flow; see 2245 Section 9 for more information on handling suspension. It is 2246 RECOMMENDED that gateways implement functional equivalence with the 2247 following flow for this case: 2249 SIP MGC/MG PSTN 2250 | |<-----------SUS-----------|1 2251 2|<--------INVITE-----------| | 2252 3|-----------200----------->| | 2253 4|<----------ACK------------| | 2254 | | *** T6 Expires *** | 2255 | |<-----------REL-----------|5 2256 | ** MG Releases PSTN Trunk ** | 2257 | |------------RLC---------->|6 2258 7|<----------BYE------------| | 2259 | ** MG Releases IP Resources ** | 2260 8|-----------200----------->| | 2262 11. ISUP Maintenance Messages 2264 ISUP contains a set of messages used for maintenance purposes. They 2265 can be received during any ongoing call. There are basically two 2266 kinds of maintenance messages (apart from the continuity check): 2267 messages for blocking circuits and messages for resetting circuits. 2269 11.1 Reset messages 2271 Upon reception of a reset (RSC) message for a circuit currently being 2272 used by the gateway for a call, the call MUST be released immediately 2273 (this typically results from a serious maintenance condition). RSC 2274 MUST be answered with an RLC after resetting the circuit in the 2275 gateway. Group reset (GRS) messages which target a range of circuits 2276 are answered with a GRA after resetting all the circuits affected by 2277 the message. 2279 The gateways SHOULD behave as if a REL had been received in order to 2280 release the dialog on the SIP side. A BYE or a CANCEL are sent 2281 depending of the status of the call. See the procedures in Section 2282 10. 2284 11.2 Blocking messages 2286 There are two kinds of blocking messages: maintenance messages or 2287 hardware-failure messages. Maintenance blocking messages indicate 2288 that the circuit is to be blocked for any subsequent calls, but these 2289 messages do not affect any ongoing call. This allows circuits to be 2290 gradually quiesced and taken out of service for maintenance. 2292 Hardware-oriented blocking messages have to be treated as reset 2293 messages. They generally are sent only when a hardware failure has 2294 occurred. Media transmission for all calls in progress on these 2295 circuits would be affected by this hardware condition, and therefore 2296 all calls must be released immediately. 2298 BLO (blocking) is always maintenance oriented and it is answered by 2299 the gateway with BLA when the circuit is blocked - this requires no 2300 corresponding SIP actions. CGB (group blocking) messages have a 2301 "type indicator" inside the Circuit Group Supervision Message Type 2302 Indicator. It indicates if the CGB is maintenance or hardware 2303 failure oriented. If the CGB results from a hardware failure, then 2304 each call in progress in the affected range of circuits MUST be 2305 terminated immediately as if a REL had been received, following the 2306 procedures in Section 10. CGBs MUST be answered with CGBAs. 2308 11.3 Continuity Checks 2310 A continuity check is a test performed on a circuit that involves the 2311 reflection of a tone generated at the originating switch by a 2312 loopback at the destination switch. Two variants of the continuity 2313 check appear in ISUP: the implicit continuity check request within an 2314 IAM (in which case the continuity check takes place as a precondition 2315 before call setup begins), and the explicit continuity check signaled 2316 by a Continuity Check Request (CCR) message. PSTN gateways in 2317 regions that support continuity checking generally SHOULD have some 2318 way of accommodating these tests (if they hope to be fielded by 2319 providers that interconnect with any major carrier). 2321 When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT 2322 send any corresponding SIP messages; the scope of the continuity 2323 check applies only to the PSTN trunks, not to any IP media paths 2324 beyond the gateway. CCR messages also do not designate any called 2325 party number, or any other way to determine what SIP user agent 2326 server should be reached. 2328 When an IAM with the Continuity Check Indicator flag set within the 2329 Nature of Connection Indicators (NCI) parameter is received, the 2330 gateway MUST process the continuity check before sending an INVITE 2331 message (and proceeding normally with call setup); if the continuity 2332 check fails (a COT with Continuity Indicator of 'failed' is 2333 received), then an INVITE MUST NOT be sent. 2335 12. Construction of Telephony URIs 2337 SIP proxy servers MAY route SIP messages on any signaling criteria 2338 desired by network administrators, but generally the Request-URI is 2339 the foremost routing criterion. The To and From headers are also 2340 frequently of interest in making routing decisions. SIP-ISUP mapping 2341 assumes that proxy servers are interested in at least these three 2342 fields of SIP messages, all of which contain URIs. 2344 SIP-ISUP mapping frequently requires the representation of telephone 2345 numbers in these URIs. In some instances these numbers will be 2346 presented first in ISUP messages, and SS7-SIP gateways will need to 2347 translate the ISUP formats of these numbers into SIP URIs. In other 2348 cases the reverse transformation will be required. 2350 The most common format used in SIP for the representation of 2351 telephone numbers is the tel URL [7]. When converting between 2352 formats, the tel URL MAY constitute the entirety of a URI field in a 2353 SIP message, or it MAY appear as the user portion of a SIP URI. For 2354 example, a To field might appear as: 2356 To: tel:+17208881000 2358 Or 2360 To: sip:+17208881000@level3.com 2362 Whether or not a particular gateway or endpoint should formulate URIs 2363 in the tel or SIP format is a matter of local administrative policy - 2364 if the presence of a host portion would aid the surrounding network 2365 in routing calls, the SIP format should be used. A gateway MUST 2366 accept either tel or SIP URIs from its peers. 2368 The '+' sign preceding the number in tel URLs indicates that the 2369 digits which follow constitute a fully-qualified E.164 [16] number; 2370 essentially, this means that a country code is provided before any 2371 national-specific area codes, exchange/city codes, or address codes. 2372 The absence of a '+' sign MAY signify that the number is merely 2373 nationally significant, or perhaps that a private dialing plan is in 2374 use. When the '+' sign is not present, but a telephone number is 2375 represented by the user portion of the URI, the SIP URI SHOULD 2376 contain the optional ';user=phone' parameter; e.g. 2378 To: sip:83000@sip.example.net;user=phone 2380 However, it is strongly RECOMMENDED that only internationally 2381 significant E.164 numbers be passed between SIP-T gateways, 2382 especially when such gateways are in different regions or different 2383 administrative domains. In many if not most SIP-T networks, gateways 2384 are not responsible for end-to-end routing of SIP calls; practically 2385 speaking, gateways have no way of knowing if the call will terminate 2386 in a local or remote administrative domain and/or region, and hence 2387 gateways SHOULD always assume that calls require an international 2388 numbering plan. There is no guarantee that recipients of SIP 2389 signaling will be capable of understanding national dialing plans 2390 used by the originators of calls - if the originating gateway does 2391 not internationalize the signaling, the context in which the digits 2392 were dialed cannot be extrapolated by far-end network elements. 2394 In ISUP signaling, a telephone number appears in a common format that 2395 is used in several parameters, including the Called Party's Number 2396 (CPN) and Calling Party's Number (CIN); when it represents a calling 2397 party number it sports some additional information (detailed below). 2398 For the purposes of this document, we will refer to this format as 2399 'ISUP format' - if the additional calling party information is 2400 present, the format shall be referred to as 'ISUP- calling format'. 2401 The format consists of a byte called the Nature of Address (NoA) 2402 indicator, followed by another byte which contains the Numbering Plan 2403 Indicator (NPI), both of which are prefixed to a variable-length 2404 series of bytes that contains the digits of the telephone number in 2405 binary coded decimal (BCD) format. In the calling party number case, 2406 the NPI's byte also contains bit fields which represent the caller's 2407 presentation preferences and the status of any call screening checks 2408 performed up until this point in the call. 2410 H G F E D C B A H G F E D C B A 2411 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2412 | | NoA | | | NoA | 2413 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2414 | | NPI | spare | | | NPI |PrI|ScI| 2415 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2416 | dig...| dig 1 | | dig...| dig 1 | 2417 | ... | | ... | 2418 | dig n | dig...| | dig n | dig...| 2419 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 2421 ISUP format ISUP calling format 2423 ISUP numbering formats 2425 The NPI field is generally set to the value 'ISDN (Telephony) 2426 numbering plan (Recommendation E.164)', but this does not mean that 2427 the digits which follow necessarily contain a country code; the NoA 2428 field dictates whether the telephone number is in a national or 2429 international format. When the represented number is not designated 2430 to be in an international format, the NoA generally provides 2431 information specific to the national dialing plan - based on this 2432 information one can usually determine how to convert the number in 2433 question into an international format. Note that if the NPI contains 2434 a value other than 'ISDN numbering plan', then the tel URL may not be 2435 suitable for carrying the address digits, and the handling for such 2436 calls is outside the scope of this document. 2438 12.1 ISUP format to tel URL mapping 2440 Based on the above, conversion from ISUP format to a tel URL is as 2441 follows. First, provided that the NPI field indicates that the 2442 telephone number format uses E.164, the NoA is consulted. If the NoA 2443 indicates that the number is an international number, then the 2444 telephone number digits SHOULD be appended unmodified to a 'tel:+' 2445 string. If the NoA has the value 'national (significant) number', 2446 then a country code MUST be prefixed to the telephone number digits 2447 before they are committed to a tel URL; if the gateway performing 2448 this conversion interconnects with switches homed to several 2449 different country codes, presumably the appropriate country code 2450 SHOULD be chosen based on the originating switch or trunk group. If 2451 the NoA has the value 'subscriber number', both a country code and 2452 any other numbering components necessary for the numbering plan in 2453 question (such as area codes or city codes) MAY need to be added in 2454 order for the number to be internationally significant - however, 2455 such procedures vary greatly from country to country, and hence they 2456 cannot be specified in detail here. Only if a country or network- 2457 specific value is used for the NoA SHOULD a tel URL not include a '+' 2458 sign; in these cases, gateways SHOULD simply copy the provided digits 2459 into the tel URL and append a 'user=phone' parameter if a SIP URI 2460 format is used. Any non-standard or proprietary mechanisms used to 2461 communicate further context for the call in ISUP are outside the 2462 scope of this document. 2464 If a nationally-specific parameter is present that allows for the 2465 transmission of the calling party's name (such as the Generic Name 2466 Parameter in ANSI), then generally, if presentation is not 2467 restricted, this information SHOULD be used to populate the display- 2468 name portion of the From field. 2470 If ISUP calling format is being converted rather than ISUP format, 2471 then two additional pieces of information must be taken into account: 2472 presentation indicators and screening indicators. If the 2473 presentation indicators are set to 'presentation restricted', then a 2474 special URI is created by the gateway which communicates to the far 2475 end that the caller's identity has been omitted. This URI SHOULD be 2476 a SIP URI with a display-name and username of 'Anonymous', e.g.: 2478 From: Anonymous 2479 For further information about privacy in SIP, see Section 5.7. 2481 If presentation is set to 'address unavailable', then gateways should 2482 treat the IAM as if the CIN parameter was omitted. Screening 2483 indicators should not be translated, as they are only meaningful end- 2484 to-end. 2486 12.2 tel URL to ISUP format mapping 2488 Conversion from tel URLs to ISUP format is simpler. If the URI is in 2489 international format, then the gateway SHOULD consult the leading 2490 country code of the URI. If the country code is local to the gateway 2491 (the gateway has one or more trunks that point to switches which are 2492 homed to the country code in question), the gateway SHOULD set the 2493 NoA to reflect 'national (significant) number' and strip the country 2494 code from the URI before populating the digits field. If the country 2495 code is not local to the gateway, the gateway SHOULD set the NoA to 2496 'international number' and retain the country code. In either case 2497 the NPI MUST be set to 'ISDN numbering plan' if the URI is in 2498 international format. 2500 If the URI is not in international format, the gateway MAY attempt to 2501 treat the telephone number within the URI as if it were appropriate 2502 to its national or network-specific dialing plan; if doing so gives 2503 rise to internal gateway errors or the gateway does not support such 2504 procedures, then the gateway SHOULD respond with appropriate SIP 2505 status codes to express that the URI could not be understood (if the 2506 URI in question is the Request-URI, a 484). 2508 When converting from a tel URL to ISUP calling format, the procedure 2509 is identical to that described in the preceding paragraphs, but 2510 additionally, the presentation indicator SHOULD be set to 2511 'presentation allowed' and the screening indicator to 'network 2512 provided', unless some service provider policy or user profile 2513 specifically disallows presentation. 2515 13. Other ISUP flavors 2517 Other flavors of ISUP different than Q.767 [10] have more parameters 2518 and more features. Some of the parameters have more possible values 2519 and provide more information about the status of the call. 2521 The Circuit Query Message (CQM) and Circuit Query Response (CQR) are 2522 used in many ISUP variants. These messages have no analog in SIP, 2523 although receipt of a CQR may cause state reconciliation if the 2524 originating and destination switches have become desynchronized; as 2525 states are reconciled some calls may be terminated, which may cause 2526 SIP or ISUP messages to be sent (as described in Section 10). 2528 However, differences in the message flows are more important. In 2529 ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent 2530 instead (when no ACM has been sent before the call is answered). In 2531 call forwarding situations, CPGs MAY be sent before the ACM is sent. 2532 SAMs MUST NOT be sent; `en bloc' signaling is always used. The ANSI 2533 Exit Message (EXM) SHOULD NOT result in any SIP signaling in 2534 gateways. ANSI also uses the Circuit Reservation Message (CRM) and 2535 Circuit Reservation Acknowledgment (CRA) as part of its interworking 2536 procedures - in the event that an MGC does receive a CRM, a CRA 2537 SHOULD be sent in return (in some implementations, transmissions of a 2538 CRA could conceivably be based on a resource reservation system); 2539 after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and 2540 process it normally. Any further circuit reservation mechanism is 2541 outside the scope of this document. 2543 Although receipt of a Confusion (CFN) message is an indication of a 2544 protocol error, corresponding SIP messages SHOULD NOT be sent on 2545 receipt of a CFN - the CFN should be handled with ISUP-specific 2546 procedures by the gateway (usually by retransmission of the packet to 2547 which the CFN responded). Only if ISUP procedures fails repeatedly 2548 should this cause a SIP error condition (and call failure) to arise. 2550 In TTC ISUP CPGs MAY be sent before the ACM is sent. Messages such 2551 as CHG MAY be sent between ACM and ANM. `En bloc' signaling is 2552 always used and there is no T9 timer. 2554 13.1 Guidelines for sending other ISUP messages 2556 Some ISUP variants send more messages than the ones described in this 2557 document. Therefore, some guidelines are provided here with regard 2558 to transport and mapping of these ISUP message. 2560 From the caller to the callee, other ISUP messages SHOULD be 2561 encapsulated (see [3]) inside INFO messages, even if the INVITE 2562 transaction is still not finished. Note that SIP does not ensure 2563 that INFO requests are delivered in order, and therefore in adverse 2564 network conditions an egress gateway might process INFOs out of 2565 order. This issue, however, does not represent an important problem 2566 since it is not likely to happen and its effects are negligible in 2567 most of the situations. The Information (INF) message and 2568 Information Response (INR) are examples of messages that should be 2569 encapsulated within an INFO. Gateway implementers might also 2570 consider building systems that wait for each INFO transaction to 2571 complete before initiating a new INFO transaction. 2573 From the callee to the caller, if a message is received by a gateway 2574 before the call has been answered (i.e. ANM is received) it SHOULD 2575 be encapsulated in an INFO, provided that this will not be the first 2576 SIP message sent in the backwards direction (in which case it SHOULD 2577 be encapsulated in a provisional 1xx response). Similarly a message 2578 which is received on the originating side (probably in response to an 2579 INR) before a 200 OK has been received by the gateway should be 2580 carried within an INFO. In order for this mechanism to function 2581 properly in the forward direction, any necessary Contact or To-tag 2582 must have appeared in a previous provisional response or the message 2583 might not be correctly routed to its destination. As such all SIP-T 2584 gateways MUST send all provisional responses with a Contact header 2585 and any necessary tags in order to enable proper routing of new 2586 requests issued before a final response has been received. When the 2587 INVITE transaction is finished INFO requests SHOULD also be used in 2588 this direction. 2590 14. Acronyms 2592 ACK Acknowledgment 2593 ACM Address Complete Message 2594 ANM Answer Message 2595 ANSI American National Standards Institute 2596 BLA Blocking ACK message 2597 BLO Blocking Message 2598 CGB Circuit Group Blocking Message 2599 CGBA Circuit Group Blocking ACK Message 2600 CHG Charging Information Message 2601 CON Connect Message 2602 CPG Call Progress Message 2603 CUG Closed User Group 2604 GRA Circuit Group Reset ACK Message 2605 GRS Circuit Group Reset Message 2606 HLR Home Location Register 2607 IAM Initial Address Message 2608 IETF Internet Engineering Task Force 2609 IP Internet Protocol 2610 ISDN Integrated Services Digital Network 2611 ISUP ISDN User Part 2612 ITU-T International Telecommunication Union 2613 Telecommunication Standardization Sector 2614 MG Media Gateway 2615 MGC Media Gateway Controller 2616 MTP Message Transfer Part 2617 REL Release Message 2618 RES Resume Message 2619 RLC Release Complete Message 2620 RTP Real-time Transport Protocol 2621 SCCP Signaling Connection Control Part 2622 SG Signaling Gateway 2623 SIP Session Initiation Protocol 2624 SS7 Signaling System No. 7 2625 SUS Suspend Message 2626 TTC Telecommunication Technology Committee 2627 UAC User Agent Client 2628 UAS User Agent Server 2629 UDP User Datagram Protocol 2630 VoIP Voice over IP 2632 15. Security Considerations 2634 The translation of ISUP parameters into SIP headers may introduce 2635 some privacy and security concerns above and beyond those that have 2636 been identified for other functions of SIP-T. Merely securing 2637 encapsulated ISUP, for example, would not provide adequate privacy 2638 for a user requesting presentation restriction if the calling party 2639 number field is openly mapped to the From header. However, since the 2640 scope of the SIP-ISUP mapping has been restricted to only those 2641 parameters that will be translated into the headers and fields used 2642 to route SIP requests, gateways consequently reveal through 2643 translation the minimum possible amount of information. 2645 In most respects, the information that is translated from ISUP to SIP 2646 has no special security requirements. In order for translated 2647 parameters to be used to route requests, they should be legible to 2648 intermediaries; end-to-end confidentiality of this data would be 2649 unnecessary and most likely detrimental. There are also numerous 2650 circumstances under which intermediaries can legitimately overwrite 2651 the values that have been provided by translation, and hence 2652 integrity over these headers is similarly not desirable. 2654 There are some concerns that arise from the other direction of 2655 mapping, the mapping of SIP headers to ISUP parameters, which are 2656 enumerated in the following section. By way of introduction, no 2657 known risk is associated with end-users having arbitrary control over 2658 the value of the Carrier Identification Code or Transit Network 2659 Selection parameter and the telephone number portion of the Called 2660 Party Number field; these fields are already set directly by the user 2661 today. The limited degree to which SIP signaling contributes to the 2662 interworking indicators of the Forward Call Indicators and Backwards 2663 Call Indicators parameters similarly incurs no foreseeable risks. 2665 The fields relevant to number portability, which include in ANSI ISUP 2666 the LRN portion of the Generic Address Parameter and the 'M' bit of 2667 the Forward Call Indicators, are used to route calls in the PSTN. 2668 Since these fields are rendered as tel URL parameters in the SIP-ISUP 2669 mapping, users can set the value of these fields arbitrarily. 2670 Consequently, an end-user could change the end office to which a call 2671 would be routed (though if LRN value were chosen at random, it is 2672 more likely that it would prevent the call from being delivered 2673 altogether). The PSTN is relatively resilient to calls that have 2674 been misrouted on account of local number portability, however. In 2675 some networks, a REL message with a some sort of "misrouted ported 2676 number" cause code is sent in the backwards direction when such a 2677 condition arises. Alternatively, the PSTN switch to which a call was 2678 misrouted can forward the call along to the proper switch after 2679 making its own number portability query - this is in interim number 2680 portability practice that is still common in most segments of the 2681 PSTN that support portability. It is not anticipated that end users 2682 will typically set these SIP fields, and the risks associated with 2683 allowing an adventurous or malicious user to set the LRN do not seem 2684 to be grave, but they should be noted by network operators. 2686 Some additional risks may result from the SIP response code to ISUP 2687 REL Cause Code parameter mapping. Called SIP user agents could 2688 conceivably respond to an INVITE with any arbitrary SIP response 2689 code, and thus they can dictate (within the boundaries of the 2690 mappings supported by the gateway) the Q.850 cause code that will be 2691 sent by the gateway in the resulting REL message. Generally 2692 speaking, the manner in which a call is rejected is unlikely to 2693 provide any avenue for fraud or denial of service - to the best 2694 knowledge of the authors there is no cause code that identified in 2695 this draft that would signal that some call should not be billed, or 2696 that the network should take critical resources off-line. However, 2697 operators may want to scrutinize the set of cause codes that could be 2698 mapped from SIP response codes (listed in 7.2.6.1) to make sure that 2699 no undesirable network-specific behavior could result from operating 2700 a gateway supporting the recommended mappings. 2702 If the Request-URI and the To header field of a request received at a 2703 gateway differ, Section 7.2.1.1 recommends that the To header (if it 2704 is a telephone number) should map to the Original Called Number 2705 parameter, and the Request-URI to the Called Party Number parameter. 2706 However, the user can, at the outset of a request, select a To header 2707 field value that differs from the Request-URI; these two field values 2708 are not required to be the same. This essentially allows a user to 2709 set the ISUP Original Called Number parameter arbitrarily. Any 2710 applications that rely on the Original Called Number for settlement 2711 purposes could be affected by this mapping recommendation. It is 2712 anticipated that future SIP work in this space will arrive at a 2713 better general account of the retargeting of SIP requests that may be 2714 applicable to the OCN mapping. 2716 The arbitrary population of the From header of requests by SIP user 2717 agents has some well-understood security implications for devices 2718 that rely on the From header as an accurate representation of the 2719 identity of the originator. Any gateway that intends to use the From 2720 header to populate the called party's number parameter of an ISUP IAM 2721 message should authenticate the originator of the request and make 2722 sure that they are authorized to assert that calling number (or make 2723 use of some more secure method to ascertain the identity of the 2724 caller). Note that gateways, like all other SIP user agents, MUST 2725 support Digest authentication as described in [1]. 2727 There is another class of potential risk related to the cut-through 2728 of the backwards media path. Several practices described in this 2729 document recommend that a gateway signal an ACM when a called user 2730 agent returns a 18x provisional response code. At that time, 2731 backwards media will be cut through end-to-end in the ISUP network, 2732 and it is possible for the called user agent then to play arbitrary 2733 audio to the caller for an indefinite period of time before 2734 transmitting a final response (in the form of a 2xx or higher 2735 response code). There are conceivable respects in which this 2736 capability could be used illegitimately by the called user agent. It 2737 is also however a useful feature to allow progress tones and 2738 announcements to be played in the backwards direction in the 'ACM 2739 sent' state (so that the caller won't be billed for calls that don't 2740 actually complete but for which failure conditions must be rendered 2741 to the user as in-band audio). In fact, ISUP commonly uses this 2742 backwards cut-through capability in order to pass tones and 2743 announcements relating to the status of a call when an ISUP network 2744 interworks with legacy networks that are not capable of expressing 2745 Q.850 cause codes. 2747 It is the contention of the authors that SIP introduces no risks with 2748 regard to backwards media that do not exist in Q.931-ISUP mapping, 2749 but gateways implementers may want to consider an optional mechanism 2750 (possibly something that could be configured by an operator) that 2751 would cut off such 'early media' on a brief timer - it is unlikely 2752 that more than 20 or 30 seconds of early media is necessary to convey 2753 status information about the call (see Section 7.2.6). A more 2754 conservative approach would be to never cut through backwards media 2755 in the gateway until a 2xx final response has been received. 2757 16. IANA Considerations 2759 This document introduces no new considerations for IANA. 2761 Normative References 2763 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2764 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2765 Session Initiation Protocol", RFC 3261, May 2002. 2767 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 2768 levels", RFC 2119, March 1997. 2770 [3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 2771 Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG 2772 objects", RFC 3204, December 2001. 2774 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2775 Extensions (MIME) Part Two: Media Types", RFC 2046, November 2776 1996. 2778 [5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 2779 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 2781 [6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 2783 [7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2784 2000. 2786 [8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. 2788 [9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header 2789 Field for the Session Initiation Protocol", draft-ietf-sip- 2790 reason-01 (work in progress), August 2002. 2792 Non-normative References 2794 [10] International Telecommunications Union, "Application of the 2795 ISDN user part of CCITT Signaling System No. 7 for 2796 international ISDN interconnection", ITU-T Q.767, February 2797 1991, . 2799 [11] American National Standards Institute, "Signaling System No. 7; 2800 ISDN User Part", ANSI T1.113, January 1995, 2801 . 2803 [12] International Telecommunications Union, "Signaling System No. 2804 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 2805 1999, . 2807 [13] International Telecommunications Union, "Abnormal conditions - 2808 Special release", ITU-T Q.118, September 1997, 2809 . 2811 [14] International Telecommunications Union, "Specifications of 2812 Signaling System No. 7 - ISDN supplementary services", ITU-T 2813 Q.737, June 1997, . 2815 [15] International Telecommunications Union, "Usage of cause 2816 location in the Digital Subscriber Signaling System No. 1 and 2817 the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 2818 1998, . 2820 [16] International Telecommunications Union, "The international 2821 public telecommunications numbering plan", ITU-T E.164, May 2822 1997, . 2824 [17] International Telecommunications Union, "Formats and codes of 2825 the ISDN User Part of Signaling System No. 7", ITU-T Q.763, 2826 December 1999, . 2828 [18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2829 Responses in SIP", draft-ietf-sip-100rel-06 (work in progress), 2830 February 2002. 2832 [19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, 2833 October 2000. 2835 [20] Rosenberg, J., "The SIP UPDATE Method", draft-ietf-sip-update- 2836 02 (work in progress), March 2002. 2838 [21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of 2839 Number Portability and Freephone Service", draft-yu-tel-url-04 2840 (work in progress), November 2001. 2842 Authors' Addresses 2844 Gonzalo Camarillo 2845 Ericsson 2846 Advanced Signalling Research Center 2847 FIN-02420 Jorvas 2848 Finland 2850 Phone: +358 9 299 3371 2851 EMail: Gonzalo.Camarillo@Ericsson.com 2852 URI: http://www.ericsson.com/ 2854 Adam Roach 2855 dynamicsoft 2856 5100 Tennyson Parkway 2857 Suite 1200 2858 Plano, TX 75024 2859 USA 2861 EMail: adam@dynamicsoft.com 2862 URI: sip:adam@dynamicsoft.com 2864 Jon Peterson 2865 NeuStar, Inc. 2866 1800 Sutter St 2867 Suite 570 2868 Concord, CA 94520 2869 USA 2871 Phone: +1 925/363-8720 2872 EMail: jon.peterson@neustar.biz 2873 URI: http://www.neustar.biz/ 2875 Lyndon Ong 2876 Ciena 2877 10480 Ridgeview Court 2878 Cupertino, CA 95014 2879 USA 2881 EMail: lyOng@ciena.com 2882 URI: http://www.ciena.com/ 2884 Appendix A. Acknowledgments 2886 This document existed as an Internet-Draft for four years, and it 2887 received innumerable contributions from members of the various 2888 Transport Area IETF working groups that it called home (which 2889 included the MMUSIC, SIP and SIPPING WGs). In particular, the 2890 authors would like to thank Olli Hynonen, Tomas Mecklin, Bill 2891 Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, 2892 Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, 2893 Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan 2894 Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter 2895 Du, John Elwell and Steve Bellovin for their help and feedback on 2896 this document. The authors would also like to thank ITU-T SG11 for 2897 their advice on ISUP procedures. 2899 Appendix B. Revision History 2901 Changes from draft-ietf-sip-isup-00: 2903 - Merged draft-jfp-sip-isup-header-00 into this draft 2905 - Removed overlap signaling component (now draft-ietf-sip-overlap- 2906 00) 2908 - Adjusted cause code to status code mappings 2910 Changes from draft-ietf-sip-isup-01: 2912 - Added procedures for placing calls on hold 2914 - Generalized language and procedures for LNP, removing ANSI bias 2916 - Fixed usage of 'user=phone' 2918 - Added handling for Segmentation Message in ISUP 2920 - Updated SUS/RES handling to use INFO consistently (rather than 2921 183) 2923 Changes from draft-ietf-sip-isup-02: 2925 - Fixed some more ANSI-specific references (GNI, screening) 2927 - Fixed timer expiry cause code values (6.2.2) 2929 - Removed some bis04 incompatibilities (6.2.10) 2931 - Added motivational text to abstract and introduction 2933 Changes from draft-ietf-sip-isup-03: 2935 - Added provision for SUS/RES over INFO method 2937 - Fixed ANSI CRM/CRA behavior 2939 - Corrected a few status code conflicts 2941 - Righted many nits (thanks Igor!) 2943 Changes from draft-ietf-sipping-isup-00: 2945 - Removed PRACK from call flows 2946 - Some updating to bring language in parity with bis 2948 - Various nits 2950 Changes from draft-ietf-sipping-isup-01: 2952 - Minor editorial corrections. 2954 - Updated references from RFC 2543 to RFC 3261. 2956 - Split normative and non-normative references. 2958 Changes from draft-ietf-sipping-isup-02: 2960 - Strengthened language about overwriting parameters. 2962 - Improved text on interworking indicators in FCI/BCI 2964 - Various nits 2966 Changes from draft-ietf-sipping-isup-03: 2968 - Improved scope language (translation and request routing) 2970 - Number portability / carrier id code mechanisms are optional 2972 - Strengthened Security Considerations 2974 Changes from draft-ietf-sipping-isup-04: 2976 - Added a significant amount of text to Security Considerations 2978 - Fixed requirements section (removing outdated references) 2980 - Added RFC2119 reference and language 2982 - Integrated some Reason header usage 2984 - Improved early media text in requirements and in state machine 2986 - Added some better text on privacy and presentation restriction 2988 - Corrected some straggling text about the use of bodies in CANCEL 2989 requests 2991 - Numerous editorial fixes for clarity 2993 - Made a few last Cause Code to Response Code mapping corrections 2994 - Tweaked FCI/BCI text 2996 Full Copyright Statement 2998 Copyright (C) The Internet Society (2002). All Rights Reserved. 3000 This document and translations of it may be copied and furnished to 3001 others, and derivative works that comment on or otherwise explain it 3002 or assist in its implementation may be prepared, copied, published 3003 and distributed, in whole or in part, without restriction of any 3004 kind, provided that the above copyright notice and this paragraph are 3005 included on all such copies and derivative works. However, this 3006 document itself may not be modified in any way, such as by removing 3007 the copyright notice or references to the Internet Society or other 3008 Internet organizations, except as needed for the purpose of 3009 developing Internet standards in which case the procedures for 3010 copyrights defined in the Internet Standards process must be 3011 followed, or as required to translate it into languages other than 3012 English. 3014 The limited permissions granted above are perpetual and will not be 3015 revoked by the Internet Society or its successors or assigns. 3017 This document and the information contained herein is provided on an 3018 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3019 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3020 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3021 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3022 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3024 Acknowledgement 3026 Funding for the RFC Editor function is currently provided by the 3027 Internet Society.