idnits 2.17.1 draft-donovan-mmusic-183-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 3 characters 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 512: '... The 183 message SHOULD include enough...' RFC 2119 keyword, line 541: '... responses MAY include a body. Mess...' RFC 2119 keyword, line 553: '... 183 responses SHALL always be forwa...' RFC 2119 keyword, line 567: '... description it SHALL setup the assoc...' RFC 2119 keyword, line 658: '... works then it MUST support the 183 ...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 662, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 669, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 673, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- No information found for draft-rosenberg-mmusic-sipqos - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1890 (ref. '4') (Obsoleted by RFC 3551) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Steve Donovan 2 Internet Draft John Hearty 3 draft-donovan-mmusic-183-00.txt Matt Cannon 4 MCI Worldcom 5 Henning Schulzrinne 6 Columbia University 7 June, 1999 Jonathan Rosenberg 8 Expires: December, 1999 Bell Laboratories 10 SIP 183 Session Progress Message 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference mate- 24 rial or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a proposed extension of the Session Initia- 35 tion Protocol. This extension would add the 183 Session Progress 36 response message. 38 The introduction of the 183 informational response message would 39 allow a called user agent to indicate to the calling user agent 40 whether or not the calling user agent should apply local alerting for 41 the session. The existing 180 Ringing message would indicate that 42 the calling user agent has the option of providing local alerting 43 (and generally should). The 183 Session Progress message would indi- 44 cate that the calling user agent should not provide local alerting 45 and should establish a media session to be used by the called user 46 agent to indicate the status of the session setup request as part of 47 the indicated media stream. 49 1 Introduction 51 There are instances, most notably dealing with SIP to PSTN interwork- 52 ing, that necessitate that the SIP called User Agent (UA) be able to 53 suppress local alerting by the SIP calling UA and to set up a prelim- 54 inary media session from the called UA to the calling UA. This would 55 allow the called UA to play back media prior to the full SIP session 56 being set up. This media would be used to report on the status of 57 the session setup request. It could also be used to play music while 58 the session setup is attempted. This would be useful for find-me 59 like services that involve attempting multiple locations for a single 60 setup request. 62 The only method in the current SIP specification that allows the 63 called UA to playback media would be to set up a full SIP session. In 64 PSTN interworking situations (and likely in end-to-end SIP sessions) 65 this will cause a billing relationship to be established between net- 66 works for the session. This causes a problem when the reason for 67 setting up the media session is to indicate a failure in the session 68 setup. 70 This document proposes an extension to the Session Initiation Proto- 71 col (SIP) that introduces this capability. 73 2 PSTN Interworking Issues 75 In the PSTN today there are times when a media (voice) path is set up 76 from the called party to the calling party in order to play a treat- 77 ment (a special tone or announcement). The treatment can range from 78 alerting (ring back) to busy tones to announcements explaining why 79 the call could not be set up. The participants in this call are not 80 charged for the remote treatment portion of the call. 82 This one way voice path is generally set up as part of the processing 83 of the SS#7 ISUP ACM message. 85 The following call flow illustrates call setup using SS7 ISUP in a 86 PSTN network. 88 Originating Terminating 89 Network Network 90 IAM----------------------> 92 <----------------------ACM 94 <========================= 95 One way voice path 97 * <----------------------ANM 99 <========================> 100 Two way voice path 102 REL----------------------> 104 <----------------------RLC 106 * If the originating network is a Local Exchange Carrier and the termi- 107 nating network is an Interexchange Carrier then the LEC will start 108 charging for the call at this point in the call. 110 The following call flow illustrates the setup of a call that does not 111 result in a completed call but does involve a media path being set 112 up. In this case, the terminating network may be playing a busy sig- 113 nal or playing an announcement. The following are examples of 114 announcements that might be played in this scenario: 116 - The number you have dialed is no longer valid. 118 - The wireless subscriber you are calling is not currently reachable. 120 Originating Terminating 121 Network Network 122 IAM----------------------> 124 <----------------------ACM 126 <========================= 127 One way voice path 129 REL----------------------> 131 <----------------------RLC 133 2.1 PSTN to SIP Network Interworking Requirements 135 The following are a subset of the requirements for interworking 136 between a PSTN network and a SIP network. 138 When the SIP network is in the middle of two PSTN networks, it must 139 support the following: 141 - The ingress gateway into the SIP network shall have the ability to 142 determine, based on SIP signaling messages, when to send an ISUP ACM 143 message and when to send an ISUP ANM message. 145 - The SIP network shall have the ability to support fast setup. This 146 occurs when the terminating network does not send an ACM prior to 147 sending an ANM. 149 - The SIP network shall support the ability to cut through a voice 150 path from the terminating PSTN network to the originating PSTN net- 151 work without the interim SIP network incurring charges from the orig- 152 inating network. 154 The SIP network shall support the ability to place calls to a PSTN 155 network without the egress gateway knowing what type of device the 156 call was originated from. Thus, the egress gateway shall not need to 157 behave differently when the call originates from a PSTN network then 158 when the call originates from a native IP SIP device. 160 The following is an illustration of the two scenarios that must be 161 supported: 163 +-------------+ +---------+ +-------------+ 164 | Originating | +-----+ | SIP | +-----+ | Terminating | 165 | PSTN |-->| IGW |-->| Network |-->| EGW |--->| PSTN | 166 | Network | +-----+ | | +-----+ | Network | 167 +-------------+ +---------+ +-------------+ 169 IGW = Ingress Gateway 170 EGW = Egress Gateway 172 +---------+ +-------------+ 173 | SIP | +-----+ | Terminating | 174 | IP |-->| EGW |--->| PSTN | 175 | Device | +-----+ | Network | 176 +---------+ +-------------+ 178 3.0 Options With Existing SIP Specification 180 The following sections show the results of investigating various 181 options for addressing the above requirements using existing SIP pro- 182 tocol capabilities. In each case, it is shown why the option either 183 cannot address the requirements or has short comings that can be 184 better addressed using the 183 Session Progress message. 186 3.1 100 Trying Mapped to ACM 188 The first option investigated involved mapping the 100 Trying message 189 to the ACM message. 191 The following call flow illustrates this option. 193 Originating Ingress Egress Terminating 194 Network SIP GW SIP GW Network 195 ------------>------------>-----------> 196 IAM INVITE IAM 198 <-----------<------------<------------ 199 ACM 100 Trying ACM 201 <=========== <============ 202 One way voice One way voice 204 The call flow breaks at this point for two reasons. First, at this 205 point in the call flow a one way voice path is needed so that the 206 terminating network can provide session setup status as part of the 207 voice path. The 100 Trying does not cause a voice path cut-through 208 between the ingress and egress gateways. This potentially could be 209 addressed by allowing the 100 Trying to carry SDP information to be 210 used for carrying the preliminary session media. This option is 211 explored in the context of the 180 Ringing message in section 3.3. 213 The use of the 100 Trying also fails because a SIP Proxy Server sit- 214 ting in the signaling path between the ingress gateway and the egress 215 gateway might have generated the 100 Trying message, causing the ACM 216 message to be sent prior to the egress gateway receiving an ACM from 217 the terminating network. 219 3.2 180 Ringing Mapped to ACM 221 The second option investigated was to use a 180 Ringing message to 222 trigger the ACM message at the ingress gateway. 224 This option is illustrated in the following call flow: 226 Originating Ingress Egress Terminating 227 Network SIP GW SIP GW Network 228 ------------>------------>-----------> 229 IAM INVITE IAM 231 <-----------<------------<------------ 232 ACM 180 Ringing ACM 234 <=========== <============ 235 One way voice One way voice 237 This option breaks at this point because a media voice path cannot be 238 cut through at this point for the terminating PSTN network to report 239 on the session progress. This is due to the fact that the egress 240 gateway has not yet communicated its RTP information to the ingress 241 gateway. The next two options attempt to address this issue. 243 3.3 180 With SDP Mapped to ACM 245 The next option investigated involves using the presence of SDP in 246 the 180 Ringing message to indicate that session progress will be 247 communicated by the called user agent using the media stream. In 248 this case, absence of the SDP message body would indicate that local 249 alerting should take place. 251 The following call flow illustrates this option: 253 Originating Ingress Egress Terminating 254 Network SIP GW SIP GW Network 255 ------------>------------>-----------> 256 IAM INVITE IAM 258 <-----------<------------<------------ 259 ACM 180 Ringing ACM 260 One way SDP 262 <============ 263 One way voice path 265 <-----------<------------<------------ 266 ANM 200 OK ANM 267 Two way SDP 269 ------------> 270 ACK 272 <====================================> 273 Two Way Voice Path 275 <-----------<------------<------------ 276 REL BYE REL 278 ------------>------------>-----------> 279 RLC 200 OK RLC 281 Although this option looks promising on first review, it does not 282 give the called user agent the ability to include SDP in the message 283 and rely on the calling user agent (the ingress gateway in this sce- 284 nario) to provide local alerting. As illustrated in [2] there are 285 other reasons that SDP might be included in a 180 Ringing message. 286 Thus the user requiring a coupling of SIP and QOS signaling, which 287 requires inclusion of SDP in the 18x message, could not also request 288 local alerting. 290 3.4 200 OK Mapped to ACM 292 The final option investigated involves setting up a full media ses- 293 sion in the SIP network prior to receiving the ANM from the terminat- 294 ing PSTN network. This involves mapping the 200 OK to the ACM mes- 295 sage at the ingress gateway and having the egress gateway send a re- 296 INVITE upon receipt of the ANM. The ingress gateway would use the 297 re-INVITE to trigger the ANM message. 299 This option is illustrated in the following call flow: 301 Originating Ingress Egress Terminating 302 Network SIP GW SIP GW Network 303 ------------>------------>-----------> 304 IAM INVITE IAM 306 <-----------<------------<------------ 307 ACM 200 OK ACM 308 One way SDP 310 ------------> 311 ACK 313 <============ 314 One way voice path 316 <-----------<------------<------------ 317 ANM INVITE ANM 319 ------------> 320 200 OK 322 <------------ 323 ACK 325 <====================================> 326 Two Way Voice Path 328 <-----------<------------<------------ 329 REL BYE REL 331 ------------>------------>-----------> 332 RLC 200 OK RLC 334 Although this will work in the above scenario, it introduces additional 335 messaging overhead. In addition, as illustrated in the following fast 336 answer call flow, it is at best awkward and may result in clipping off 337 of the beginning of the voice call. 339 Originating Ingress Egress Terminating 340 Network SIP GW SIP GW Network 341 ------------>------------>-----------> 342 IAM INVITE IAM 344 <-----------<------------<------------ 345 ACM 200 OK ANM 346 One way SDP 348 <-----------<------------ 349 ANM INVITE 350 Two way SDP 352 ------------> 353 ACK 355 <----------- 356 200 OK 358 -----------> 359 ACK 361 <====================================> 362 Two Way Voice Path 364 <-----------<------------<------------ 365 REL BYE REL 367 ------------>------------>-----------> 368 RLC 200 OK RLC 370 4 Proposed 183 Session Progress 372 The following session signaling flows show the proposed solution 373 using the 183 Session Progress Message to map to the ISUP ACM message 374 and how the 183 Session Progress message is used for when the call 375 originates from a SIP IP Device. 377 4.1 PSTN to SIP to PSTN Session Using 183 Session Progress 379 The following session signaling flow shows the use of the 183 Session 380 Progress message for a session setup in a SIP based network when the 381 session will be between two PSTN networks. 383 Originating Ingress Egress Terminating 384 Network SIP GW SIP GW Network 385 ------------>------------>-----------> 386 IAM INVITE IAM 388 <-----------<------------<------------ 389 ACM 183 Session ACM 390 Progress 391 One way SDP 393 <============ 394 One way voice path 396 <-----------<------------<------------ 397 ANM 200 OK ANM 398 Two way SDP 400 ------------> 401 ACK 403 <====================================> 404 Two Way Voice Path 406 <-----------<------------<------------ 407 REL BYE REL 409 ------------>------------>-----------> 410 RLC 200 OK RLC 412 4.2 PSTN Fast Answer 414 The following session signaling flow shows the method for handling of 415 the fast answer scenario. Note that in this case the 183 Session 416 Progress message is not used, as the ANM is mapped directly to a 200 417 OK. This meets the requirement that the SIP gateways must be able to 418 differentiate between ACM and ANM messages. 420 Originating Ingress Egress Terminating 421 Network SIP GW SIP GW Network 422 ------------>------------>-----------> 423 IAM INVITE IAM 425 <-----------<------------<------------ 426 ANM 200 OK ANM 427 Two way SDP 429 ------------> 430 ACK 432 <====================================> 433 Two Way Voice Path 435 <-----------<------------<------------ 436 REL BYE REL 438 ------------>------------>-----------> 439 RLC 200 OK RLC 441 4.3 SIP to PSTN Session Using 183 Session Progress 443 The following session signaling flow shows the use of the 183 Session 444 Progress message for a session setup in a SIP based network when the 445 session originates in the SIP network and terminates to a PSTN net- 446 work. 448 Calling Egress Terminating 449 UA SIP GW Network 450 ------------>------------> 451 INVITE IAM 453 <----------- 454 100 Trying 456 <-----------<------------ 457 183 Session ACM 458 Progress 459 One way SDP 461 <======================== 462 One way voice path 464 <-----------<------------ 465 200 OK ANM 467 ------------> 468 ACK 470 <======================== 471 Two Way Voice Path 473 <-----------<------------ 474 BYE REL 476 ------------>------------> 478 200 OK RLC 480 5 Proposed Extensions to the SIP Specification 482 The remainder of the document describes the proposed extensions to 483 the SIP specification. The section number indicates the section of 484 the SIP specification that requires modification. Thus section 5.M.N 485 would include proposed modifications to section M.N of the SIP speci- 486 fication. 488 Absence of a section indicates that no modifications are proposed for 489 that section. 491 5.7 Status Code Definitions 492 5.7.1 Informational 1xx 494 5.7.1.2 180 Ringing 496 The following text is proposed to be added to the description of the 497 180 Ringing message: 499 The calling UA should initiate local alerting (for instance, the 500 playing of a ringing tone or other alerting mechanism) so as to indi- 501 cate the progress of the session setup. 503 5.7.1.5 183 Session Progress 505 The called UA has the need to communicate the status of the session 506 setup attempt as part of a media stream. The calling UA shall estab- 507 lish a media session according to the contents of the session 508 description contained in the 183 message. The calling UA should not 509 apply local alerting that would interfere with the media session 510 information supplied by the called UA. 512 The 183 message SHOULD include enough session description information 513 to allow for a media session between the called UA and the calling 514 UA. 516 Although not strictly required for a one way voice path to be setup 517 between the egress gateway and the ingress gateway, the SDP in the 518 183 has the following benefits: 520 1. The list of audio (or video) codecs is reduced, so the calling 521 gateway need only expect a smaller set. 523 2. The 183 can contain security preconditions in the SDP (if they 524 were in the SDP in the INVITE), so that the calling gateway can per- 525 form appropriate authentication/encryption for each media stream from 526 each egress gateway. 528 3. If any kind of pre-call announcement requires two-way media (per- 529 haps some kind of speech recognition for credit card numbers, or even 530 DTMF too), the SDP in the 183 is needed. 532 5.8 SIP Message Body 534 5.8.1 Body Inclusion 536 The following is proposed rewording of paragraph 2 in Section 8.1 of 537 the SIP specification: 539 For response messages, the request method and the response status 540 code determine the type and interpretation of any message body. All 541 responses MAY include a body. Message bodies for 1xx responses con- 542 tain advisory information about the progress of the request. In 543 addition, message bodies for 1xx responses can contain session 544 descriptions. 2xx responses ... 546 5.10 Behavior of SIP Clients and Servers 548 5.10.1.2 Responses 550 The following is proposed text for inclusion in section 10.1.2 of the 551 SIP specification: 553 183 responses SHALL always be forwarded. 555 5.11 Behavior of SIP User Agents 557 5.11.6. Callee Needs Early Media 559 When the called UA receives and INVITE message that results in the 560 need to report on the status of the media setup through a media 561 stream, the called UA has the option to send a 183 message with a 562 session description to the calling UA. 564 5.11.7 Caller Receives 183 Response 566 When the calling UA receives a 183 response that contains a session 567 description it SHALL setup the associated media session and present 568 any media received from the called UA to the user. 570 5.13 Security Considerations 572 The security considerations for the 183 Session Progress message are 573 the same as for SIP in general. 575 5.16 Examples 577 5.16.9 PSTN to PSTN Session Setup (SIP in the middle) 579 The following call flow illustrates the case where a call is origi- 580 nating from a PSTN network, transiting a SIP network and being deliv- 581 ered to a second PSTN network. In this case, the 183 message is used 582 to trigger the ACM message and results in a one way media session 583 being setup through the SIP network. 585 Originating Ingress Egress Terminating 586 Network SIP GW SIP GW Network 587 ------------>------------>-----------> 588 IAM INVITE IAM 590 <------------ 591 100 Trying 593 <-----------<------------<------------ 595 ACM 183 Session ACM 596 Progress 597 One way SDP 599 <===================================== 600 One way voice path 602 <-----------<------------<------------ 603 ANM 200 OK ANM 605 ------------> 606 ACK 608 <====================================> 609 Two Way Voice Path 611 <-----------<------------<------------ 612 REL BYE REL 614 ------------>------------>-----------> 615 RLC 200 OK RLC 617 5.16.10 SIP User Agent Session Setup to a PSTN Destination 619 Calling Egress Terminating 620 UA SIP GW Network 621 ------------>------------> 622 INVITE IAM 624 <----------- 625 100 Trying 627 <-----------<------------ 628 183 Session ACM 629 Progress 630 One way SDP 632 <======================== 633 One way voice path 635 <-----------<------------ 636 200 OK ANM 638 ------------> 639 ACK 641 <======================== 642 Two Way Voice Path 644 <-----------<------------ 645 BYE REL 647 ------------>------------> 648 200 OK RLC 650 5.A Minimal Implementation 652 5.A.1 Client 654 The following is a suggested addition to Appendix A.1 of the SIP 655 specification: 657 PSTN Interworking: If a client wishes to interwork properly with PSTN 658 works then it MUST support the 183 Session Progress message. 660 6 References 662 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: Ses- 663 sion Initiation Protocol", RFC 2543, March 1999. 665 [2] J. Rosenberg, H. Schulzrinne, S. Donovan, "Establishing QoS and 666 Security Preconditions for SDP Sessions", draft-rosenberg-mmusic- 667 sipqos-00.txt, To be published, Work in Progress. 669 [3] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses 670 in SIP", draft-ietf-mmusic-sip-100rel-01.txt, May 21, 1999, Work in 671 Progress. 673 [4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with 674 Minimal Control ", RFC 1890, January, 1996. 676 6 Authors' Addresses 678 Steve Donovan 679 MCI Worldcom 680 1493/678 681 901 International Parkway 682 Richardson, Texas 75081 683 Email: steven.r.donovan@mci.com 685 John Hearty 686 MCI Worldcom 687 9514/107 688 2400 North Glenville Drive 689 Richardson, TX 75082 690 Email: john.h.hearty@mci.com 692 Mathew Cannon 693 MCI Worldcom 694 9514/107 695 2400 North Glenville Drive 696 Richardson, TX 75082 697 Email: matt.cannon@wcom.com 699 Henning Schulzrinne 700 Dept. of Computer Science 701 Columbia University 702 1214 Amsterdam Avenue 703 New York, NY 10027 704 USA 705 Email: schulzrinne@cs.columbia.edu 707 Jonathan Rosenberg 708 Lucent Technologies, Bell Laboratories 709 Rm. 4C-526 710 101 Crawfords Corner Road 711 Holmdel, NJ 07733 712 USA 713 Email: jdrosen@bell-labs.com