idnits 2.17.1 draft-ietf-mmusic-rtsp-announce-01.txt: -(331): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 528. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 534), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 546 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 14 instances of too long lines in the document, the longest one being 6 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 151: '... include "CSeq" header. It MAY include...' RFC 2119 keyword, line 159: '...ANNOUNCE request MAY include entity bo...' RFC 2119 keyword, line 160: '... MUST follow the rules for entity bo...' RFC 2119 keyword, line 163: '...announcement, the actual SDP SHOULD be...' RFC 2119 keyword, line 165: '... the entity body MAY contain "text/par...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 193 has weird spacing: '...oken is defin...' == Line 378 has weird spacing: '...chanism to si...' -- 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: 'ABNF' is defined on line 481, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Thomas M. Zeng 2 PacketVideo Network Solutions 3 P. Greg Sherwood 4 Internet-Draft PacketVideo Corp. 5 Expires: Aug. 6, 2005 Feb 7,2005 7 RTSP Announce Method 8 draft-ietf-mmusic-rtsp-announce-01 10 Status of this Memo 12 By submitting this Internet-Draft, I (we) certify that any 13 applicable patent or other IPR claims of which I am (we are) aware 14 have been disclosed, and any of which I (we) become aware will be 15 disclosed, in accordance with RFC 3668. 17 By submitting this Internet-Draft, I (we) accept the provisions of 18 Section 3 of RFC 3667 (BCP 78). 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsolete by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is an individual submission to the IETF. Comments 37 should be directed to the authors. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 44 Changes since the last revision: 45 The only change is the update of dates in order to prevent the 46 draft from expiring. 48 This memo describes an extension RTSP request, ANNOUNCE, which 49 extends the core RTSP protocol [RTSP_NEW] to allow one end to 50 push to the other end various types of information by RTSP 51 means. 53 This RTSP extension is identified by a feature tag, "method.announce", 54 and supports capability exchange via the feature-tag framework 55 as detailed in [RTSP_NEW]. 57 Examples of information in ANNOUNCE requests include session 58 descriptions and end of stream events. 60 The receiver of the ANNOUNCE request is expected to reply with 61 200 OK response. 63 1. Motivation 65 In RFC2326, ANNOUNCE is part of the RTSP protocol. In the updated 66 core RTSP protocol [RTSP_NEW], however, ANNOUNCE method has been 67 removed from the core RTSP protocol because, for one, ANNOUNCE is 68 not required for basic RTSP playback, for the other, ANNOUNCE had 69 a lack of implementation at the time when [RTSP_NEW] was being 70 conceived. 72 Nonetheless, there are advanced use cases that require 73 ANNOUNCE method for the server to asynchronously publish session 74 descriptions or other event information. It is clear that such 75 functionality needs to be made available in a way consistent 76 to the extension mechanism in [RTSP_NEW]. 78 The first use case is for either the server or the client to publish 79 a new or updated session description pertinent to a RTSP session URL. 80 Specifically, a multi-unicast live video server utilizing RTSP may 81 want to publish an updated SDP (Session Description Protocol) 82 when a new media track is added to the RTSP session. When client 83 receives the ANNOUNCE request (with an SDP entity body), 84 it has the option to perform SETUP on the newly available media 85 track. 87 The second use case is for the server to signal end of stream 88 event to its client(s). Appendix A presents the reasons why 89 ANNOUNCE is better suited to signal end of stream than the 90 other options using RTCP BYE packet, RTSP TEARDOWN, PAUSE or 91 SET_PARAMETER requests. 93 Given the use cases presented above, we propose to utilize 94 ANNOUNCE method to signal several types of events common to 95 RTSP-based media applications, including 96 session description events and End-Of-Stream events. 98 2. The Definition of ANNOUNCE method 100 This memo defines ANNOUNCE as an extension to the core RTSP 101 protocol [RTSP_NEW]. It presents ANNOUNCE method as a 102 general mechanism for RTSP server to signal to its clients 103 various events including end of stream events or session 104 description updates events. This memo will discuss the general 105 usage of ANNOUNCE, its feature tag, as well as well as a 106 new "Event-Type" header for ANNOUNCE method. 108 [RTSP_NEW] has defined a mechanism to extend the core RTSP 109 protocol. Following that mechanism, a feature tag is used to 110 identify ANNOUCE method as an extension to the core RTSP protocol. 112 The ANNOUNCE method is an RTSP request that can be sent in both 113 directions, either from client to server or server to client. 114 When server intends to send ANNOUNCE to client, it must have the 115 means to reach the client, because the RTSP client is not required 116 to keep a persistent connection with the RTSP server. It is 117 beyond the scope of this memo to define the exact means for server 118 to reach client. It suffices to say that if the client intends to 119 receive server's ANNOUNCE requests, it must keep the RTSP 120 connection open, or inform the server on how to reach it without 121 a persistent RTSP connection. 123 Below is an example RTSP conversation in which an RTSP server 124 announces an end of stream event for a media stream using a 125 non-aggregate URI. The new header, "Event-Type" is formally 126 defined later in this section. 128 S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 129 CSeq: 10 130 Session: 12345678 131 Event-Type: 2000 End-Of-Stream 132 Range: npt=0-200 133 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102 134 Content-Type: text/parameters 135 Content-Length: 49 137 eos-reason: Reached the end of requested range. 139 C->S: RTSP/1.0 200 OK 140 CSeq: 10 141 Session: 12345678 143 2.1 Normative definitions 145 "ANNOUNCE" is an "extension-method" in the ABNF in section 16.2 146 "RTSP Protocol Definitions" in [RTSP_NEW]. 148 The request-URI of an ANNOUNCE request can be either aggregate 149 or non-aggregate URI. 151 An ANNOUNCE request must include "CSeq" header. It MAY include 152 the following optional headers: 154 "Range", 155 "Session", 156 "RTP-Info", 157 "Event-Type" 159 An ANNOUNCE request MAY include entity body, in which case it 160 MUST follow the rules for entity body defined in section 8.2 161 of [RTSP_NEW]. Entity body can be used to convey further details 162 specific to an event type. For instance, if the event type is 163 session description announcement, the actual SDP SHOULD be 164 included in the entity body. If the event type is end-of-stream 165 announcement, the entity body MAY contain "text/parameter" 166 content type that conveys the reason of the end-of-stream 167 event. 169 ANNOUNCE does NOT affect RTSP session state. If a receiver does not 170 understand any of the headers in an ANNOUNCE request, it simply 171 ignores those headers. 173 The next section defines a new RTSP headers for ANNOUNCE method: 174 "Event-Type". 176 2.2 Event-Type Header 178 The Event-Type header is an optional header to identify the type of 179 event pertaining to the ANNOUNCE request. Example event types include 180 session description, end of stream and error. 182 If an ANNOUNCE request does not contain Event-Type header, the 183 Event-Type defaults to "Session-Description", consistent with 184 RFC2326. 186 The Event-Type header is defined in ABNF as: 187 Event-Type = "Event-Type" ":" event-type 188 event-type = event-type-code SP event-type-string 189 event-type-code = 4DIGITS 190 event-type-string = token 192 where: 193 -- token is defined in section 17 of [RTSP_NEW]. 195 The only method that "Event-Type" header applies is the ANNOUNCE method, 196 either from client to server or from server to client. 198 The following pairs fo event-type-code and event-type-string are 199 defined in this memo. 201 Code Message 203 1000 Session-Description 205 2000 End-of-Stream 207 3000 Error 209 If "Event-Type" header is missing, the default is 210 "1000 Session-Description". 211 This is to be consistent with the usage of ANNOUNCE in RFC2326. 213 If "Event-Type" is "2000 End-Of-Stream", the optional RTP-Info header 214 SHOULD contain the "seq" attribute that indicates the sequence number 215 of the next RTP packet. See example in section 4.2. 217 2.3 Limitations on serve to client "ANNOUNCE" requests 219 Server to client ANNOUNCE method is issued only if the server 220 has the means to contact the client when it has information to push. 221 This may not be possible if the RTSP connection between server and 222 client is not persistent. In such cases, the server will 223 simply skip the sending of ANNOUNCE requests. That is to say, the 224 server will not queue up the ANNOUNCE requests to be sent 225 when client eventually connects. Such a queue would unnecessarily 226 complicate server implementations. 228 3. Feature tag 230 The support of the ANNOUNCE method is represented by the feature tag 231 below: 233 method.announce 235 This feature tag applies to both servers and proxies. 237 Implementations claiming "method.announce" feature tag MUST support 238 the new "Event-Type" header defined in previous section. 240 4. Use Cases 242 This section presents several use cases of the ANNOUNCE method. 244 4.1 Client Announcing SDP To Server For Recording 246 This use case is the same as the first RTSP exchange presented in 247 section 14.6 in RFC2326, with capability exchange via 248 OPTIONS method. 250 The conference participant client C asks the media server M to record 251 the audio and video portions of a meeting. After first verifying that 252 the server supports the "ANNOUNCE" feature, the client uses the 253 ANNOUNCE method to provide meta-information about the recorded 254 session to the server. The client omits "Event-Type" 255 because "Event-Type: Session-Description" is the default. 257 C->M: OPTIONS * RTSP/1.0 258 Require: method.announce 259 CSeq: 1 261 M->C: RTSP/1.0 200 OK 262 CSeq: 1 263 Supported: method.announce 264 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, RECORD, \ 265 ANNOUNCE 267 C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 268 CSeq: 90 269 Content-Type: application/sdp 270 Content-Length: 121 272 v=0 273 o=camera1 3080117314 3080118787 IN IP4 195.27.192.36 274 s=IETF Meeting, Munich - 1 275 i=The thirty-ninth IETF meeting will be held in Munich 276 u=http://www.ietf.org/meetings/Munich.html 277 e=IETF Channel 1 278 p=IETF Channel 1 +49-172-2312 451 279 c=IN IP4 224.0.1.11/127 280 t=3080271600 3080703600 281 a=tool:sdr v2.4a6 282 a=type:test 283 m=audio 21010 RTP/AVP 5 284 c=IN IP4 224.0.1.11/127 285 a=ptime:40 286 m=video 61010 RTP/AVP 31 287 c=IN IP4 224.0.1.12/127 289 M->C: RTSP/1.0 200 OK 290 CSeq: 90 292 4.2 Server Announcing End Of Stream 294 In this example, the server announces the End-Of-Stream event to 295 client for one live media stream, because upstream source terminates 296 the stream after 200 seconds. The fact that the stream has played for 297 200 seconds is communicated by the Range header in the ANNOUNCE request. 298 The fact that the server has sent a total of 45102 RTP packets is 299 conveyed in the RTP-Info headers. 301 C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 302 Supported: method.announce 303 CSeq: 10 304 Session: 12345678 305 Range: npt=0-200 307 S->C: RTSP/1.0 200 OK 308 Supported: method.announce 309 CSeq: 10 310 Session: 12345678 311 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=0; rtptime=0 313 S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 314 CSeq: 123 315 Session: 12345678 316 Require: method.announce 317 Event-Type: 2000 End-Of-Stream 318 Range: npt=0-200 319 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102 321 Content-Type: text/parameters 322 Content-Length: 49 324 eos-reason: reached the end of requested range. 326 C->S: RTSP/1.0 200 OK 327 CSeq: 123 328 Session: 12345678 330 The Require header in the above ANNOUNCE request indicates that in 331 order to understand the ��Event-Type�� header the client must support 332 the feature tag in the Require header. In this case the client happens 333 to signal its support in its PLAY request. 335 From the ANNOUNCE request, the client will learn that the server has 336 completed the stream as requested. 338 From the two RTP-Info headers, one in PLAY response, one in 339 ANNOUNCE request, the client can derive the total number 340 of RTP packets that the server has sent. In this example, 341 the server has sent RTP packets 0 to 45101, for a total of 45102 342 packets. The "seq" attribute of the RTP-Info header in ANNOUNCE 343 tells the client that the next RTP packet was going to be packet 344 number 45102 when the stream stops. 346 From the npt field in the Range header, the client can derive 347 the presentation time that this stream has covered. 349 5. Security Considerations 351 Because there is only one new TEXT header, "Event-Type", added by the 352 extension RTSP method, 353 the security considerations outlined in [RTSP_NEW] apply here as well. 355 6. IANA Considerations 357 A new method name, its associated feature tag, and a new header, 358 need to be registered with IANA. 360 -- Method name: ANNOUNCE. See section 2.1 for the relevant definition. 362 -- Feature tag: method.announce. See section 3 for the relevant 363 definition. 365 -- Header name: Event-Type, see section 2.2 for the relevant information. 367 Appendix A: Justification for Using ANNOUNCE to Signal End Of Stream 369 This appendix presents the reasons why we have selected the 370 ANNOUNCE proposal from several proposals to signal end of stream. 371 The competing proposals were based on: 372 1) RTCP BYE packet, 373 2) RTSP TEARDOWN request, 374 3) RTSP PAUSE request, 375 4) SET_PARAMETER request. 377 In the core RTSP protocol [RTSP_NEW], an RTSP client relies on the 378 media transport mechanism to signal end of stream. 380 When the media transport mechanism happens to be RTP over UDP, this 381 is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are 382 some drawbacks with this approach: 384 1. When the server sends an RTCP BYE packet with its SSRC, the 385 server is giving up on 386 the SSRC (see section 8.2 in [RTP_NEW]). The server would be 387 required to 388 switch to a new SSRC on a subsequent PLAY of the same media 389 stream. 390 Since server's SSRC is only communicated in the Transport header 391 of SETUP 392 response, the server would not have an opportunity to send a new 393 value to 394 the player, and the client would have to discover the SSRC from 395 the incoming RTP packets -- a non-trivial process. 397 2. RTCP BYE packet method does not offer a simple, guaranteed 398 method of delivering 399 an end-of-stream announcement, given BYE packet is carried over 400 UDP. 402 3. RTCP BYE packet method does not offer the option to have a single 403 aggregate 404 end-of-stream announcement for all media streams in the RTSP 405 session. 407 4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot 408 send RTCP BYE 409 before leaving the RTP session if it has not already sent at 410 least one RTP or RTCP packet. This is a problem under 411 error conditions. Consider the case 412 where an RTP session has just started (i.e., RTSP PLAY has been 413 successfully acknowledged with an RTSP 200 OK response), and the 414 sender attempts to 415 retrieve media frames from its media source. The media source 416 fails to provide any media frame due to its internal error such 417 as file corruption. The sender should inform its receiver(s) 418 but it cannot send BYE packets. 420 The motivation to solve the above issues is particularly high for 421 unicast-streaming applications that use RTSP over TCP in the control 422 plane, and RTP over UDP in the media transport. 424 There is also the desire to have an EOS (End Of Stream) 425 signaling mechanism 426 for non-RTP delivery. One such delivery is MPEG2 transport streams 427 used in the cable TV environment. In non-IP delivery environments, 428 the transport typically remains allocated even if no media is being 429 delivered. This 430 means that a client cannot watch for the server to close the 431 transport to signal the end of stream. Meanwhile, watching for the 432 incoming media to stop is unreliable. Short 433 timeouts can trigger a false end of media detection if the 434 media flow is temporarily delayed. Long timeouts introduce 435 unacceptable latencies. Clients are unable to distinguish 436 between a normal end of stream and an error condition that 437 resulted in the media delivery stopping. 439 We note that using TEARDOWN from server to client is not 440 appropriate because: 441 1. TEARDOWN is currently not allowed from server to 442 client [RTSP_NEW]; 443 2. Even if TEARDOWN is made available in server to client 444 direction, 445 the definition of TEARDOWN requires that, if the request 446 URI is 447 aggregate, that the session must be de-allocated by the 448 server. 449 There are RTSP applications that use SET_PARAMETER from 450 client to 451 server as the means to report session QoS statistics, but if 452 server uses TEARDOWN on aggregate URL to signal end of stream, 453 the client can no longer use SET_PARAMETER with a 454 session header. 455 3. In general, RTSP, being a client-server protocol, 456 should let client, not server to control session state. But 457 TEARDOWN 458 on aggregate URL will change session from PLAYING state 459 to INIT state. 461 We note that using PAUSE from server to client is not appropriate 462 either, because PAUSE will change the state of the RTSP session. 464 We note that using SET_PARAMETER from server to client will require 465 at least two parameters in the entity body, one for event type that 466 should be set to End-Of-Stream, and the other parameter for the 467 reason of End-Of-Stream. Also using SET_PARAMETER with an SDP 468 entity body to update session descriptoin will not be compatible 469 with RFC2326 where ANNOUNCE was defined for that purpose. 470 Therefore, SET_PARAMETER is not appropriate to convey the 471 announcement of End-Of-Stream and other events. 473 Normative References 475 [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 476 "Real Time Streaming Protocol", 477 draft-ietf-mmusic-rfc2326bis-06.txt 479 [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003 481 [ABNF] RFC2234 "Augmented BNF for Syntax Specifications: ABNF", 482 Nov. 1997 484 Acknowledgement 486 Thanks to Sean Sheedy for suggesting the inclusion of "Range" header 487 and for contributing part of the text in the motivations section. 489 Thanks to Anders Klemets for suggesting the current semantics of the 490 "seq" attribtue in the RTP-Info header. 492 Author Addresses 494 Thomas Zeng 495 PacketVideo Network Solutions 496 9605 Scranton Road, Suite 400 497 San Diego, CA 92121 498 email: zeng@pvnetsolutions.com 500 P. Greg Sherwood 501 PacketVideo Device Solutions. 502 10350 Science Center Dr., Suite 210 503 San Diego, CA 92121 504 email: sherwood@pv.com 506 IPR Notice 508 The IETF takes no position regarding the validity or scope of any 509 Intellectual Property Rights or other rights that might be claimed 510 to pertain to the implementation or use of the technology described 511 in this document or the extent to which any license under such 512 rights might or might not be available; nor does it represent that 513 it has made any independent effort to identify any such rights. 514 Information on the procedures with respect to rights in RFC 515 documents can be found in BCP 78 and BCP 79. 517 Copies of IPR disclosures made to the IETF Secretariat and any 518 assurances of licenses to be made available, or the result of an 519 attempt made to obtain a general license or permission for the use 520 of such proprietary rights by implementers or users of this 521 specification can be obtained from the IETF on-line IPR repository 522 at http://www.ietf.org/ipr. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights that may cover technology that may be required to implement 527 this standard. Please address the information to the IETF at ietf- 528 ipr@ietf.org. 530 Copyright Notice 532 Copyright (C) The Internet Society (2004). This document is subject 533 to the rights, licenses and restrictions contained in BCP 78, and 534 except as set forth therein, the authors retain all their rights. 536 This document and the information contained herein are provided on 537 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 538 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 539 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 540 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 541 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.