idnits 2.17.1 draft-roach-mmusic-sip-provisional-media-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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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 46 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 122: '...onse, the client MUST immediately ceas...' RFC 2119 keyword, line 127: '... contain no session description SHOULD...' RFC 2119 keyword, line 133: '... temporary media MUST be discontinued ...' RFC 2119 keyword, line 149: '... status. It SHOULD NOT, however, b...' RFC 2119 keyword, line 153: '... implementors SHOULD include a text...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: N/A', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (January 2000) is 8866 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Adam Roach 2 Internet Draft Ericsson Inc. 3 Category: N/A June 1999 4 Expires January 2000 5 7 Provisional SIP Responses with Media 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To view the entire list of current Internet-Drafts, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 34 (Northern Europe), ftp.nis.garr.it (Southern Europe), 35 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 This document describes an extension of the SIP protocol which 41 allows transit of SDP in provisional INVITE responses, so that 42 media may be transferred before a final connection is 43 established. 45 1. Introduction 47 When SIP ( ref [1] ) is used for inter-operation with standard 48 telephony networks, several situations arise when it is useful to 49 allow temporary media sessions to be established before an INVITE 50 request has finished. While these have certain useful 51 applications in interaction with "standard" SIP clients (e.g. PC 52 software applications), they provide the greatest benefit when 53 used between gateways to a standard telephony network. 55 The usefulness of being able to send media before a final 56 connection is established can be demonstrated for the existing 57 100 class INVITE responses: 59 100 Trying -- Some localities provide a call progressing tone 60 between dialing and ringing (known as a "comfort tone") under 61 certain circumstances. 63 180 Ringing -- Public network telephony users are accustomed to 64 hearing a remotely generated ringtone when placing a call. 65 For example, when dialing a British destination from the 66 U.S., users expect to hear a British ringtone, not a U.S. 67 one. Additionally, this allows users to hear a "caller 68 waiting tone" when applicable (see ref [4] ). 70 181 Call is being Forwarded -- PBX systems will often provide a 71 voice announcement or tone indicating that a call is being 72 forwarded from the dialed number. 74 182 Call is Queued -- PBX systems will typically produce an 75 announcement, hold music, or a tone to indicate to users that 76 they are queued. 78 The simplest method by which this type of media transit can be 79 accomplished is by including session description information for 80 the temporary media streams in these provisional responses. 82 Temporary media streams which do not fit into the above 83 categories can be sent in a "183" provisional response; see 84 section 3, "New Provisional 183 Status Code" . 86 2. Format and Usage 88 The format of provisional responses with media sessions is 89 identical to that of 200-class responses to INVITE requests, 90 except as noted in section 4, "Reliability" ; the body will 91 contain a session description (usually SDP; see ref [2] ). 93 2.1. Temporary Media Establishment 95 Under most circumstances, provisional responses used to initiate 96 temporary media will contain SDP which is a subset of the media 97 description presented in the INVITE message (as in normal 200 98 responses). 100 If the original INVITE message contains no media description, the 101 server will generate SDP representing the capabilities it 102 requires for media transmission and include it in the provisional 103 response. The client will include a final SDP in its 104 acknowledgement of receipt (see section 4, "Reliability" ). 106 In both cases, the media streams will be established after the 107 message confirming receipt of the provisional response has been 108 sent (from the client's perspective) or received (from the 109 server's perspective). 111 The designation of media capabilities in a provisional response 112 has no implications on the capabilities of any subsequent 113 temporary connections or the final connection. Each media stream 114 is negotiated relative to the session description in the original 115 INVITE request (or lack thereof). 117 2.2. Change of Temporary Media 119 After a temporary media stream has been established, its 120 parameters can be changed by sending further provisional 121 responses which also contain session descriptions. Upon receipt 122 of such a response, the client MUST immediately cease 123 transmission of media relating to the old temporary stream. As 124 before, the new temporary media stream is established after 125 acknowledgement of the provisional response. 127 Provisional responses which contain no session description SHOULD 128 NOT have an effect on any currently established temporary media 129 stream. 131 2.3. Discontinuation of Temporary Media 133 Sending of temporary media MUST be discontinued upon the sending 134 (from the server's perspective) or the receipt (from the client's 135 perspective) of any INVITE final response. 137 A temporary media stream can also be discontinued by sending a 138 provisional response which contains a session description with 139 all media stream port numbers set to zero. 141 3. New Provisional 183 Status Code 143 To allow for transmission of temporary media which does not 144 correspond to the four provisional status codes defined in the 145 SIP RFC ( ref [1] ), this protocol extension defines one 146 additional response code of "183." 148 183 can be used for any arbitrary in-band communication of call 149 status. It SHOULD NOT, however, be used to convey ringing, 150 forwarding, or call queueing situations. 152 No suggested text is provided for the 183 status code; instead, 153 implementors SHOULD include a text representation of the 154 information conveyed by the media stream. In the case of a 155 recorded announcement, this text SHOULD be the text of the 156 announcement. For a tone, this text SHOULD be either the name of 157 the tone as defined in E.182 ( ref [4] ) (e.g. "Payphone 158 Recognition Tone") or a description of the condition the tone is 159 attempting to report (e.g. "The Called Party is a Payphone"). 161 4. Reliability 163 Clients which understand this extension MUST also understand the 164 extension described in "Reliability of Provisional Responses in 165 SIP" ( ref [3] ) and will indicate that they require reliable 166 transmission of provisional responses in Require: and 167 Proxy-Require: headers. 169 If a server requires the ability to deliver provisional media, 170 but the client INVITE does not contain an appropriate Requires: 171 header, the server will respond with a "403 Forbidden" response 172 which contains a "Warning:" header. The value of the warning code 173 will be reserved from the IANA at a later date. The warning 174 header will indicate that reliable responses are required for 175 communication with the server. Clients understanding the warning 176 code SHOULD then automatically re-issue the INVITE request with 177 appropriate headers. 179 5. Media Negotiation Failure for Temporary Media 181 If no acceptable media type is available in the client's INVITE 182 request session description, the server MAY return a "406 Not 183 Acceptable" message; the alternative is to forgo the transmission 184 of provisional media. While it is perhaps a more appropriate 185 error code, "606 Not Acceptable" is not suggested, owing to its 186 properties of terminating any ongoing searches. 188 If the client finds the session description proposed by the 189 server in a provisional response unacceptable, its 190 acknowledgement SHOULD contain a session description with all 191 media stream port numbers set to zero. A server which receives 192 such a message MAY respond with a "406 Not Acceptable" message; 193 the alternative is to forgo the transmission of provisional 194 media. 196 6. Examples 198 Only the relevant headers have been included in the following 199 examples. Notably, the mandatory parameters Call-ID and CSeq are 200 not shown. 202 6.1. Remote Ringtone, Followed by "Queued" Announcement 204 Client to server: 206 INVITE sip:+12145551212@bell.com SIP/2.0 207 RAck: 0 208 To: sip:+12145551212@bell.com 209 From: sip:+15125559876@domain.com 210 Require: org.ietf.sip.reliable-100 211 Proxy-Require: org.ietf.sip.reliable-100 212 Content-Type: application/sdp 214 v=0 215 o=- 929142225 929142225 IN IP4 vgw.domain.com 216 c=IN IP4 vgw.domain.com 217 M=audio 49152 RTP/AVP 0 1 218 a=rtpmap:0 PCMU/8000 219 a=rtpmap:1 1016/8000 221 Server to client: 223 SIP/2.0 180 Ringing 224 RSeq: 1 225 To: sip:+12145551212@bell.com 226 From: sip:+15125559876@domain.com 227 Content-Type: application/sdp 229 v=0 230 o=- 929142942 929142942 IN IP4 media.bell.com 231 c=IN IP4 media.bell.com 232 M=audio 49180 RTP/AVP 0 233 a=rtpmap:0 PCMU/8000 235 Client to server: 237 INVITE sip:+12145551212@bell.com SIP/2.0 238 RAck: 1 239 To: sip:+12145551212@bell.com 240 From: sip:+15125559876@domain.com 241 Require: org.ietf.sip.reliable-100 242 Proxy-Require: org.ietf.sip.reliable-100 244 [Remote ringing tone is played] 246 Server to client: 248 SIP/2.0 182 Call is queued; est. wait is 5 minutes 249 RSeq: 2 250 To: sip:+12145551212@bell.com 251 From: sip:+15125559876@domain.com 252 Content-Type: application/sdp 254 v=0 255 o=- 929143057 929143057 IN IP4 media.bell.com 256 c=IN IP4 media.bell.com 257 M=audio 49180 RTP/AVP 1 258 a=rtpmap:1 1016/8000 260 [Ring tone is discontinued] 262 Client to server: 264 INVITE sip:+12145551212@bell.com SIP/2.0 265 RAck: 2 266 To: sip:+12145551212@bell.com 267 From: sip:+15125559876@domain.com 268 Require: org.ietf.sip.reliable-100 269 Proxy-Require: org.ietf.sip.reliable-100 271 ["Your call is queued" announcement is played, followed by hold 272 music] 274 Server to client: 276 SIP/2.0 200 OK 277 To: sip:+12145551212@bell.com 278 From: sip:+15125559876@domain.com 279 Content-Type: application/sdp 281 v=0 282 o=- 929143373 929143373 IN IP4 vgw.bell.com 283 c=IN IP4 mg.bell.com 284 M=audio 49199 RTP/AVP 1 285 a=rtpmap:1 1016/8000 287 [Hold music is discontinued] 289 Client to server: 291 ACK sip:+12145551212@bell.com SIP/2.0 292 To: sip:+12145551212@bell.com 293 From: sip:+15125559876@domain.com 295 [Final media stream is established] 297 6.2. Remote Announcement: "Call is being forwarded," local ring tone. 299 Client to server: 301 INVITE sip:+12145551212@bell.com SIP/2.0 302 RAck: 0 303 To: sip:+12145551212@bell.com 304 From: sip:+15125559876@domain.com 305 Require: org.ietf.sip.reliable-100 306 Proxy-Require: org.ietf.sip.reliable-100 307 Content-Type: application/sdp 309 v=0 310 o=- 929142225 929142225 IN IP4 vgw.domain.com 311 c=IN IP4 vgw.domain.com 312 M=audio 49152 RTP/AVP 0 1 313 a=rtpmap:0 PCMU/8000 314 a=rtpmap:1 1016/8000 316 Server to client: 318 SIP/2.0 180 Call is being forwarded 319 RSeq: 1 320 To: sip:+12145551212@bell.com 321 From: sip:+15125559876@domain.com 322 Content-Type: application/sdp 324 v=0 325 o=- 929142942 929142942 IN IP4 media.bell.com 326 c=IN IP4 media.bell.com 327 M=audio 49180 RTP/AVP 0 328 a=rtpmap:0 PCMU/8000 330 Client to server: 332 INVITE sip:+12145551212@bell.com SIP/2.0 333 RAck: 1 334 To: sip:+12145551212@bell.com 335 From: sip:+15125559876@domain.com 336 Require: org.ietf.sip.reliable-100 337 Proxy-Require: org.ietf.sip.reliable-100 339 [Announcement plays: "Your call is being forwarded to a phone 340 outside the company's premises. Please wait."] 342 Server to client: 344 SIP/2.0 180 Ringing 345 RSeq: 2 346 To: sip:+12145551212@bell.com 347 From: sip:+15125559876@domain.com 348 Content-Type: application/sdp 350 v=0 351 o=- 929143373 929143373 IN IP4 media.bell.com 352 c=IN IP4 media.bell.com 353 M=audio 0 RTP/AVP 0 355 [Media stream is discontinued. Local ring-tone is generated by 356 the client towards the PSTN user.] 358 Client to server: 360 INVITE sip:+12145551212@bell.com SIP/2.0 361 RAck: 2 362 To: sip:+12145551212@bell.com 363 From: sip:+15125559876@domain.com 364 Require: org.ietf.sip.reliable-100 365 Proxy-Require: org.ietf.sip.reliable-100 367 Server to client: 369 SIP/2.0 200 OK 370 To: sip:+12145551212@bell.com 371 From: sip:+15125559876@domain.com 372 Content-Type: application/sdp 374 v=0 375 o=- 929143373 929143373 IN IP4 vgw.bell.com 376 c=IN IP4 mg.bell.com 377 M=audio 49199 RTP/AVP 1 378 a=rtpmap:1 1016/8000 380 Client to server: 382 ACK sip:+12145551212@bell.com SIP/2.0 383 To: sip:+12145551212@bell.com 384 From: sip:+15125559876@domain.com 386 [Final media stream is established] 388 6.3. Reliable Provisional Responses not specified, but supported 390 Client to server: 392 INVITE sip:+12145551212@bell.com SIP/2.0 393 To: sip:+12145551212@bell.com 394 From: sip:+15125559876@domain.com 395 Content-Type: application/sdp 397 v=0 398 o=- 929142225 929142225 IN IP4 vgw.domain.com 399 c=IN IP4 vgw.domain.com 400 M=audio 49152 RTP/AVP 0 1 401 a=rtpmap:0 PCMU/8000 402 a=rtpmap:1 1016/8000 404 Server to client (the 395 warning code is only an example; an 405 actual number will be reserved from the IANA as this draft 406 progresses): 408 SIP/2.0 403 Forbidden 409 To: sip:+12145551212@bell.com 410 From: sip:+15125559876@domain.com 411 Warning: 395 bell.com "Incompatible Client" 413 Client to server: 415 ACK sip:+12145551212@bell.com SIP/2.0 416 To: sip:+12145551212@bell.com 417 From: sip:+15125559876@domain.com 419 Client to server (no user interaction required): 421 INVITE sip:+12145551212@bell.com SIP/2.0 422 RAck: 0 423 To: sip:+12145551212@bell.com 424 From: sip:+15125559876@domain.com 425 Require: org.ietf.sip.reliable-100 426 Proxy-Require: org.ietf.sip.reliable-100 427 Content-Type: application/sdp 429 v=0 430 o=- 929142225 929142225 IN IP4 vgw.domain.com 431 c=IN IP4 vgw.domain.com 432 M=audio 49152 RTP/AVP 0 1 433 a=rtpmap:0 PCMU/8000 434 a=rtpmap:1 1016/8000 436 Call continues normally from here. 438 6.4. Server Side Media Failure 440 Client to server: 442 INVITE sip:+12145551212@bell.com SIP/2.0 443 RAck: 0 444 To: sip:+12145551212@bell.com 445 From: sip:+15125559876@domain.com 446 Require: org.ietf.sip.reliable-100 447 Proxy-Require: org.ietf.sip.reliable-100 448 Content-Type: application/sdp 450 v=0 451 o=- 929142225 929142225 IN IP4 vgw.domain.com 452 c=IN IP4 vgw.domain.com 453 M=audio 49152 RTP/AVP 0 1 454 a=rtpmap:0 PCMU/8000 455 a=rtpmap:1 1016/8000 457 Server to client: 459 SIP/2.0 406 No codecs match 460 To: sip:+12145551212@bell.com 461 From: sip:+15125559876@domain.com 463 Client to server: 465 ACK sip:+12145551212@bell.com SIP/2.0 466 To: sip:+12145551212@bell.com 467 From: sip:+15125559876@domain.com 469 6.5. Client Side Media Failure 471 Client to server: 473 INVITE sip:+12145551212@bell.com SIP/2.0 474 RAck: 0 475 To: sip:+12145551212@bell.com 476 From: sip:+15125559876@domain.com 477 Require: org.ietf.sip.reliable-100 478 Proxy-Require: org.ietf.sip.reliable-100 480 Server to client: 482 SIP/2.0 180 Ringing 483 RSeq: 1 484 To: sip:+12145551212@bell.com 485 From: sip:+15125559876@domain.com 486 Content-Type: application/sdp 488 v=0 489 o=- 929142942 929142942 IN IP4 media.bell.com 490 c=IN IP4 media.bell.com 491 M=audio 49180 RTP/AVP 0 492 a=rtpmap:0 PCMU/8000 494 Client to server: 496 INVITE sip:+12145551212@bell.com SIP/2.0 497 RAck: 1 498 To: sip:+12145551212@bell.com 499 From: sip:+15125559876@domain.com 500 Require: org.ietf.sip.reliable-100 501 Proxy-Require: org.ietf.sip.reliable-100 502 Content-Type: application/sdp 504 v=0 505 o=- 929144697 929144697 IN IP4 vgw.domain.com 506 c=IN IP4 vgw.domain.com 507 M=audio 0 RTP/AVP 0 509 Server to client: 511 SIP/2.0 406 No codecs match 512 To: sip:+12145551212@bell.com 513 From: sip:+15125559876@domain.com 515 Client to server: 517 ACK sip:+12145551212@bell.com SIP/2.0 518 To: sip:+12145551212@bell.com 519 From: sip:+15125559876@domain.com 521 7. Security Considerations 523 When this extension is used by PSTN gateways, care must be taken 524 that provisional responses with media descriptions are accepted 525 only from trusted nodes in the network. Most gateway 526 implementations will operate such that only final connections 527 will trigger billing (since billing for ringtone or announcements 528 doesn't generally make sense). If provisional media is accepted 529 from arbitrary nodes, a limited level of free service may be 530 stolen by clients which have been programmed to return 531 provisional responses with media description instead of final 532 responses. 534 8. References 536 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 537 Session Initiation Protocol", RFC 2543, IETF; March 1999. 539 [2] M. Handley/V. Jacobson, "SDP: Session Description Protocol", 540 RFC 2327, IETF; April 1998. 542 [3] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional 543 Responses in SIP", Internet Draft 544 , IETF; May 1999. Work 545 in progress. 547 [4] "Application of Tones and Recorded Announcements in Telephone 548 Services", ITU-T Recommendation E.182; 1993 550 9. Acknowledgements 552 I must express my gratitude to John Hearty, Sean Olson, and Eric 553 Havens for their feedback on this document. 555 10. Author's Address 557 Adam Roach 558 Ericsson Inc. 559 Mailstop L-04 560 851 International Pkwy. 561 Richardson, TX 75081 562 USA 563 Phone: +1 972-583-7594 564 Fax: +1 972-669-0154 565 E-Mail: adam.roach@ericsson.com