idnits 2.17.1 draft-camarillo-mmusic-sip-isup-bcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 733 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2000) is 8807 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gonzalo Camarillo 2 Internet draft Ericsson 3 Category: Informational August 1999 4 Expires March 2000 6 Best Current Practice for ISUP to SIP mapping 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 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 Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes a way to perform the mapping between two 32 signalling protocols: SIP and ISUP. 34 General comment 36 This is a very preliminary version of this draft. It intends to get 37 feedback and opinions about 'SIP to ISUP mapping' related issues. 39 1. Introduction 41 SIP [1] is an application layer protocol for establishing, 42 terminating and modifying multimedia sessions. It is typically 43 carried over IP. Telephone calls are considered a type of 44 multimedia sessions where just audio is exchanged. 46 ISUP [2] is a level 4 protocol used in SS7 networks. It typically 47 runs over MTP although it will run also over IP (work in progress, 48 IETF SIGTRAN working group). ISUP is used for controlling telephone 49 calls and for maintenance of the network (blocking circuits, 50 resetting circuits etc.). 52 The module performing the mapping between these two protocols is 53 usually referred to as Media Gateway Controller (MGC). It has 54 logical interfaces towards both networks, the network carrying ISUP 55 and the network carrying SIP, although usually they are on the same 56 physical interface. The MGC also has capabilities for controlling 57 the voice path. There is typically a Media Gateway (MG) with E1/T1 58 interfaces (voice from PSTN) and with IP interfaces (VoIP). The MGC 59 and the MG can be merged together in one physical box or kept 60 separate. 62 2. Scope 64 This document only takes into account the call control 65 functionality of ISUP. Maintenance messages are outside the scope 66 of this document. 68 There are several flavours of ISUP. ITU-T Q.767 International ISUP 69 [2] is used through this document and some differences with ANSI 70 ISUP [3] are outlined. ISUP Q.767 [2] was chosen because is the 71 least complex of all the ISUP flavours. Once the mapping between 72 this flavour of ISUP and SIP is clear, mapping from other flavours 73 to SIP will be easier to resolve. 75 This document describes when the media path has to be initialized, 76 terminated, modified, etc, but it does not go into details such as 77 how the initialization is performed or which protocol are used for 78 that purpose. 80 3. Scenarios 82 There are several scenarios where ISUP-SIP mapping takes place. The 83 way the messages are generated is different depending on the 84 scenario. 86 When there is a single MGC and the call is from a SIP phone to a 87 PSTN phone, or vice versa, the MGC generates the ISUP messages 88 based on the methods described in this document. 90 +-------------+ +-----+ +-------------+ 91 | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | 92 +-------------+ +-----+ +-------------+ 94 The scenario where a call originates in the PSTN, goes into a SIP 95 network and terminates in the PSTN again is known as "SIP bridging". 96 SIP bridging should provide ISUP transparency between the PSTN 97 switches handling the call. This is achieved by carrying the 98 incoming ISUP messages in the body of the SIP messages [4],[8]. In 99 this case, the ISUP messages generated by the egress MGC are the 100 ones present in the SIP body. 102 +------+ +-------------+ +-----+ +------------+ +------+ 103 | PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN | 104 +------+ +-------------+ +-----+ +------------+ +------+ 106 In both scenarios, the ingress MGC places the incoming ISUP messages 107 in the SIP body by default. If the recipient of these messages 108 (typically a SIP UAC/UAS) does not understand them a negotiation 109 using the SIP 'Accept' and 'Require' headers will take place and 110 they will not be included in the next SIP message exchange. 112 Eventually there can be a Signalling Gateway (SG) between the PSTN 113 and the MGC. It encapsulates the ISUP messages over IP. The mapping 114 described in this document is not affected by its presence. 116 4. Require extensions 118 For a correct mapping between ISUP and SIP, some extensions to the 119 basic SIP specification are needed. They are defined in [5]. If the 120 SIP UAC/UAS involved in the call does not support them it is still 121 possible to proceed, but the behaviour in the establishment of the 122 call may be slightly different to the one expected by the user 123 (other party answers before receiving the ringback tone, user is not 124 informed about the call being forwarded, etc.). 126 5. Mapping 128 The mapping between ISUP and SIP is described using two state 129 machines. One handles calls from SIP to ISUP and the second from 130 ISUP to SIP. There are details, such as some retransmissions and 131 some states when the call is being disconnected (waiting for RLC, 132 waiting for ACK etc.), that are not shown in the figures in order to 133 make them easier to follow. 135 The boxes represent the different states of the gateway, and the 136 arrows show changes in the state. The event that triggers the change 137 in the state and the actions to take appear on the arrow: 139 event / section describing the actions to take 141 For example, 'INVITE / 6.1' indicates that an INVITE request has 142 been received by the gateway, and the procedure upon reception is 143 described in the section 6.1 of this document. 145 6. SIP to ISUP state machine 147 +---------+ 148 +----------------------->| Idle |<---------------------+ 149 | +----+----+ | 150 | | | 151 | | INVITE/6.1 | 152 | V | 153 | T7/6.2 +-------------------------+ REL/6.4 | 154 +<----------------+ Trying +------------>+ 155 | +-+--------+------+-------+ | 156 | CANCEL/6.3 | | | | | 157 +<----------------+ | E.ACM/ | ACM/ | CON/ | 158 | | 6.5 | 6.6 | 6.7 | 159 | V | | | 160 | T9/6.8 +--------------+ | | | 161 +<----------+ Not alerting | | | | 162 | +-------+------+ | | | 163 | | | | | 164 | | CPG/ | | | 165 | | 6.9 | | | 166 | V V | | 167 | T9/6.10 +---------------+ | | 168 +<----------------+ Alerting | | | 169 | ++-------+------+ | | 170 | | ^ | | | 171 | CPG/ | | | ANM/ | | 172 | 6.11 +--+ | 6.12 | | 173 | V V | 174 | +-------------------------+ | 175 | | Waiting for ACK | | 176 | +-------------+-----------+ | 177 | | | 178 | | ACK/6.13 | 179 | V | 180 | BYE/8 +-------------------------+ REL/8 | 181 +<----------------+ Connected +------------>+ 182 +-------------------------+ 184 6.1 INVITE request received 186 When an INVITE request is received by the gateway, a "100 Trying" 187 response is sent back to the SIP network indicating that the MGC is 188 handling of the call. 190 The resources for the media stream have to be reserved at this 191 stage, since an IAM message cannot be sent before the resource 192 reservation takes place. Typically the resources consist of a time 193 slot in an E1/T1 and an RTP/UDP port on the IP side. Before sending 194 the IAM the MG gets backward through connected. 196 An ISUP IAM is sent. The mandatory parameters of the IAM are 197 described below: 199 Message type: IAM 201 Nature of connection indicators 202 Satellite Indicator: 00 no satellite circuit 203 Continuity check indicator: It depends on the call 204 Echo control device indicator: It depends on the call 206 Forward call indicators 207 National/International call indicator: It depends on the call 208 End-to-end method indicator: 00 no end-to-end method 209 Interworking indicator: 0 no interworking 210 End-to-end information indicator 0 no end-to-end info 211 ISDN user part indicator: 1 ISDN all the way 212 ISDN user part preference indicator: 00 ISDN preferred 213 ISDN access indicator: 1 ISDN access 214 SCCP method indicator: 0 no indication 216 Calling party's category: 00001010 ordinary 218 Transmission medium requirement: It depends on the call 220 Called party's number: Based on the 'to' field 222 The optional parameter 'Calling party number' can be added. Its 223 value can be derived based on the SIP 'from' header. 225 When the ISUP parameters regarding interworking are set, this 226 indicates that ISDN is interworking with a network which is not 227 capable of providing as many services as ISDN does. ISUP will 228 therefore not employ certain features it otherwise normally uses. 229 Thus, 'interworking encountered' must not be specified so that ISUP 230 behaves normally. SIP is considered as an SS7 network and a SIP 231 phone is considered as ISDN access since the SIP network is supposed 232 to provide at least as many services as ISUP. 234 After sending the IAM the timer T7 is started. The default value of 235 T7 is between 20 and 30 seconds. 237 The MGC goes to the 'Trying' state. 239 6.2 Timer T7 expires 241 Since no response was received from the PSTN all the resources in 242 the MG are released. A '408 request timeout' is sent back to the SIP 243 network. An ACK arrives acknowledging the reception of the response. 245 6.3 CANCEL request is received 247 If a CANCEL request is received, a '200 OK' is sent to the SIP 248 network. All the resources are released and a REL message is sent to 249 the PSTN with cause value 16 (normal clearing). A RLC from the PSTN 250 is received indicating that the release sequence is complete. 252 It is important that all the resources are released before the 253 gateway sends any REL message. 255 If instead of receiving a CANCEL, a BYE request arrives, after 256 answering properly to the BYE (200 OK) all the resources in the MGC 257 are released and a REL message is sent to the PSTN with cause value 258 16 (normal clearing). A RLC from the PSTN is received indicating 259 that the release sequence is complete. 261 This section (6.3) applies every time that a CANCEL or a BYE is 262 received before a final SIP response has been sent. 264 6.4 REL is received 266 The REL contains a cause value. The SIP response is sent based on 267 this cause value. 269 ISUP Cause value SIP response 271 Normal event 273 1 unallocated number 410 Gone 274 3 no route to destination 404 Not found 275 4 send special information tone --- 276 16 normal call clearing --- 277 17 user busy 486 Busy here 278 18 no user responding 480 Temporarily unavailable 279 19 no answer from the user 480 Temporarily unavailable 280 21 call rejected 603 Decline 281 22 number changed 301 Moved Permanently 282 27 destination out of order 404 Not found 283 28 address incomplete 484 Address incomplete 284 29 facility rejected 501 Not implemented 285 31 normal unspecified 404 Not found 287 Resource unavailable 289 This kind of cause value indicates a non permanent situation. A 290 'Retry-After' header has to be added to the response. 292 34 no circuit available 503 Service unavailable 293 38 network out of order 503 Service unavailable 294 41 temporary failure 503 Service unavailable 295 42 switching equipment congestion 503 Service unavailable 296 44 requested channel not available 503 Service unavailable 297 47 resource unavailable 503 Service unavailable 299 Service or option not available 301 This kind of cause value indicates a permanent situation 303 55 incoming calls bared within CUG 603 Decline 304 57 bearer capability not authorized 501 Not implemented 305 58 bearer capability not presently 501 Not implemented 306 available 307 63 service/option not available 501 Not implemented 309 Service or option not implemented 311 65 bearer capability not implemented 501 Not implemented 312 79 service or option not implemented 501 Not implemented 314 Invalid message 316 87 user not member of CUG 603 decline 317 88 incompatible destination 400 Bad request 318 95 invalid message 400 Bad request 320 Protocol error 322 102 recovery of timer expiry 480 Request timeout 323 111 protocol error 400 Bad request 325 Interworking 327 127 interworking unspecified 500 Server internal error 329 If a different cause value was received the default response '500 330 Server internal error' would be used. 332 This section applies every time that a REL is received before a 333 final SIP response has been sent. 335 6.5 Early ACM is received 337 This message is sent in certain situations for resetting the timers. 338 In these cases this message indicates that the call is in progress 339 but callee is not being alerted. This occurs for example in mobile 340 networks, where roaming can take a long time. The early ACM is sent 341 before the user is alerted to reset T7 and start T9. 343 An ACM is considered an 'early ACM' if the Called Party's Status 344 Indicator is set to 00 (no indication). 346 After receiving an early ACM the progress of the call is indicated 347 by the network sending CPGs. 349 When there is interworking with some old systems, it is possible to 350 receive an ANM immediately after an early ACM (without CPG). In this 351 situation the SIP user will not hear any kind of ringback tone 352 before the callee answers. In ISDN [6] this is solved by connecting 353 the voice path backwards before sending the IAM. 355 6.6 ACM is received 357 The nearest local exchange to the caller generates the ringback tone 358 and may send voice announcements. 360 A '183 session progress message' [7] is sent to the SIP network. 361 Even if there are not in-band notifications or announcements it is 362 not correct to send a '180 Ringing' response, since the ringback 363 tone has to be generated by the PSTN exchange, and not by the SIP 364 UAC/UAS. 366 6.7 CON is received 368 A '200 OK' response is sent to the SIP network. 370 6.8 Timer T9 expires 372 Since an ANM has not arrived in time the call is aborted. All the 373 resources in the MG are released. A '408 request timeout' is sent to 374 the SIP network. A REL message with cause value 102 (recovery of 375 timer expiry) is sent to the PSTN. The PSTN responds with RLC and 376 the SIP network responds with an ACK indicating that the release 377 sequence has been completed. 379 6.9 CPG with status 'alerting' is received 381 If a CPG message with Event Indicator 'Alerting' or 'in-band 382 information or an appropriate pattern is now available' is received 383 the same procedure as described in section 6.5 is followed. 385 6.10 Timer T9 expires 387 This indicates that the ANM has not arrived in time specified. This 388 results in the call being aborted. All the resources related to the 389 media path are released. A '480 temporarily unavailable' is sent to 390 the SIP network. A REL message with cause value 102 (recovery of 391 timer expiry) is sent to the ISUP part. The PSTN responds with RLC 392 and the SIP network responds with an ACK indicating that the release 393 sequence has been completed. 395 6.11 CPG is received 397 A CPG can indicate progress, alerting or in-band information. Since 398 there is already a one-way voice path open, there is no need of 399 taking further action. 401 6.12 ANM is received 403 The callee has picked up the phone. A '200 OK' response is sent to 404 the SIP network. 406 6.13 ACK is received 408 At this stage a two-way voice channel is established between the 409 caller and the callee. The call is connected and the conversation 410 can take place. 412 7. ISUP to SIP state machine 414 +---------+ 415 +----------------------->| Idle |<---------------------+ 416 | +----+----+ | 417 | | | 418 | | Address info complete/7.1 | 419 | V | 420 | +-------------------------+ | 421 +<----------------+ Trying | | 422 | +-+--------+------+-------+ | 423 | | | | | 424 | | 3xx/ | 1xx/ | 200/ | 425 | | 7.4 | 7.2 | 7.3 | 426 | V | | | 427 | +--------------+ | | | 428 | | Progressing | | | | 429 | +--+----+------+ | | | 430 | | | | | | 431 | | | 1xx/ | | | 432 | | | 7.2 | | | 433 | | V V | | 434 | | +---------------+ | | 435 | 200/ | | Alerting | | | 436 | 7.3 | +--------+------+ | | 437 | | | | | 438 | | | 200/ | | 439 | | | 7.3 | | 440 | V V V | 441 | BYE/8 +-----------------------------+ REL/8 | 442 +<------------+ Connected +------------>+ 443 +-----------------------------+ 445 7.1 Address received 447 Upon the reception of an IAM resources are reserved in the MG and it 448 gets backward through connected. 450 The B-party number can be received in just one IAM ('en bloc' 451 signalling) or in one IAM followed by one or several SAMs (overlap 452 signalling). In some countries there is no way for the MGC to know 453 whether the B-party number is already complete or some SAMs will 454 still arrive. 456 If the MGC relies on the inter-digit timeout to assume that the 457 number is complete the establishment of the connection is delayed. 458 Alternatively, if the MGC sends the INVITE request immediately after 459 receiving the IAM heavy signalling traffic may be generated. 461 Therefore every individual MGC must be configured with a specific 462 timer. If an MGC never receives a SAM the value of the timer should 463 be zero. If the reception of a SAM is likely the value of the timer 464 should be sufficient for receiving them before the INVITE is sent 465 (after receiving the minimum amount of digits that can represent a 466 number, around 5 seconds). 468 Thus, after receiving the B-party number, the MGC issues an INVITE 469 request. If after sending this request a SAM is received the MGC 470 will CANCEL the INVITE and send a new INVITE to the complete 471 address. If a '484 Address Incomplete' is received the MGC should 472 wait for subsequent SAMs and send a new INVITE. 474 7.2 1xx received 476 Response received Message sent by the MGC 478 100 Trying Nothing 479 180 Ringing ACM 480 181 Call is being forwarded Early ACM 481 182 Queued ACM 482 183 Session progress message ACM 484 After the MGC receives of a '180 Ringing' response the MG generates 485 the ringback tone. 487 After the MGC receives a '183 Session progress message' response 488 the SIP network generates the ringback tone (or any announcement). 490 The ACM sent by the MGC after the reception of a '180' response or a 491 '183' response is the same. The mandatory parameters of the ACM are 492 described below: 494 Message type: ACM 496 Backward Indicators 497 Charge indicator: 10 charge 498 Called party's status indicator: 01 subscriber free 499 Called party's category indicator: 01 ordinary subscriber 500 End-to-end method indicator: 00 no end-to-end method 501 Interworking indicator: 0 no interworking 502 End-to-end information indicator: 0 no end-to-end info 503 ISDN user part indicator: 1 ISDN all the way 504 Holding indicator: 0 no holding 505 ISDN access indicator: 1 ISDN access 506 Echo control device indicator: It depends on the call 507 SCCP method indicator: 00 no indication 509 7.3 200 received 511 Response received Message sent by the MGC 513 200 OK ANM, ACK 515 After receiving a 200 OK response the MGC establishes a two-way 516 voice path in the MG and it sends an ANM to the PSTN and an ACK to 517 the SIP network. 519 If the '200 OK' response arrives before the MGC has sent the ACM, a 520 CON is sent instead of the ANM. 522 7.3 3xx received 524 3xx responses Message sent by the MGC 526 300 Multiple choices Early ACM 527 301 Moved permanently Early ACM 528 302 Moved temporarily Early ACM 529 305 Use proxy Early ACM 530 380 Alternative services Early ACM or REL 531 with cause 58 532 (if the service proposed is 533 not supported by the PSTN) 535 When any of these responses is received the MGC should try to 536 contact the user using the 'Contact' headers present in the 537 response. These 3xx responses are typically sent by a re-direct 538 server. This is a similar device to the HLR in mobile networks. It 539 provides another address where the callee may be reached. 541 If a SIP provisional response is received after sending the Early 542 ACM, a CPG is sent (instead of an ACM). 544 7.4 4xx received 546 The MGC releases the resources in the MG, send a REL to the PSTN 547 with a cause value and send an ACK to the SIP network. An RLC 548 arrives indicating that the release sequence is complete. 550 Response received Cause value in the REL 552 400 Bad request 127 interworking 553 401 Unauthorized 57 bearer capability not 554 authorized 555 402 Payment required 21 Call rejected 556 403 Forbidden 57 bearer capability not 557 authorized 558 404 Not found 1 Unallocated number 559 405 Method not allowed 127 Interworking 560 406 Not acceptable 127 Interworking 561 407 Proxy authentication required 21 Call rejected 562 408 Request timeout 102 recovery on timer expiry 563 409 Conflict 41 Temporary failure 564 410 Gone 1 Unallocated number 565 411 Length required 127 Interworking 566 413 Request Entity too long 127 Interworking 567 414 Request-URI too long 127 Interworking 568 415 Unsupported media type 79 Service/option not 569 implemented 570 420 Bad extension 127 Interworking 571 480 Temporarily unavailable 18 No user responding 572 481 Call leg/transaction doesn't exist 127 Interworking 573 482 Loop detected 127 Interworking 574 483 Too many hoops 127 Interworking 575 484 Address incomplete 28 Address incomplete 576 485 Ambiguous 1 Unallocated number 577 486 Busy here 17 User busy 579 7.5 5xx received 581 The MGC releases the resources in the MG, sends a REL to the PSTN 582 with a cause value and sends an ACK to the SIP network. An RLC 583 arrives indicating that the release sequence is complete. 585 Response received Cause value in the REL 587 500 Server internal error 41 Temporary failure 588 501 Not implemented 79 Service/option not 589 implemented 590 502 Bad gateway 38 Network out of order 591 503 Service unavailable 63 Service/option not 592 available 593 504 Gateway time-out 102 recovery on timer expiry 594 505 Version not supported 127 Interworking 596 7.6 6xx received 598 The MGC releases the resources in the MG, sends a REL to the PSTN 599 with a cause value and sends an ACK to the SIP network. An RLC 600 arrives indicating that the release sequence is complete. 602 Response received Cause value in the REL 604 600 Busy everywhere 17 User busy 605 603 Decline 21 Call rejected 606 604 Does not exist anywhere 1 Unallocated number 607 606 Not acceptable 58 Bearer capability not 608 presently available 610 8. Release of the connection 612 In analog PSTN, if the callee hangs up in the middle of a call the 613 local exchange sends a SUS instead of a REL and starts a timer (T6, 614 SUS is network initiated). When the timer expires, the REL is sent. 616 In ISDN networks, the user can generate a SUS (timer T2, user 617 initiated) in order to unplug the terminal from the socket and plug 618 it in another one. A RES is sent once the terminal has been 619 reconnected and the T2 timer has not expired. 621 When SUS and RES messages arrive from the PSTN the gateway will not 622 modify the status of the resources involved in the control of the 623 media stream. This way the signalling traffic in the network is 624 reduced (no messages are exchanged between MGC and MG). For the SIP 625 UAC/UAS the result is an interruption in the voice path until the 626 other party picks up the phone again. 628 For a normal release of the call (reception of REL from the PSTN or 629 BYE from the SIP network), the MGC first releases the resources in 630 the MG and then answers the message received (RLC to the PSTN or 631 '200 OK' to the SIP network). The connection on the other side is 632 then released by sending a REL for the PSTN or a BYE to the SIP 633 network. The REL sent by the MGC has a cause value of 16 (normal 634 call clearing). 636 9. Other ISUP flavours 638 Other flavours of ISUP different than Q.767 [2] have more parameters 639 and more features. Some of the parameters have more possible values 640 and provide more information about the status of the call. 642 However, differences in the message flows are more important. In 643 ANSI ISUP, there is no CON message. An ANM is sent instead (with no 644 ACM). In call forwarding situations, CPGs can be sent before the ACM 645 is sent. No SAMs are sent. 'En bloc' signalling is always used. 647 10. Acronyms 649 ACK Acknowledgment 650 ACM Address Complete Message 651 ANM Answer Message 652 ANSI American National Standards Institute 653 CON Connect Message 654 CPG Call Progress Message 655 CUG Closed User Group 656 HLR Home Location Register 657 IAM Initial Address Message 658 IETF Internet Engineering Task Force 659 IP Internet Protocol 660 ISDN Integrated Services Digital Network 661 ISUP ISDN User Part 662 ITU-T International Telecommunication Union 663 Telecommunication Standardization Sector 664 MG Media Gateway 665 MGC Media Gateway Controller 666 MTP Message Transfer Part 667 REL Release Message 668 RES Resume Message 669 RLC Release Complete Message 670 RTP Real-time Transport Protocol 671 SCCP Signalling Connection Control Part 672 SG Signalling Gateway 673 SIP Session Initiation Protocol 674 SS7 System Signalling No. 7 675 SUS Suspend Message 676 UAC User Agent Client 677 UAS User Agent Server 678 UDP User Data Protocol 679 VoIP Voice over IP 681 11. References 683 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 684 Session Initiation Protocol", RFC 2543, IETF; Mach 1999. 686 [2] "Application of the ISDN user part of CCITT signalling system 687 No. 7 for international ISDN interconnections" ITU-T Q.767 688 recommendation, February 1991. 690 [3] "Signalling System No. 7; ISDN User Part" T1.113-1995 ANSI. 691 January 1995. 693 [4] E. Zimmerer/A. Vemuri, "The SIP ISUP/MIME type", Internet draft 694 IETF July 1999. Work in progress. 696 [5] A. Roach, "SIP PSTN Interworking Umbrella 'Require:' Header", 697 Internet draft IETF June 1999. Work in progress. 699 [6] "Signalling System No. 7; ISDN User Part Signalling 700 procedures", ITU-T Q.764 recommendation, September 1997. 702 [7] S. Donovan/M. Cannon/H. Schulzrinne/J. Rosenberg, "SIP 183 703 Session Progress Message", Internet draft IETF June 1999. Work in 704 progress. 706 [8] A. Roach, "ISUP parameters expected in SIP messages", Internet 707 draft IETF June 1999. Work in progress. 709 12. Acknowledgments 711 I would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas and 712 Miguel A. Garcia for their help and feedback on this document. 714 13. Author's Addresses 716 Gonzalo Camarillo 717 Ericsson 718 Advanced Signalling Research Lab. 719 FIN-02420 Jorvas 720 Finland 722 Phone: +358 9 299 3371 723 Fax: +358 9 299 3118 724 Email: Gonzalo.Camarillo@ericsson.com