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