idnits 2.17.1 draft-camarillo-sip-isup-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? 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 1891: '... The 3xx MUST NOT result in the g...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 226 has weird spacing: '...essages is de...' == Line 366 has weird spacing: '...message to co...' == Line 378 has weird spacing: '...message to co...' == Line 699 has weird spacing: '...message to co...' == Line 756 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 (June 2001) is 8345 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) ** Obsolete normative reference: RFC 2833 (ref. '6') (Obsoleted by RFC 4733, RFC 4734) ** Obsolete normative reference: RFC 2976 (ref. '10') (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 2960 (ref. '15') (Obsoleted by RFC 4960) Summary: 11 errors (**), 0 flaws (~~), 6 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 November 2000 4 Expires June 2001 5 7 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.... 10 57 6.1.4. Auto-answer call setup................................. 11 58 6.1.5. ISUP T7 expires........................................ 12 59 6.1.6. SIP Timeout............................................ 12 60 6.1.7. ISUP Setup Failure..................................... 14 61 6.1.8. Cause present in ACM message........................... 14 62 6.1.9. Call cancelled by SIP node............................. 16 63 6.2. State Machine.......................................... 17 64 6.2.1. INVITE received........................................ 18 65 6.2.2. ISUP T7 expires........................................ 20 66 6.2.3. CANCEL or BYE received................................. 20 67 6.2.4. REL received........................................... 21 68 6.2.5. Early ACM received..................................... 23 69 6.2.6. ACM received........................................... 23 70 6.2.7. CON or ANM received.................................... 24 71 6.2.8. Timer T9 expires....................................... 24 72 6.2.9. CPG received........................................... 24 73 6.2.10. ACK received........................................... 25 74 7. ISUP to SIP mapping.................................... 25 75 7.1. Call Flows............................................. 25 76 7.1.1. En-bloc call setup (non auto-answer)................... 25 77 7.1.2. Overlap call setup..................................... 26 78 7.1.3. Overlap call setup with a routing (redirect) server.... 29 79 7.1.4. Auto-answer call setup................................. 31 80 7.1.5. SIP Timeout............................................ 32 81 7.1.6. ISUP T9 Expires........................................ 33 82 7.1.7. SIP Error Response..................................... 34 83 7.1.8. SIP Redirection........................................ 35 84 7.1.9. Call Cancelled by ISUP................................. 36 85 7.2. State Machine.......................................... 37 86 7.2.1. Address received....................................... 38 87 7.2.2. 100 received........................................... 39 88 7.2.3. 18x received........................................... 39 89 7.2.4. 200 received........................................... 40 90 7.2.5. 3xx received........................................... 41 91 7.2.6. 4xx - 6xx received..................................... 41 92 7.2.7. REL received........................................... 42 93 7.2.8. ISUP T11 Expires....................................... 43 94 8. Suspend/Resume......................................... 43 95 9. Normal Release of the Connection....................... 44 96 9.1. SIP initiated.......................................... 44 97 9.2. ISUP Initiated......................................... 44 98 9.2.1. Caller hangs up........................................ 45 99 9.2.2. Callee hangs up........................................ 45 100 10. ISUP maintenance messages.............................. 45 101 10.1. Reset messages......................................... 45 102 10.2. Blocking messages...................................... 46 103 11. Overlap signalling..................................... 46 104 11.1. ISUP to SIP............................................ 46 105 11.2. SIP to ISUP............................................ 48 106 11.3. Example of SIP bridging and overlap signalling......... 48 107 12. Other ISUP flavours.................................... 50 108 12.1. Guidelines to send other ISUP messages................. 50 109 13. Acronyms............................................... 50 110 14. Acknowledgments........................................ 51 111 15. References............................................. 51 112 16. Security Considerations................................ 53 113 17. Authors' Addresses..................................... 53 115 1. Introduction 117 SIP [1] is an application layer protocol for establishing, 118 terminating and modifying multimedia sessions. It is typically 119 carried over IP. Telephone calls are considered a type of 120 multimedia sessions where just audio is exchanged. 122 ISUP [2] is a level 4 protocol used in SS7 networks. It typically 123 runs over MTP although it can also run over IP [15]. ISUP is used 124 for controlling telephone calls and for maintenance of the 125 network (blocking circuits, resetting circuits etc.). 127 The module performing the mapping between these two protocols is 128 usually referred to as Media Gateway Controller (MGC). It has 129 logical interfaces towards both networks, the network carrying 130 ISUP and the network carrying SIP, although usually they are on 131 the same physical interface. The MGC also has capabilities for 132 controlling the voice path. There is typically a Media Gateway 133 (MG) with E1/T1 interfaces (voice from PSTN) and with IP 134 interfaces (VoIP). The MGC and the MG can be merged together in 135 one physical box or kept separate. 137 2. Scope 139 This document only takes into account the call functionality of 140 ISUP. Maintenance messages dealing with PSTN trunks are treated 141 only as far as they affect the control of an ongoing call. 143 Messages indicating error or congestion situations in the PSTN 144 (MTP-3) and the recovery mechanisms used such as User Part 145 Available and User Part Test ISUP messages are outside the scope 146 of this document 148 There are several flavours of ISUP. ITU-T Q.767 International 149 ISUP [2] is used through this document; some differences with 150 ANSI ISUP [3] and TTC ISUP are outlined. ISUP Q.767 [2] is used 151 in this document because it is the least complex of all the ISUP 152 flavours. Due to the small number of fields that map directly 153 from ISUP to SIP, the signalling differences between Q.767 and 154 specific national variants of ISUP will generally have little to 155 no impact on the mapping. 157 This document describes when the media path is to be initialized, 158 terminated, modified, etc., but it does not go into details such 159 as how the initialization is performed or which protocols are 160 used for that purpose. 162 3. Scenarios 164 There are several scenarios where ISUP-SIP mapping takes place. 165 The way the messages are generated is different depending on the 166 scenario. 168 When there is a single MGC and the call is from a SIP phone to a 169 PSTN phone, or vice versa, the MGC generates the ISUP messages 170 based on the methods described in this document. 172 +-------------+ +-----+ +-------------+ 173 | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | 174 +-------------+ +-----+ +-------------+ 176 The scenario where a call originates in the PSTN, goes into a SIP 177 network and terminates in the PSTN again is known as "SIP 178 bridging". SIP bridging should provide ISUP transparency between 179 the PSTN switches handling the call. This is achieved by carrying 180 the incoming ISUP messages in the body of the SIP messages [4] . 181 In this case, the ISUP messages generated by the egress MGC are 182 the ones present in the SIP body (possibly with some 183 modifications; for example, if the called number in the request 184 URI is different from the one present in the ISUP due to SIP 185 redirection, the ISUP message will need to be adjusted). 187 +------+ +-------------+ +-----+ +------------+ +------+ 188 | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 189 +------+ +-------------+ +-----+ +------------+ +------+ 191 SIP is used in the middle of both MGCs because the voice path has 192 to be established through the IP network between both MGs; this 193 structure also allows the call to take advantage of certain SIP 194 services. ISUP messages in the SIP bodies provide further 195 information (such as cause values and optional parameters) to the 196 peer MGC. 198 In both scenarios, the ingress MGC places the incoming ISUP 199 messages in the SIP body by default. Note that this has security 200 implications; see section 16. If the recipient of these messages 201 (typically a SIP UAC/UAS) does not understand them a negotiation 202 using the SIP `Accept' and `Require' headers will take place and 203 they will not be included in the next SIP message exchange. 205 There can be a Signalling Gateway (SG) between the PSTN and the 206 MGC. It encapsulates the ISUP messages over IP. The mapping 207 described in this document is not affected by its presence. 209 4. Extensions Required 211 For a correct mapping between ISUP and SIP, some extensions to 212 the basic SIP specification are needed. These extensions are 213 discussed below. If the SIP UAC/UAS involved in the call does not 214 support them, it is still possible to proceed, but the behavior 215 in the establishment of the call may be slightly different than 216 that expected by the user (e.g. other party answers before 217 receiving the ringback tone, user is not informed about the call 218 being forwarded, etc.). 220 4.1. "Transparent" Transit of ISUP messages 222 To provide users the ability to take advantage of the full range 223 of services afforded by the existing telephone network when 224 placing calls from PSTN to PSTN across a SIP network, SIP 225 messages will need to carry ISUP payloads from gateway to 226 gateway. The format for carrying these messages is defined in 227 "MIME media types for ISUP and QSIG Objects" [4] . 229 SIP clients and servers which do not understand ISUP are 230 encouraged to recognize this MIME type and ignore it. 232 4.2. Understanding of Multipart Bodies 234 In most PSTN interworking situations, the SIP body will be 235 required to carry session information in addition to ISUP and/or 236 billing information. 238 PSTN interworking nodes should understand the MIME type of 239 "multipart/mixed" as defined in RFC2046 [5] . Clients express 240 support for this by including "multipart/mixed" in an "Accept" 241 header. 243 4.3. Transmission of DTMF information 245 Since the codec selected for voice transmission may not be 246 ideally suited for carrying DTMF information, a symbolic method 247 of transmitting this information in-band is desirable (since 248 out-of-band transmission alone would provide many challenges for 249 syncronization of the media stream for tone re-insertion). This 250 transmission will be performed as described in "RTP Payload for 251 DTMF Digits, Telephony Tones and Telephony Signals" [6] . 253 In addition to the need to faithfully carry telephony tones 254 across the audio channel, PSTN interworking situations will 255 require the capability on the part of SIP nodes to collect 256 further digits from the end user. This may be used, for example, 257 to provide authentication information to a SIP node via DTMF 258 without the SIP node needing to process the media stream. This 259 transit is accomplished using the method described in section 2.1 260 of "Sample Uses of SIP INFO with Varying Reliability Needs" [7] . 262 4.4. Reliable Transmission of Provisional Responses 264 Provisional responses are used to transmission of various 265 progress information. PSTN interworking in particular relies on 266 these messages for control of the media channel and timing of 267 messages. 269 PSTN interoperation nodes should implement the extension defined 270 in "Reliability of Provisional Responses in SIP" [8] . 272 4.5. Provisional Media Streams 274 To allow the transmission of messages and tones before a final 275 connection has been established, SIP nodes which interwork with 276 the PSTN need to be able to establish temporary media connections 277 during this period. 279 PSTN interoperating nodes should support the establishement of 280 temporary provisional media streams, as specified in "SIP 183 281 Session Progress Message" [9] . 283 4.6. Mid-Call Transactions Which do not Change SIP State 285 When interworking with PSTN, there are situations when PSTN nodes 286 will need to send messages which do not correspond to any SIP 287 operations to each other across a SIP network. 289 The method for performing this transit will be in the INFO 290 method, defined in "The SIP INFO Method" [10] . 292 Nodes which do serve as PSTN interworking points should accept 293 "405 Method Not Allowed" and "501 Not Implemented" responses to 294 INFO requests as non-fatal. 296 5. Mapping 298 The mapping between ISUP and SIP is described using call flow 299 diagrams and state machines. One state machine handles calls from 300 SIP to ISUP and the second from ISUP to SIP. There are details, 301 such as some retransmissions and some states (waiting for RLC, 302 waiting for ACK etc.), that are not shown in the figures in order 303 to make them easier to follow. 305 The boxes represent the different states of the gateway, and the 306 arrows show changes in the state. The event that triggers the 307 change in the state and the actions to take appear on the arrow: 308 event / section describing the actions to take. 310 For example, `INVITE / 6.2.1' indicates that an INVITE request 311 has been received by the gateway, and the procedure upon 312 reception is described in the section 6.2.1 of this document. 314 6. SIP to ISUP mapping 316 6.1. Call Flows 318 The following call flows illustrate the order of messages in 319 typical success and error cases when setting up a call initiated 320 from the SIP network. "100 Trying" acknowledgements to INVITE 321 requests are not explained, since their presence is optional. 323 In these diagrams, all call singnalling (SIP, ISUP) is going to 324 and from the MGC; media handling (e.g. audio cut-through, trunk 325 freeing) is being performed by the MG, under the control of the 326 MGC. For the purpose of simplicity, these are shown as a single 327 node, labeled "MGC/MG." 329 6.1.1. En-bloc Call Setup (non auto-answer) 331 SIP MGC/MG PSTN 332 1|---------INVITE---------->| | 333 |<----------100------------| | 334 | |------------IAM---------->|2 335 | |<=========Audio===========| 336 | |<-----------ACM-----------|3 337 4|<----------18x------------| | 338 |<=========Audio===========| | 339 5|----------PRACK---------->| | 340 6|<----------200------------| | 341 | |<-----------CPG-----------|7 342 8|<----------18x------------| | 343 9|----------PRACK---------->| | 344 10|<----------200------------| | 345 | |<-----------ANM-----------|11 346 | |<=========Audio==========>| 347 12|<----------200------------| | 348 |<=========Audio==========>| | 349 13|-----------ACK----------->| | 350 (1) When a SIP user wishes to begin a session with a PSTN user, 351 the SIP node issues an INVITE request. 353 (2) Upon receipt of an INVITE request, the gateway maps it to an 354 IAM message and sends it to the ISUP network. 356 (3) The remote ISUP node indicates that the address is sufficient 357 to set up a call by sending back an ACM message. 359 (4) The "called party status" code in the ACM message is mapped 360 to a SIP provisional response (180 for "subscriber free" and 361 183 for "no indication") and returned to the SIP node. This 362 response may contain SDP to establish an early media stream 363 (as shown in the diagram). If no SDP is present, the audio 364 will be established in both directions after step 12. 366 (5) The SIP node sends a PRACK message to confirm receipt of the 367 provisional response. 369 (6) The PRACK is confirmed 371 (7) The remote ISUP node may issue a variety of CPG messages to 372 indicate, for example, that the call is being forwarded. 374 (8) Upon receipt of a CPG message, the gateway will map the event 375 code to a SIP provisional response (see section 6.2.9. ) and 376 send it to the SIP node. 378 (9) The SIP node sends a PRACK message to confirm receipt of the 379 provisional response. 381 (10) The PRACK is confirmed 383 (11) Once the PSTN user answers, an ANM message will be sent to 384 the gateway. 386 (12) Upon receipt of the ANM, the gateway will send a 200 message 387 to the SIP node. 389 (13) The SIP node, upon receiving an INVITE final response (200), 390 will send an ACK to acknowledge receipt. 392 6.1.2. Overlap Call Setup 394 (1) The gateway may be able to determine that the number in the 395 SIP message is not long enough to set up a call (for example; 396 it may not have enough of a number to know what PSTN node to 397 route to). Under these circumstances, it will immediately 398 return a "484 Address Incomplete" message. 400 (2) The 484 is acknowledged. 402 (3) After collecting more digits, the SIP node sends another 403 INVITE. This invite contains the same "From" and "Call-ID" 404 headers. The "To" field is updated to reflect the entire 405 called number as known so far. Since the "To" field is 406 different, this transaction represents a different call leg 407 than the INVITE in step 1; consequently, there is no 408 relationship between the CSeq values in the two INVITE 409 messages. Note that the gateway may drop state knowledge 410 between steps 3 and 4 unless ISUP tunnelling is being 411 performed. (For ISUP tunneling, the IAM present in the 412 initial INVITE will need to be reserved for step 5). 414 (4) Once the gateway is not sure that the number is too short, it 415 will send out the digits from the INVITE message as an IAM. 417 (5) As more digits are collected, they will also be sent as 418 INVITE messages. Note that the "To" field still contains the 419 entire string of digits collected so far, not just the new 420 ones. 422 (6) The newly collected digits are sent to the PSTN as SAM 423 messages. 425 (7) See step 6 427 (8) See step 7 429 (9) See step 6 431 (10) See step 7 433 (11) Once the remote PSTN node receives enough digits, it will 434 send an ACM message to indicate that it can now route the 435 call. 437 (12) The gateway sends a 180 message for the most recent pending 438 transaction (or a 183 if the "called party status" field is 439 marked "no indication"). The transaction to which this 440 response belongs will be same as the INVITE which contains a 441 complete phone number in its "To" field (the one sent in step 442 10). 444 (13) "484 Address Incomplete" is sent to complete the INVITE 445 transaction started in step 4. 447 (14) "484 Address Incomplete" is sent to complete the INVITE 448 transaction started in step 6. 450 (15) "484 Address Incomplete" is sent to complete the INVITE 451 transaction started in step 8. 453 (16) The remote node sends a PRACK to acknowledge receipt of the 454 18x message sent in step 13. 456 (17) The 484 from step 14 is acknowledged. 458 (18) The 484 from step 15 is acknowledged. 460 (19) The 484 from step 16 is acknowledged. 462 (20) Once the PSTN user answers, an ANM message will be sent to 463 the gateway. 465 (21) Upon receipt of the ANM, the gateway will send a 200 message 466 to the SIP node. 468 (22) The SIP node, upon receiving an INVITE final response (200), 469 will send an ACK to acknowledge receipt. 471 6.1.3. Overlap call setup with a routing (redirect) server 473 SIP Routing Server PSTN 474 1|---------INVITE---------->| | 475 2|<----------484------------| | 476 3|-----------ACK----------->| | 477 4|---------INVITE---------->| | 478 5|<----------484------------| | 479 6|-----------ACK----------->| | 480 7|---------INVITE---------->| | 481 8|<----------302------------| | 482 9|-----------ACK----------->| | 483 | | 484 | | 485 | MGC/MG | 486 10|---------INVITE---------->| | 487 ... 489 (1) When a SIP user wishes to begin a session with a PSTN user, 490 the SIP node issues an INVITE request. In this example, the 491 INVITE is sent to a server which knows how to select the 492 egress gateway based on a numbering prefix. 494 (2) Since the routing server doesn't have enough information to 495 select an egress gateway, it responds with a "484 Address 496 Incomplete". 498 (3) The 484 is acknowledged. 500 (4) After collecting more digits, the SIP node sends another 501 INVITE. This invite contains the same "From" and "Call-ID" 502 headers. The "To" field is updated to reflect the entire 503 called number as known so far. Since the "To" field is 504 different, this transaction represents a different call leg 505 than the INVITE in step 1; consequently, there is no 506 relationship between the CSeq values in the two INVITE 507 messages. Note that the routing server will probably drop 508 state knowledge between steps 3 and 4. 510 (5) In this example, there is still not enough information to 511 route the call. 513 (6) The 484 is acknowledged. 515 (7) As in step 4, more digits are collected. While this INVITE 516 contains enough information for the routing server to select 517 a gateway, it is quite probable that the number is not yet 518 complete. 520 (8) A "302 Temporarily Moved" response is returned to redirect 521 the SIP node to the appropriate gateway. (In practice, this 522 may not necessarily be a gateway; it might be another 523 redirect server, a proxy server, or a native client). 525 (9) The 302 is acknowledged. 527 (10) The call now continues as in step 1 of section 6.1.2. 529 6.1.4. Auto-answer call setup 531 SIP MGC/MG PSTN 532 1|---------INVITE---------->| | 533 |<----------100------------| | 534 | |------------IAM---------->|2 535 | |<=========Audio===========| 536 | |<-----------CON-----------|3 537 | |<=========Audio==========>| 538 4|<----------200------------| | 539 |<=========Audio==========>| | 540 5|-----------ACK----------->| | 542 (1) When a SIP user wishes to begin a session with a PSTN user, 543 the SIP node issues an INVITE request. 545 (2) Upon receipt of an INVITE request, the gateway maps it to an 546 IAM message and sends it to the ISUP network. 548 (3) Since the remote node is configured for automatic answering, 549 it will send a CON message upon receipt of the IAM. (For 550 ANSI, this message will be an ANM). 552 (4) Upon receipt of the CON, the gateway will send a 200 message 553 to the SIP node. 555 (5) The SIP node, upon receiving an INVITE final response (200), 556 will send an ACK to acknowledge receipt. 558 6.1.5. ISUP T7 expires 560 SIP MGC/MG PSTN 561 1|---------INVITE---------->| | 562 |<----------100------------| | 563 | |------------IAM---------->|2 564 | |<=========Audio===========| 565 | | *** T7 Expires *** | 566 | ** MG Releases PSTN Trunk ** | 567 4|<----------504------------|------------REL---------->|3 568 5|-----------ACK----------->| | 570 (1) When a SIP user wishes to begin a session with a PSTN user, 571 the SIP node issues an INVITE request. 573 (2) Upon receipt of an INVITE request, the gateway maps it to an 574 IAM message and sends it to the ISUP network. The ISUP timer 575 T7 is started at this point. 577 (3) The ISUP timer T7 expires before receipt of an ACM or CON 578 message, so a REL message is sent to cancel the call. 580 (4) A gateway timeout message is sent back to the SIP node. 582 (5) The SIP node, upon receiving an INVITE final response (504), 583 will send an ACK to acknowledge receipt. 585 6.1.6. SIP Timeout 586 SIP MGC/MG PSTN 587 1|---------INVITE---------->| | 588 |<----------100------------| | 589 | |------------IAM---------->|2 590 | |<=========Audio===========| 591 | |<-----------CON-----------|3 592 | |<=========Audio==========>| 593 4|<----------200------------| | 594 | *** T1 Expires *** | | 595 |<----------200------------| | 596 | *** T1 Expires *** | | 597 |<----------200------------| | 598 | *** T1 Expires *** | | 599 |<----------200------------| | 600 | *** T1 Expires *** | | 601 |<----------200------------| | 602 | *** T1 Expires *** | | 603 |<----------200------------| | 604 | *** T1 Expires *** | | 605 5|<----------200------------| | 606 | *** T1 Expires *** | | 607 | ** MG Releases PSTN Trunk ** | 608 7|<----------BYE------------|------------REL---------->|6 609 | |<-----------RLC-----------|8 611 (1) When a SIP user wishes to begin a session with a PSTN user, 612 the SIP node issues an INVITE request. 614 (2) Upon receipt of an INVITE request, the gateway maps it to an 615 IAM message and sends it to the ISUP network. 617 (3) Since the remote node is configured for automatic answering, 618 it will send a CON message upon receipt of the IAM. 620 (4) Upon receipt of the ANM, the gateway will send a 200 message 621 to the SIP node and set SIP timer T1. 623 (5) The response is retransmitted every time the SIP timer T1 624 expires. 626 (6) After seven retransmissions, the call is torn down by sending 627 a REL to the ISUP node, with a cause code of 102 (recover on 628 timer expiry). 630 (7) A BYE is transmitted to the SIP node in an attempt to close 631 the call. Further handling for this clean up is not shown, 632 since the SIP node's state is not easily known in this 633 scenario. 635 (8) Upon receipt of the REL message, the remote ISUP node will 636 reply with an RLC message. 638 6.1.7. ISUP Setup Failure 640 SIP MGC/MG PSTN 641 1|---------INVITE---------->| | 642 |<----------100------------| | 643 | |------------IAM---------->|2 644 | |<-----------REL-----------|3 645 | |------------RLC---------->|4 646 5|<----------4xx+-----------| | 647 6|-----------ACK----------->| | 649 (1) When a SIP user wishes to begin a session with a PSTN user, 650 the SIP node issues an INVITE request. 652 (2) Upon receipt of an INVITE request, the gateway maps it to an 653 IAM message and sends it to the ISUP network. 655 (3) Since the remote ISUP node is unable to complete the call, it 656 will send a REL. 658 (4) The gateway releases the circuit and confirms that it is 659 available for reuse by sending an RLC. 661 (5) The gateway translates the cause code in the REL to a SIP 662 error response (see section 6.2.4. ) and sends it to the SIP 663 node. 665 (6) The SIP node sends an ACK to acknowledge receipt of the 666 INVITE final response. 668 6.1.8. Cause present in ACM message 669 SIP MGC/MG PSTN 670 1|---------INVITE---------->| | 671 |<----------100------------| | 672 | |------------IAM---------->|2 673 | |<=========Audio===========| 674 | |<---ACM with cause code---|3 675 4|<------183 with SDP-------| | 676 |<=========Audio===========| | 677 5|----------PRACK---------->| | 678 6|<----------200------------| | 679 ** Interwork timer expires ** 680 7|<----------4xx+-----------| | 681 | |------------REL---------->|8 682 | |<-----------RLC-----------|9 683 10|-----------ACK----------->| | 685 (1) When a SIP user wishes to begin a session with a PSTN user, 686 the SIP node issues an INVITE request. 688 (2) Upon receipt of an INVITE request, the gateway maps it to an 689 IAM message and sends it to the ISUP network. 691 (3) Since the ISUP node is unable to complete the call and wants 692 to generate the error tone/announcement itself, it sends an 693 ACM with a cause code. The gateway starts an interwork timer. 695 (4) Upon receipt of an ACM with cause, the gateway will generate 696 a 183 message towards the SIP node; this contains SDP to 697 establish early media cut-through. 699 (5) The SIP node sends a PRACK message to confirm receipt of the 700 provisional response. 702 (6) The PRACK is confirmed 704 (7) A final INVITE response, based on the cause code received in 705 the earlier ACM message, is generated and sent to the SIP 706 node to terminate the call. See section 6.2.4. for the table 707 which contains the mapping from cause code to SIP response. 709 (8) Upon expiration of the interwork timer, a REL is sent towards 710 the PSTN node to terminate the call. Note that the SIP node 711 can also terminate the call by sending a CANCEL before the 712 interwork timer expires. In this case, the signalling 713 progresses as in section 6.1.9. 715 (9) Upon receipt of the REL message, the remote ISUP node will 716 reply with an RLC message. 718 (10) The SIP node sends an ACK to acknowledge receipt of the 719 INVITE final response. 721 6.1.9. Call cancelled by SIP node 723 SIP MGC/MG PSTN 724 1|---------INVITE---------->| | 725 |<----------100------------| | 726 | |------------IAM---------->|2 727 | |<=========Audio===========| 728 | |<-----------ACM-----------|3 729 4|<----------18x------------| | 730 |<=========Audio===========| | 731 5|----------PRACK---------->| | 732 6|<----------200------------| | 733 | ** MG Releases IP Resources ** | 734 7|----------CANCEL--------->| | 735 8|<----------200------------| | 736 | ** MG Releases PSTN Trunk ** | 737 | |------------REL---------->|9 738 10|<----------487------------| | 739 | |<-----------RLC-----------|11 740 12|-----------ACK----------->| | 742 (1) When a SIP user wishes to begin a session with a PSTN user, 743 the SIP node issues an INVITE request. 745 (2) Upon receipt of an INVITE request, the gateway maps it to an 746 IAM message and sends it to the ISUP network. 748 (3) The remote ISUP node indicates that the address is sufficient 749 to set up a call by sending back an ACM message. 751 (4) The "called party status" code in the ACM message is mapped 752 to a SIP provisional response (180 for "subscriber free" and 753 183 for "no indication") and returned to the SIP node. This 754 response may contain SDP to establish an early media stream. 756 (5) The SIP node sends a PRACK message to confirm receipt of the 757 provisional response. 759 (6) The PRACK is confirmed 761 (7) To cancel the call before it is answered, the SIP node sends 762 a CANCEL request. 764 (8) The CANCEL request is confirmed with a 200 response. 766 (9) Upon receipt of the CANCEL request, the gateway sends a REL 767 message to terminate the ISUP call. 769 (10) The gateway sends a "487 Call Cancelled" message to the SIP 770 node to complete the INVITE transaction. 772 (11) Upon receipt of the REL message, the remote ISUP node will 773 reply with an RLC message. 775 (12) Upon receipt of the 487, the SIP node will confirm reception 776 with an ACK. 778 6.2. State Machine 780 Note that REL can be received in any state; the handling is the 781 same for each case (see section 6.2.4. ). 783 +---------+ 784 +----------------------->| Idle |<---------------------+ 785 | +----+----+ | 786 | | | 787 | | INVITE/6.2.1 | 788 | V | 789 | T7/6.2.2 +-------------------------+ REL/6.2.4 | 790 +<----------------+ Trying +------------>+ 791 | +-+--------+------+-------+ | 792 | CANCEL/6.2.3 | | | | | 793 +<----------------+ | E.ACM/ | ACM/ | CON/ | 794 | | 6.2.5 |6.2.6 | 6.2.7 | 795 | V | | | 796 | T9/6.2.8 +--------------+ | | | 797 +<----------+ Not alerting | | | | 798 | +-------+------+ | | | 799 | CANCEL/6.2.3 | | | | | 800 |<--------------+ | CPG/ | | | 801 | | 6.2.9 | | | 802 | V V | | 803 | T9/6.2.8 +---------------+ | REL/6.2.4 | 804 +<----------------+ Alerting |-|-------------------->| 805 |<----------------+--+-----+------+ | | 806 | CANCEL/6.2.3 | ^ | | | 807 | CPG/ | | | ANM/ | | 808 | 6.2.9 +--+ | 6.2.7 | | 809 | V V | 810 | +-------------------------+ REL/9.2 | 811 | | Waiting for ACK |------------>| 812 | +-------------+-----------+ | 813 | | | 814 | | ACK/6.2.10 | 815 | V | 816 | BYE/9.1 +-------------------------+ REL/9.2 | 817 +<----------------+ Connected +------------>+ 818 +-------------------------+ 820 6.2.1. INVITE received 822 When an INVITE request is received by the gateway, a "100 Trying" 823 response may be sent back to the SIP network indicating that the 824 MGC is handling the call. 826 The resources for the media stream have to be reserved at this 827 stage, since an IAM message cannot be sent before the resource 828 reservation takes place. Typically the resources consist of a 829 time slot in an E1/T1 and an RTP/UDP port on the IP side. 830 Resources might also include QoS or/and security provisions. 831 Before sending the IAM the MG gets backward through connected. 833 An ISUP IAM is sent. If the incoming INVITE contains a IAM in its 834 body this IAM is sent (possibly with certain changes; for 835 example, the called number may need to be updated from the "To" 836 field if the call was redirected inside the SIP network). If no 837 IAM is present the MGC generates one. The mandatory parameters of 838 the IAM are described below: 840 Message type: IAM 842 Nature of connection indicators 843 Satellite Indicator: 00 no satellite circuit 844 Continuity check indicator: It depends on the call 845 typically, 0 (no check) 846 Echo control device indicator: It depends on the call 848 Forward call indicators 849 National/International call indicator: It depends on the call 850 End-to-end method indicator: 00 no end-to-end method 851 Interworking indicator: 0 no interworking 852 End-to-end information indicator 0 no end-to-end info 853 ISDN user part indicator: 1 ISUP all the way 854 ISDN user part preference indicator: 00 ISUP preferred 855 ISDN access indicator: 1 ISDN access 856 SCCP method indicator: 0 no indication 858 Calling party's category: Depends on caller; usually 859 00001010 ordinary 861 Transmission medium requirement: It depends on the call 863 Called party's number: Based on the 'to' field 865 The optional parameter `Calling party number' can be added. Its 866 value can be derived based on the SIP `from' header. Optionally, 867 if this information cannot be verified, it may be sent as a 868 `Generic Address Parameter.' Further, the gateway may choose to 869 populate the `Original Called Number' (if it had to update the 870 `Called Number' field) and the `Charge Number' field (based on a 871 billing number obtained through means which are outside the scope 872 of this document). 874 When the ISUP parameters regarding interworking are set, this 875 indicates that ISDN is interworking with a network which is not 876 capable of providing as many services as ISDN does. ISUP will 877 therefore not employ certain features it otherwise normally uses. 879 Thus, `interworking encountered' must not be specified so that 880 ISUP behaves normally. SIP is considered as an SS7 network and a 881 SIP phone is considered as ISDN access since the SIP network is 882 supposed to provide at least as many services as ISUP. 884 Claiming to be an ISDN node might make the callee request ISDN 885 user to user services. Since user to user sevices 1 and 2 must be 886 requested by the caller, they do not represent a problem [13] . 887 User to user service 3 can be requested by the callee also. In 888 non-SIP bridging situations, the MGC should be capable of 889 rejecting this service request. 891 After sending the IAM the timer T7 is started. The default value 892 of T7 is between 20 and 30 seconds. The MGC goes to the `Trying' 893 state. 895 When overlap signalling is used in SIP bridging situations, more 896 INVITEs might arrive containing subsequent digits of the callees' 897 number. These INVITEs have the same Call-ID and From fields, but 898 the To field contains more digits. 900 The MGC receives these digits and sends a SAM with the new digits 901 and restarts T7 every time a new INVITE arrives. All the INVITEs 902 but the last one containing all the digits are answered with 484 903 Address Incomplete. The reception of an ACM from the ISUP network 904 confirms that the callees' address is complete. 906 See sections 6.1.2. and 7.1.2. for a more detailed handling of 907 overlapped dialing. 909 6.2.2. ISUP T7 expires 911 Since no response was received from the PSTN all the resources in 912 the MG are released. A `504 gateway timeout' is sent back to the 913 SIP network. A REL message with cause value 111 (protocol error) 914 is sent to the PSTN. The PSTN responds with RLC and the SIP 915 network responds with an ACK indicating that the release sequence 916 has been completed. 918 6.2.3. CANCEL or BYE received 920 If a CANCEL or BYE request is received, a `200 OK' is sent to the 921 SIP network to confirm the CANCEL or BYE; a 487 is also sent to 922 terminate the INVITE transaction. All the resources are released 923 and a REL message is sent to the PSTN with cause value 16 (normal 924 clearing). A RLC from the PSTN is received indicating that the 925 release sequence is complete. 927 It is important that all the resources are released before the 928 gateway sends any REL message. 930 In SIP bridging situations, a REL might arrive in the CANCEL or 931 BYE request body. This REL is sent to the PSTN. 933 This section ( 6.2.3. ) applies every time that a CANCEL or a BYE 934 is received before a final SIP response has been sent. 936 6.2.4. REL received 938 This section applies every time that a REL is received before a 939 final SIP response has been sent. 941 The resources are released in the MG and a RLC is sent to the 942 ISUP network to indicate that the circuit is available for reuse. 944 If the INVITE originating this transaction contained ISUP 945 messages in its body (IAM or SAMs), the MGC is handling a SIP 946 bridging situation. Therefore, the REL message jut received 947 should be included in the body of the response. 949 The REL contains a cause value. The SIP response is sent based on 950 this cause value. If a cause value other than what is listed 951 below is received, the default response `500 Server internal 952 error' would be used. 954 Normal event 956 ISUP Cause value SIP response 957 ---------------- ------------ 958 1 unallocated number 410 Gone 959 2 no route to network 404 Not found 960 3 no route to destination 404 Not found 961 4 send special information tone --- 962 16 normal call clearing --- 963 17 user busy 486 Busy here 964 18 no user responding 480 Temporarily unavailable 965 19 no answer from the user 480 Temporarily unavailable 966 21 call rejected 603 Decline 967 22 number changed 301 Moved Permanently 968 27 destination out of order 404 Not found 969 28 address incomplete 484 Address incomplete 970 29 facility rejected 501 Not implemented 971 31 normal unspecified 480 Temporarily unavailable 973 A REL with cause 22 (number changed) might contain information 974 about a new number where the callee might be reachable. If the 975 MGC is able to parse this information it might be added to the 976 SIP response in a Contact header. 978 Resource unavailable 980 This kind of cause value indicates a non permanent situation. A 981 `Retry-After' header has to be added to the response. 983 ISUP Cause value SIP response 984 ---------------- ------------ 985 34 no circuit available 503 Service unavailable 986 38 network out of order 503 Service unavailable 987 41 temporary failure 503 Service unavailable 988 42 switching equipment congestion 503 Service unavailable 989 44 requested channel not available 503 Service unavailable 990 47 resource unavailable 503 Service unavailable 992 Service or option not available 994 This kind of cause value indicates a permanent situation 996 ISUP Cause value SIP response 997 ---------------- ------------ 998 55 incoming calls bared within CUG 603 Decline 999 57 bearer capability not authorized 503 Service unavailable 1000 58 bearer capability not presently 503 Service unavailable 1001 available 1002 63 service/option not available 503 Service unavailable 1004 Service or option not implemented 1006 ISUP Cause value SIP response 1007 ---------------- ------------ 1008 65 bearer capability not implemented 501 Not implemented 1009 79 service or option not implemented 501 Not implemented 1011 Invalid message 1013 ISUP Cause value SIP response 1014 ---------------- ------------ 1015 87 user not member of CUG 503 Service unavailable 1016 88 incompatible destination 503 Service unavailable 1017 95 invalid message 503 Service unavailable 1019 Protocol error 1020 ISUP Cause value SIP response 1021 ---------------- ------------ 1022 102 recovery of timer expiry 408 Request timeout 1023 111 protocol error 500 Server internal error 1025 Interworking 1027 ISUP Cause value SIP response 1028 ---------------- ------------ 1029 127 interworking unspecified 500 Server internal error 1031 6.2.5. Early ACM received 1033 This message is sent in certain situations for resetting the 1034 timers. In these cases this message indicates that the call is in 1035 progress but callee is not being alerted. This occurs for example 1036 in mobile networks, where roaming can take a long time. The early 1037 ACM is sent before the user is alerted to reset T7 and start T9. 1039 An ACM is considered an `early ACM' if the Called Party's Status 1040 Indicator is set to 00 (no indication). 1042 After receiving an early ACM the progress of the call is 1043 indicated by the network sending CPGs. 1045 When there is interworking with some old systems, it is possible 1046 to receive an ANM immediately after an early ACM (without CPG). 1047 In this situation the SIP user will not hear any kind of ringback 1048 tone before the callee answers. In ISDN [11] this is solved by 1049 connecting the voice path backwards before sending the IAM. 1051 The MGC sends a 183 Session Progress [9] to the SIP network with 1052 a media description inside. In SIP bridging situations the early 1053 ACM is included in the response body. Thus, the problem of 1054 missing the ring back tone is solved and the early ACM is 1055 transported transparently through the SIP network. 1057 6.2.6. ACM received 1059 Upon reception of an ACM timer T9 is started. T9 typically lasts 1060 between 90 seconds and 3 minutes [12] . It allows the caller to 1061 hear announcements from the network for that period of time 1062 without being charged for the connection. If longer announcements 1063 have to be played the network has to send an ANM. When the ANM is 1064 sent the call begins being charged. 1066 The nearest local exchange to the callee generates the ringback 1067 tone and may send voice announcements. 1069 A `180 Ringing' is sent to the SIP network. It contains a media 1070 description. The ringback tone or the proper announcements will 1071 be generated by the PSTN exchange, and not by the callers SIP 1072 UAC/UAS. 1074 In SIP bridging situations, the ACM is included in the body of 1075 the 180 response. 1077 6.2.7. CON or ANM received 1079 A `200 OK' response is sent to the SIP network. In SIP bridging 1080 situations, the ISUP message is included in the body of the 200 1081 OK response. This is also the point at which a two-way media 1082 stream will be established. 1084 6.2.8. Timer T9 expires 1086 This indicates that the ANM has not arrived in time specified. 1087 This results in the call being aborted. All the resources related 1088 to the media path are released. A `480 temporarily unavailable' 1089 is sent to the SIP network. A REL message with cause value 19 (no 1090 answer from the user) is sent to the ISUP part. The PSTN responds 1091 with RLC and the SIP network responds with an ACK indicating that 1092 the release sequence has been completed. 1094 6.2.9. CPG received 1096 A CPG can indicate progress, alerting or in-band information. If 1097 the CPG comes after an ACM, there is already a one-way voice path 1098 open, so there is no need of taking further action in the media 1099 path. 1101 In SIP bridging situations, the CPG is sent in the body of a 18x 1102 response, determined from the CPG event code. 1104 ISUP event code SIP response 1105 ---------------- ------------ 1106 1 Alerting 180 Ringing 1107 2 Progress 183 Call progress 1108 3 In-band information 183 Call progress 1109 4 Call forward; line busy 181 Call is being forwarded 1110 5 Call forward; no reply 181 Call is being forwarded 1111 6 Call forward; unconditional 181 Call is being forwarded 1112 - (no event code present) 183 Call progress 1114 Note that, if the CPG does not indicate "Alerting," the current 1115 state will not change. 1117 6.2.10. ACK received 1119 At this stage, the two-way voice channel may be modified based on 1120 the SDP present in the ACK. The call is connected and the 1121 conversation can take place. 1123 7. ISUP to SIP mapping 1125 7.1. Call Flows 1127 The following call flows illustrate the order of messages in 1128 typical success and error cases when setting up a call initiated 1129 from the PSTN network. "100 Trying" acknowledgements to INVITE 1130 requests are not explained, since their presence is optional. 1132 In these diagrams, all call singnalling (SIP, ISUP) is going to 1133 and from the MGC; media handling (e.g. audio cut-through, trunk 1134 freeing) is being performed by the MG, under the control of the 1135 MGC. For the purpose of simplicity, these are shown as a single 1136 node, labeled "MGC/MG." 1138 7.1.1. En-bloc call setup (non auto-answer) 1140 SIP MGC/MG PSTN 1141 | |<-----------IAM-----------|1 1142 | |==========Audio==========>| 1143 2|<--------INVITE-----------| | 1144 |-----------100----------->| | 1145 3|-----------18x----------->| | 1146 |==========Audio==========>| | 1147 | |------------ACM---------->|4 1148 5|<---------PRACK-----------| | 1149 6|-----------200----------->| | 1150 7|-----------18x----------->| | 1151 | |------------CPG---------->|8 1152 9|<---------PRACK-----------| | 1153 10|-----------200----------->| | 1154 11|-----------200----------->| | 1155 |<=========Audio==========>| | 1156 | |------------ANM---------->|12 1157 | |<=========Audio==========>| 1158 13|<----------ACK------------| | 1160 (1) When a PSTN user wishes to begin a session with a SIP user, 1161 the PSTN network generates an IAM message towards the 1162 gateway. 1164 (2) Upon receipt of the IAM message, the gateway generates an 1165 INVITE message, and sends it to an appropriate SIP node based 1166 on called number analysis. 1168 (3) When an event signifying that the call has sufficient 1169 addressing information occurs, the SIP node will generate a 1170 provisional response of 180 or greater. 1172 (4) Upon receipt of a provisional response of 180 or greater, the 1173 gateway will generate an ACM message. If the response is not 1174 180, the ACM will carry a "called party status" value of "no 1175 indication." 1177 (5) The gateway sends a PRACK message to confirm receipt of the 1178 provisional response. 1180 (6) The PRACK is confirmed 1182 (7) The SIP node may use further provisional messages to indicate 1183 call progress. 1185 (8) After an ACM has been sent, all provisional responses will 1186 translate into ISUP CPG messages as indicated in 7.2.3. 1188 (9) The gateway sends a PRACK message to confirm receipt of the 1189 provisional response. 1191 (10) The PRACK is confirmed 1193 (11) When the SIP node answers the call, it will send a 200 OK 1194 message. 1196 (12) Upon receipt of the 200 OK message, the gateway will send an 1197 ANM message towards the ISUP node. 1199 (13) The gateway will send an ACK to the SIP node to acknowledge 1200 receipt of the INVITE final response. 1202 7.1.2. Overlap call setup 1204 Note that supporting overlap dialing in the SIP network is an 1205 option that may be deemed undesirable due to the large number of 1206 messages involved. In this case, the gateway may elect to collect 1207 digits until a timer expires or a stop digit (such as #) is 1208 entered by the user. 1210 For a more detailed description of overlap signalling see section 1211 11. 1213 SIP MGC/MG PSTN 1214 | |<-----------IAM-----------|1 1215 | |==========Audio==========>| 1216 2|<--------INVITE-----------| | 1217 3|-----------484----------->| | 1218 4|<----------ACK------------| | 1219 | |<-----------SAM-----------|5 1220 6|<--------INVITE-----------| | 1221 |-----------100----------->| | 1222 | |<-----------SAM-----------|7 1223 8|<--------INVITE-----------| | 1224 |-----------100----------->| | 1225 | |<-----------SAM-----------|9 1226 10|<--------INVITE-----------| | 1227 |-----------100----------->| | 1228 | |<-----------SAM-----------|11 1229 12|<--------INVITE-----------| | 1230 |-----------100----------->| | 1231 13|-----------18x----------->| | 1232 |==========Audio==========>| | 1233 14|<---------PRACK-----------| | 1234 | |------------ACM---------->|15 1235 16|-----------484----------->| | 1236 17|<----------ACK------------| | 1237 18|-----------484----------->| | 1238 19|<----------ACK------------| | 1239 20|-----------484----------->| | 1240 21|<----------ACK------------| | 1241 22|-----------200----------->| | 1242 23|-----------18x----------->| | 1243 | |------------CPG---------->|24 1244 25|<---------PRACK-----------| | 1245 26|-----------200----------->| | 1246 27|-----------200----------->| | 1247 |<=========Audio==========>| | 1248 | |------------ANM---------->|28 1249 | |<=========Audio==========>| 1250 29|<----------ACK------------| | 1252 (1) When a PSTN user wishes to begin a session with a SIP user, 1253 the PSTN network generates an IAM message towards the 1254 gateway. 1256 (2) Upon receipt of the IAM message, the gateway generates an 1257 INVITE message, and sends it to an appropriate SIP node based 1258 on called number analysis. It is possible that the gateway 1259 won't have enough information to send the INVITE yet; this 1260 situation is not shown. Under these circumstances, the 1261 gateway holds on to the IAM until it has received enough 1262 digits that it knows where to send the INVITE. 1264 (3) The far end may immediately determine that it is unable to 1265 terminate the call due to an insufficient number of digits. 1266 It will return a "484 Address Incomplete" message under these 1267 circumstances. 1269 (4) The 484 is acknowledged. 1271 (5) A SAM arrives from the PSTN with additional digits present. 1273 (6) The gateway appends the new digits to the number it is 1274 sending in the "To" field and re-sends the INVITE. This 1275 INVITE contains the same "From" and "Call-ID" headers. Since 1276 the "To" field of this message is different from the previous 1277 INVITE(s), this transaction represents a different call leg 1278 than the INVITE in step 1; consequently, there is no 1279 relationship between the CSeq values in the two INVITE 1280 messages. 1282 (7) See step 5 1284 (8) See step 6 1286 (9) See step 5 1288 (10) See step 6 1290 (11) See step 5 1292 (12) See step 6 1294 (13) Once the far end SIP node has determined that it has enough 1295 information to successfully route the call, it sends a 18x 1296 message. 1298 (14) The gateway sends a PRACK message to confirm receipt of the 1299 provisional response. 1301 (15) Upon receipt of a provisional response of 180 or greater, 1302 the gateway will generate an ACM message to indicate that 1303 enough digits have been collected. If the response is not 1304 180, the ACM will carry a "called party status" value of "no 1305 indication." 1307 (16) "484 Address Incomplete" arrives to complete the INVITE 1308 transaction started in step 6. 1310 (17) The 484 in step 16 is acknowledged 1311 (18) "484 Address Incomplete" arrives to complete the INVITE 1312 transaction started in step 8. 1314 (19) The 484 in step 18 is acknowledged 1316 (20) "484 Address Incomplete" arrives to complete the INVITE 1317 transaction started in step 10. 1319 (21) The 484 in step 20 is acknowledged 1321 (22) The PRACK from step 14 is acknowledged 1323 (23) The SIP node may use further provisional messages to 1324 indicate call progress. 1326 (24) After an ACM has been sent, all provisional responses will 1327 translate into ISUP CPG messages as indicated in 7.2.3. 1329 (25) The gateway sends a PRACK message to confirm receipt of the 1330 provisional response. 1332 (26) The PRACK is confirmed 1334 (27) When the SIP node answers the call, it will send a 200 OK 1335 message. 1337 (28) Upon receipt of the 200 OK message, the gateway will send an 1338 ANM message towards the ISUP node. 1340 (29) The gateway will send an ACK to the SIP node to acknowledge 1341 receipt of the INVITE final response. 1343 7.1.3. Overlap call setup with a routing (redirect) server 1344 Redirect Server MGC/MG PSTN 1345 | |<-----------IAM-----------|1 1346 | |==========Audio==========>| 1347 2|<--------INVITE-----------| | 1348 3|-----------484----------->| | 1349 4|<----------ACK------------| | 1350 | |<-----------SAM-----------|5 1351 6|<--------INVITE-----------| | 1352 7|-----------484----------->| | 1353 8|<----------ACK------------| | 1354 | |<-----------SAM-----------|9 1355 10|<--------INVITE-----------| | 1356 11|-----------302----------->| | 1357 12|<----------ACK------------| | 1358 | | 1359 | | 1360 Egress MGC/MG | | 1361 13|<--------INVITE-----------| | 1362 |-----------100----------->| | 1363 | |<-----------SAM-----------| 1364 ... 1366 (1) When a PSTN user wishes to begin a session with a SIP user, 1367 the PSTN network generates an IAM message towards the 1368 gateway. 1370 (2) Upon receipt of the IAM message, the gateway generates an 1371 INVITE message, and sends it to an appropriate SIP node based 1372 on called number analysis. In this example, this node is a 1373 routing (redirection) server. 1375 (3) Since the routing server doesn't have enough information to 1376 select an egress gateway, it responds with a "484 Address 1377 Incomplete". 1379 (4) The 484 is acknowledged. 1381 (5) After collecting more digits, the PSTN node sends a SAM with 1382 the additional digits. 1384 (6) The gateway appends the new digits to the number it is 1385 sending in the "To" field and re-sends the INVITE. This 1386 INVITE contains the same "From" and "Call-ID" headers. Since 1387 the "To" field of this message is different from the previous 1388 INVITE(s), this transaction represents a different call leg 1389 than the INVITE in step 1; consequently, there is no 1390 relationship between the CSeq values in the two INVITE 1391 messages. 1393 (7) In this example, there is still not enough information to 1394 route the call. 1396 (8) The 484 is acknowledged. 1398 (9) See step 5. 1400 (10) See step 6. 1402 (11) The INVITE finally contains enough digits that the redirect 1403 server can select a next-hop SIP node. A "302 Temporarily 1404 Moved" response is returned to redirect the SIP node to the 1405 appropriate gateway. (In practice, this may not necessarily 1406 be a gateway; it might be another redirect server, a proxy 1407 server, or a native client). Note that it is quite probable 1408 that the called number is not completely collected at this 1409 time; sending an ACM towards the PSTN would be extremely 1410 destructive at this point in the call, since it would prevent 1411 any further collection of digits. 1413 (12) The 302 is acknowledged. 1415 (13) The call now continues as in step 2 of section 7.1.2. 1417 7.1.4. Auto-answer call setup 1419 SIP MGC/MG PSTN 1420 | |<-----------IAM-----------|1 1421 | |==========Audio==========>| 1422 2|<--------INVITE-----------| | 1423 3|-----------200----------->| | 1424 |<=========Audio==========>| | 1425 | |------------CON---------->|4 1426 | |<=========Audio==========>| 1427 5|<----------ACK------------| | 1429 (1) When a PSTN user wishes to begin a session with a SIP user, 1430 the PSTN network generates an IAM message towards the 1431 gateway. 1433 (2) Upon receipt of the IAM message, the gateway generates an 1434 INVITE message, and sends it to an appropriate SIP node based 1435 on called number analysis. 1437 (3) Since the SIP node is set up to automatically answer the 1438 call, it will send a 200 OK message. 1440 (4) Upon receipt of the 200 OK message, the gateway will send a 1441 CON message towards the ISUP node. 1443 (5) The gateway will send an ACK to the SIP node to acknowledge 1444 receipt of the INVITE final response. 1446 7.1.5. SIP Timeout 1448 SIP MGC/MG PSTN 1449 | |<-----------IAM-----------|1 1450 | |==========Audio==========>| 1451 2|<--------INVITE-----------| | 1452 | *** T1 Expires *** | | 1453 3|<--------INVITE-----------| | 1454 | *** T1 Expires *** | | 1455 |<--------INVITE-----------| | 1456 | | *** T11 Expires *** | 1457 | |------------ACM---------->|4 1458 | *** T1 Expires *** | | 1459 |<--------INVITE-----------| | 1460 | *** T1 Expires *** | | 1461 |<--------INVITE-----------| | 1462 | *** T1 Expires *** | | 1463 |<--------INVITE-----------| | 1464 | *** T1 Expires *** | | 1465 |<--------INVITE-----------| | 1466 | *** T1 Expires *** | | 1467 | ** MG Releases PSTN Trunk ** | 1468 | |------------REL---------->|5 1469 6|<--------CANCEL-----------| | 1470 | |<-----------RLC-----------|7 1472 (1) When a PSTN user wishes to begin a session with a SIP user, 1473 the PSTN network generates an IAM message towards the 1474 gateway. 1476 (2) Upon receipt of the IAM message, the gateway generates an 1477 INVITE message, and sends it to an appropriate SIP node based 1478 on called number analysis. The ISUP timer T11 and SIP timer 1479 T1 are set at this time. 1481 (3) The INVITE message will continue to be sent to the SIP node 1482 each time the timer T1 expires. The SIP standard specifies 1483 that INVITE transmission will be performed 7 times if no 1484 response is received. 1486 (4) When T11 expires, an ACM message will be sent to the ISUP 1487 node to prevent the from being torn down by the remote node's 1488 ISUP T7. This ACM contains a `Called Party Status' value of 1489 `no indication.' 1491 (5) Once the maximum number of INVITE requests has been sent, the 1492 gateway will send a REL to the ISUP node to terminate the 1493 call. Since this would appear to be a serious problem with 1494 the network, the REL contains a cause code of 38: network out 1495 of order. 1497 (6) The gateway also sends a CANCEL message to the SIP node to 1498 terminate any initiation attempts. 1500 (7) Upon receipt of the REL, the remote ISUP node will send an 1501 RLC to acknowledge. 1503 7.1.6. ISUP T9 Expires 1505 SIP MGC/MG PSTN 1506 | |<-----------IAM-----------|1 1507 | |==========Audio==========>| 1508 2|<--------INVITE-----------| | 1509 | *** T1 Expires *** | | 1510 3|<--------INVITE-----------| | 1511 | *** T1 Expires *** | | 1512 |<--------INVITE-----------| | 1513 | | *** T11 Expires *** | 1514 | |------------ACM---------->|4 1515 | *** T1 Expires *** | | 1516 |<--------INVITE-----------| | 1517 | *** T1 Expires *** | | 1518 |<--------INVITE-----------| | 1519 | *** T1 Expires *** | | 1520 |<--------INVITE-----------| | 1521 | | *** T9 Expires *** | 1522 | ** MG Releases PSTN Trunk ** | 1523 | |<-----------REL-----------|5 1524 | |------------RLC---------->|6 1525 7|<--------CANCEL-----------| | 1527 (1) When a PSTN user wishes to begin a session with a SIP user, 1528 the PSTN network generates an IAM message towards the 1529 gateway. 1531 (2) Upon receipt of the IAM message, the gateway generates an 1532 INVITE message, and sends it to an appropriate SIP node based 1533 on called number analysis. The ISUP timer T11 and SIP timer 1534 T1 are set at this time. 1536 (3) The INVITE message will continue to be sent to the SIP node 1537 each time the timer T1 expires. The SIP standard specifies 1538 that INVITE transmission will be performed 7 times if no 1539 response is received. Since SIP T1 starts at 1/2 second or 1540 more and doubles each time it is retransmitted, it will be at 1541 least a minute before SIP times out the INVITE request; since 1542 SIP T1 is allowed to be larger than 500 ms initially, it is 1543 possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP 1544 T9. 1546 (4) When T11 expires, an ACM message will be sent to the ISUP 1547 node to prevent the from being torn down by the remote node's 1548 ISUP T7. This ACM contains a `Called Party Status' value of 1549 `no indication.' 1551 (5) When ISUP T9 in the remote PSTN node expires, it will send a 1552 REL. 1554 (6) Upon receipt of the REL, the gateway will send an RLC to 1555 acknowledge. 1557 (7) The REL will trigger a CANCEL request, which gets sent to the 1558 SIP node. 1560 7.1.7. SIP Error Response 1562 SIP MGC/MG PSTN 1563 | |<-----------IAM-----------|1 1564 | |==========Audio==========>| 1565 2|<--------INVITE-----------| | 1566 3|-----------4xx+---------->| | 1567 4|<----------ACK------------| | 1568 | ** MG Releases PSTN Trunk ** | 1569 | |------------REL---------->|5 1570 | |<-----------RLC-----------|6 1572 (1) When a PSTN user wishes to begin a session with a SIP user, 1573 the PSTN network generates an IAM message towards the 1574 gateway. 1576 (2) Upon receipt of the IAM message, the gateway generates an 1577 INVITE message, and sends it to an appropriate SIP node based 1578 on called number analysis. 1580 (3) The SIP node indicates an error condition by replying with a 1581 response with a code of 400 or greater. 1583 (4) The gateway sends an ACK message to acknowledge receipt of 1584 the INVITE final response. 1586 (5) An ISUP REL message is generated from the SIP code, as 1587 specified in section 7.2.6. 1589 (6) The remote ISUP node confirms receipt of the REL message with 1590 an RLC message. 1592 7.1.8. SIP Redirection 1594 SIP node 1 MGC/MG PSTN 1595 | |<-----------IAM-----------|1 1596 | |==========Audio==========>| 1597 2|<--------INVITE-----------| | 1598 3|-----------3xx+---------->| | 1599 | |------------CPG---------->|4 1600 5|<----------ACK------------| | 1601 | | 1602 | | 1603 SIP node 2 | | 1604 6|<--------INVITE-----------| | 1605 7|-----------18x----------->| | 1606 |<=========Audio===========| | 1607 | |------------ACM---------->|8 1608 9|<---------PRACK-----------| | 1609 10|-----------200----------->| | 1610 11|-----------200----------->| | 1611 |<=========Audio==========>| | 1612 | |------------ANM---------->|12 1613 | |<=========Audio==========>| 1614 13|<----------ACK------------| | 1616 (1) When a PSTN user wishes to begin a session with a SIP user, 1617 the PSTN network generates an IAM message towards the 1618 gateway. 1620 (2) Upon receipt of the IAM message, the gateway generates an 1621 INVITE message, and sends it to an appropriate SIP node based 1622 on called number analysis. 1624 (3) The SIP node indicates that the resource which the user is 1625 attempting to contact is at a different location by sending a 1626 3xx message. 1628 (4) The gateway sends a CPG with event indication that the call 1629 is being forwarded upon receipt of the 3xx message. Note that 1630 this translation should be able to be disabled by 1631 configuration, as some ISUP nodes do not support receipt of 1632 CPG messages before ACM messages. 1634 (5) The gateway acknowledges receipt of the INVITE final response 1635 by sending an ACK message to the SIP node. 1637 (6) The gateway re-sends the INVITE message to the address 1638 indicated in the Contact: field of the 3xx message. 1640 (7) When an event signifying that the call has sufficient 1641 addressing information occurs, the SIP node will generate a 1642 provisional response of 180 or greater. 1644 (8) Upon receipt of a provisional response of 180 or greater, the 1645 gateway will generate an ACM message with an event code as 1646 indicated in section 7.2.3. 1648 (9) The gateway sends a PRACK message to confirm receipt of the 1649 provisional response. 1651 (10) The PRACK is confirmed 1653 (11) When the SIP node answers the call, it will send a 200 OK 1654 message. 1656 (12) Upon receipt of the 200 OK message, the gateway will send an 1657 ANM message towards the ISUP node. 1659 (13) The gateway will send an ACK to the SIP node to acknowledge 1660 receipt of the INVITE final response. 1662 7.1.9. Call Cancelled by ISUP 1664 SIP MGC/MG PSTN 1665 | |<-----------IAM-----------|1 1666 | |==========Audio==========>| 1667 2|<--------INVITE-----------| | 1668 3|-----------18x----------->| | 1669 |==========Audio==========>| | 1670 | |------------ACM---------->|4 1671 5|<---------PRACK-----------| | 1672 6|-----------200----------->| | 1673 | ** MG Releases PSTN Trunk ** | 1674 | |<-----------REL-----------|7 1675 | |------------RLC---------->|8 1676 9|<---------CANCEL----------| | 1677 | ** MG Releases IP Resources ** | 1678 10|-----------200----------->| | 1679 11|-----------487----------->| | 1680 12|<----------ACK------------| | 1682 (1) When a PSTN user wishes to begin a session with a SIP user, 1683 the PSTN network generates an IAM message towards the 1684 gateway. 1686 (2) Upon receipt of the IAM message, the gateway generates an 1687 INVITE message, and sends it to an appropriate SIP node based 1688 on called number analysis. 1690 (3) When an event signifying that the call has sufficient 1691 addressing information occurs, the SIP node will generate a 1692 provisional response of 180 or greater. 1694 (4) Upon receipt of a provisional response of 180 or greater, the 1695 gateway will generate an ACM message with an event code as 1696 indicated in section 7.2.3. 1698 (5) The gateway sends a PRACK message to confirm receipt of the 1699 provisional response. 1701 (6) The PRACK is confirmed 1703 (7) If the calling party hangs up before the SIP node answers the 1704 call, a REL message will be generated. 1706 (8) The gateway frees the PSTN circuit and indicates that it is 1707 available for reuse by sending an RLC. 1709 (9) Upon receipt of a REL message before an INVITE final 1710 response, the gateway will send a CANCEL towards the SIP 1711 node. 1713 (10) Upon receipt of the CANCEL, the SIP node will send a 200 1714 response. 1716 (11) The remote SIP node will send a "487 Call Cancelled" to 1717 complete the INVITE transaction. 1719 (12) The gateway will send an ACK to the SIP node to acknowledge 1720 receipt of the INVITE final response. 1722 7.2. State Machine 1724 Note that REL may arrive in any state. Whenever this occurs, the 1725 actions in section 7.2.7. are taken. Not all of these transitions 1726 are shown in this diagram. 1728 +---------+ 1729 +----------------------->| Idle |<---------------------+ 1730 | +----+----+ | 1731 | | | 1732 | | IAM/7.2.1 | 1733 | V | 1734 | REL/7.2.7 +-------------------------+ 400+/7.2.6 | 1735 +<----------------+ Trying |------------>| 1736 | +-+--------+------+-------+ | 1737 | | | | | 1738 | | T11/ | 18x/ | 200/ | 1739 | | 7.2.8 |7.2.3 | 7.2.4 | 1740 | V | | | 1741 | REL/7.2.7 +--------------+ | | 400+/7.2.6 | 1742 |<----------| Progressing |-|------|-------------------->| 1743 | +--+----+------+ | | | 1744 | | | | | | 1745 | 200/ | | 18x/ | | | 1746 | 7.2.4 | | 7.2.3 | | | 1747 | | V V | | 1748 | REL/7.2.7 | +---------------+ | 400+/7.2.6 | 1749 |<-------------|--| Alerting |-|-------------------->| 1750 | | +--------+------+ | | 1751 | | | | | 1752 | | | 200/ | | 1753 | | | 7.2.4 | | 1754 | V V V | 1755 | BYE/9.1 +-----------------------------+ REL/9.1 | 1756 +<------------+ Connected +------------>+ 1757 +-----------------------------+ 1759 7.2.1. Address received 1761 Upon the reception of an IAM, resources are reserved in the media 1762 gateway and it connects audio in the backwards direction 1763 (towards the caller). 1765 The called number can be received in just one IAM (`en bloc' 1766 signalling) or in one IAM followed by one or several SAMs 1767 (overlap signalling). In some countries there is no way for the 1768 MGC to know whether the callees' number is already complete or 1769 some SAMs will still arrive. 1771 If the MGC relies on the inter-digit timeout to assume that the 1772 number is complete, the establishment of the connection is 1773 delayed. Alternatively, if the MGC sends the INVITE request 1774 immediately after receiving the IAM, heavy signalling traffic may 1775 be generated. 1777 Therefore, an individual MGC might implement a timer and/or a 1778 stop digit (such as #). All the digits that arrive before this 1779 timer expires will be included in the INVITE sent. The timer can 1780 be bypassed by the user sending the stop digit. This timer should 1781 not be larger than 5 seconds. 1783 Thus, after receiving the IAM and possibly one or several SAMs, 1784 the MGC issues an INVITE request. The "To" field contains the 1785 digits received so far. If, after sending this INVITE request, 1786 one or more SAMs are received, the MGC sends a new INVITE. This 1787 new INVITE has the same "From" and "Call-ID" as the previous 1788 INVITE sent. The "To" field is updated and contains all the 1789 available digits. 1791 `484 Address Incomplete' responses will be received for all the 1792 INVITEs sent with the incomplete callees number. Thus, all the 1793 call legs (same `Call-ID', different to) created while the digits 1794 are arriving are deleted. 1796 See section 11 for a more detailed handling of overlapped 1797 dialing. 1799 7.2.2. 100 received 1801 A 100 response does not trigger any PSTN interworking messages; 1802 it only serves the purpose of suppressing INVITE retransmissions. 1804 7.2.3. 18x received 1806 If no ACM has been sent yet and no ISUP is present in the 18x 1807 message body, and ISUP message is generated according to the 1808 following table Note that, if an early ACM is sent, the call 1809 enters state "Progressing" instead of state "Alerting." 1811 Response received Message sent by the MGC 1812 ----------------- ----------------------- 1813 180 Ringing ACM 1814 181 Call is being forwarded Early ACM and CPG, event=6 1815 182 Queued ACM 1816 183 Session progress message ACM 1818 If an ACM has already been sent and no ISUP is present in the 18x 1819 message body, an ISUP message is generated according to the 1820 following table. 1822 Response received Message sent by the MGC 1823 ----------------- ----------------------- 1824 180 Ringing CPG, event = 1 (Alerting) 1825 181 Call is being forwarded CPG, event = 6 (Forwarding) 1826 182 Queued CPG, event = 2 (Progress) 1827 183 Session progress message CPG, event = 2 (Progress) 1829 If the reception of a `180 Ringing' response without media 1830 description, the MG generates the ringback tone to be heard by 1831 the caller. 1833 If the MGC receives any 1xx response (except 100) with a session 1834 description present for media setup, it sets up the session being 1835 described. The call progress media (e.g. ringback tone or 1836 announcement) is generated by an entity downstream (in the SIP 1837 network or by a PSTN exchange in SIP bridging situations). 1839 If an ACM has not been sent yet, one is generated and sent. The 1840 mandatory parameters of the ACM are described below: 1842 Message type: ACM 1844 Backward Indicators 1845 Charge indicator: 10 charge 1846 Called party's status indicator: 01 subscriber free or 1847 00 no indication (E.ACM) 1848 Called party's category indicator: 01 ordinary subscriber 1849 End-to-end method indicator: 00 no end-to-end method 1850 Interworking indicator: 0 no interworking 1851 End-to-end information indicator: 0 no end-to-end info 1852 ISDN user part indicator: 1 ISUP all the way 1853 Holding indicator: 0 no holding 1854 ISDN access indicator: 1 ISDN access 1855 Echo control device indicator: It depends on the call 1856 SCCP method indicator: 00 no indication 1858 In SIP bridging situations the MGC sends the ISUP message 1859 contained in the response body. 1861 7.2.4. 200 received 1863 Response received Message sent by the MGC 1864 ----------------- ----------------------- 1865 200 OK ANM, ACK 1867 After receiving a 200 OK response the MGC establishes a two-way 1868 voice path in the MG and it sends an ANM to the PSTN and an ACK 1869 to the SIP network. 1871 If the `200 OK' response arrives before the MGC has sent the ACM, 1872 a CON is sent instead of the ANM. 1874 In SIP bridging situations the MGC sends the ANM or the CON in 1875 the response body. If the response body contains an ACM and an 1876 ANM both are sent to the PSTN (first the ACM and then the ANM). 1878 7.2.5. 3xx received 1880 When any 3xx response is received ,the MGC should try to contact 1881 the user using the `Contact' header or headers present in the 1882 response. These 3xx responses are typically sent by a re-direct 1883 server. This is a similar device to the HLR in mobile networks. 1884 It provides another address where the callee may be reached. 1886 A CPG message with an event code of 2 (Progress) may be sent to 1887 indicate that the call is proceeding. Note that some ISUP nodes 1888 may not support CPG before ACM, so this feature should be 1889 configurable. 1891 The 3xx MUST NOT result in the generation of an ACM message, 1892 since there may be more digits pending in overlap dialing 1893 situations. See sections 6.1.3. and 7.1.3. for callflows that 1894 demonstrate the situations in which this behavior would prove 1895 harmful. 1897 In SIP bridging situations, the MGC sends the ISUP message 1898 contained in the response body (if any). It is worthwhile 1899 mentioning that a REL with cause value 22 (number changed) might 1900 be contained in the response body of the 3xx response. This REL 1901 might contain a new number where the callee might be reachable. 1903 This REL can be sent to the PSTN, but most of the PSTN switches 1904 are not able to process this information. Thus, if the MGC is 1905 able to parse the new number, it might try the new location. 1907 If the new location is reachable via PSTN, the MGC sends a new 1908 IAM and from that moment on acts as a normal PSTN switch (no SIP 1909 involved). If the new location is reachable using SIP, the MGC 1910 sends an INVITE with possibly a new IAM generated by the MGC in 1911 the message body. 1913 All redirection situations have to be treated very carefully 1914 because they involved special charging situations. In PSTN the 1915 caller typically pays the first call leg and the callee pays the 1916 second. 1918 7.2.6. 4xx - 6xx received 1919 The MGC releases the resources in the MG, send a REL to the PSTN 1920 with a cause value and send an ACK to the SIP network. An RLC 1921 arrives indicating that the release sequence is complete. 1923 Response received Cause value in the REL 1924 ----------------- ---------------------- 1925 400 Bad request 127 Interworking 1926 401 Unauthorized 21 Call rejected 1927 402 Payment required 21 Call rejected 1928 403 Forbidden 1 Unallocated number 1929 404 Not found 1 Unallocated number 1930 405 Method not allowed 38 Network out of order 1931 406 Not acceptable 58 Bearer capability not 1932 presently available 1933 407 Proxy authentication required 21 Call rejected 1934 408 Request timeout 102 Recovery on timer expiry 1935 409 Conflict 41 Temporary failure 1936 410 Gone 1 Unallocated number 1937 411 Length required 127 Interworking 1938 413 Request Entity too long 127 Interworking 1939 414 Request-URI too long 127 Interworking 1940 415 Unsupported media type 79 Service/option not 1941 implemented 1942 420 Bad extension 127 Interworking 1943 480 Temporarily unavailable 18 No user responding 1944 481 Call leg/transaction doesn't exist 127 Interworking 1945 482 Loop detected 127 Interworking 1946 483 Too many hoops 127 Interworking 1947 484 Address incomplete --- 1948 485 Ambiguous 1 Unallocated number 1949 486 Busy here 17 User busy 1950 500 Server internal error 41 Temporary failure 1951 501 Not implemented 38 Network out of order 1952 502 Bad gateway 38 Network out of order 1953 503 Service unavailable 41 Temporary failure 1954 504 Gateway time-out 102 Recovery on timer expiry 1955 505 Version not supported 127 Interworking 1956 600 Busy everywhere 17 User busy 1957 603 Decline 21 Call rejected 1958 604 Does not exist anywhere 1 Unallocated number 1959 606 Not acceptable 38 Network out of order 1961 7.2.7. REL received 1963 The MGC should abort the establishment of the session. A CANCEL 1964 request has to be issued. A BYE is not used, since no final 1965 response has arrived from the SIP side. A 200 OK for the CANCEL 1966 arrives, and a 487 for the INVITE arrives. 1968 The MGC has to store state information for a certain period of 1969 time, since a 200 final response for the INVITE originally sent 1970 might arrive (even after the reception of the 200 OK for the 1971 CANCEL). In this situation, the MGC sends an ACK and then a BYE. 1973 In SIP bridging situations, the REL message may be included in 1974 the CANCEL message body. CANCEL requests are answered with a 1975 final response (such as 200 OK) by the first proxy. Therefore, 1976 the MGC does not know if the CANCEL has arrived to the end user 1977 (egress MGC in this scenario). Hence, if a 200 OK response for 1978 the previously sent INVITE arrives the MGC sends an ACK and then 1979 a BYE with the REL in the message body. 1981 7.2.8. ISUP T11 Expires 1983 In order to prevent the remote ISUP node's timer T7 from 1984 expiring, the gateway may choose to keep its own supervisory 1985 timer; ISUP defines this timer as T11. T11's duration is 1986 carefully chosen so that it will always be shorter than the T7 of 1987 any node to which the gateway is communicating. 1989 To clarify timer T11's relevance with respect to SIP 1990 interworking, Q.764 [14] explains its use as: "If in normal 1991 operation, a delay in the receipt of an address complete signal 1992 from the succeeding network is expected, the last common channel 1993 signalling exchange will originate and send an address complete 1994 message 15 to 20 seconds [timer (T11)] after receiving the latest 1995 address message." Since SIP nodes have no obligation to respond 1996 to an INVITE request within 20 seconds, SIP interworking 1997 inarguably qualifies as such a situation. 1999 If the gateway's T11 expires, it will send an early ACM (i.e. 2000 called party status set to "no indication") to prevent the 2001 expiration of the remote node's T7. See section 7.2.3. for the 2002 value of the ACM parameters. 2004 If a "180 Ringing" message arrives subsequently, it will be sent 2005 in a CPG, as shown in section 7.2.3. 2007 See 7.1.6. for an example callflow that includes the expiration 2008 of T11. 2010 8. Suspend/Resume 2012 In ISDN networks, the user can generate a SUS (timer T2, user 2013 initiated) in order to unplug the terminal from the socket and 2014 plug it in another one. A RES is sent once the terminal has been 2015 reconnected and the T2 timer has not expired. 2017 When a SUS arrives from the PSTN, the MGC sends an INVITE to put 2018 the media stream on hold. The reception of a RES triggers another 2019 INVITE that resumes the media stream. For the SIP UAC/UAS the 2020 result is an interruption in the voice path until the other party 2021 picks up the phone again. 2023 In SIP bridging situations, the SUS and RES messages can be 2024 transferred in the body of the INVITE. 2026 SIP MGC/MG PSTN 2027 | |<-----------SUS-----------|1 2028 2|<--------INVITE-----------| | 2029 3|-----------200----------->| | 2030 4|<----------ACK------------| | 2031 | |<-----------RES-----------|5 2032 6|<--------INVITE-----------| | 2033 7|-----------200----------->| | 2034 8|<----------ACK------------| | 2036 The handling of a network-initiated SUS prior to call teardown is 2037 handled in section 9.2.2. 2039 9. Normal Release of the Connection 2041 Either the SIP side or the ISUP side may release a call, 2042 regardless of which side initiated the call. 2044 9.1. SIP initiated 2046 For a normal release of the call (reception of BYE), the MGC 2047 immediately sends a 200 response. It then releases the resources 2048 in the MG and sends an REL with a cause code of 16 (normal call 2049 clearing) to the PSTN. Release of resources is confirmed by the 2050 PSTN with a RLC. 2052 In SIP bridging situations, the REL contained in the BYE is sent 2053 to the PSTN. 2055 SIP MGC/MG PSTN 2056 1|-----------BYE----------->| | 2057 | ** MG Releases IP Resources ** | 2058 2|<----------200------------| | 2059 | ** MG Releases PSTN Trunk ** | 2060 | |------------REL---------->|3 2061 | |<-----------RLC-----------|4 2063 9.2. ISUP Initiated 2064 If the release of the connection was caused by the reception of a 2065 REL, the REL is included in the BYE sent by the MGC. 2067 9.2.1. Caller hangs up 2069 For a normal release of the call (reception of REL from the 2070 PSTN), the MGC first releases the resources in the MG and then 2071 confirms that they are ready for re-use by sending an RLC. The 2072 SIP connection is released by sending a BYE (which is confirmed 2073 with a 200). 2075 SIP MGC/MG PSTN 2076 | |<-----------REL-----------|1 2077 | ** MG Releases PSTN Trunk ** | 2078 | |------------RLC---------->|2 2079 3|<----------BYE------------| | 2080 | ** MG Releases IP Resources ** | 2081 4|-----------200----------->| | 2083 9.2.2. Callee hangs up 2085 In analog PSTN, if the callee hangs up in the middle of a call, 2086 the local exchange sends a SUS instead of a REL and starts a 2087 timer (T6, SUS is network initiated). When the timer expires, the 2088 REL is sent. 2090 SIP MGC/MG PSTN 2091 | |<-----------SUS-----------|1 2092 2|<--------INVITE-----------| | 2093 3|-----------200----------->| | 2094 4|<----------ACK------------| | 2095 | | *** T6 Expires *** | 2096 | |<-----------REL-----------|5 2097 | ** MG Releases PSTN Trunk ** | 2098 | |------------RLC---------->|6 2099 7|<----------BYE------------| | 2100 | ** MG Releases IP Resources ** | 2101 8|-----------200----------->| | 2103 10. ISUP maintenance messages 2105 ISUP contains a set of messages used for maintenance purposes. 2106 They can be received during an ongoing call. There are basically 2107 two kinds of maintenance messages (apart from the continuity 2108 check): message for blocking circuits and messages for resetting 2109 circuits. 2111 10.1. Reset messages 2112 Upon reception of a reset message for the circuit being used, the 2113 call has to be released. RSC messages are answered with RLC after 2114 resetting the circuit in the MG. GRS messages are answered with 2115 GRA after resetting all the circuits affected by the message. 2117 The MGC acts as if a REL had been received in order to release 2118 the connection on the SIP side. The session will be terminated. A 2119 BYE or a CANCEL are sent depending of the status of the call. 2121 10.2. Blocking messages 2123 There are two kinds of blocking messages: maintenance oriented or 2124 hardware failure oriented. Maintenance oriented blocking messages 2125 indicates that the circuit has to be blocked for subsequent 2126 calls. Therefore, these messages do not affect any ongoing call. 2128 Hardware oriented blocking messages have to be treated as reset 2129 messages. The call is released. 2131 BLO is always maintenance oriented and it is answered by the MGC 2132 with BLA when the circuit is blocked. CGB messages have a "type 2133 indicator" inside the "circuit group supervision message type 2134 indicator". It indicates if the CGB is maintenance or hardware 2135 failure oriented. CGBs are answered with CGBAs." 2137 11. Overlap signalling 2139 Many of the examples contained in this draft assume "en-bloc" 2140 signalling. This section describes the behavior expected from a 2141 MGC that deals with overlap signalling. 2143 11.1. ISUP to SIP 2145 In this scenario the IAM contains just a portion of the called 2146 number. The rest of the digits dialed arrive in one or more SAMs 2147 to the MGC. 2149 Upon reception of a IAM, the gateway starts T35 and waits until 2150 the minimum amount of digits that can represent a telephone 2151 number is received (or a stop digit is received). If T35 expires 2152 before the minimum amount of digits (or a stop digit) has been 2153 received a REL with cause value 28 is sent to the ISUP side. 2155 If a stop digit is received the INVITE message generated by the 2156 gateway will contain the complete called number. Therefore, the 2157 call proceeds as usual - no overlap signalling in the SIP 2158 network. 2160 There are cases when the gateway, after having received the 2161 minimum amount of digits, cannot know whether the number received 2162 is a complete number or not. Since supporting overlap signalling 2163 in the SIP network is an option that may be deemed undesirable 2164 due to the large number of messages involved, the gateway may 2165 elect to collect digits until a timer (T10) expires or a stop 2166 digit (such as #) in entered by the user (note that T10 is 2167 refreshed every time a new digit is received). In this case, when 2168 T10 expires an ACM is sent to the ISUP side and an INVITE with 2169 the digits collected so far is sent to the SIP side. After this, 2170 any SAM received is ignored. 2172 If the gateway decides to use overlap signalling in the SIP 2173 network it should proceed as follows. As soon as the minimum 2174 amount of digits is received an INVITE is sent and T10 is 2175 started. 2177 If a SAM arrives T10 is refreshed and a new INVITE with the new 2178 digits received is sent. The new INVITE has the same Call-ID than 2179 the first INVITE sent, but has an updated To field. Therefore, 2180 both INVITEs belong to the same call but different call legs. 2182 If class 4, 5 or 6 final responses arrive (e.g. 484 address 2183 incomplete) for the pending INVITE transactions before T10 has 2184 expired the gateway should not send any REL. A REL is sent just 2185 if no more SAMs arrive, T10 expires and all the INVITEs sent have 2186 been answered with a final response (different than 200 OK). 2188 As soon as a provisional response different than 100 Trying 2189 arrives (typically a 183 Session Progress) the gateway should 2190 send all its subsequent INVITEs to the sever that generated the 2191 response. 2193 This avoids in SIP bridging situations sending subsequent INVITEs 2194 to different gateways. This would generate several IAMs in the 2195 network for just one call (rather than a IAM followed by one or 2196 more SAMs). 2198 Therefore, subsequent INVITEs would contain an updated To field, 2199 the same Call-ID and a Route header built with the Record-route 2200 and the Contact headers received in the provisional response. 2202 If two or more provisional response are received from a different 2203 location it means that the INVITEs generated reached different 2204 UASs. The gateway should choose which UAS will handle the call 2205 and send a BYE specifically addressed to the rest of UASs 2206 (Record-Route, Contact and tag in the To field). CANCEL should 2207 not be used here because the whole call could be terminated. The 2208 gateway typically chooses the UAS that returned the provisional 2209 response to the INVITE that contained more digits (see section 2210 11.3). 2212 If T10 expires and a 183 Session Progress has been received an 2213 ACM is sent to the ISUP side. 2215 An alternative approach proposed that was refused for overlap 2216 signalling consisted of sending re-INVITEs with the same To field 2217 and an updated Request-URI containing the new digits. This would 2218 confuse UAS because re-INVITEs are received before the previous 2219 INVITE transaction is finished. 2221 11.2. SIP to ISUP 2223 Gateways should be ready to receive overlap signalling from the 2224 SIP side. Thus, gateways are encouraged to return a 183 Session 2225 Progress with a Contact header as soon as they receive an INVITE 2226 that are going to handle and might contain an incomplete number. 2228 Gateways should be prepared to receive subsequent INVITEs 2229 belonging to the same call but different call-legs and generate 2230 SAMs accordingly. 2232 11.3. Example of SIP bridging and overlap signalling. 2234 This section contains an example of a proxy server that performs 2235 load balancing in a SIP bridging situation. It sends requests 2236 from the same transaction to the same egress gateway. Thus, the 2237 first INVITE sent after the IAM is routed to a different egress 2238 gateway than the second INVITE that was sent after a SAM (they 2239 are different transactions). Following the rules described in 2240 section 11.1, the ingress gateway will send a BYE to one of the 2241 egress gateways and continue call set up with the other one. This 2242 implies a big amount of messages exchanged. 2244 This situation can be avoided if proxies performing load 2245 balancing are configured to route all the requests belonging to a 2246 call (same call-ID) to the same egress gateway. 2248 In the following diagram PRACKs have been omitted. 2250 PSTN MGC1 Proxy MGC2 MGC3 2251 1|-----IAM--->| | | | 2252 2| 123 |---INVITE-->| | | 2253 3| | 123 |---INVITE-->| | 2254 4|-----SAM--->| | 123 | | 2255 5| 4 |---INVITE-->| | | 2256 6| | 1234 |---------INVITE--------->| 2257 | | | 1234 | 2258 7| | |<---183-----| | 2259 8| |<---183-----| | | 2260 9| | |<----------183-----------| 2261 10| |<---183-----| | | 2262 11|-----SAM--->| | | | 2263 12| 5 |-----------BYE---------->| | 2264 13| |<---------200 OK---------| | 2265 | | | | | 2266 14| |----------------INVITE--------------->| 2267 | | | 12345 | | 2268 15| |<----------------183------------------| 2270 (1) MGC1 receives an IAM with the called number 123. MGC1 2271 generates an INVITE. 2273 (2) The proxy routes the INVITE towards MGC2. 2275 (3) MGC2 receives the INVITE and generates a IAM (not shown) 2277 (4) MGC1 receives a SAM with the digit 4. It sends a second 2278 INVITE containing all teh digits received so far - 1234. 2280 (5) The proxy routes this second INVITE towards MGC3. 2282 (6) MGC3 receives the INVITE and generates a IAM (not shown). 2284 (7) MGC2 returns a 183 Session Progress indicating that it is 2285 handling the call. 2287 (8) The 183 response arrives to MGC1. 2289 (9) MGC3 returns a 183 Session Progress indicating that it is 2290 handling the call. 2292 (10) The 183 response arrives to MGC1. 2294 (11) MGC1 knows that there are two MGCs handling the call. MGC1 2295 chooses MGC3. So, it sends a BYE to MGC2 and an INVITE with 2296 the digits received so far (including the last SAM) to MGC3. 2298 (12) MGC2 receives the BYE and generates a REL (not shown). 2300 (13) The 200 OK for the BYE arrives to MGC1 2302 (14) An INVITE with all the digits is sent to MGC3. 2304 (15) MGC3 returns a 183 for the last INVITE. 2306 12. Other ISUP flavours 2308 Other flavours of ISUP different than Q.767 [2] have more 2309 parameters and more features. Some of the parameters have more 2310 possible values and provide more information about the status of 2311 the call. 2313 However, differences in the message flows are more important. In 2314 ANSI ISUP [3] , there is no CON message. An ANM is sent instead 2315 (with no ACM). In call forwarding situations, CPGs can be sent 2316 before the ACM is sent. SAMs are sent. `En bloc' signalling is 2317 always used. 2319 In TCC ISUP CPGs can be sent before the ACM is sent. Messages 2320 such as CHG can be sent between ACM and ANM. `En bloc' signalling 2321 is always used and there is no T9 timer. 2323 12.1. Guidelines to send other ISUP messages 2325 Some ISUP flavors send more messages than the ones described in 2326 this document. It is good to follow some guidelines to transport 2327 these ISUP messages inside SIP bodies. 2329 From the caller to the callee ISUP messages should be sent inside 2330 INFO messages, even if the INVITE transaction is still not 2331 finished. Note that SIP does not ensure that INFO requests are 2332 delivered in order. Therefore, an egress gateway might process 2333 first an INFO request that was sent after another INFO request. 2334 This issue, however, does not represent an important problem 2335 since it is not likely to happen and its effects are negligible 2336 in most of the situations. 2338 ISUP messages from the callee to the caller should be sent inside 2339 provisional responses. SIP ensure that provisional responses 2340 transmitted reliably are delivered in order. When the INVITE 2341 transaction is finished INFO requests should be used also in this 2342 direction. 2344 13. Acronyms 2345 ACK Acknowledgment 2346 ACM Address Complete Message 2347 ANM Answer Message 2348 ANSI American National Standards Institute 2349 BLA Blocking ACK message 2350 BLO Blocking Message 2351 CGB Circuit Group Blocking Message 2352 CGBA Circuit Group Blocking ACK Message 2353 CHG Charging Information Message 2354 CON Connect Message 2355 CPG Call Progress Message 2356 CUG Closed User Group 2357 GRA Circuit Group Reset ACK Message 2358 GRS Circuit Group Reset Message 2359 HLR Home Location Register 2360 IAM Initial Address Message 2361 IETF Internet Engineering Task Force 2362 IP Internet Protocol 2363 ISDN Integrated Services Digital Network 2364 ISUP ISDN User Part 2365 ITU-T International Telecommunication Union 2366 Telecommunication Standardization Sector 2367 MG Media Gateway 2368 MGC Media Gateway Controller 2369 MTP Message Transfer Part 2370 REL Release Message 2371 RES Resume Message 2372 RLC Release Complete Message 2373 RTP Real-time Transport Protocol 2374 SCCP Signalling Connection Control Part 2375 SG Signalling Gateway 2376 SIP Session Initiation Protocol 2377 SS7 System Signalling No. 7 2378 SUS Suspend Message 2379 TTC Telecommunication Technology Committee 2380 UAC User Agent Client 2381 UAS User Agent Server 2382 UDP User Data Protocol 2383 VoIP Voice over IP 2385 14. Acknowledgments 2387 The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill 2388 Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada 2389 and Miguel A. Garcia for their help and feedback on this 2390 document. 2392 15. References 2394 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 2395 Session Initiation Protocol", RFC 2543, IETF; March 1999. 2397 [2] "Application of the ISDN user part of CCITT signalling system 2398 No. 7 for international ISDN interconnections" ITU-T Q.767 2399 recommendation, February 1991. 2401 [3] "Signalling System No. 7; ISDN User Part" T1.113-1995 ANSI. 2402 January 1995. 2404 [4] E Zimmerer et al, "MIME media types for ISUP and QSIG 2405 Objects", Internet Draft , 2406 IETF; September 2000. Work in progress. 2408 [5] N. Freed/ N. Borenstein, "Multipurpose Internet Mail 2409 Extensions (MIME) Part Two: Media Types", RFC 2046, IETF; 2410 November 1996. 2412 [6] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits, 2413 Telephony Tones and Telephony Signals", RFC 2833, IETF; May 2414 2000 2000. Work in progress. 2416 [7] Jiri Kuthan, "Sample Uses of SIP INFO with Varying 2417 Reliability Needs", Internet Draft 2418 , IETF; October 1999. 2419 Work in progress. 2421 [8] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional 2422 Responses in SIP", Internet Draft 2423 , IETF; June 2000. Work in 2424 progress. 2426 [9] S. Donovan/M. Cannon/H. Schulzrinne/J. Rosenberg/A. Roach, 2427 "SIP 183 Session Progress Message", Internet draft IETF 2428 October 1999. Work in progress. 2430 [10] Steven R. Donovan, "The SIP INFO Method", RFC 2976, IETF; 2431 February 2000. Work in progress. 2433 [11] "Signalling System No. 7; ISDN User Part Signalling 2434 procedures", ITU-T Q.764 recommendation, September 1997. 2436 [12] Abnormal conditions - Special release ITU-T Q.118 2437 recommendation, September 1997. 2439 [13] "Specifications of Signalling System No. 7 - ISDN 2440 supplementary services" ITU-T Q.737 recommendation, June 2441 1997. 2443 [14] "Specifications of Signalling System No. 7 - ISDN User Part 2444 Signalling Procedures" ITU-T Q.764 recommendation, March 2445 1993. 2447 [15] R. Stewart et al, "Stream Control Transmission Protocol". 2448 RFC 2960, IETF; October 2000. 2450 16. Security Considerations 2452 The transit of ISUP in SIP bodies may provide may opportunities 2453 for abuse and fraud. In particular, SIP users may be able to 2454 interpret "private" (i.e. caller-id-blocked) numbers by examining 2455 the ISUP. Similarly, if care is not taken, SIP clients would be 2456 able to send ISUP messages into the SS7 network with invalid 2457 calling line identification and spoofed billing numbers. 2459 For these reasons, it is absolutely necessary that any ISUP sent 2460 through an IP network be strongly encrypted and authenticated. 2461 The keys used for encryption should not be static, to prevent 2462 replay attacks. A challenge-response model is recommended. As an 2463 extra layer of security, it is recommended that ISUP be sent and 2464 received only to and from nodes that are known to have an 2465 established trust relationship with the gateway. 2467 17. Authors' Addresses 2469 Gonzalo Camarillo 2470 Ericsson 2471 Advanced Signalling Research Lab 2472 FIN-02420 Jorvas 2473 Finland 2474 Phone: +358 9 299 3371 2475 Fax: +358 9 299 3052 2476 Email: Gonzalo.Camarillo@ericsson.com 2478 Adam Roach 2479 Ericsson Inc. 2480 Mailstop L-04 2481 851 International Pkwy. 2482 Richardson, TX 75081 2483 USA 2484 Phone: +1 972-583-7594 2485 Fax: +1 972-669-0154 2486 E-Mail: Adam.Roach@ericsson.com