idnits 2.17.1 draft-ietf-sip-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: ---------------------------------------------------------------------------- ** 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 26 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 28 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 578: '... client MUST immediately cease trans...' RFC 2119 keyword, line 582: '...tain no session description SHOULD NOT...' RFC 2119 keyword, line 587: '... temporary media MUST be discontinued ...' RFC 2119 keyword, line 603: '... call status. It SHOULD NOT, however, ...' RFC 2119 keyword, line 606: '...he response text SHOULD include a text...' (11 more instances...) 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: '4' is defined on line 1104, 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) ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 6 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 MCI Worldcom 3 draft-ietf-sip-183-00.txt Henning Schulzrinne 4 October, 1999 Columbia University 5 Expires: April, 2000 Jonathan Rosenberg 6 Bell Laboratories 7 Matt Cannon 8 BroadBandOffice Inc. 9 Adam Roach 10 Ericsson Inc. 12 SIP 183 Session Progress Message 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference mate- 26 rial or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes a proposed extension to SIP [1]. This exten- 37 sion adds the 183 Session Progress response and a new header to indi- 38 cate why a SDP message body is included in a 18x message. 40 The introduction of the 183 informational response message would 41 allow a called user agent to indicate to the calling user agent 42 whether or not the calling user agent should apply local alerting for 43 the session. The existing 180 Ringing message would indicate that 44 the calling user agent has the option of providing local alerting 45 (and generally should). The 183 Session Progress message would indi- 46 cate that the calling user agent should not provide local alerting. 47 In additionally, the calling user agent may be called on to establish 48 a media session to be used by the called user agent to indicate the 49 status of the session setup request as part of the indicated media 50 stream. The indication of whether or not to play early media to the 51 calling user would be controlled with a new Session header included 52 in the 183 message. 54 1 Introduction 56 There are instances, most notably dealing with SIP to PSTN interwork- 57 ing, that necessitate that the SIP called User Agent (UA) be able to 58 suppress local alerting by the SIP calling UA and to set up a prelim- 59 inary media session from the called UA to the calling UA. This would 60 allow the called UA to play back media prior to the full SIP session 61 being set up. This media would be used to report on the status of 62 the session setup request. It could also be used to play music while 63 the session setup is attempted. This would be useful for find-me 64 like services that involve attempting multiple locations for a single 65 setup request. 67 The only method in the current SIP specification that allows the 68 called UA to playback media is to set up a full SIP session. In PSTN 69 interworking situations (and likely in end-to-end SIP sessions) this 70 will cause a billing relationship to be established between networks 71 for the session. This causes a problem when the reason for setting 72 up the media session is to indicate a failure in the session setup. 74 This document proposes an extension to the Session Initiation Proto- 75 col (SIP) that introduces this capability. 77 2 PSTN Interworking Issues 79 In the PSTN today there are times when a media (voice) path is set up 80 from the called party to the calling party in order to play a treat- 81 ment (a special tone or announcement). The treatment can range from 82 alerting (ring back) to busy tones to announcements explaining why 83 the call could not be set up. The participants in this call are not 84 charged for the remote treatment portion of the call. 86 This one way voice path is generally set up as part of the processing 87 of the SS#7 ISUP ACM message. 88 The following call flow illustrates call setup using SS7 ISUP in a 89 PSTN network. 91 Originating Terminating 92 Network Network 93 IAM----------------------> 95 <----------------------ACM 97 <========================= 98 One way voice path 100 * <----------------------ANM 102 <========================> 103 Two way voice path 105 REL----------------------> 107 <----------------------RLC 109 * If the originating network is a Local Exchange Carrier and the termi- 110 nating network is an Interexchange Carrier then the LEC will start 111 charging for the call at this point in the call. 113 The following call flow illustrates the setup of a call that does not 114 result in a completed call but does involve a media path being set 115 up. In this case, the terminating network may be playing a busy sig- 116 nal or playing an announcement. The following are examples of 117 announcements that might be played in this scenario: 119 - The number you have dialed is no longer valid. 121 - The wireless subscriber you are calling is not currently reachable. 123 Originating Terminating 124 Network Network 125 IAM----------------------> 127 <----------------------ACM 129 <========================= 130 One way voice path 132 REL----------------------> 134 <----------------------RLC 136 2.1 PSTN to SIP Network Interworking Requirements 138 The following are a subset of the requirements for interworking 139 between a PSTN network and a SIP network. 141 When the SIP network is in the middle of two PSTN networks, it must 142 support the following: 144 - The ingress gateway into the SIP network shall have the ability to 145 determine, based on SIP signaling messages, when to send an ISUP ACM 146 message and when to send an ISUP ANM message. 148 - The SIP network shall have the ability to support fast setup. This 149 occurs when the terminating network does not send an ACM prior to 150 sending an ANM. 152 - The SIP network shall support the ability to cut through a voice 153 path from the terminating PSTN network to the originating PSTN net- 154 work without the interim SIP network incurring charges from the orig- 155 inating network. 157 The SIP network shall support the ability to place calls to a PSTN 158 network without the egress gateway knowing what type of device the 159 call was originated from. Thus, the egress gateway shall not need to 160 behave differently when the call originates from a PSTN network then 161 when the call originates from a native IP SIP device. 163 The following is an illustration of the two scenarios that must be 164 supported: 166 +-------------+ +---------+ +-------------+ 167 | Originating | +-----+ | SIP | +-----+ | Terminating | 168 | PSTN |-->| IGW |-->| Network |-->| EGW |--->| PSTN | 169 | Network | +-----+ | | +-----+ | Network | 170 +-------------+ +---------+ +-------------+ 172 IGW = Ingress Gateway 173 EGW = Egress Gateway 175 +---------+ +-------------+ 176 | SIP | +-----+ | Terminating | 177 | IP |-->| EGW |--->| PSTN | 178 | Device | +-----+ | Network | 179 +---------+ +-------------+ 181 2.2 Solution Options With Existing SIP Specification 183 The following sections show the results of investigating various 184 options for addressing the above requirements using existing SIP pro- 185 tocol capabilities. In each case, it is shown why the option either 186 cannot address the requirements or has short comings that can be bet- 187 ter addressed using the 183 Session Progress message. 189 2.2.1 100 Trying Mapped to ACM 191 The first option investigated involved mapping the 100 Trying message 192 to the ACM message. 194 The following call flow illustrates this option. 196 Originating Ingress Egress Terminating 197 Network SIP GW SIP GW Network 198 ------------>------------>-----------> 199 IAM INVITE IAM 201 <-----------<------------<------------ 202 ACM 100 Trying ACM 204 <=========== <============ 205 One way voice One way voice 207 The call flow breaks at this point for two reasons. First, at this 208 point in the call flow a one way voice path is needed so that the 209 terminating network can provide session setup status as part of the 210 voice path. The 100 Trying does not cause a voice path cut-through 211 between the ingress and egress gateways. This potentially could be 212 addressed by allowing the 100 Trying to carry SDP information to be 213 used for carrying the preliminary session media. This option is 214 explored in the context of the 180 Ringing message in section 3.3. 216 The use of the 100 Trying also fails because a SIP Proxy Server sit- 217 ting in the signaling path between the ingress gateway and the egress 218 gateway might have generated the 100 Trying message. This would 219 result in the ACM message being sent prior to the egress gateway 220 receiving an ACM from the terminating network. 222 2.2.2 180 Ringing Mapped to ACM 224 The second option investigated was to use a 180 Ringing message to 225 trigger the ACM message at the ingress gateway. 227 This option is illustrated in the following call flow: 229 Originating Ingress Egress Terminating 230 Network SIP GW SIP GW Network 231 ------------>------------>-----------> 232 IAM INVITE IAM 234 <-----------<------------<------------ 235 ACM 180 Ringing ACM 237 <=========== <============ 238 One way voice One way voice 240 This option breaks at this point because a media voice path cannot be 241 cut through at this point for the terminating PSTN network to report 242 on the session progress. This is due to the fact that the egress 243 gateway has not yet communicated its RTP information to the ingress 244 gateway. The next two options attempt to address this issue. 246 2.2.3 180 With SDP Mapped to ACM 248 The next option investigated involves using the presence of SDP in 249 the 180 Ringing message to indicate that session progress will be 250 communicated by the called user agent using the media stream. In 251 this case, absence of the SDP message body would indicate that local 252 alerting should take place. 254 The following call flow illustrates this option: 256 Originating Ingress Egress Terminating 257 Network SIP GW SIP GW Network 258 ------------>------------>-----------> 259 IAM INVITE IAM 261 <-----------<------------<------------ 262 ACM 180 Ringing ACM 263 One way SDP 265 <============ 266 One way voice path 268 <-----------<------------<------------ 269 ANM 200 OK ANM 270 Two way SDP 272 ------------> 273 ACK 275 <====================================> 276 Two Way Voice Path 278 <-----------<------------<------------ 279 REL BYE REL 281 -----------> 282 RLC 283 ------------> 284 200 OK 285 ------------> 286 RLC 288 Although this option looks promising on first review, it does not 289 give the called user agent the ability to include SDP in the message 290 and rely on the calling user agent (the ingress gateway in this sce- 291 nario) to provide local alerting. As illustrated in [2] there are 292 other reasons that SDP might be included in a 180 Ringing message. 293 Thus the user requiring a coupling of SIP and QOS signaling, which 294 requires inclusion of SDP in the 18x message, could not also request 295 local alerting. 297 2.2.4 200 OK Mapped to ACM 299 The final option investigated involves setting up a full media ses- 300 sion in the SIP network prior to receiving the ANM from the terminat- 301 ing PSTN network. This involves mapping the 200 OK to the ACM mes- 302 sage at the ingress gateway and having the egress gateway send a re- 303 INVITE upon receipt of the ANM. The ingress gateway would use the 304 re-INVITE to trigger the ANM message. 306 This option is illustrated in the following call flow: 308 Originating Ingress Egress Terminating 309 Network SIP GW SIP GW Network 310 ------------>------------>-----------> 311 IAM INVITE IAM 313 <-----------<------------<------------ 314 ACM 200 OK ACM 315 One way SDP 317 ------------> 318 ACK 320 <============ 321 One way voice path 323 <-----------<------------<------------ 324 ANM INVITE ANM 326 ------------> 327 200 OK 329 <------------ 330 ACK 332 <====================================> 333 Two Way Voice Path 335 <-----------<------------<------------ 336 REL BYE REL 338 -----------> 339 RLC 340 ------------> 341 200 OK 342 ------------> 343 RLC 345 Although this will work in the above scenario, it introduces additional 346 messaging overhead. In addition, as illustrated in the following fast 347 answer call flow, it is at best awkward and may result in clipping off 348 of the beginning of the voice call. 350 Originating Ingress Egress Terminating 351 Network SIP GW SIP GW Network 352 ------------>------------>-----------> 353 IAM INVITE IAM 355 <-----------<------------<------------ 356 ACM 200 OK ANM 357 One way SDP 359 <-----------<------------ 360 ANM INVITE 361 Two way SDP 363 ------------> 364 ACK 366 <----------- 367 200 OK 369 -----------> 370 ACK 372 <====================================> 373 Two Way Voice Path 375 <-----------<------------<------------ 376 REL BYE REL 378 -----------> 379 RLC 380 ------------> 381 200 OK 382 ------------> 383 RLC 385 2.3 Proposed 183 Session Progress 387 The following session signaling flows show the proposed solution 388 using the 183 Session Progress Message to map to the ISUP ACM message 389 and how the 183 Session Progress message is used for when the call 390 originates from a SIP IP Device. 392 2.3.1 PSTN to SIP to PSTN Session Using 183 Session Progress 394 The following session signaling flow shows the use of the 183 Session 395 Progress message for a session setup in a SIP based network when the 396 session will be between two PSTN networks. 398 Originating Ingress Egress Terminating 399 Network SIP GW SIP GW Network 400 ------------>------------>-----------> 401 IAM INVITE IAM 403 <-----------<------------<------------ 404 ACM 183 Session ACM 405 Progress 406 One way SDP 408 <============ 409 One way voice path 411 <-----------<------------<------------ 412 ANM 200 OK ANM 413 Two way SDP 415 ------------> 416 ACK 418 <====================================> 419 Two Way Voice Path 421 <-----------<------------<------------ 422 REL BYE REL 424 -----------> 425 RLC 426 ------------> 427 200 OK 428 ------------> 429 RLC 431 2.3.2 PSTN Fast Answer 433 The following session signaling flow shows the method for handling of 434 the fast answer scenario. Note that in this case the 183 Session 435 Progress message is not used, as the ANM is mapped directly to a 200 436 OK. This meets the requirement that the SIP gateways must be able to 437 differentiate between ACM and ANM messages. 439 Originating Ingress Egress Terminating 440 Network SIP GW SIP GW Network 441 ------------>------------>-----------> 442 IAM INVITE IAM 444 <-----------<------------<------------ 445 ANM 200 OK ANM 446 Two way SDP 448 ------------> 449 ACK 451 <====================================> 452 Two Way Voice Path 454 <-----------<------------<------------ 455 REL BYE REL 457 -----------> 458 RLC 459 ------------> 460 200 OK 461 ------------> 462 RLC 464 2.3.3 SIP to PSTN Session Using 183 Session Progress 466 The following session signaling flow shows the use of the 183 Session 467 Progress message for a session setup in a SIP based network when the 468 session originates in the SIP network and terminates to a PSTN net- 469 work. 471 Calling Egress Terminating 472 UA SIP GW Network 473 ------------>------------> 474 INVITE IAM 476 <----------- 477 100 Trying 479 <-----------<------------ 480 183 Session ACM 481 Progress 482 One way SDP 484 <======================== 485 One way voice path 487 <-----------<------------ 488 200 OK ANM 490 ------------> 491 ACK 493 <======================== 494 Two Way Voice Path 496 <-----------<------------ 497 BYE REL 499 ------------> 500 RLC 501 ------------> 502 200 OK 504 3 Session Description Message Bodies in 18x Responses 506 The previous sections illustrated how the 183 response can be used to 507 communicate the need for the calling user agent to receive media 508 prior to receiving a final response from the called user agent. 510 There are other reasons for including SDP message bodies in an 18x 511 message. 513 One possible use is to use the SDP to establish security and/or QoS 514 relationship between the called and calling user agents, as 515 documented in [2]. 517 As a result, it is necessary to communicate to the calling user agent 518 why the SDP was included in the 18x message. The following section 519 describes the Session header, which will be used for this purpose. 521 3.1 Session Header in 18x Message Bodies 523 The Session header will be used to communicate to the calling user 524 agent the reason for a SDP message body being included in an 18x mes- 525 sage. The valid values for the Session header are Media, QoS and 526 Security. Multiple of these values can be indicated. 528 A value of Media indicates that the SDP should be used for establish- 529 ing of an early media session. The early media session will gener- 530 ally be used to communicate the status of the session but could also 531 be used for other reasons. For instance, it could be used to play 532 music while the calling user is being alerted. 534 A value of QoS indicates that the SDP should be used for establishing 535 of a QoS relationship between the calling and called user agents. 536 This could involve the user agents requesting QoS resources using 537 RSVP or some other signaling mechanism. 539 A value of Security indicates that the SDP should be used for estab- 540 lishing of a security relationship between the calling and called 541 user agents. This could be an IPSEC based relationship, for example. 543 4 Format and Usage 545 The format of provisional responses with media session descriptions 546 is identical to that of 200-class responses to INVITE requests, 547 except as noted in section 7, "Reliability"; the body will contain a 548 session description (usually SDP; see ref [5]). 550 4.1. Temporary Media Establishment 552 Under most circumstances, provisional responses used to initiate tem- 553 porary media will contain SDP that is a subset of the media descrip- 554 tion presented in the INVITE message (as in normal 200 responses). 556 If the original INVITE message contains no media description, the 557 server will generate SDP representing the capabilities it requires 558 for media transmission and include it in the provisional response. 559 The client will include a final SDP in its acknowledgement of receipt 560 (see section 4, "Reliability" ). 562 In both cases, the media streams will be established after the mes- 563 sage confirming receipt of the provisional response has been sent 564 (from the client's perspective) or received (from the server's per- 565 spective). 567 The designation of media capabilities in a provisional response has 568 no implications on the capabilities of any subsequent temporary con- 569 nections or the final connection. Each media stream is negotiated 570 relative to the session description in the original INVITE request 571 (or lack thereof). 573 4.2. Change of Temporary Media 575 After a temporary media stream has been established, its parameters 576 can be changed by sending further provisional responses that also 577 contain session descriptions. Upon receipt of such a response, the 578 client MUST immediately cease transmission of media relating to the 579 old temporary stream. As before, the new temporary media stream is 580 established after acknowledgement of the provisional response. 582 Provisional responses which contain no session description SHOULD NOT 583 have an effect on any currently established temporary media stream. 585 4.3. Discontinuation of Temporary Media 587 Sending of temporary media MUST be discontinued upon the sending 588 (from the server's perspective) or the receipt (from the client's 589 perspective) of any INVITE final response. 591 Sending a provisional response that contains a session description 592 with all media stream port numbers set to zero can also discontinue a 593 temporary media stream. 595 4.4. New Provisional 183 Status Code 597 To allow for transmission of temporary media which does not corre- 598 spond to the four provisional status codes defined in the SIP RFC 599 (ref [1]), this protocol extension defines one additional response 600 code of "183 Session Progress." 602 The 183 Session Progress response can be used for any arbitrary in- 603 band communication of call status. It SHOULD NOT, however, be used to 604 convey ringing, forwarding, or call queueing situations. 606 When applicable, the response text SHOULD include a text representa- 607 tion of the information conveyed by the media stream. In the case of 608 a recorded announcement, this text SHOULD be the text of the 609 announcement. For a tone, this text SHOULD be either the name of the 610 tone as defined in E.182 (ref [6]) (e.g. "Payphone Recognition Tone") 611 or a description of the condition the tone is attempting to report 612 (e.g. "The Called Party is a Payphone"). 614 4.5 Reliability 616 Clients which understand this extension SHOULD also understand the 617 extension described in "Reliability of Provisional Responses in SIP" 618 (ref [3]) and indicate that they require reliable transmission of 619 provisional responses in Require: and Proxy-Require: headers. 621 4.6 Media Negotiation Failure for Temporary Media 623 If no acceptable media type is available in the client's INVITE 624 request session description, the server MAY return a "406 Not Accept- 625 able" message; the alternative is to forgo the transmission of provi- 626 sional media. While it is perhaps a more appropriate error code, "606 627 Not Acceptable" is not suggested, owing to its properties of termi- 628 nating any ongoing searches. 630 If the client finds the session description proposed by the server in 631 a provisional response unacceptable, its acknowledgement SHOULD con- 632 tain a session description with all media stream port numbers set to 633 zero. A server which receives such a message MAY respond with a "406 634 Not Acceptable" message; the alternative is to forgo the transmission 635 of provisional media. 637 4.7 Issues 639 There are situations when the called user agent (the UAS) requires 640 the support of the mechanisms defined in this document and does not 641 know through the INVITE message whether the calling user agent (the 642 UAC) supports the extension. There is currently no method for the 643 UAS to communicate to the UAC the required capabilities required to 644 properly setup the session. 646 This is a general problem with the SIP protocol that should be fixed 647 in an upcoming version. The mechanisms established for the SIP pro- 648 tocol will be used to indicate a need for this extension. 650 5 Proposed Extensions to the SIP Specification 652 The remainder of the document describes the proposed extensions to 653 the SIP specification. The section number indicates the section of 654 the SIP specification that requires modification. Thus section 5.M.N 655 would include proposed modifications to section M.N of the SIP speci- 656 fication. 658 Absence of a section indicates that no modifications are proposed for 659 that section. 661 5.5.1.1 Status Codes and Reason Phrases 663 The following is the updated Figure 5: 665 Informational = "100" ; Trying 666 | "180" ; Ringing 667 | "181" ; Call is Being Forwarded 668 | "182" ; Queued 669 | "183" ; Session Progress 670 Success = "200" ; OK 672 Figure 5: Informational and Success codes 674 5.6 Header Field Definitions 676 The following needs to be added to Table 5 678 where enc. e-e ACK BYE CAN INV OPT REG 679 -------------------------------------------------------------- 680 Session 18x e - - - - - - 682 5.6.43 Session 684 The session header is used in 18x response messages to communicate to 685 the UAC the purpose of the session description message body included 686 in response message. 688 The valid values are Media, QoS and Security. 690 A value of Media indicates that the SDP should be used for establish- 691 ing of an early media session. The early media session will gener- 692 ally be used to communicate the status of the session but could also 693 be used for other reasons. For instance, it could be used to play 694 music while the calling user is being alerted. 696 A value of QoS indicates that the SDP should be used for establishing 697 of a QoS relationship between the calling and called user agents. 698 This could involve the user agents requesting QoS resources using 699 RSVP or some other signaling mechanism. 701 A value of Security indicates that the SDP should be used for estab- 702 lishing of a security relationship between the calling and called 703 user agents. This could be an IPSEC based relationship, for example. 705 See [2] for details on the handling of the QoS and Security values. 707 Session = "Session" ":" 1#( "Media" | "QoS" | "Security" ) 709 5.7 Status Code Definitions 711 5.7.1 Informational 1xx 713 5.7.1.2 180 Ringing 714 The following text is proposed to be added to the description of the 715 180 Ringing message: 717 The calling UA should initiate local alerting (for instance, the 718 playing of a ringing tone or other alerting mechanism) so as to indi- 719 cate the progress of the session setup. 721 5.7.1.5 183 Session Progress 723 The called UA may have the need to communicate session progress with- 724 out the indication that the called user is being alerted. 726 The calling UA should not apply local alerting upon receipt of the 727 183 Session Progress Response. 729 The 183 Session Progress may have been sent to communicate the status 730 of the session setup attempt as part of a media stream. The called 731 user agent will indicate this by including the Session header with a 732 value of media. 734 In this case, the calling UA shall establish a media session accord- 735 ing to the contents of the session description contained in the 183 736 message. The calling UA should not apply local alerting that would 737 interfere with the media session information supplied by the called 738 UA. 740 The 183 message SHOULD include enough session description information 741 to allow for a media session between the called UA and the calling 742 UA. 744 Although not strictly required for a one way voice path to be setup 745 between the egress gateway and the ingress gateway, the SDP in the 746 183 has the following benefits: 748 1. The list of audio (or video) codecs is reduced, so the calling 749 gateway need only expect a smaller set. 751 2. The 183 can contain security preconditions in the SDP (if they 752 were in the SDP in the INVITE), so that the calling gateway can per- 753 form appropriate authentication/encryption for each media stream from 754 each egress gateway. 756 3. If any kind of pre-call announcement requires two-way media (per- 757 haps some kind of speech recognition for credit card numbers, or even 758 DTMF too), the SDP in the 183 is needed. 760 5.8 SIP Message Body 762 5.8.1 Body Inclusion 764 The following is proposed rewording of paragraph 2 in Section 8.1 of 765 the SIP specification: 767 For response messages, the request method and the response status 768 code determine the type and interpretation of any message body. All 769 responses MAY include a body. Message bodies for 1xx responses con- 770 tain advisory information about the progress of the request. In 771 addition, message bodies for 1xx responses can contain session 772 descriptions. 2xx responses ... 774 5.10 Behavior of SIP Clients and Servers 776 5.10.1.2 Responses 778 The following is proposed text for inclusion in section 10.1.2 of the 779 SIP specification: 781 183 responses SHALL always be forwarded. 783 5.11 Behavior of SIP User Agents 785 5.11.6. Callee Needs Early Media 787 When the called UA receives and INVITE message that results in the 788 need to report on the status of the media setup through a media 789 stream, the called UA has the option to send a 183 message with a 790 session description to the calling UA. 792 5.11.7 Caller Receives 183 Response 794 When the calling UA receives a 183 response that contains a session 795 description and an indication that the session description is for 796 early media, it SHALL setup the associated media session and present 797 any media received from the called UA to the user. 799 5.13 Security Considerations 801 The security considerations for the 183 Session Progress message are 802 the same as for SIP in general. 804 5.16 Examples 806 5.16.9 PSTN to PSTN Session Setup (SIP in the middle) 808 The following call flow illustrates the case where a call is origi- 809 nating from a PSTN network, transiting a SIP network and being deliv- 810 ered to a second PSTN network. In this case, the 183 message is used 811 to trigger the ACM message and results in a one way media session 812 being setup through the SIP network. 814 Originating Ingress Egress Terminating 815 Network SIP GW SIP GW Network 816 ------------>------------>-----------> 817 IAM INVITE IAM 819 <------------ 820 100 Trying 822 <-----------<------------<------------ 824 ACM 183 Session ACM 825 Progress 826 SESSION: Media 827 One way SDP 829 <===================================== 830 One way voice path 832 <-----------<------------<------------ 833 ANM 200 OK ANM 835 ------------> 836 ACK 838 <====================================> 839 Two Way Voice Path 841 <-----------<------------<------------ 842 REL BYE REL 844 -----------> 845 RLC 846 ------------> 847 200 OK 848 ------------> 849 RLC 851 5.16.10 SIP User Agent Session Setup to a PSTN Destination 853 Calling Egress Terminating 854 UA SIP GW Network 855 ------------>------------> 856 INVITE IAM 858 <----------- 859 100 Trying 861 <-----------<------------ 862 183 Session ACM 863 Progress 864 Session: Media 865 One way SDP 867 <======================== 868 One way voice path 870 <-----------<------------ 871 200 OK ANM 873 ------------> 874 ACK 876 <======================== 877 Two Way Voice Path 879 <-----------<------------ 880 BYE REL 882 ------------> 883 RLC 884 ------------> 885 200 OK 887 5.A Minimal Implementation 889 5.A.1 Client 891 The following is a suggested addition to Appendix A.1 of the SIP 892 specification: 894 PSTN Interworking: If a client wishes to interwork properly with PSTN 895 networks then it MUST support the 183 Session Progress message. 897 6 Further Examples 899 Only the relevant headers have been included in the following exam- 900 ples. Notably, the mandatory parameters Call-ID and CSeq are not 901 shown. 903 6.1. Remote Ringtone, Followed by "Queued" Announcement 905 Client to server: 907 INVITE sip:+12145551212@bell.com SIP/2.0 908 RAck: 0 909 To: sip:+12145551212@bell.com 910 From: sip:+15125559876@domain.com 911 Require: org.ietf.sip.reliable-100 912 Proxy-Require: org.ietf.sip.reliable-100 913 Content-Type: application/sdp 915 v=0 916 o=- 929142225 929142225 IN IP4 vgw.domain.com 917 c=IN IP4 vgw.domain.com 918 M=audio 49152 RTP/AVP 0 1 919 a=rtpmap:0 PCMU/8000 920 a=rtpmap:1 1016/8000 922 Server to client: 924 SIP/2.0 180 Ringing 925 RSeq: 1 926 To: sip:+12145551212@bell.com 927 From: sip:+15125559876@domain.com 928 Session: Media 929 Content-Type: application/sdp 931 v=0 932 o=- 929142942 929142942 IN IP4 media.bell.com 933 c=IN IP4 media.bell.com 934 M=audio 49180 RTP/AVP 0 935 a=rtpmap:0 PCMU/8000 937 Client to server: 939 INVITE sip:+12145551212@bell.com SIP/2.0 940 RAck: 1 941 To: sip:+12145551212@bell.com 942 From: sip:+15125559876@domain.com 943 Require: org.ietf.sip.reliable-100 944 Proxy-Require: org.ietf.sip.reliable-100 946 [Remote ringing tone is played] 947 Server to client: 949 SIP/2.0 182 Call is queued; est. wait is 5 minutes 950 RSeq: 2 951 To: sip:+12145551212@bell.com 952 From: sip:+15125559876@domain.com 953 Session: Media 954 Content-Type: application/sdp 956 v=0 957 o=- 929143057 929143057 IN IP4 media.bell.com 958 c=IN IP4 media.bell.com 959 M=audio 49180 RTP/AVP 1 960 a=rtpmap:1 1016/8000 962 [Ring tone is discontinued] 964 Client to server: 966 INVITE sip:+12145551212@bell.com SIP/2.0 967 RAck: 2 968 To: sip:+12145551212@bell.com 969 From: sip:+15125559876@domain.com 970 Require: org.ietf.sip.reliable-100 971 Proxy-Require: org.ietf.sip.reliable-100 973 ["Your call is queued" announcement is played, followed by hold 974 music] 976 Server to client: 978 SIP/2.0 200 OK 979 To: sip:+12145551212@bell.com 980 From: sip:+15125559876@domain.com 981 Content-Type: application/sdp 983 v=0 984 o=- 929143373 929143373 IN IP4 vgw.bell.com 985 c=IN IP4 mg.bell.com 986 M=audio 49199 RTP/AVP 1 987 a=rtpmap:1 1016/8000 989 [Hold music is discontinued] 990 Client to server: 992 ACK sip:+12145551212@bell.com SIP/2.0 993 To: sip:+12145551212@bell.com 994 From: sip:+15125559876@domain.com 996 [Final media stream is established] 998 6.2. Remote Announcement: "Call is being forwarded," local ring tone. 1000 Client to server: 1002 INVITE sip:+12145551212@bell.com SIP/2.0 1003 RAck: 0 1004 To: sip:+12145551212@bell.com 1005 From: sip:+15125559876@domain.com 1006 Require: org.ietf.sip.reliable-100 1007 Proxy-Require: org.ietf.sip.reliable-100 1008 Content-Type: application/sdp 1010 v=0 1011 o=- 929142225 929142225 IN IP4 vgw.domain.com 1012 c=IN IP4 vgw.domain.com 1013 M=audio 49152 RTP/AVP 0 1 1014 a=rtpmap:0 PCMU/8000 1015 a=rtpmap:1 1016/8000 1017 Server to client: 1019 SIP/2.0 180 Call is being forwarded 1020 RSeq: 1 1021 To: sip:+12145551212@bell.com 1022 From: sip:+15125559876@domain.com 1023 Session: Media 1024 Content-Type: application/sdp 1026 v=0 1027 o=- 929142942 929142942 IN IP4 media.bell.com 1028 c=IN IP4 media.bell.com 1029 M=audio 49180 RTP/AVP 0 1030 a=rtpmap:0 PCMU/8000 1032 Client to server: 1034 INVITE sip:+12145551212@bell.com SIP/2.0 1035 RAck: 1 1036 To: sip:+12145551212@bell.com 1037 From: sip:+15125559876@domain.com 1038 Require: org.ietf.sip.reliable-100 1039 Proxy-Require: org.ietf.sip.reliable-100 1041 [Announcement plays: "Your call is being forwarded to a phone 1042 outside the company's premises. Please wait."] 1044 Server to client: 1046 SIP/2.0 180 Ringing 1047 RSeq: 2 1048 To: sip:+12145551212@bell.com 1049 From: sip:+15125559876@domain.com 1050 Session: Media 1051 Content-Type: application/sdp 1053 v=0 1054 o=- 929143373 929143373 IN IP4 media.bell.com 1055 c=IN IP4 media.bell.com 1056 M=audio 0 RTP/AVP 0 1058 [Media stream is discontinued. Local ring-tone is generated by 1059 the client towards the PSTN user.] 1061 Client to server: 1063 INVITE sip:+12145551212@bell.com SIP/2.0 1064 RAck: 2 1065 To: sip:+12145551212@bell.com 1066 From: sip:+15125559876@domain.com 1067 Require: org.ietf.sip.reliable-100 1068 Proxy-Require: org.ietf.sip.reliable-100 1070 Server to client: 1072 SIP/2.0 200 OK 1073 To: sip:+12145551212@bell.com 1074 From: sip:+15125559876@domain.com 1075 Content-Type: application/sdp 1077 v=0 1078 o=- 929143373 929143373 IN IP4 vgw.bell.com 1079 c=IN IP4 mg.bell.com 1080 M=audio 49199 RTP/AVP 1 1081 a=rtpmap:1 1016/8000 1083 Client to server: 1085 ACK sip:+12145551212@bell.com SIP/2.0 1086 To: sip:+12145551212@bell.com 1087 From: sip:+15125559876@domain.com 1089 [Final media stream is established] 1091 7 References 1093 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: Ses- 1094 sion Initiation Protocol", RFC 2543, March 1999. 1096 [2] J. Rosenberg, H. Schulzrinne, S. Donovan, "Establishing QoS and 1097 Security Preconditions for SDP Sessions", draft-rosenberg-mmusic- 1098 sipqos-00.txt, To be published, Work in Progress. 1100 [3] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses 1101 in SIP", draft-ietf-mmusic-sip-100rel-01.txt, May 21, 1999, Work in 1102 Progress. 1104 [4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with 1105 Minimal Control ", RFC 1890, January, 1996. 1107 [5] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC 1108 2327, April 1998. 1110 [6] "Application of Tones and Recorded Announcements in Telephone Ser- 1111 vices", ITU-T Recommendation E.182; 1993. 1113 8 Authors' Addresses 1115 Steve Donovan 1116 MCI Worldcom 1117 1493/678 1118 901 International Parkway 1119 Richardson, Texas 75081 1120 Email: steven.r.donovan@wcom.com 1122 Matthew Cannon 1123 BroadBandOffice Inc. 1124 2070 Chain Bridge Road Suite G-99 1125 Vienna VA, 22182 1126 USA 1127 Email: mcannon@broadbandoffice.net 1129 Henning Schulzrinne 1130 Dept. of Computer Science 1131 Columbia University 1132 1214 Amsterdam Avenue 1133 New York, NY 10027 1134 USA 1135 Email: schulzrinne@cs.columbia.edu 1137 Jonathan Rosenberg 1138 Lucent Technologies, Bell Laboratories 1139 Rm. 4C-526 1140 101 Crawfords Corner Road 1141 Holmdel, NJ 07733 1142 USA 1143 Email: jdrosen@bell-labs.com 1145 Adam Roach 1146 Ericsson Inc. 1147 Mailstop L-04 1148 851 International Pkwy. 1149 Richardson, TX 75081 1150 USA 1151 Phone: +1 972-583-7594 1152 Fax: +1 972-669-0154 1153 E-Mail: adam.roach@ericsson.com