idnits 2.17.1 draft-zeng-mmusic-rtsp-announce-01.txt: -(389): 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 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 459), 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 499 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 16 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 5 instances of lines with control characters 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 232: '... include "CSeq" header. It MAY include...' RFC 2119 keyword, line 240: '...ANNOUNCE request MAY include entity bo...' RFC 2119 keyword, line 241: '... MUST follow the rules for entity bo...' RFC 2119 keyword, line 244: '...announcement, the actual SDP SHOULD be...' RFC 2119 keyword, line 246: '... the entity body MAY contain "text/par...' (1 more instance...) 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 48 has weird spacing: '...rmation witho...' == Line 78 has weird spacing: '...chanism to si...' == Line 274 has weird spacing: '...oken is defin...' -- 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 428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) Summary: 12 errors (**), 0 flaws (~~), 9 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: Jan. 17, 2005 July 18,2004 7 RTSP Announce Method 8 draft-zeng-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 (BCP 79). 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 45 This memo describes an extension RTSP method, ANNOUNCE, which 46 extends the core RTSP protocol [RTSP_NEW] 47 to enable a RTSP protocol entity to 48 push to the other side various types of information without the 49 other side asking for it, as long as the other 50 side has singaled the capability to support ANNOUNCE. 52 Examples of information in ANNOUNCE requests 53 include session descriptions and end of stream events. 55 The receiver of this RTSP request is expected to reply with 200 OK 56 response. 58 Since ANNOUNCE represents an extension to the core RTSP protocol, 59 a feature tag, 60 "method.announce", is defined to facilitate capability negotiation 61 using RTSP extension mechanism [RTSP_NEW]. 63 1. Motivation 65 In RFC2326, ANNOUNCE is part of the RTSP protocol. In the updated 66 core RTSP protocol [RTSP_NEW], ANNOUNCE method is NOT part of the 67 core RTSP protocol. 69 There are use cases that require ANNOUNCE method to convey session 70 description as well as other event information. Hence there is a 71 need to make the announce functionality still available but in 72 a way consistent to the extension mechanism in [RTSP_NEW]. 74 As an example, there is a need to signal end of stream event from 75 server to client, as detailed below. 77 In the core RTSP protocol [RTSP_NEW], an RTSP client relies on the 78 media transport mechanism to signal end of stream. 80 When the media transport mechanism happens to be RTP over UDP, this 81 is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are 82 some drawbacks with this approach: 84 1. When the server sends an RTCP BYE packet with its SSRC, the 85 server is giving up on 86 the SSRC (see section 8.2 in [RTP_NEW]). The server would be 87 required to 88 switch to a new SSRC on a subsequent PLAY of the same media 89 stream. 90 Since server's SSRC is only communicated in the Transport header 91 of SETUP 92 response, the server would not have an opportunity to send a new 93 value to 94 the player, and the client would have to discover the SSRC from 95 the incoming RTP packets -- a non-trivial process. 97 2. RTCP BYE packet method does not offer a simple, guaranteed 98 method of delivering 99 an end-of-stream announcement, given BYE packet is carried over 100 UDP. 102 3. RTCP BYE packet method does not offer the option to have a single 103 aggregate 104 end-of-stream announcement for all media streams in the RTSP 105 session. 107 4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot 108 send RTCP BYE 109 before leaving the RTP session if it has not already sent at 110 least one RTP or RTCP packet. This is a problem under 111 error conditions. Consider the case 112 where an RTP session has just started (i.e., RTSP PLAY has been 113 successfully acknowledged with an RTSP 200 OK response), and the 114 sender attempts to 115 retrieve media frames from its media source. The media source 116 fails to provide any media frame due to its internal error such 117 as file corruption. The sender should inform its receiver(s) 118 but it cannot send BYE packets. 120 The motivation to solve the above issues is particularly high for 121 unicast-streaming applications that use RTSP over TCP in the control 122 plane, and RTP over UDP in the media transport. 124 There is also the desire to have an EOS (End Of Stream) 125 signaling mechanism 126 for non-RTP delivery. One such delivery is MPEG2 transport streams 127 used in the cable TV environment. In non-IP delivery environments, 128 the transport typically remains allocated even if no media is being 129 delivered. This 130 means that a client cannot watch for the server to close the 131 transport to signal the end of stream. Meanwhile, watching for the 132 incoming media to stop is unreliable. Short 133 timeouts can trigger a false end of media detection if the 134 media flow is temporarily delayed. Long timeouts introduce 135 unacceptable latencies. Clients are unable to distinguish 136 between a normal end of stream and an error condition that 137 resulted in the media delivery stopping. 139 We note that using TEARDOWN from server to client is not 140 appropriate because: 141 1. TEARDOWN is currently not allowed from server to 142 client [RTSP_NEW]; 143 2. Even if TEARDOWN is made available in server to client 144 direction, 145 the definition of TEARDOWN requires that, if the request 146 URI is 147 aggregate, that the session must be de-allocated by the 148 server. 149 There are RTSP applications that use SET_PARAMETER from 150 client to 151 server as the means to report session QoS statistics, but if 152 server uses TEARDOWN on aggregate URL to signal end of stream, 153 the client can no longer use SET_PARAMETER with a 154 session header. 155 3. In general, RTSP, being a client-server protocol, 156 should let client, not server to control session state. But 157 TEARDOWN 158 on aggregate URL will change session from PLAYING state 159 to INIT state. 161 We note that using PAUSE from server to client is not appropriate 162 either, because PAUSE will change the state of the RTSP session. 164 We note that using SET_PARAMETER from server to client will require 165 at least two parameters in the entity body, one for event type that 166 should be set to End-Of-Stream, and the other parameter for the 167 reason of End-Of-Stream. Also using SET_PARAMETER with an SDP 168 entity body to update session descriptoin will not be compatible 169 with RFC2326 where ANNOUNCE was defined for that purpose. Therefore, 170 SET_PARAMETER is not appropriate to convey the announcement of 171 End-Of-Stream and other events. 173 This memo proposes to define ANNOUNCE method to signal serveral event 174 types including End-Of-Stream events. 176 The ANNOUNCE method is an RTSP request originally 177 defined in RFC2326 but excluded from the core RTSP protocol due 178 to lack of support [RTSP_NEW]. 180 This memo defines ANNOUNCE as an extension to the core RTSP 181 protocol [RTSP_NEW]. It presents ANNOUNCE method as a 182 general mechanism for RTSP server to signal to its clients 183 various events including end of stream events or session description 184 updates events. This memo will discuss the general 185 usage of ANNOUNCE, its feature tag, as well as well as a 186 new "Event-Type" header for ANNOUNCE method. 188 3. The Definition of ANNOUNCE method 190 [RTSP_NEW] has defined a mechanism to extend the core RTSP 191 protocol. Following that mechanism, a feature tag is used to 192 identify ANNOUCE method as an extension to the core RTSP protocol. 194 The ANNOUNCE method is an RTSP request that can be sent in both 195 directions, either from client to server or server to client. 196 When server intends to send ANNOUNCE to client, it must have the means 197 to reach the client, because the RTSP client is not required 198 to keep a persistent connection with the RTSP server. It is beyond 199 the scope of this memo to define the exact means for server to reach 200 client. It suffices to say that if the client intends to receive 201 server's ANNOUNCE requests, it must keep the RTSP connection open, or 202 inform the server on how to reach it without a persistent RTSP 203 connection. 205 Below is an example RTSP conversation in which an RTSP server 206 announces an end of stream event for a media stream using a 207 non-aggregate URI. The new header, "Event-Type" is to be defined later. 209 S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 210 CSeq: 10 211 Session: 12345678 212 Event-Type: End-Of-Stream 213 Range: npt=0-200 214 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102 215 Content-Type: text/parameters 216 Content-Length: 49 218 eos-reason: Reached the end of requested range. 220 C->S: RTSP/1.0 200 OK 221 CSeq: 10 222 Session: 12345678 224 3.1 Normative definitions 226 "ANNOUNCE" is an "extension-method" in the ABNF in section 16.2 227 "RTSP Protocol Definitions" in [RTSP_NEW]. 229 The request-URI of an ANNOUNCE request can be either aggregate 230 or non-aggregate URI. 232 An ANNOUNCE request must include "CSeq" header. It MAY include 233 the following optional headers: 235 "Range", 236 "Session", 237 "RTP-Info", 238 "Event-Type" 240 An ANNOUNCE request MAY include entity body, in which case it 241 MUST follow the rules for entity body defined in section 8.2 242 of [RTSP_NEW]. Entity body can be used to convey further details 243 specific to an event type. For instance, if the event type is 244 session description announcement, the actual SDP SHOULD be 245 included in the entity body. If the event type is end-of-stream 246 announcement, the entity body MAY contain "text/parameter" 247 content type that conveys the reason of the end-of-stream 248 event. 250 ANNOUNCE does NOT affect RTSP session state. If a receiver does not 251 understand any of the headers in an ANNOUNCE request, it simply 252 ignores those headers. 254 The next section defines a new RTSP headers for ANNOUNCE method: 255 "Event-Type". 257 3.2 Event-Type Header 259 The Event-Type header is an optional header to identify the type of 260 event pertaining to the ANNOUNCE request. Example event types include 261 session description, end of stream and error. 263 If an ANNOUNCE request does not contain Event-Type header, the 264 Event-Type defaults to "Session-Description", consistent with 265 RFC2326. 267 The Event-Type header is defined in ABNF as: 268 Event-Type = "Event-Type" ":" event-type 269 event-type = "Session-Descriptoin" / "End-Of-Stream" 270 / "Error" / extension-event-type 271 extension-event-type = token 273 where: 274 -- token is defined in section 17 of [RTSP_NEW]. 276 The only method that "Event-Type" applies is the ANNOUNCE method, 277 either from client to server or from server to client. 279 3.3 Limitations on serve to client "ANNOUNCE" requests 281 Server to client ANNOUNCE method is issued only if the server 282 has the means to contact the client when it has information to push. 283 This may not be possible if the RTSP connection between server and 284 client is not persistent. In such cases, the server will 285 simply skip the sending of ANNOUNCE requests. That is to say, the 286 server will not queue up the ANNOUNCE requests to be sent 287 when client eventually connects. Such a queue would unnecessarily 288 complicate server implementations. 290 4. Feature tag 292 The support of the ANNOUNCE method is represented by the feature tag 293 below: 295 method.announce 297 This feature tag applies to both servers and proxies. 299 Implementations claiming "method.announce" feature tag MUST support 300 the new "Event-Type" header defined in previous section. 302 5. Use Cases 304 This section presents several use cases of the ANNOUNCE method. 306 5.1 Client Announcing SDP To Server For Recording 308 This use case is the same as the first RTSP exchange presented in 309 section 14.6 in RFC2326, with capability exchange via 310 OPTIONS method. 312 The conference participant client C asks the media server M to record 313 the audio and video portions of a meeting. After first verifying that 314 the server supports the "ANNOUNCE" feature, the client uses the 315 ANNOUNCE method to provide meta-information about the recorded 316 session to the server. The client omits "Event-Type" 317 because "Event-Type: Session-Description" is the default. 319 C->M: OPTIONS * RTSP/1.0 320 Require: method.announce 321 CSeq: 1 323 M->C: RTSP/1.0 200 OK 324 CSeq: 1 325 Supported: method.announce 326 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, RECORD,ANNOUNCE 328 C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 329 CSeq: 90 330 Content-Type: application/sdp 331 Content-Length: 121 333 v=0 334 o=camera1 3080117314 3080118787 IN IP4 195.27.192.36 335 s=IETF Meeting, Munich - 1 336 i=The thirty-ninth IETF meeting will be held in Munich, Germany 337 u=http://www.ietf.org/meetings/Munich.html 338 e=IETF Channel 1 339 p=IETF Channel 1 +49-172-2312 451 340 c=IN IP4 224.0.1.11/127 341 t=3080271600 3080703600 342 a=tool:sdr v2.4a6 343 a=type:test 344 m=audio 21010 RTP/AVP 5 345 c=IN IP4 224.0.1.11/127 346 a=ptime:40 347 m=video 61010 RTP/AVP 31 348 c=IN IP4 224.0.1.12/127 350 M->C: RTSP/1.0 200 OK 351 CSeq: 90 353 5.2 Server Announcing End Of Stream 355 In this example, the server announces the End-Of-Stream event to client for 356 one live media stream, because upstream source terminates the stream 357 after 200 seconds. The fact that the stream has played for 200 seconds 358 is communicated by the Range header in the ANNOUNCE request. 360 C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 361 Supported: method.annonce 362 CSeq: 10 363 Session: 12345678 364 Range: npt=0-200 366 S->C: RTSP/1.0 200 OK 367 Supported: method.announce 368 CSeq: 10 369 Session: 12345678 370 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=0; rtptime=0 372 S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 373 CSeq: 123 374 Session: 12345678 375 Range: npt=0-200 376 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102 377 Require: method.announce 378 Event-Type: End-Of-Stream 379 Content-Type: text/parameters 380 Content-Length: 49 382 eos-reason: reached the end of requested range. 384 C->S: RTSP/1.0 200 OK 385 CSeq: 123 386 Session: 12345678 388 The Require header in the above ANNOUNCE request indicates that in 389 order to understand the �Event-Type� header the client must support 390 the feature tag in the Require header. In this case the client happens 391 to signal its support in its PLAY request. 393 From the ANNOUNCE request, the client will learn that the server has 394 completed the stream as requested. 396 From the two RTP-Info headers, one in PLAY response, one in 397 ANNOUNCE request, the client can derive the total number 398 of RTP packets that the server has sent. From the npt field in the 399 Range header, the client knows the presentation time that this stream 400 has covered, from the server's point of view. 402 6. Security Considerations 404 Because there is only one new TEXT header, "Event-Type", added by the 405 extension RTSP method, 406 the security considerations outlined in [RTSP_NEW] apply here as well. 408 7. IANA Considerations 410 A new method name, its associated feature tag, and a new header, 411 need to be registered with IANA. 413 -- Method name: ANNOUNCE. See section 3.1 for the relevant definition. 415 -- Feature tag: method.announce. See section 4 for the relevant 416 definition. 418 -- Header name: Event-Type, see section 3.2 for the relevant information. 420 Normative References 422 [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 423 "Real Time Streaming Protocol", 424 draft-ietf-mmusic-rfc2326bis-06.txt 426 [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003 428 [ABNF] RFC2234 "Augmented BNF for Syntax Specifications: ABNF", 429 Nov. 1997 431 IPR Notice 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed 435 to pertain to the implementation or use of the technology described 436 in this document or the extent to which any license under such 437 rights might or might not be available; nor does it represent that 438 it has made any independent effort to identify any such rights. 439 Information on the procedures with respect to rights in RFC 440 documents can be found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use 445 of such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository 447 at http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at ietf- 453 ipr@ietf.org. 455 Copyright Notice 457 Copyright (C) The Internet Society (2004). This document is subject 458 to the rights, licenses and restrictions contained in BCP 78, and 459 except as set forth therein, the authors retain all their rights. 461 This document and the information contained herein are provided on 462 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 463 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 464 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 465 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 466 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 467 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 469 This Internet-Draft expires in January 2005. 471 Acknowledgement 473 Thanks to Sean Sheedy for suggesting the inclusion of "Range" header 474 and for contributing some text in the motivations section. 476 Funding for the RFC Editor function is currently provided by the 477 Internet Society. 479 Author Addresses 481 Thomas Zeng 482 PacketVideo Network Solutions 483 9605 Scranton Road, Suite 400 484 San Diego, CA 92121 485 email: zeng@pvnetsolutions.com 487 P. Greg Sherwood 488 PacketVideo Device Solutions. 489 10350 Science Center Dr., Suite 210 490 San Diego, CA 92121 491 email: sherwood@pv.com