idnits 2.17.1 draft-camarillo-sip-isup-bcp-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 49 longer pages, the longest (page 50) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 50 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1920: '... The 3xx MUST NOT result in the g...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 220 has weird spacing: '...essages is de...' == Line 361 has weird spacing: '...message to co...' == Line 373 has weird spacing: '...message to co...' == Line 730 has weird spacing: '...message to co...' == Line 787 has weird spacing: '...message to co...' == (11 more instances...) -- 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 (September 2000) is 8623 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gonzalo Camarillo/Adam Roach 2 Internet Draft Ericsson 3 Category: Informational March 2000 4 Expires September 2000 5 7 Best Current Practice for ISUP to SIP mapping 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or cite them other than as "work in 23 progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 This document describes a way to perform the mapping between two 37 signalling protocols: SIP and ISUP. 39 Table of Contents 41 1. Introduction........................................... 3 42 2. Scope.................................................. 3 43 3. Scenarios.............................................. 4 44 4. Extensions Required.................................... 5 45 4.1. "Transparent" Transit of ISUP messages................. 5 46 4.2. Understanding of Multipart Bodies...................... 5 47 4.3. Transmission of DTMF information....................... 5 48 4.4. Reliable Transmission of Provisional Responses......... 6 49 4.5. Provisional Media Streams.............................. 6 50 4.6. Mid-Call Transactions Which do not Change SIP State.... 6 51 5. Mapping................................................ 6 52 6. SIP to ISUP mapping.................................... 7 53 6.1. Call Flows............................................. 7 54 6.1.1. En-bloc Call Setup (non auto-answer)................... 7 55 6.1.2. Overlap Call Setup..................................... 8 56 6.1.3. Overlap call setup with a routing (redirect) server.... 11 57 6.1.4. Auto-answer call setup................................. 12 58 6.1.5. ISUP T7 expires........................................ 13 59 6.1.6. SIP Timeout............................................ 13 60 6.1.7. ISUP Setup Failure..................................... 15 61 6.1.8. Cause present in ACM message........................... 15 62 6.1.9. Call cancelled by SIP node............................. 17 63 6.2. State Machine.......................................... 18 64 6.2.1. INVITE received........................................ 19 65 6.2.2. ISUP T7 expires........................................ 21 66 6.2.3. CANCEL or BYE received................................. 21 67 6.2.4. REL received........................................... 22 68 6.2.5. Early ACM received..................................... 24 69 6.2.6. ACM received........................................... 24 70 6.2.7. CON or ANM received.................................... 25 71 6.2.8. Timer T9 expires....................................... 25 72 6.2.9. CPG received........................................... 25 73 6.2.10. ACK received........................................... 26 74 7. ISUP to SIP mapping.................................... 26 75 7.1. Call Flows............................................. 26 76 7.1.1. En-bloc call setup (non auto-answer)................... 26 77 7.1.2. Overlap call setup..................................... 27 78 7.1.3. Overlap call setup with a routing (redirect) server.... 30 79 7.1.4. Auto-answer call setup................................. 32 80 7.1.5. SIP Timeout............................................ 33 81 7.1.6. ISUP T9 Expires........................................ 34 82 7.1.7. SIP Error Response..................................... 35 83 7.1.8. SIP Redirection........................................ 36 84 7.1.9. Call Cancelled by ISUP................................. 37 85 7.2. State Machine.......................................... 38 86 7.2.1. Address received....................................... 39 87 7.2.2. 100 received........................................... 40 88 7.2.3. 18x received........................................... 40 89 7.2.4. 200 received........................................... 41 90 7.2.5. 3xx received........................................... 42 91 7.2.6. 4xx - 6xx received..................................... 42 92 7.2.7. REL received........................................... 43 93 7.2.8. ISUP T11 Expires....................................... 44 94 8. Suspend/Resume......................................... 44 95 9. Normal Release of the Connection....................... 45 96 9.1. SIP initiated.......................................... 45 97 9.2. ISUP Initiated......................................... 45 98 9.2.1. Caller hangs up........................................ 46 99 9.2.2. Callee hangs up........................................ 46 100 10. ISUP maintenance messages.............................. 46 101 10.1. Reset messages......................................... 46 102 10.2. Blocking messages...................................... 47 103 11. Other ISUP flavours.................................... 47 104 12. Acronyms............................................... 47 105 13. Acknowledgments........................................ 48 106 14. References............................................. 48 107 15. Security Considerations................................ 50 108 16. Authors' Addresses..................................... 50 110 1. Introduction 112 SIP [1] is an application layer protocol for establishing, 113 terminating and modifying multimedia sessions. It is typically 114 carried over IP. Telephone calls are considered a type of 115 multimedia sessions where just audio is exchanged. 117 ISUP [2] is a level 4 protocol used in SS7 networks. It typically 118 runs over MTP although it will run also over IP (work in 119 progress, IETF SIGTRAN working group). ISUP is used for 120 controlling telephone calls and for maintenance of the network 121 (blocking circuits, resetting circuits etc.). 123 The module performing the mapping between these two protocols is 124 usually referred to as Media Gateway Controller (MGC). It has 125 logical interfaces towards both networks, the network carrying 126 ISUP and the network carrying SIP, although usually they are on 127 the same physical interface. The MGC also has capabilities for 128 controlling the voice path. There is typically a Media Gateway 129 (MG) with E1/T1 interfaces (voice from PSTN) and with IP 130 interfaces (VoIP). The MGC and the MG can be merged together in 131 one physical box or kept separate. 133 2. Scope 135 This document only takes into account the call functionality of 136 ISUP. Maintenance messages dealing with PSTN trunks are treated 137 only as far as they affect the control of an ongoing call. 139 Messages indicating error or congestion situations in the PSTN 140 (MTP-3) and the recovery mechanisms used such as User Part 141 Available and User Part Test ISUP messages are outside the scope 142 of this document 144 There are several flavours of ISUP. ITU-T Q.767 International 145 ISUP [2] is used through this document and some differences with 146 ANSI ISUP [3] are outlined. ISUP Q.767 [2] was chosen because is 147 the least complex of all the ISUP flavours. Once the mapping 148 between this flavour of ISUP and SIP is clear, mapping from other 149 flavours to SIP will be easier to resolve. 151 This document describes when the media path has to be 152 initialized, terminated, modified, etc., but it does not go into 153 details such as how the initialization is performed or which 154 protocols are used for that purpose. 156 3. Scenarios 158 There are several scenarios where ISUP-SIP mapping takes place. 159 The way the messages are generated is different depending on the 160 scenario. 162 When there is a single MGC and the call is from a SIP phone to a 163 PSTN phone, or vice versa, the MGC generates the ISUP messages 164 based on the methods described in this document. 166 +-------------+ +-----+ +-------------+ 167 | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | 168 +-------------+ +-----+ +-------------+ 170 The scenario where a call originates in the PSTN, goes into a SIP 171 network and terminates in the PSTN again is known as "SIP 172 bridging". SIP bridging should provide ISUP transparency between 173 the PSTN switches handling the call. This is achieved by carrying 174 the incoming ISUP messages in the body of the SIP messages [4] . 175 In this case, the ISUP messages generated by the egress MGC are 176 the ones present in the SIP body (possibly with some 177 modifications; for example, if the called number in the request 178 URI is different from the one present in the ISUP due to SIP 179 redirection, the ISUP message will need to be adjusted). 181 +------+ +-------------+ +-----+ +------------+ +------+ 182 | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 183 +------+ +-------------+ +-----+ +------------+ +------+ 185 SIP is used in the middle of both MGCs because the voice path has 186 to be established through the IP network between both MGs; this 187 structure also allows the call to take advantage of certain SIP 188 services. ISUP messages in the SIP bodies provide further 189 information (such as cause values and optional parameters) to the 190 peer MGC. 192 In both scenarios, the ingress MGC places the incoming ISUP 193 messages in the SIP body by default. Note that this has security 194 implications; see section 15. If the recipient of these messages 195 (typically a SIP UAC/UAS) does not understand them a negotiation 196 using the SIP `Accept' and `Require' headers will take place and 197 they will not be included in the next SIP message exchange. 199 There can be a Signalling Gateway (SG) between the PSTN and the 200 MGC. It encapsulates the ISUP messages over IP. The mapping 201 described in this document is not affected by its presence. 203 4. Extensions Required 205 For a correct mapping between ISUP and SIP, some extensions to 206 the basic SIP specification are needed. These extensions are 207 discussed below. If the SIP UAC/UAS involved in the call does not 208 support them, it is still possible to proceed, but the behavior 209 in the establishment of the call may be slightly different than 210 that expected by the user (e.g. other party answers before 211 receiving the ringback tone, user is not informed about the call 212 being forwarded, etc.). 214 4.1. "Transparent" Transit of ISUP messages 216 To provide users the ability to take advantage of the full range 217 of services afforded by the existing telephone network when 218 placing calls from PSTN to PSTN across a SIP network, SIP 219 messages will need to carry ISUP payloads from gateway to 220 gateway. The format for carrying these messages is defined in 221 "MIME media types for ISUP and QSIG Objects" [4] . 223 SIP clients and servers which do not understand ISUP are 224 encouraged to recognize this MIME type and ignore it. 226 4.2. Understanding of Multipart Bodies 228 In most PSTN interworking situations, the SIP body will be 229 required to carry session information in addition to ISUP and/or 230 billing information. 232 PSTN interworking nodes should understand the MIME type of 233 "multipart/mixed" as defined in RFC2046 [5] . Clients express 234 support for this by including "multipart/mixed" in an "Accept" 235 header. 237 4.3. Transmission of DTMF information 239 Since the codec selected for voice transmission may not be 240 ideally suited for carrying DTMF information, a symbolic method 241 of transmitting this information in-band is desirable (since 242 out-of-band transmission alone would provide many challenges for 243 syncronization of the media stream for tone re-insertion). This 244 transmission will be performed as described in "RTP Payload for 245 DTMF Digits, Telephony Tones and Telephony Signals" [6] . 247 In addition to the need to faithfully carry telephony tones 248 across the audio channel, PSTN interworking situations will 249 require the capability on the part of SIP nodes to collect 250 further digits from the end user. This may be used, for example, 251 to provide authentication information to a SIP node via DTMF 252 without the SIP node needing to process the media stream. This 253 transit is accomplished using the method described in section 2.1 254 of "Sample Uses of SIP INFO with Varying Reliability Needs" [7] . 256 4.4. Reliable Transmission of Provisional Responses 258 Provisional responses are used to transmission of various 259 progress information. PSTN interworking in particular relies on 260 these messages for control of the media channel and timing of 261 messages. 263 PSTN interoperation nodes should implement the extension defined 264 in "Reliability of Provisional Responses in SIP" [8] . 266 4.5. Provisional Media Streams 268 To allow the transmission of messages and tones before a final 269 connection has been established, SIP nodes which interwork with 270 the PSTN need to be able to establish temporary media connections 271 during this period. 273 PSTN interoperating nodes should support the establishement of 274 temporary provisional media streams, as specified in "SIP 183 275 Session Progress Message" [9] . 277 4.6. Mid-Call Transactions Which do not Change SIP State 279 When interworking with PSTN, there are situations when PSTN nodes 280 will need to send messages which do not correspond to any SIP 281 operations to each other across a SIP network. 283 The method for performing this transit will be in the INFO 284 method, defined in "The SIP INFO Method" [10] . 286 Nodes which do serve as PSTN interworking points should accept 287 "405 Method Not Allowed" and "501 Not Implemented" responses to 288 INFO requests as non-fatal. 290 5. Mapping 292 The mapping between ISUP and SIP is described using call flow 293 diagrams and state machines. One state machine handles calls from 294 SIP to ISUP and the second from ISUP to SIP. There are details, 295 such as some retransmissions and some states (waiting for RLC, 296 waiting for ACK etc.), that are not shown in the figures in order 297 to make them easier to follow. 299 The boxes represent the different states of the gateway, and the 300 arrows show changes in the state. The event that triggers the 301 change in the state and the actions to take appear on the arrow: 302 event / section describing the actions to take. 304 For example, `INVITE / 6.1' indicates that an INVITE request has 305 been received by the gateway, and the procedure upon reception is 306 described in the section 6.1 of this document. 308 6. SIP to ISUP mapping 310 6.1. Call Flows 312 The following call flows illustrate the order of messages in 313 typical success and error cases when setting up a call initiated 314 from the SIP network. "100 Trying" acknowledgements to INVITE 315 requests are not explained, since their presence is optional. 317 In these diagrams, all call singnalling (SIP, ISUP) is going to 318 and from the MGC; media handling (e.g. audio cut-through, trunk 319 freeing) is being performed by the MG, under the control of the 320 MGC. For the purpose of simplicity, these are shown as a single 321 node, labeled "MGC/MG." 323 6.1.1. En-bloc Call Setup (non auto-answer) 325 SIP MGC/MG PSTN 326 1|---------INVITE---------->| | 327 |<----------100------------| | 328 | |------------IAM---------->|2 329 | |<=========Audio===========| 330 | |<-----------ACM-----------|3 331 4|<----------18x------------| | 332 |<=========Audio===========| | 333 5|----------PRACK---------->| | 334 6|<----------200------------| | 335 | |<-----------CPG-----------|7 336 8|<----------18x------------| | 337 9|----------PRACK---------->| | 338 10|<----------200------------| | 339 | |<-----------ANM-----------|11 340 | |<=========Audio==========>| 341 12|<----------200------------| | 342 |<=========Audio==========>| | 343 13|-----------ACK----------->| | 345 (1) When a SIP user wishes to begin a session with a PSTN user, 346 the SIP node issues an INVITE request. 348 (2) Upon receipt of an INVITE request, the gateway maps it to an 349 IAM message and sends it to the ISUP network. 351 (3) The remote ISUP node indicates that the address is sufficient 352 to set up a call by sending back an ACM message. 354 (4) The "called party status" code in the ACM message is mapped 355 to a SIP provisional response (180 for "subscriber free" and 356 183 for "no indication") and returned to the SIP node. This 357 response may contain SDP to establish an early media stream 358 (as shown in the diagram). If no SDP is present, the audio 359 will be established in both directions after step 12. 361 (5) The SIP node sends a PRACK message to confirm receipt of the 362 provisional response. 364 (6) The PRACK is confirmed 366 (7) The remote ISUP node may issue a variety of CPG messages to 367 indicate, for example, that the call is being forwarded. 369 (8) Upon receipt of a CPG message, the gateway will map the event 370 code to a SIP provisional response (see section 6.2.6. ) and 371 send it to the SIP node. 373 (9) The SIP node sends a PRACK message to confirm receipt of the 374 provisional response. 376 (10) The PRACK is confirmed 378 (11) Once the PSTN user answers, an ANM message will be sent to 379 the gateway. 381 (12) Upon receipt of the ANM, the gateway will send a 200 message 382 to the SIP node. 384 (13) The SIP node, upon receiving an INVITE final response (200), 385 will send an ACK to acknowledge receipt. 387 6.1.2. Overlap Call Setup 388 SIP MGC/MG PSTN 389 1|---------INVITE---------->| | 390 2|<----------484------------| | 391 3|-----------ACK----------->| | 392 4|---------INVITE---------->| | 393 |<----------100------------| | 394 | |------------IAM---------->|5 395 | |<=========Audio===========| 396 6|---------INVITE---------->| | 397 |<----------100------------| | 398 | |------------SAM---------->|7 399 8|---------INVITE---------->| | 400 |<----------100------------| | 401 | |------------SAM---------->|9 402 10|---------INVITE---------->| | 403 |<----------100------------| | 404 | |------------SAM---------->|11 405 | |<-----------ACM-----------|12 406 13|<----------180------------| | 407 |<=========Audio===========| | 408 14|<----------484------------| | 409 15|<----------484------------| | 410 16|<----------484------------| | 411 17|----------PRACK---------->| | 412 18|<----------200------------| | 413 19|-----------ACK----------->| | 414 20|-----------ACK----------->| | 415 21|-----------ACK----------->| | 416 | |<-----------ANM-----------|22 417 | |<=========Audio==========>| 418 23|<----------200------------| | 419 |<=========Audio==========>| | 420 24|-----------ACK----------->| | 422 (1) When a SIP user wishes to begin a session with a PSTN user, 423 the SIP node issues an INVITE request. 425 (2) The gateway may be able to determine that the number in the 426 SIP message is not long enough to set up a call (for example; 427 it may not have enough of a number to know what PSTN node to 428 route to). Under these circumstances, it will immediately 429 return a "484 Address Incomplete" message. 431 (3) The 484 is acknowledged. 433 (4) After collecting more digits, the SIP node sends another 434 INVITE. This invite contains the same "From" and "Call-ID" 435 headers. The "To" field is updated to reflect the entire 436 called number as known so far. Since the "To" field is 437 different, this transaction represents a different call leg 438 than the INVITE in step 1; consequently, there is no 439 relationship between the CSeq values in the two INVITE 440 messages. Note that the gateway may drop state knowledge 441 between steps 3 and 4 unless ISUP tunnelling is being 442 performed. (For ISUP tunneling, the IAM present in the 443 initial INVITE will need to be reserved for step 5). 445 (5) Once the gateway is not sure that the number is too short, it 446 will send out the digits from the INVITE message as an IAM. 448 (6) As more digits are collected, they will also be sent as 449 INVITE messages. Note that the "To" field still contains the 450 entire string of digits collected so far, not just the new 451 ones. 453 (7) The newly collected digits are sent to the PSTN as SAM 454 messages. 456 (8) See step 6 458 (9) See step 7 460 (10) See step 6 462 (11) See step 7 464 (12) Once the remote PSTN node receives enough digits, it will 465 send an ACM message to indicate that it can now route the 466 call. 468 (13) The gateway sends a 180 message for the most recent pending 469 transaction (or a 183 if the "called party status" field is 470 marked "no indication"). The transaction to which this 471 response belongs will be same as the INVITE which contains a 472 complete phone number in its "To" field (the one sent in step 473 10). 475 (14) "484 Address Incomplete" is sent to complete the INVITE 476 transaction started in step 4. 478 (15) "484 Address Incomplete" is sent to complete the INVITE 479 transaction started in step 6. 481 (16) "484 Address Incomplete" is sent to complete the INVITE 482 transaction started in step 8. 484 (17) The remote node sends a PRACK to acknowledge receipt of the 485 18x message sent in step 13. 487 (18) The 484 from step 14 is acknowledged. 489 (19) The 484 from step 15 is acknowledged. 491 (20) The 484 from step 16 is acknowledged. 493 (21) Once the PSTN user answers, an ANM message will be sent to 494 the gateway. 496 (22) Upon receipt of the ANM, the gateway will send a 200 message 497 to the SIP node. 499 (23) The SIP node, upon receiving an INVITE final response (200), 500 will send an ACK to acknowledge receipt. 502 6.1.3. Overlap call setup with a routing (redirect) server 504 SIP Routing Server PSTN 505 1|---------INVITE---------->| | 506 2|<----------484------------| | 507 3|-----------ACK----------->| | 508 4|---------INVITE---------->| | 509 5|<----------484------------| | 510 6|-----------ACK----------->| | 511 7|---------INVITE---------->| | 512 8|<----------302------------| | 513 9|-----------ACK----------->| | 514 | | 515 | | 516 | MGC/MG | 517 10|---------INVITE---------->| | 518 ... 520 (1) When a SIP user wishes to begin a session with a PSTN user, 521 the SIP node issues an INVITE request. In this example, the 522 INVITE is sent to a server which knows how to select the 523 egress gateway based on a numbering prefix. 525 (2) Since the routing server doesn't have enough information to 526 select an egress gateway, it responds with a "484 Address 527 Incomplete". 529 (3) The 484 is acknowledged. 531 (4) After collecting more digits, the SIP node sends another 532 INVITE. This invite contains the same "From" and "Call-ID" 533 headers. The "To" field is updated to reflect the entire 534 called number as known so far. Since the "To" field is 535 different, this transaction represents a different call leg 536 than the INVITE in step 1; consequently, there is no 537 relationship between the CSeq values in the two INVITE 538 messages. Note that the routing server will probably drop 539 state knowledge between steps 3 and 4. 541 (5) In this example, there is still not enough information to 542 route the call. 544 (6) The 484 is acknowledged. 546 (7) As in step 4, more digits are collected. While this INVITE 547 contains enough information for the routing server to select 548 a gateway, it is quite probable that the number is not yet 549 complete. 551 (8) A "302 Temporarily Moved" response is returned to redirect 552 the SIP node to the appropriate gateway. (In practice, this 553 may not necessarily be a gateway; it might be another 554 redirect server, a proxy server, or a native client). 556 (9) The 302 is acknowledged. 558 (10) The call now continues as in step 1 of section 6.1.2. 560 6.1.4. Auto-answer call setup 562 SIP MGC/MG PSTN 563 1|---------INVITE---------->| | 564 |<----------100------------| | 565 | |------------IAM---------->|2 566 | |<=========Audio===========| 567 | |<-----------CON-----------|3 568 | |<=========Audio==========>| 569 4|<----------200------------| | 570 |<=========Audio==========>| | 571 5|-----------ACK----------->| | 573 (1) When a SIP user wishes to begin a session with a PSTN user, 574 the SIP node issues an INVITE request. 576 (2) Upon receipt of an INVITE request, the gateway maps it to an 577 IAM message and sends it to the ISUP network. 579 (3) Since the remote node is configured for automatic answering, 580 it will send a CON message upon receipt of the IAM. (For 581 ANSI, this message will be an ANM). 583 (4) Upon receipt of the ANM, the gateway will send a 200 message 584 to the SIP node. 586 (5) The SIP node, upon receiving an INVITE final response (200), 587 will send an ACK to acknowledge receipt. 589 6.1.5. ISUP T7 expires 591 SIP MGC/MG PSTN 592 1|---------INVITE---------->| | 593 |<----------100------------| | 594 | |------------IAM---------->|2 595 | |<=========Audio===========| 596 | | *** T7 Expires *** | 597 | ** MG Releases PSTN Trunk ** | 598 4|<----------504------------|------------REL---------->|3 599 5|-----------ACK----------->| | 601 (1) When a SIP user wishes to begin a session with a PSTN user, 602 the SIP node issues an INVITE request. 604 (2) Upon receipt of an INVITE request, the gateway maps it to an 605 IAM message and sends it to the ISUP network. The ISUP timer 606 T7 is started at this point. 608 (3) The ISUP timer T7 expires before receipt of an ACM or CON 609 message, so a REL message is sent to cancel the call. 611 (4) A gateway timeout message is sent back to the SIP node. 613 (5) The SIP node, upon receiving an INVITE final response (504), 614 will send an ACK to acknowledge receipt. 616 6.1.6. SIP Timeout 617 SIP MGC/MG PSTN 618 1|---------INVITE---------->| | 619 |<----------100------------| | 620 | |------------IAM---------->|2 621 | |<=========Audio===========| 622 | |<-----------CON-----------|3 623 | |<=========Audio==========>| 624 4|<----------200------------| | 625 | *** T1 Expires *** | | 626 |<----------200------------| | 627 | *** T1 Expires *** | | 628 |<----------200------------| | 629 | *** T1 Expires *** | | 630 |<----------200------------| | 631 | *** T1 Expires *** | | 632 |<----------200------------| | 633 | *** T1 Expires *** | | 634 |<----------200------------| | 635 | *** T1 Expires *** | | 636 5|<----------200------------| | 637 | *** T1 Expires *** | | 638 | ** MG Releases PSTN Trunk ** | 639 7|<----------BYE------------|------------REL---------->|6 640 | |<-----------RLC-----------|8 642 (1) When a SIP user wishes to begin a session with a PSTN user, 643 the SIP node issues an INVITE request. 645 (2) Upon receipt of an INVITE request, the gateway maps it to an 646 IAM message and sends it to the ISUP network. 648 (3) Since the remote node is configured for automatic answering, 649 it will send a CON message upon receipt of the IAM. 651 (4) Upon receipt of the ANM, the gateway will send a 200 message 652 to the SIP node and set SIP timer T1. 654 (5) The response is retransmitted every time the SIP timer T1 655 expires. 657 (6) After seven retransmissions, the call is torn down by sending 658 a REL to the ISUP node, with a cause code of 102 (recover on 659 timer expiry). 661 (7) A BYE is transmitted to the SIP node in an attempt to close 662 the call. Further handling for this clean up is not shown, 663 since the SIP node's state is not easily known in this 664 scenario. 666 (8) Upon receipt of the REL message, the remote ISUP node will 667 reply with an RLC message. 669 6.1.7. ISUP Setup Failure 671 SIP MGC/MG PSTN 672 1|---------INVITE---------->| | 673 |<----------100------------| | 674 | |------------IAM---------->|2 675 | |<-----------REL-----------|3 676 | |------------RLC---------->|4 677 5|<----------4xx+-----------| | 678 6|-----------ACK----------->| | 680 (1) When a SIP user wishes to begin a session with a PSTN user, 681 the SIP node issues an INVITE request. 683 (2) Upon receipt of an INVITE request, the gateway maps it to an 684 IAM message and sends it to the ISUP network. 686 (3) Since the remote ISUP node is unable to complete the call, it 687 will send a REL. 689 (4) The gateway releases the circuit and confirms that it is 690 available for reuse by sending an RLC. 692 (5) The gateway translates the cause code in the REL to a SIP 693 error response (see section 6.2.4. ) and sends it to the SIP 694 node. 696 (6) The SIP node sends an ACK to acknowledge receipt of the 697 INVITE final response. 699 6.1.8. Cause present in ACM message 700 SIP MGC/MG PSTN 701 1|---------INVITE---------->| | 702 |<----------100------------| | 703 | |------------IAM---------->|2 704 | |<=========Audio===========| 705 | |<---ACM with cause code---|3 706 4|<------183 with SDP-------| | 707 |<=========Audio===========| | 708 5|----------PRACK---------->| | 709 6|<----------200------------| | 710 ** Interwork timer expires ** 711 7|<----------4xx+-----------| | 712 | |------------REL---------->|8 713 | |<-----------RLC-----------|9 714 10|-----------ACK----------->| | 716 (1) When a SIP user wishes to begin a session with a PSTN user, 717 the SIP node issues an INVITE request. 719 (2) Upon receipt of an INVITE request, the gateway maps it to an 720 IAM message and sends it to the ISUP network. 722 (3) Since the ISUP node is unable to complete the call and wants 723 to generate the error tone/announcement itself, it sends an 724 ACM with a cause code. The gateway starts an interwork timer. 726 (4) Upon receipt of an ACM with cause, the gateway will generate 727 a 183 message towards the SIP node; this contains SDP to 728 establish early media cut-through. 730 (5) The SIP node sends a PRACK message to confirm receipt of the 731 provisional response. 733 (6) The PRACK is confirmed 735 (7) A final INVITE response, based on the cause code received in 736 the earlier ACM message, is generated and sent to the SIP 737 node to terminate the call. See section 6.2.4. for the table 738 which contains the mapping from cause code to SIP response. 740 (8) Upon expiration of the interwork timer, a REL is sent towards 741 the SIP node to terminate the call. Note that the SIP node 742 can also terminate the call by sending a CANCEL before the 743 interwork timer expires. In this case, the signalling 744 progresses as in section 6.1.9. 746 (9) Upon receipt of the REL message, the remote ISUP node will 747 reply with an RLC message. 749 (10) The SIP node sends an ACK to acknowledge receipt of the 750 INVITE final response. 752 6.1.9. Call cancelled by SIP node 754 SIP MGC/MG PSTN 755 1|---------INVITE---------->| | 756 |<----------100------------| | 757 | |------------IAM---------->|2 758 | |<=========Audio===========| 759 | |<-----------ACM-----------|3 760 4|<----------18x------------| | 761 |<=========Audio===========| | 762 5|----------PRACK---------->| | 763 6|<----------200------------| | 764 | ** MG Releases IP Resources ** | 765 7|----------CANCEL--------->| | 766 8|<----------200------------| | 767 | ** MG Releases PSTN Trunk ** | 768 | |------------REL---------->|9 769 10|<----------487------------| | 770 | |<-----------RLC-----------|11 771 12|-----------ACK----------->| | 773 (1) When a SIP user wishes to begin a session with a PSTN user, 774 the SIP node issues an INVITE request. 776 (2) Upon receipt of an INVITE request, the gateway maps it to an 777 IAM message and sends it to the ISUP network. 779 (3) The remote ISUP node indicates that the address is sufficient 780 to set up a call by sending back an ACM message. 782 (4) The "called party status" code in the ACM message is mapped 783 to a SIP provisional response (180 for "subscriber free" and 784 183 for "no indication") and returned to the SIP node. This 785 response may contain SDP to establish an early media stream. 787 (5) The SIP node sends a PRACK message to confirm receipt of the 788 provisional response. 790 (6) The PRACK is confirmed 792 (7) To cancel the call before it is answered, the SIP node sends 793 a CANCEL request. 795 (8) The CANCEL request is confirmed with a 200 response. 797 (9) Upon receipt of the CANCEL request, the gateway sends a REL 798 message to terminate the ISUP call. 800 (10) The gateway sends a "487 Call Cancelled" message to the SIP 801 node to complete the INVITE transaction. 803 (11) Upon receipt of the REL message, the remote ISUP node will 804 reply with an RLC message. 806 (12) Upon receipt of the 487, the SIP node will confirm reception 807 with an ACK. 809 6.2. State Machine 811 Note that REL can be received in any state; the handling is the 812 same for each case (see section 6.2.4. ). 814 +---------+ 815 +----------------------->| Idle |<---------------------+ 816 | +----+----+ | 817 | | | 818 | | INVITE/6.2.1 | 819 | V | 820 | T7/6.2.2 +-------------------------+ REL/6.2.4 | 821 +<----------------+ Trying +------------>+ 822 | +-+--------+------+-------+ | 823 | CANCEL/6.2.3 | | | | | 824 +<----------------+ | E.ACM/ | ACM/ | CON/ | 825 | | 6.2.5 |6.2.6 | 6.2.7 | 826 | V | | | 827 | T9/6.2.8 +--------------+ | | | 828 +<----------+ Not alerting | | | | 829 | +-------+------+ | | | 830 | CANCEL/6.2.3 | | | | | 831 |<--------------+ | CPG/ | | | 832 | | 6.2.9 | | | 833 | V V | | 834 | T9/6.2.8 +---------------+ | REL/6.2.4 | 835 +<----------------+ Alerting |-|-------------------->| 836 |<----------------+--+-----+------+ | | 837 | CANCEL/6.2.3 | ^ | | | 838 | CPG/ | | | ANM/ | | 839 | 6.2.9 +--+ | 6.2.7 | | 840 | V V | 841 | +-------------------------+ REL/9.2 | 842 | | Waiting for ACK |------------>| 843 | +-------------+-----------+ | 844 | | | 845 | | ACK/6.2.10 | 846 | V | 847 | BYE/9.1 +-------------------------+ REL/9.2 | 848 +<----------------+ Connected +------------>+ 849 +-------------------------+ 851 6.2.1. INVITE received 853 When an INVITE request is received by the gateway, a "100 Trying" 854 response may be sent back to the SIP network indicating that the 855 MGC is handling the call. 857 The resources for the media stream have to be reserved at this 858 stage, since an IAM message cannot be sent before the resource 859 reservation takes place. Typically the resources consist of a 860 time slot in an E1/T1 and an RTP/UDP port on the IP side. 861 Resources might also include QoS or/and security provisions. 862 Before sending the IAM the MG gets backward through connected. 864 An ISUP IAM is sent. If the incoming INVITE contains a IAM in its 865 body this IAM is sent (possibly with certain changes; for 866 example, the called number may need to be updated from the "To" 867 field if the call was redirected inside the SIP network). If no 868 IAM is present the MGC generates one. The mandatory parameters of 869 the IAM are described below: 871 Message type: IAM 873 Nature of connection indicators 874 Satellite Indicator: 00 no satellite circuit 875 Continuity check indicator: It depends on the call 876 typically, 0 (no check) 877 Echo control device indicator: It depends on the call 879 Forward call indicators 880 National/International call indicator: It depends on the call 881 End-to-end method indicator: 00 no end-to-end method 882 Interworking indicator: 0 no interworking 883 End-to-end information indicator 0 no end-to-end info 884 ISDN user part indicator: 1 ISUP all the way 885 ISDN user part preference indicator: 00 ISUP preferred 886 ISDN access indicator: 1 ISDN access 887 SCCP method indicator: 0 no indication 889 Calling party's category: Depends on caller; usually 890 00001010 ordinary 892 Transmission medium requirement: It depends on the call 894 Called party's number: Based on the 'to' field 896 The optional parameter `Calling party number' can be added. Its 897 value can be derived based on the SIP `from' header. Optionally, 898 if this information cannot be verified, it may be sent as a 899 `Generic Address Parameter.' Further, the gateway may choose to 900 populate the `Original Called Number' (if it had to update the 901 `Called Number' field) and the `Charge Number' field (based on a 902 billing number obtained through means which are outside the scope 903 of this document). 905 When the ISUP parameters regarding interworking are set, this 906 indicates that ISDN is interworking with a network which is not 907 capable of providing as many services as ISDN does. ISUP will 908 therefore not employ certain features it otherwise normally uses. 910 Thus, `interworking encountered' must not be specified so that 911 ISUP behaves normally. SIP is considered as an SS7 network and a 912 SIP phone is considered as ISDN access since the SIP network is 913 supposed to provide at least as many services as ISUP. 915 Claiming to be an ISDN node might make the callee request ISDN 916 user to user services. Since user to user sevices 1 and 2 must be 917 requested by the caller, they do not represent a problem [13] . 918 User to user service 3 can be requested by the callee also. In 919 non-SIP bridging situations, the MGC should be capable of 920 rejecting this service request. 922 After sending the IAM the timer T7 is started. The default value 923 of T7 is between 20 and 30 seconds. The MGC goes to the `Trying' 924 state. 926 When overlap signalling is used in SIP bridging situations, more 927 INVITEs might arrive containing subsequent digits of the callees' 928 number. These INVITEs have the same Call-ID and From fields, but 929 the To field contains more digits. 931 The MGC receives these digits and sends a SAM with the new digits 932 and restarts T7 every time a new INVITE arrives. All the INVITEs 933 but the last one containing all the digits are answered with 484 934 Address Incomplete. The reception of an ACM from the ISUP network 935 confirms that the callees' address is complete. 937 See sections 6.1.2. and 7.1.2. for a more detailed handling of 938 overlapped dialing. 940 6.2.2. ISUP T7 expires 942 Since no response was received from the PSTN all the resources in 943 the MG are released. A `408 request timeout' is sent back to the 944 SIP network. A REL message with cause value 111 (protocol error) 945 is sent to the PSTN. The PSTN responds with RLC and the SIP 946 network responds with an ACK indicating that the release sequence 947 has been completed. 949 6.2.3. CANCEL or BYE received 951 If a CANCEL or BYE request is received, a `200 OK' is sent to the 952 SIP network to confirm the CANCEL or BYE; a 487 is also sent to 953 terminate the INVITE transaction. All the resources are released 954 and a REL message is sent to the PSTN with cause value 16 (normal 955 clearing). A RLC from the PSTN is received indicating that the 956 release sequence is complete. 958 It is important that all the resources are released before the 959 gateway sends any REL message. 961 In SIP bridging situations, a REL might arrive in the CANCEL or 962 BYE request body. This REL is sent to the PSTN. 964 This section ( 6.2.3. ) applies every time that a CANCEL or a BYE 965 is received before a final SIP response has been sent. 967 6.2.4. REL received 969 This section applies every time that a REL is received before a 970 final SIP response has been sent. 972 The resources are released in the MG and a RLC is sent to the 973 ISUP network to indicate that the circuit is available for reuse. 975 If the INVITE originating this transaction contained ISUP 976 messages in its body (IAM or SAMs), the MGC is handling a SIP 977 bridging situation. Therefore, the REL message jut received 978 should be included in the body of the response. 980 The REL contains a cause value. The SIP response is sent based on 981 this cause value. If a cause value other than what is listed 982 below is received, the default response `500 Server internal 983 error' would be used. 985 Normal event 987 ISUP Cause value SIP response 988 ---------------- ------------ 989 1 unallocated number 410 Gone 990 2 no route to network 404 Not found 991 3 no route to destination 404 Not found 992 4 send special information tone --- 993 16 normal call clearing --- 994 17 user busy 486 Busy here 995 18 no user responding 480 Temporarily unavailable 996 19 no answer from the user 480 Temporarily unavailable 997 21 call rejected 603 Decline 998 22 number changed 301 Moved Permanently 999 27 destination out of order 404 Not found 1000 28 address incomplete 484 Address incomplete 1001 29 facility rejected 501 Not implemented 1002 31 normal unspecified 404 Not found 1004 A REL with cause 22 (number changed) might contain information 1005 about a new number where the callee might be reachable. If the 1006 MGC is able to parse this information it might be added to the 1007 SIP response in a Contact header. 1009 Resource unavailable 1011 This kind of cause value indicates a non permanent situation. A 1012 `Retry-After' header has to be added to the response. 1014 ISUP Cause value SIP response 1015 ---------------- ------------ 1016 34 no circuit available 503 Service unavailable 1017 38 network out of order 503 Service unavailable 1018 41 temporary failure 503 Service unavailable 1019 42 switching equipment congestion 503 Service unavailable 1020 44 requested channel not available 503 Service unavailable 1021 47 resource unavailable 503 Service unavailable 1023 Service or option not available 1025 This kind of cause value indicates a permanent situation 1027 ISUP Cause value SIP response 1028 ---------------- ------------ 1029 55 incoming calls bared within CUG 603 Decline 1030 57 bearer capability not authorized 503 Service unavailable 1031 58 bearer capability not presently 503 Service unavailable 1032 available 1033 63 service/option not available 503 Service unavailable 1035 Service or option not implemented 1037 ISUP Cause value SIP response 1038 ---------------- ------------ 1039 65 bearer capability not implemented 501 Not implemented 1040 79 service or option not implemented 501 Not implemented 1042 Invalid message 1044 ISUP Cause value SIP response 1045 ---------------- ------------ 1046 87 user not member of CUG 503 Service unavailable 1047 88 incompatible destination 503 Service unavailable 1048 95 invalid message 503 Service unavailable 1050 Protocol error 1051 ISUP Cause value SIP response 1052 ---------------- ------------ 1053 102 recovery of timer expiry 408 Request timeout 1054 111 protocol error 500 Server internal error 1056 Interworking 1058 ISUP Cause value SIP response 1059 ---------------- ------------ 1060 127 interworking unspecified 500 Server internal error 1062 6.2.5. Early ACM received 1064 This message is sent in certain situations for resetting the 1065 timers. In these cases this message indicates that the call is in 1066 progress but callee is not being alerted. This occurs for example 1067 in mobile networks, where roaming can take a long time. The early 1068 ACM is sent before the user is alerted to reset T7 and start T9. 1070 An ACM is considered an `early ACM' if the Called Party's Status 1071 Indicator is set to 00 (no indication). 1073 After receiving an early ACM the progress of the call is 1074 indicated by the network sending CPGs. 1076 When there is interworking with some old systems, it is possible 1077 to receive an ANM immediately after an early ACM (without CPG). 1078 In this situation the SIP user will not hear any kind of ringback 1079 tone before the callee answers. In ISDN [11] this is solved by 1080 connecting the voice path backwards before sending the IAM. 1082 The MGC sends a 183 Session Progress [9] to the SIP network with 1083 a media description inside. In SIP bridging situations the early 1084 ACM is included in the response body. Thus, the problem of 1085 missing the ring back tone is solved and the early ACM is 1086 transported transparently through the SIP network. 1088 6.2.6. ACM received 1090 Upon reception of an ACM timer T9 is started. T9 typically lasts 1091 between 90 seconds and 3 minutes [12] . It allows the caller to 1092 hear announcements from the network for that period of time 1093 without being charged for the connection. If longer announcements 1094 have to be played the network has to send an ANM. When the ANM is 1095 sent the call begins being charged. 1097 The nearest local exchange to the callee generates the ringback 1098 tone and may send voice announcements. 1100 A `180 Ringing' is sent to the SIP network. It contains a media 1101 description. The ringback tone or the proper announcements will 1102 be generated by the PSTN exchange, and not by the callers SIP 1103 UAC/UAS. 1105 In SIP bridging situations, the ACM is included in the body of 1106 the 180 response. 1108 6.2.7. CON or ANM received 1110 A `200 OK' response is sent to the SIP network. In SIP bridging 1111 situations, the ISUP message is included in the body of the 200 1112 OK response. This is also the point at which a two-way media 1113 stream will be established. 1115 6.2.8. Timer T9 expires 1117 This indicates that the ANM has not arrived in time specified. 1118 This results in the call being aborted. All the resources related 1119 to the media path are released. A `480 temporarily unavailable' 1120 is sent to the SIP network. A REL message with cause value 19 (no 1121 answer from the user) is sent to the ISUP part. The PSTN responds 1122 with RLC and the SIP network responds with an ACK indicating that 1123 the release sequence has been completed. 1125 6.2.9. CPG received 1127 A CPG can indicate progress, alerting or in-band information. If 1128 the CPG comes after an ACM, there is already a one-way voice path 1129 open, so there is no need of taking further action in the media 1130 path. 1132 In SIP bridging situations, the CPG is sent in the body of a 18x 1133 response, determined from the CPG event code. 1135 ISUP event code SIP response 1136 ---------------- ------------ 1137 1 Alerting 180 Ringing 1138 2 Progress 183 Call progress 1139 3 In-band information 183 Call progress 1140 4 Call forward; line busy 181 Call is being forwarded 1141 5 Call forward; no reply 181 Call is being forwarded 1142 6 Call forward; unconditional 181 Call is being forwarded 1143 - (no event code present) 183 Call progress 1145 Note that, if the CPG does not indicate "Alerting," the current 1146 state will not change. 1148 6.2.10. ACK received 1150 At this stage, the two-way voice channel may be modified based on 1151 the SDP present in the ACK. The call is connected and the 1152 conversation can take place. 1154 7. ISUP to SIP mapping 1156 7.1. Call Flows 1158 The following call flows illustrate the order of messages in 1159 typical success and error cases when setting up a call initiated 1160 from the PSTN network. "100 Trying" acknowledgements to INVITE 1161 requests are not explained, since their presence is optional. 1163 In these diagrams, all call singnalling (SIP, ISUP) is going to 1164 and from the MGC; media handling (e.g. audio cut-through, trunk 1165 freeing) is being performed by the MG, under the control of the 1166 MGC. For the purpose of simplicity, these are shown as a single 1167 node, labeled "MGC/MG." 1169 7.1.1. En-bloc call setup (non auto-answer) 1171 SIP MGC/MG PSTN 1172 | |<-----------IAM-----------|1 1173 | |==========Audio==========>| 1174 2|<--------INVITE-----------| | 1175 |-----------100----------->| | 1176 3|-----------18x----------->| | 1177 |==========Audio==========>| | 1178 | |------------ACM---------->|4 1179 5|<---------PRACK-----------| | 1180 6|-----------200----------->| | 1181 7|-----------18x----------->| | 1182 | |------------CPG---------->|8 1183 9|<---------PRACK-----------| | 1184 10|-----------200----------->| | 1185 11|-----------200----------->| | 1186 |<=========Audio==========>| | 1187 | |------------ANM---------->|12 1188 | |<=========Audio==========>| 1189 13|<----------ACK------------| | 1191 (1) When a PSTN user wishes to begin a session with a SIP user, 1192 the PSTN network generates an IAM message towards the 1193 gateway. 1195 (2) Upon receipt of the IAM message, the gateway generates an 1196 INVITE message, and sends it to an appropriate SIP node based 1197 on called number analysis. 1199 (3) When an event signifying that the call has sufficient 1200 addressing information occurs, the SIP node will generate a 1201 provisional response of 180 or greater. If this 180 contains 1202 a session description, 1204 (4) Upon receipt of a provisional response of 180 or greater, the 1205 gateway will generate an ACM message. If the response is not 1206 180, the ACM will carry a "called party status" value of "no 1207 indication." 1209 (5) The gateway sends a PRACK message to confirm receipt of the 1210 provisional response. 1212 (6) The PRACK is confirmed 1214 (7) The SIP node may use further provisional messages to indicate 1215 call progress. 1217 (8) After an ACM has been sent, all provisional responses will 1218 translate into ISUP CPG messages as indicated in 7.2.3. 1220 (9) The gateway sends a PRACK message to confirm receipt of the 1221 provisional response. 1223 (10) The PRACK is confirmed 1225 (11) When the SIP node answers the call, it will send a 200 OK 1226 message. 1228 (12) Upon receipt of the 200 OK message, the gateway will send an 1229 ANM message towards the ISUP node. 1231 (13) The gateway will send an ACK to the SIP node to acknowledge 1232 receipt of the INVITE final response. 1234 7.1.2. Overlap call setup 1236 Note that supporting overlap dialing in the SIP network is an 1237 option that may be deemed undesirable due to the large number of 1238 messages involved. In this case, the gateway may elect to collect 1239 digits until a timer expires or a stop digit (such as #) is 1240 entered by the user. 1242 SIP MGC/MG PSTN 1243 | |<-----------IAM-----------|1 1244 | |==========Audio==========>| 1245 2|<--------INVITE-----------| | 1246 3|-----------484----------->| | 1247 4|<----------ACK------------| | 1248 | |<-----------SAM-----------|5 1249 6|<--------INVITE-----------| | 1250 |-----------100----------->| | 1251 | |<-----------SAM-----------|7 1252 8|<--------INVITE-----------| | 1253 |-----------100----------->| | 1254 | |<-----------SAM-----------|9 1255 10|<--------INVITE-----------| | 1256 |-----------100----------->| | 1257 | |<-----------SAM-----------|11 1258 12|<--------INVITE-----------| | 1259 |-----------100----------->| | 1260 13|-----------18x----------->| | 1261 |==========Audio==========>| | 1262 14|<---------PRACK-----------| | 1263 | |------------ACM---------->|15 1264 16|-----------484----------->| | 1265 17|<----------ACK------------| | 1266 18|-----------484----------->| | 1267 19|<----------ACK------------| | 1268 20|-----------484----------->| | 1269 21|<----------ACK------------| | 1270 22|-----------200----------->| | 1271 23|-----------18x----------->| | 1272 | |------------CPG---------->|24 1273 25|<---------PRACK-----------| | 1274 26|-----------200----------->| | 1275 27|-----------200----------->| | 1276 |<=========Audio==========>| | 1277 | |------------ANM---------->|28 1278 | |<=========Audio==========>| 1279 29|<----------ACK------------| | 1281 (1) When a PSTN user wishes to begin a session with a SIP user, 1282 the PSTN network generates an IAM message towards the 1283 gateway. 1285 (2) Upon receipt of the IAM message, the gateway generates an 1286 INVITE message, and sends it to an appropriate SIP node based 1287 on called number analysis. It is possible that the gateway 1288 won't have enough information to send the INVITE yet; this 1289 situation is not shown. Under these circumstances, the 1290 gateway holds on to the IAM until it has received enough 1291 digits that it knows where to send the INVITE. 1293 (3) The far end may immediately determine that it is unable to 1294 terminate the call due to an insufficient number of digits. 1295 It will return a "484 Address Incomplete" message under these 1296 circumstances. 1298 (4) The 484 is acknowledged. 1300 (5) A SAM arrives from the PSTN with additional digits present. 1302 (6) The gateway appends the new digits to the number it is 1303 sending in the "To" field and re-sends the INVITE. This 1304 INVITE contains the same "From" and "Call-ID" headers. Since 1305 the "To" field of this message is different from the previous 1306 INVITE(s), this transaction represents a different call leg 1307 than the INVITE in step 1; consequently, there is no 1308 relationship between the CSeq values in the two INVITE 1309 messages. 1311 (7) See step 5 1313 (8) See step 6 1315 (9) See step 5 1317 (10) See step 6 1319 (11) See step 5 1321 (12) See step 6 1323 (13) Once the far end SIP node has determined that it has enough 1324 information to successfully route the call, it sends a 18x 1325 message. 1327 (14) The gateway sends a PRACK message to confirm receipt of the 1328 provisional response. 1330 (15) Upon receipt of a provisional response of 180 or greater, 1331 the gateway will generate an ACM message to indicate that 1332 enough digits have been collected. If the response is not 1333 180, the ACM will carry a "called party status" value of "no 1334 indication." 1336 (16) "484 Address Incomplete" arrives to complete the INVITE 1337 transaction started in step 6. 1339 (17) The 484 in step 16 is acknowledged 1340 (18) "484 Address Incomplete" arrives to complete the INVITE 1341 transaction started in step 8. 1343 (19) The 484 in step 18 is acknowledged 1345 (20) "484 Address Incomplete" arrives to complete the INVITE 1346 transaction started in step 10. 1348 (21) The 484 in step 20 is acknowledged 1350 (22) The PRACK from step 14 is acknowledged 1352 (23) The SIP node may use further provisional messages to 1353 indicate call progress. 1355 (24) After an ACM has been sent, all provisional responses will 1356 translate into ISUP CPG messages as indicated in 7.2.3. 1358 (25) The gateway sends a PRACK message to confirm receipt of the 1359 provisional response. 1361 (26) The PRACK is confirmed 1363 (27) When the SIP node answers the call, it will send a 200 OK 1364 message. 1366 (28) Upon receipt of the 200 OK message, the gateway will send an 1367 ANM message towards the ISUP node. 1369 (29) The gateway will send an ACK to the SIP node to acknowledge 1370 receipt of the INVITE final response. 1372 7.1.3. Overlap call setup with a routing (redirect) server 1373 Redirect Server MGC/MG PSTN 1374 | |<-----------IAM-----------|1 1375 | |==========Audio==========>| 1376 2|<--------INVITE-----------| | 1377 3|-----------484----------->| | 1378 4|<----------ACK------------| | 1379 | |<-----------SAM-----------|5 1380 6|<--------INVITE-----------| | 1381 7|-----------484----------->| | 1382 8|<----------ACK------------| | 1383 | |<-----------SAM-----------|9 1384 10|<--------INVITE-----------| | 1385 11|-----------302----------->| | 1386 12|<----------ACK------------| | 1387 | | 1388 | | 1389 Egress MGC/MG | | 1390 13|<--------INVITE-----------| | 1391 |-----------100----------->| | 1392 | |<-----------SAM-----------| 1393 ... 1395 (1) When a PSTN user wishes to begin a session with a SIP user, 1396 the PSTN network generates an IAM message towards the 1397 gateway. 1399 (2) Upon receipt of the IAM message, the gateway generates an 1400 INVITE message, and sends it to an appropriate SIP node based 1401 on called number analysis. In this example, this node is a 1402 routing (redirection) server. 1404 (3) Since the routing server doesn't have enough information to 1405 select an egress gateway, it responds with a "484 Address 1406 Incomplete". 1408 (4) The 484 is acknowledged. 1410 (5) After collecting more digits, the PSTN node sends a SAM with 1411 the additional digits. 1413 (6) The gateway appends the new digits to the number it is 1414 sending in the "To" field and re-sends the INVITE. This 1415 INVITE contains the same "From" and "Call-ID" headers. Since 1416 the "To" field of this message is different from the previous 1417 INVITE(s), this transaction represents a different call leg 1418 than the INVITE in step 1; consequently, there is no 1419 relationship between the CSeq values in the two INVITE 1420 messages. 1422 (7) In this example, there is still not enough information to 1423 route the call. 1425 (8) The 484 is acknowledged. 1427 (9) See step 5. 1429 (10) See step 6. 1431 (11) The INVITE finally contains enough digits that the redirect 1432 server can select a next-hop SIP node. A "302 Temporarily 1433 Moved" response is returned to redirect the SIP node to the 1434 appropriate gateway. (In practice, this may not necessarily 1435 be a gateway; it might be another redirect server, a proxy 1436 server, or a native client). Note that it is quite probable 1437 that the called number is not completely collected at this 1438 time; sending an ACM towards the PSTN would be extremely 1439 destructive at this point in the call, since it would prevent 1440 any further collection of digits. 1442 (12) The 302 is acknowledged. 1444 (13) The call now continues as in step 2 of section 7.1.2. 1446 7.1.4. Auto-answer call setup 1448 SIP MGC/MG PSTN 1449 | |<-----------IAM-----------|1 1450 | |==========Audio==========>| 1451 2|<--------INVITE-----------| | 1452 3|-----------200----------->| | 1453 |<=========Audio==========>| | 1454 | |------------CON---------->|4 1455 | |<=========Audio==========>| 1456 5|<----------ACK------------| | 1458 (1) When a PSTN user wishes to begin a session with a SIP user, 1459 the PSTN network generates an IAM message towards the 1460 gateway. 1462 (2) Upon receipt of the IAM message, the gateway generates an 1463 INVITE message, and sends it to an appropriate SIP node based 1464 on called number analysis. 1466 (3) Since the SIP node is set up to automatically answer the 1467 call, it will send a 200 OK message. 1469 (4) Upon receipt of the 200 OK message, the gateway will send a 1470 CON message towards the ISUP node. 1472 (5) The gateway will send an ACK to the SIP node to acknowledge 1473 receipt of the INVITE final response. 1475 7.1.5. SIP Timeout 1477 SIP MGC/MG PSTN 1478 | |<-----------IAM-----------|1 1479 | |==========Audio==========>| 1480 2|<--------INVITE-----------| | 1481 | *** T1 Expires *** | | 1482 3|<--------INVITE-----------| | 1483 | *** T1 Expires *** | | 1484 |<--------INVITE-----------| | 1485 | | *** T11 Expires *** | 1486 | |------------ACM---------->|4 1487 | *** T1 Expires *** | | 1488 |<--------INVITE-----------| | 1489 | *** T1 Expires *** | | 1490 |<--------INVITE-----------| | 1491 | *** T1 Expires *** | | 1492 |<--------INVITE-----------| | 1493 | *** T1 Expires *** | | 1494 |<--------INVITE-----------| | 1495 | *** T1 Expires *** | | 1496 | ** MG Releases PSTN Trunk ** | 1497 | |------------REL---------->|5 1498 6|<--------CANCEL-----------| | 1499 | |<-----------RLC-----------|7 1501 (1) When a PSTN user wishes to begin a session with a SIP user, 1502 the PSTN network generates an IAM message towards the 1503 gateway. 1505 (2) Upon receipt of the IAM message, the gateway generates an 1506 INVITE message, and sends it to an appropriate SIP node based 1507 on called number analysis. The ISUP timer T11 and SIP timer 1508 T1 are set at this time. 1510 (3) The INVITE message will continue to be sent to the SIP node 1511 each time the timer T1 expires. The SIP standard specifies 1512 that INVITE transmission will be performed 7 times if no 1513 response is received. 1515 (4) When T11 expires, an ACM message will be sent to the ISUP 1516 node to prevent the from being torn down by the remote node's 1517 ISUP T7. This ACM contains a `Called Party Status' value of 1518 `no indication.' 1520 (5) Once the maximum number of INVITE requests has been sent, the 1521 gateway will send a REL to the ISUP node to terminate the 1522 call. Since this would appear to be a serious problem with 1523 the network, the REL contains a cause code of 38: network out 1524 of order. 1526 (6) The gateway also sends a CANCEL message to the SIP node to 1527 terminate any initiation attempts. 1529 (7) Upon receipt of the REL, the remote ISUP node will send an 1530 RLC to acknowledge. 1532 7.1.6. ISUP T9 Expires 1534 SIP MGC/MG PSTN 1535 | |<-----------IAM-----------|1 1536 | |==========Audio==========>| 1537 2|<--------INVITE-----------| | 1538 | *** T1 Expires *** | | 1539 3|<--------INVITE-----------| | 1540 | *** T1 Expires *** | | 1541 |<--------INVITE-----------| | 1542 | | *** T11 Expires *** | 1543 | |------------ACM---------->|4 1544 | *** T1 Expires *** | | 1545 |<--------INVITE-----------| | 1546 | *** T1 Expires *** | | 1547 |<--------INVITE-----------| | 1548 | *** T1 Expires *** | | 1549 |<--------INVITE-----------| | 1550 | | *** T9 Expires *** | 1551 | ** MG Releases PSTN Trunk ** | 1552 | |<-----------REL-----------|5 1553 | |------------RLC---------->|6 1554 7|<--------CANCEL-----------| | 1556 (1) When a PSTN user wishes to begin a session with a SIP user, 1557 the PSTN network generates an IAM message towards the 1558 gateway. 1560 (2) Upon receipt of the IAM message, the gateway generates an 1561 INVITE message, and sends it to an appropriate SIP node based 1562 on called number analysis. The ISUP timer T11 and SIP timer 1563 T1 are set at this time. 1565 (3) The INVITE message will continue to be sent to the SIP node 1566 each time the timer T1 expires. The SIP standard specifies 1567 that INVITE transmission will be performed 7 times if no 1568 response is received. Since SIP T1 starts at 1/2 second or 1569 more and doubles each time it is retransmitted, it will be at 1570 least a minute before SIP times out the INVITE request; since 1571 SIP T1 is allowed to be larger than 500 ms initially, it is 1572 possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP 1573 T9. 1575 (4) When T11 expires, an ACM message will be sent to the ISUP 1576 node to prevent the from being torn down by the remote node's 1577 ISUP T7. This ACM contains a `Called Party Status' value of 1578 `no indication.' 1580 (5) When ISUP T9 in the remote PSTN node expires, it will send a 1581 REL. 1583 (6) Upon receipt of the REL, the gateway will send an RLC to 1584 acknowledge. 1586 (7) The REL will trigger a CANCEL request, which gets sent to the 1587 SIP node. 1589 7.1.7. SIP Error Response 1591 SIP MGC/MG PSTN 1592 | |<-----------IAM-----------|1 1593 | |==========Audio==========>| 1594 2|<--------INVITE-----------| | 1595 3|-----------4xx+---------->| | 1596 4|<----------ACK------------| | 1597 | ** MG Releases PSTN Trunk ** | 1598 | |------------REL---------->|5 1599 | |<-----------RLC-----------|6 1601 (1) When a PSTN user wishes to begin a session with a SIP user, 1602 the PSTN network generates an IAM message towards the 1603 gateway. 1605 (2) Upon receipt of the IAM message, the gateway generates an 1606 INVITE message, and sends it to an appropriate SIP node based 1607 on called number analysis. 1609 (3) The SIP node indicates an error condition by replying with a 1610 response with a code of 400 or greater. 1612 (4) The gateway sends an ACK message to acknowledge receipt of 1613 the INVITE final response. 1615 (5) An ISUP REL message is generated from the SIP code, as 1616 specified in section 7.2.6. 1618 (6) The remote ISUP node confirms receipt of the REL message with 1619 an RLC message. 1621 7.1.8. SIP Redirection 1623 SIP node 1 MGC/MG PSTN 1624 | |<-----------IAM-----------|1 1625 | |==========Audio==========>| 1626 2|<--------INVITE-----------| | 1627 3|-----------3xx+---------->| | 1628 | |------------CPG---------->|4 1629 5|<----------ACK------------| | 1630 | | 1631 | | 1632 SIP node 2 | | 1633 6|<--------INVITE-----------| | 1634 7|-----------18x----------->| | 1635 |<=========Audio===========| | 1636 | |------------ACM---------->|8 1637 9|<---------PRACK-----------| | 1638 10|-----------200----------->| | 1639 11|-----------200----------->| | 1640 |<=========Audio==========>| | 1641 | |------------ANM---------->|12 1642 | |<=========Audio==========>| 1643 13|<----------ACK------------| | 1645 (1) When a PSTN user wishes to begin a session with a SIP user, 1646 the PSTN network generates an IAM message towards the 1647 gateway. 1649 (2) Upon receipt of the IAM message, the gateway generates an 1650 INVITE message, and sends it to an appropriate SIP node based 1651 on called number analysis. 1653 (3) The SIP node indicates that the resource which the user is 1654 attempting to contact is at a different location by sending a 1655 3xx message. 1657 (4) The gateway sends a CPG with event indication that the call 1658 is being forwarded upon receipt of the 3xx message. Note that 1659 this translation should be able to be disabled by 1660 configuration, as some ISUP nodes do not support receipt of 1661 CPG messages before ACM messages. 1663 (5) The gateway acknowledges receipt of the INVITE final response 1664 by sending an ACK message to the SIP node. 1666 (6) The gateway re-sends the INVITE message to the address 1667 indicated in the Contact: field of the 3xx message. 1669 (7) When an event signifying that the call has sufficient 1670 addressing information occurs, the SIP node will generate a 1671 provisional response of 180 or greater. 1673 (8) Upon receipt of a provisional response of 180 or greater, the 1674 gateway will generate an ACM message with an event code as 1675 indicated in section 7.2.3. 1677 (9) The gateway sends a PRACK message to confirm receipt of the 1678 provisional response. 1680 (10) The PRACK is confirmed 1682 (11) When the SIP node answers the call, it will send a 200 OK 1683 message. 1685 (12) Upon receipt of the 200 OK message, the gateway will send an 1686 ANM message towards the ISUP node. 1688 (13) The gateway will send an ACK to the SIP node to acknowledge 1689 receipt of the INVITE final response. 1691 7.1.9. Call Cancelled by ISUP 1693 SIP MGC/MG PSTN 1694 | |<-----------IAM-----------|1 1695 | |==========Audio==========>| 1696 2|<--------INVITE-----------| | 1697 3|-----------18x----------->| | 1698 |==========Audio==========>| | 1699 | |------------ACM---------->|4 1700 5|<---------PRACK-----------| | 1701 6|-----------200----------->| | 1702 | ** MG Releases PSTN Trunk ** | 1703 | |<-----------REL-----------|7 1704 | |------------RLC---------->|8 1705 9|<---------CANCEL----------| | 1706 | ** MG Releases IP Resources ** | 1707 10|-----------200----------->| | 1708 11|-----------487----------->| | 1709 12|<----------ACK------------| | 1711 (1) When a PSTN user wishes to begin a session with a SIP user, 1712 the PSTN network generates an IAM message towards the 1713 gateway. 1715 (2) Upon receipt of the IAM message, the gateway generates an 1716 INVITE message, and sends it to an appropriate SIP node based 1717 on called number analysis. 1719 (3) When an event signifying that the call has sufficient 1720 addressing information occurs, the SIP node will generate a 1721 provisional response of 180 or greater. 1723 (4) Upon receipt of a provisional response of 180 or greater, the 1724 gateway will generate an ACM message with an event code as 1725 indicated in section 7.2.3. 1727 (5) The gateway sends a PRACK message to confirm receipt of the 1728 provisional response. 1730 (6) The PRACK is confirmed 1732 (7) If the calling party hangs up before the SIP node answers the 1733 call, a REL message will be generated. 1735 (8) The gateway frees the PSTN circuit and indicates that it is 1736 available for reuse by sending an RLC. 1738 (9) Upon receipt of a REL message before an INVITE final 1739 response, the gateway will send a CANCEL towards the SIP 1740 node. 1742 (10) Upon receipt of the CANCEL, the SIP node will send a 200 1743 response. 1745 (11) The remote SIP node will send a "487 Call Cancelled" to 1746 complete the INVITE transaction. 1748 (12) The gateway will send an ACK to the SIP node to acknowledge 1749 receipt of the INVITE final response. 1751 7.2. State Machine 1753 Note that REL may arrive in any state. Whenever this occurs, the 1754 actions in section 7.2.7. are taken. Not all of these transitions 1755 are shown in this diagram. 1757 +---------+ 1758 +----------------------->| Idle |<---------------------+ 1759 | +----+----+ | 1760 | | | 1761 | | IAM/7.2.1 | 1762 | V | 1763 | REL/7.2.7 +-------------------------+ 400+/7.2.6 | 1764 +<----------------+ Trying |------------>| 1765 | +-+--------+------+-------+ | 1766 | | | | | 1767 | | T11/ | 18x/ | 200/ | 1768 | | 7.2.8 |7.2.3 | 7.2.4 | 1769 | V | | | 1770 | REL/7.2.7 +--------------+ | | 400+/7.2.6 | 1771 |<----------| Progressing |-|------|-------------------->| 1772 | +--+----+------+ | | | 1773 | | | | | | 1774 | 200/ | | 18x/ | | | 1775 | 7.2.4 | | 7.2.3 | | | 1776 | | V V | | 1777 | REL/7.2.7 | +---------------+ | 400+/7.2.6 | 1778 |<-------------|--| Alerting |-|-------------------->| 1779 | | +--------+------+ | | 1780 | | | | | 1781 | | | 200/ | | 1782 | | | 7.2.4 | | 1783 | V V V | 1784 | BYE/9.1 +-----------------------------+ REL/9.1 | 1785 +<------------+ Connected +------------>+ 1786 +-----------------------------+ 1788 7.2.1. Address received 1790 Upon the reception of an IAM, resources are reserved in the media 1791 gateway and it connects audio in the backwards direction 1792 (towards the caller). 1794 The called number can be received in just one IAM (`en bloc' 1795 signalling) or in one IAM followed by one or several SAMs 1796 (overlap signalling). In some countries there is no way for the 1797 MGC to know whether the callees' number is already complete or 1798 some SAMs will still arrive. 1800 If the MGC relies on the inter-digit timeout to assume that the 1801 number is complete, the establishment of the connection is 1802 delayed. Alternatively, if the MGC sends the INVITE request 1803 immediately after receiving the IAM, heavy signalling traffic may 1804 be generated. 1806 Therefore, an individual MGC might implement a timer and/or a 1807 stop digit (such as #). All the digits that arrive before this 1808 timer expires will be included in the INVITE sent. The timer can 1809 be bypassed by the user sending the stop digit. This timer should 1810 not be larger than 5 seconds. 1812 Thus, after receiving the IAM and possibly one or several SAMs, 1813 the MGC issues an INVITE request. The "To" field contains the 1814 digits received so far. If, after sending this INVITE request, 1815 one or more SAMs are received, the MGC sends a new INVITE. This 1816 new INVITE has the same "From" and "Call-ID" as the previous 1817 INVITE sent. The "To" field is updated and contains all the 1818 available digits. 1820 `484 Address Incomplete' responses will be received for all the 1821 INVITEs sent with the incomplete callees number. Thus, all the 1822 call legs (same `Call-ID', different to) created while the digits 1823 are arriving are deleted. 1825 See sections 6.1.2. and 7.1.2. for a more detailed handling of 1826 overlapped dialing. 1828 7.2.2. 100 received 1830 A 100 response does not trigger any PSTN interworking messages; 1831 it only serves the purpose of suppressing INVITE retransmissions. 1833 7.2.3. 18x received 1835 If no ACM has been sent yet and no ISUP is present in the 18x 1836 message body, and ISUP message is generated according to the 1837 following table Note that, if an early ACM is sent, the call 1838 enters state "Progressing" instead of state "Alerting." 1840 Response received Message sent by the MGC 1841 ----------------- ----------------------- 1842 180 Ringing ACM 1843 181 Call is being forwarded Early ACM and CPG, event=6 1844 182 Queued ACM 1845 183 Session progress message ACM 1847 If an ACM has already been sent and no ISUP is present in the 18x 1848 message body, an ISUP message is generated according to the 1849 following table. 1851 Response received Message sent by the MGC 1852 ----------------- ----------------------- 1853 180 Ringing CPG, event = 1 (Alerting) 1854 181 Call is being forwarded CPG, event = 6 (Forwarding) 1855 182 Queued CPG, event = 2 (Progress) 1856 183 Session progress message CPG, event = 2 (Progress) 1858 If the reception of a `180 Ringing' response without media 1859 description, the MG generates the ringback tone to be heard by 1860 the caller. 1862 If the MGC receives any 1xx response (except 100) with a session 1863 description present for media setup, it sets up the session being 1864 described. The call progress media (e.g. ringback tone or 1865 announcement) is generated by an entity downstream (in the SIP 1866 network or by a PSTN exchange in SIP bridging situations). 1868 If an ACM has not been sent yet, one is generated and sent. The 1869 mandatory parameters of the ACM are described below: 1871 Message type: ACM 1873 Backward Indicators 1874 Charge indicator: 10 charge 1875 Called party's status indicator: 01 subscriber free or 1876 00 no indication (E.ACM) 1877 Called party's category indicator: 01 ordinary subscriber 1878 End-to-end method indicator: 00 no end-to-end method 1879 Interworking indicator: 0 no interworking 1880 End-to-end information indicator: 0 no end-to-end info 1881 ISDN user part indicator: 1 ISUP all the way 1882 Holding indicator: 0 no holding 1883 ISDN access indicator: 1 ISDN access 1884 Echo control device indicator: It depends on the call 1885 SCCP method indicator: 00 no indication 1887 In SIP bridging situations the MGC sends the ISUP message 1888 contained in the response body. 1890 7.2.4. 200 received 1892 Response received Message sent by the MGC 1893 ----------------- ----------------------- 1894 200 OK ANM, ACK 1896 After receiving a 200 OK response the MGC establishes a two-way 1897 voice path in the MG and it sends an ANM to the PSTN and an ACK 1898 to the SIP network. 1900 If the `200 OK' response arrives before the MGC has sent the ACM, 1901 a CON is sent instead of the ANM. 1903 In SIP bridging situations the MGC sends the ANM or the CON in 1904 the response body. If the response body contains an ACM and an 1905 ANM both are sent to the PSTN (first the ACM and then the ANM). 1907 7.2.5. 3xx received 1909 When any 3xx response is received ,the MGC should try to contact 1910 the user using the `Contact' header or headers present in the 1911 response. These 3xx responses are typically sent by a re-direct 1912 server. This is a similar device to the HLR in mobile networks. 1913 It provides another address where the callee may be reached. 1915 A CPG message with an event code of 2 (Progress) may be sent to 1916 indicate that the call is proceeding. Note that some ISUP nodes 1917 may not support CPG before ACM, so this feature should be 1918 configurable. 1920 The 3xx MUST NOT result in the generation of an ACM message, 1921 since there may be more digits pending in overlap dialing 1922 situations. See sections 6.1.3. and 7.1.3. for callflows that 1923 demonstrate the situations in which this behavior would prove 1924 harmful. 1926 In SIP bridging situations, the MGC sends the ISUP message 1927 contained in the response body (if any). It is worthwhile 1928 mentioning that a REL with cause value 22 (number changed) might 1929 be contained in the response body of the 3xx response. This REL 1930 might contain a new number where the callee might be reachable. 1932 This REL can be sent to the PSTN, but most of the PSTN switches 1933 are not able to process this information. Thus, if the MGC is 1934 able to parse the new number, it might try the new location. 1936 If the new location is reachable via PSTN, the MGC sends a new 1937 IAM and from that moment on acts as a normal PSTN switch (no SIP 1938 involved). If the new location is reachable using SIP, the MGC 1939 sends an INVITE with possibly a new IAM generated by the MGC in 1940 the message body. 1942 All redirection situations have to be treated very carefully 1943 because they involved special charging situations. In PSTN the 1944 caller typically pays the first call leg and the callee pays the 1945 second. 1947 7.2.6. 4xx - 6xx received 1948 The MGC releases the resources in the MG, send a REL to the PSTN 1949 with a cause value and send an ACK to the SIP network. An RLC 1950 arrives indicating that the release sequence is complete. 1952 Response received Cause value in the REL 1953 ----------------- ---------------------- 1954 400 Bad request 127 Interworking 1955 401 Unauthorized 21 Call rejected 1956 402 Payment required 21 Call rejected 1957 403 Forbidden 1 Unallocated number 1958 404 Not found 1 Unallocated number 1959 405 Method not allowed 38 Network out of order 1960 406 Not acceptable 58 Bearer capability not 1961 presently available 1962 407 Proxy authentication required 21 Call rejected 1963 408 Request timeout 102 Recovery on timer expiry 1964 409 Conflict 41 Temporary failure 1965 410 Gone 1 Unallocated number 1966 411 Length required 127 Interworking 1967 413 Request Entity too long 127 Interworking 1968 414 Request-URI too long 127 Interworking 1969 415 Unsupported media type 79 Service/option not 1970 implemented 1971 420 Bad extension 127 Interworking 1972 480 Temporarily unavailable 18 No user responding 1973 481 Call leg/transaction doesn't exist 127 Interworking 1974 482 Loop detected 127 Interworking 1975 483 Too many hoops 127 Interworking 1976 484 Address incomplete --- 1977 485 Ambiguous 1 Unallocated number 1978 486 Busy here 17 User busy 1979 500 Server internal error 41 Temporary failure 1980 501 Not implemented 38 Network out of order 1981 502 Bad gateway 38 Network out of order 1982 503 Service unavailable 41 Temporary failure 1983 504 Gateway time-out 102 Recovery on timer expiry 1984 505 Version not supported 127 Interworking 1985 600 Busy everywhere 17 User busy 1986 603 Decline 21 Call rejected 1987 604 Does not exist anywhere 1 Unallocated number 1988 606 Not acceptable 38 Network out of order 1990 7.2.7. REL received 1992 The MGC should abort the establishment of the session. A CANCEL 1993 request has to be issued. A BYE is not used, since no final 1994 response has arrived from the SIP side. A 200 OK for the CANCEL 1995 arrives, and a 487 for the INVITE arrives. 1997 The MGC has to store state information for a certain period of 1998 time, since a 200 final response for the INVITE originally sent 1999 might arrive (even after the reception of the 200 OK for the 2000 CANCEL). In this situation, the MGC sends an ACK and then a BYE. 2002 In SIP bridging situations, the REL message may be included in 2003 the CANCEL message body. CANCEL requests are answered with a 2004 final response (such as 200 OK) by the first proxy. Therefore, 2005 the MGC does not know if the CANCEL has arrived to the end user 2006 (egress MGC in this scenario). Hence, if a 200 OK response for 2007 the previously sent INVITE arrives the MGC sends an ACK and then 2008 a BYE with the REL in the message body. 2010 7.2.8. ISUP T11 Expires 2012 In order to prevent the remote ISUP node's timer T7 from 2013 expiring, the gateway may choose to keep its own supervisory 2014 timer; ISUP defines this timer as T11. T11's duration is 2015 carefully chosen so that it will always be shorter than the T7 of 2016 any node to which the gateway is communicating. 2018 To clarify timer T11's relevance with respect to SIP 2019 interworking, Q.764 [14] explains its use as: "If in normal 2020 operation, a delay in the receipt of an address complete signal 2021 from the succeeding network is expected, the last common channel 2022 signalling exchange will originate and send an address complete 2023 message 15 to 20 seconds [timer (T11)] after receiving the latest 2024 address message." Since SIP nodes have no obligation to respond 2025 to an INVITE request within 20 seconds, SIP interworking 2026 inarguably qualifies as such a situation. 2028 If the gateway's T11 expires, it will send an early ACM (i.e. 2029 called party status set to "no indication") to prevent the 2030 expiration of the remote node's T7. See section 7.2.3. for the 2031 value of the ACM parameters. 2033 If a "180 Ringing" message arrives subsequently, it will be sent 2034 in a CPG, as shown in section 7.2.3. 2036 See 7.1.6. for an example callflow that includes the expiration 2037 of T11. 2039 8. Suspend/Resume 2041 In ISDN networks, the user can generate a SUS (timer T2, user 2042 initiated) in order to unplug the terminal from the socket and 2043 plug it in another one. A RES is sent once the terminal has been 2044 reconnected and the T2 timer has not expired. 2046 When a SUS arrives from the PSTN, the MGC sends an INVITE to put 2047 the media stream on hold. The reception of a RES triggers another 2048 INVITE that resumes the media stream. For the SIP UAC/UAS the 2049 result is an interruption in the voice path until the other party 2050 picks up the phone again. 2052 In SIP bridging situations, the SUS and RES messages can be 2053 transferred in the body of the INVITE. 2055 SIP MGC/MG PSTN 2056 | |<-----------SUS-----------|1 2057 2|<--------INVITE-----------| | 2058 3|-----------200----------->| | 2059 4|<----------ACK------------| | 2060 | |<-----------RES-----------|5 2061 6|<--------INVITE-----------| | 2062 7|-----------200----------->| | 2063 8|<----------ACK------------| | 2065 The handling of a network-initiated SUS prior to call teardown is 2066 handled in section 9.2.2. 2068 9. Normal Release of the Connection 2070 Either the SIP side or the ISUP side may release a call, 2071 regardless of which side initiated the call. 2073 9.1. SIP initiated 2075 For a normal release of the call (reception of BYE), the MGC 2076 immediately sends a 200 response. It then releases the resources 2077 in the MG and sends an REL with a cause code of 16 (normal call 2078 clearing) to the PSTN. Release of resources is confirmed by the 2079 PSTN with a RLC. 2081 In SIP bridging situations, the REL contained in the BYE is sent 2082 to the PSTN. 2084 SIP MGC/MG PSTN 2085 1|-----------BYE----------->| | 2086 | ** MG Releases IP Resources ** | 2087 2|<----------200------------| | 2088 | ** MG Releases PSTN Trunk ** | 2089 | |------------REL---------->|3 2090 | |<-----------RLC-----------|4 2092 9.2. ISUP Initiated 2093 If the release of the connection was caused by the reception of a 2094 REL, the REL is included in the BYE sent by the MGC. 2096 9.2.1. Caller hangs up 2098 For a normal release of the call (reception of REL from the 2099 PSTN), the MGC first releases the resources in the MG and then 2100 confirms that they are ready for re-use by sending an RLC. The 2101 SIP connection is released by sending a BYE (which is confirmed 2102 with a 200). 2104 SIP MGC/MG PSTN 2105 | |<-----------REL-----------|1 2106 | ** MG Releases PSTN Trunk ** | 2107 | |------------RLC---------->|2 2108 3|<----------BYE------------| | 2109 | ** MG Releases IP Resources ** | 2110 4|-----------200----------->| | 2112 9.2.2. Callee hangs up 2114 In analog PSTN, if the callee hangs up in the middle of a call, 2115 the local exchange sends a SUS instead of a REL and starts a 2116 timer (T6, SUS is network initiated). When the timer expires, the 2117 REL is sent. 2119 SIP MGC/MG PSTN 2120 | |<-----------SUS-----------|1 2121 2|<--------INVITE-----------| | 2122 3|-----------200----------->| | 2123 4|<----------ACK------------| | 2124 | | *** T6 Expires *** | 2125 | |<-----------REL-----------|5 2126 | ** MG Releases PSTN Trunk ** | 2127 | |------------RLC---------->|6 2128 7|<----------BYE------------| | 2129 | ** MG Releases IP Resources ** | 2130 8|-----------200----------->| | 2132 10. ISUP maintenance messages 2134 ISUP contains a set of messages used for maintenance purposes. 2135 They can be received during an ongoing call. There are basically 2136 two kinds of maintenance messages (apart from the continuity 2137 check): message for blocking circuits and messages for resetting 2138 circuits. 2140 10.1. Reset messages 2141 Upon reception of a reset message for the circuit being used, the 2142 call has to be released. RSC messages are answered with RLC after 2143 resetting the circuit in the MG. GRS messages are answered with 2144 GRA after resetting all the circuits affected by the message. 2146 The MGC acts as if a REL had been received in order to release 2147 the connection on the SIP side. The session will be terminated. A 2148 BYE or a CANCEL are sent depending of the status of the call. 2150 10.2. Blocking messages 2152 There are two kinds of blocking messages: maintenance oriented or 2153 hardware failure oriented. Maintenance oriented blocking messages 2154 indicates that the circuit has to be blocked for subsequent 2155 calls. Therefore, these messages do not affect any ongoing call. 2157 Hardware oriented blocking messages have to be treated as reset 2158 messages. The call is released. 2160 BLO is always maintenance oriented and it is answered by the MGC 2161 with BLA when the circuit is blocked. CGB messages have a "type 2162 indicator" inside the "circuit group supervision message type 2163 indicator". It indicates if the CGB is maintenance or hardware 2164 failure oriented. CGBs are answered with CGBAs." 2166 11. Other ISUP flavours 2168 Other flavours of ISUP different than Q.767 [2] have more 2169 parameters and more features. Some of the parameters have more 2170 possible values and provide more information about the status of 2171 the call. 2173 However, differences in the message flows are more important. In 2174 ANSI ISUP [3] , there is no CON message. An ANM is sent instead 2175 (with no ACM). In call forwarding situations, CPGs can be sent 2176 before the ACM is sent. No SAMs are sent. `En bloc' signalling is 2177 always used. 2179 12. Acronyms 2180 ACK Acknowledgment 2181 ACM Address Complete Message 2182 ANM Answer Message 2183 ANSI American National Standards Institute 2184 BLA Blocking ACK message 2185 BLO Blocking Message 2186 CGB Circuit Group Blocking Message 2187 CGBA Circuit Group Blocking ACK Message 2188 CON Connect Message 2189 CPG Call Progress Message 2190 CUG Closed User Group 2191 GRA Circuit Group Reset ACK Message 2192 GRS Circuit Group Reset Message 2193 HLR Home Location Register 2194 IAM Initial Address Message 2195 IETF Internet Engineering Task Force 2196 IP Internet Protocol 2197 ISDN Integrated Services Digital Network 2198 ISUP ISDN User Part 2199 ITU-T International Telecommunication Union 2200 Telecommunication Standardization Sector 2201 MG Media Gateway 2202 MGC Media Gateway Controller 2203 MTP Message Transfer Part 2204 REL Release Message 2205 RES Resume Message 2206 RLC Release Complete Message 2207 RTP Real-time Transport Protocol 2208 SCCP Signalling Connection Control Part 2209 SG Signalling Gateway 2210 SIP Session Initiation Protocol 2211 SS7 System Signalling No. 7 2212 SUS Suspend Message 2213 UAC User Agent Client 2214 UAS User Agent Server 2215 UDP User Data Protocol 2216 VoIP Voice over IP 2218 13. Acknowledgments 2220 The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill 2221 Kavadas, and Miguel A. Garcia for their help and feedback on this 2222 document. 2224 14. References 2226 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 2227 Session Initiation Protocol", RFC 2543, IETF; March 1999. 2229 [2] "Application of the ISDN user part of CCITT signalling system 2230 No. 7 for international ISDN interconnections" ITU-T Q.767 2231 recommendation, February 1991. 2233 [3] "Signalling System No. 7; ISDN User Part" T1.113-1995 ANSI. 2234 January 1995. 2236 [4] E Zimmerer/A. Vemuri/L. Ong/M. Zonoun/M. Watson, "MIME media 2237 types for ISUP and QSIG Objects", Internet Draft 2238 , IETF; January 2000. Work 2239 in progress. 2241 [5] N. Freed/ N. Borenstein, "Multipurpose Internet Mail 2242 Extensions (MIME) Part Two: Media Types", RFC 2046, IETF; 2243 November 1996. 2245 [6] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits, 2246 Telephony Tones and Telephony Signals", Internet Draft 2247 , IETF; February 2000. Work in 2248 progress. 2250 [7] Jiri Kuthan, "Sample Uses of SIP INFO with Varying 2251 Reliability Needs", Internet Draft 2252 , IETF; October 1999. 2253 Work in progress. 2255 [8] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional 2256 Responses in SIP", Internet Draft 2257 , IETF; January 2000. Work in 2258 progress. 2260 [9] S. Donovan/M. Cannon/H. Schulzrinne/J. Rosenberg/A. Roach, 2261 "SIP 183 Session Progress Message", Internet draft IETF 2262 October 1999. Work in progress. 2264 [10] Steven R. Donovan, "The SIP INFO Method", Internet Draft 2265 , IETF; February 2000. 2266 Work in progress. 2268 [11] "Signalling System No. 7; ISDN User Part Signalling 2269 procedures", ITU-T Q.764 recommendation, September 1997. 2271 [12] Abnormal conditions - Special release ITU-T Q.118 2272 recommendation, September 1997. 2274 [13] "Specifications of Signalling System No. 7 - ISDN 2275 supplementary services" ITU-T Q.737 recommendation, June 2276 1997. 2278 [14] "Specifications of Signalling System No. 7 - ISDN User Part 2279 Signalling Procedures" ITU-T Q.764 recommendation, March 2280 1993. 2282 15. Security Considerations 2284 The transit of ISUP in SIP bodies may provide may opportunities 2285 for abuse and fraud. In particular, SIP users may be able to 2286 interpret "private" (i.e. caller-id-blocked) numbers by examining 2287 the ISUP. Similarly, if care is not taken, SIP clients would be 2288 able to send ISUP messages into the SS7 network with invalid 2289 calling line identification and spoofed billing numbers. 2291 For these reasons, it is absolutely necessary that any ISUP sent 2292 through an IP network be strongly encrypted and authenticated. 2293 The keys used for encryption should not be static, to prevent 2294 replay attacks. A challenge-response model is recommended. As an 2295 extra layer of security, it is recommended that ISUP be sent and 2296 received only to and from nodes that are known to have an 2297 established trust relationship with the gateway. 2299 16. Authors' Addresses 2301 Gonzalo Camarillo 2302 Ericsson 2303 Advanced Signalling Research Lab 2304 FIN-02420 Jorvas 2305 Finland 2306 Phone: +358 9 299 3371 2307 Fax: +358 9 299 3052 2308 Email: Gonzalo.Camarillo@ericsson.com 2310 Adam Roach 2311 Ericsson Inc. 2312 Mailstop L-04 2313 851 International Pkwy. 2314 Richardson, TX 75081 2315 USA 2316 Phone: +1 972-583-7594 2317 Fax: +1 972-669-0154 2318 E-Mail: Adam.Roach@ericsson.com