idnits 2.17.1 draft-stiemerling-rtsp-announce-00.txt: 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.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 429. -- 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 222 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.) -- The document date (November 12, 2007) is 6010 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) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-14 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC T. Ura 3 Internet-Draft K. Oku 4 Intended status: Standards Track NTT 5 Expires: May 15, 2008 H. Harada 6 Hitachi 7 A. Kobayashi 8 NEC Corp. 9 M. Stiemerling (Ed.) 10 NEC Europe Ltd. 11 November 12, 2007 13 RTSP Asynchronous Notification 14 draft-stiemerling-rtsp-announce-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 15, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 Some IPTV deployments that are using the Real Time Streaming Protocol 48 (RTSP) require the ability of the server to notify clients about 49 asynchronous events occurring during an RTSP session. Current 50 deployments typically use the ANNOUNCE method of RTSP 1.0 for sending 51 such asynchronous events from a server to clients by using some 52 proprietary extensions. However, the ANNOUNCE method has been 53 removed from the current RTSP 2.0 draft, leaving the new 54 specification without a mechanism for sending asynchronous messages 55 from the server. This memo describes a use case for such an 56 asynchronous message and proposes a new RTSP 2.0 method. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definition of Method . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Normative Definitions . . . . . . . . . . . . . . . . . . 5 63 2.2. Notice Header . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Limitations of ANNOUNCE . . . . . . . . . . . . . . . . . 8 65 3. Feature Tag . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Design Choices for Asynchronous Notifications . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 75 1. Introduction 77 Some IPTV deployments that are using the Real Time Streaming Protocol 78 (RTSP) require the ability of the server to ANNOUNCE clients about 79 asynchronous events occurring during an RTSP session. Such 80 asynchronous events are, for example, termination of session or 81 change (redirect) of the RTSP server. While redirecting RTSP clients 82 to a different RTSP server is well-described in RTSP 1.0 [RFC2326], 83 end of stream or end of session by the server is not defined. 85 Some RTSP 1.0 deployments are extending the ANNOUNCE method of 86 [RFC2326], which is defined as: 88 When sent from client to server, ANNOUNCE posts the description of 89 a presentation or media object identified by the request URL to a 90 server. When sent from server to client, ANNOUNCE updates the 91 session description in real-time. 93 These implementations use ANNOUNCE to send asynchronous notifications 94 for RTSP sessions from an RTSP server to RTSP clients. The ANNOUNCE 95 method is extended by adding a reason header, to indicate end of 96 stream reason to the clients. However, this extension of the 97 ANNOUNCE method is not standardised. 99 An example for a deployment using the extended ANNOUNCE method is the 100 Hikari service provided by NTT in Japan [Hikari]. This service is 101 based on the Hikari Service Architecture (HSA), developed by the 102 Hikari Service Architecture Consortium (HSAC, [HSAC]) in Japan. NB: 103 The consortium itself was closed, as the service specification was 104 completed, and the specification is currently used. HSA is actually 105 using the ANNOUNCE method as described above but does not use the 106 client to server mode of it. 108 The ANNOUNCE method has been removed in RTSP 2.0 109 [I-D.ietf-mmusic-rfc2326bis], thus also having removed this way of 110 sending asynchronous end of stream notifications to clients. The 111 current way in RTSP 2.0 of sending end of stream notifications is the 112 REDIRECT method (see Section 11.9): 114 The lack of a Location header in any REDIRECT request is 115 indicative of the server no longer being able to fulfil the 116 current request and having no alternatives for the client to 117 continue with its normal operation. It is akin to a server 118 initiated TEARDOWN that applies both to sessions as well as the 119 general connection associated with that client. 121 The REDIRECT request does not include any reason header why the 122 stream or the RTSP session is actually about to end. Furthermore, 123 REDIRECT seems to be logically the wrong place for such a stream or 124 session termination. 126 Given the lack of a good and extensible semantics in the current RTSP 127 2.0 draft for sending asynchronous notifications, we propose a new 128 method in the next section. The next section also discusses two 129 different ways of including the new method in the RTSP 2.0 130 specification. 132 There was already an attempt to re-introduce the ANNOUNCE method 133 described in [I-D.ietf-mmusic-rtsp-announce]. The goal of this draft 134 was to revive ANNOUNCE for end of stream and change of session 135 description. This memo deliberately reuses some of ideas of 136 [I-D.ietf-mmusic-rtsp-announce]. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Definition of Method 144 This section defines a new method for RTSP servers to asynchronously 145 ANNOUNCE clients about end of stream or end of RTSP session with a 146 reason code. The new method is called ANNOUNCE, but any other 147 suitable name is also possible (e.g., HALT, STOP, BYE), i.e., it is 148 subject to further discussions. 150 There are actually two ways of adding this extension to the RTSP 151 protocol. First, the ANNOUNCE method could be added directly to the 152 core RTSP protocol or, second, it could be added as an extension to 153 the core RTSP protocol. This is also subject to WG discussions. 155 The ANNOUNCE method is a mechanism for RTSP servers to signal RTSP 156 clients about end of stream or end of RTSP session events. ANNOUNCE 157 is an RTSP request that can only be sent from servers to clients, 158 thus requiring a persistent connection between server and client. 159 Otherwise there is no way for the server to sent this request method 160 to the client. Therefore, clients are required to keep the RTSP 161 connection to the server open at all times of an RTSP session. 163 Here is an example RTSP conversation in which an RTSP server 164 announces an end of stream event for a media stream using a non- 165 aggregate URI. 167 S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/2.0 168 CSeq: 99 169 Session: 12345678 170 Notice: 2101 End-Of-Stream 171 Range: npt=0-200 172 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102 174 C->S: RTSP/2.0 200 OK 175 CSeq: 99 176 Session: 12345678 178 2.1. Normative Definitions 180 The request-URI of an ANNOUNCE request can be either aggregate or 181 non-aggregate URI. 183 An ANNOUNCE request must include "CSeq" header and "Notice". It MAY 184 include the following optional headers: 186 "Range", 188 "Session", 190 "RTP-Info". 192 An ANNOUNCE request MAY include an entity body, in which case it MUST 193 follow the rules for entity body defined in Section 8.2 of 194 [I-D.ietf-mmusic-rfc2326bis]. The entity body can be used to convey 195 further details specific to an event type. If the event type is end- 196 of-stream or session termination announcement, the entity body MAY 197 contain "text/parameter" content type that conveys the reason of the 198 event. 200 ANNOUNCE does NOT affect RTSP session state if the event type is 201 "2101 End of Stream" but does affect the RTSP session state if the 202 event type is "3000 End of Session". If a receiver does not 203 understand any of the headers in an ANNOUNCE request, it simply 204 ignores those headers. 206 The next section defines a new RTSP headers for ANNOUNCE method: 207 "Notice". 209 2.2. Notice Header 211 This section defines a new mandatory header. The Notice header is 212 identifying the type of event pertaining to the ANNOUNCE request. 214 The Notice header is defined in ABNF as: 216 Notice = "Notice" ":" Notice 217 Notice = Notice-code SP Notice-string 218 Notice-code = 4DIGITS 219 Notice-string = token 221 where: 222 -- token is defined in section 17 of [RTSP_NEW]. 224 The "Notice" header applies only the ANNOUNCE method, which is sent 225 from server to client. 227 The following pairs for Notice-code and Notice-string are defined in 228 this memo. 230 +-------------+-------------------------+---------------------------+ 231 | Notice-code | Notice-string | Description | 232 +-------------+-------------------------+---------------------------+ 233 | 1103 | Playout Stalled | -/- | 234 | | | | 235 | 1104 | Playout Resumed | Temporarily stopped | 236 | | | | 237 | 2101 | End-of-Stream Reached | Content terminated | 238 | | | | 239 | 2103 | Transition | In transition | 240 | | | | 241 | 2104 | Start-of-Stream Reached | Returned to the initial | 242 | | | content | 243 | | | | 244 | 2306 | Continuous Feed | Live finished | 245 | | Terminated | | 246 | | | | 247 | 2401 | Ticket Expired | Viewing right expired | 248 | | | | 249 | 4400 | Error Reading Content | Data read error | 250 | | Data | | 251 | | | | 252 | 5200 | Server Resource | Resource cannot be | 253 | | Unavailable | obtained | 254 | | | | 255 | 5401 | Downstream Failure | Stream could not be | 256 | | | obtained | 257 | | | | 258 | 5402 | Client Session | -/- | 259 | | Terminated | | 260 | | | | 261 | 5403 | Server Shutting Down | -/- | 262 | | | | 263 | 5404 | Internal Server Error | -/- | 264 | | | | 265 | 5501 | End-of-Window_term | -/- | 266 | | | | 267 | 5502 | End-of-Contract_term | -/- | 268 +-------------+-------------------------+---------------------------+ 270 Table 1: The Notice values 272 If "Notice" is "2101 End-Of-Stream", the optional RTP-Info header 273 SHOULD contain the "seq" attribute that indicates the sequence number 274 of the next RTP packet. 276 2.3. Limitations of ANNOUNCE 278 The server to client ANNOUNCE method is issued only if the server has 279 the means to contact the client when it has information to push. 280 This may not be possible if the RTSP connection between server and 281 client is not persistent. In such cases, the server will simply skip 282 the sending of ANNOUNCE requests. The server MUST NOT queue up the 283 ANNOUNCE requests to be sent when client eventually connects. Such a 284 queue would unnecessarily complicate server implementations. 286 3. Feature Tag 288 The support of the ANNOUNCE method is represented by this feature 289 tag: 291 method.announce 293 This feature tag applies to both servers and proxies. 295 Implementations claiming "method.announce" feature tag MUST support 296 the new "Notice" header defined in previous section. 298 4. Security Considerations 300 This initial version of this memo does not have yet any security 301 considerations, but they will be added with the next revision. 303 5. Conclusion 305 This memo is work in progress and is requesting feedback from the 306 MMUSIC working group . 308 This memo needs to be further discussed to clarify these open issues: 310 o Should the proposed mechanism can be integrated in the current 311 RTSP 2.0 specification or if it should be defined as an extension 312 to the current RTSP 2.0 specification? 314 o The text mentions just RTSP server, but never clarifies the role 315 of ANNOUNCE w.r.t. RTSP proxies; 317 o Is the name ANNOUNCE appropriate for this method? 319 o The entity body should be better specified 321 o The only real reason codes are not very helpful yet. 323 o Exemplifying use cases are missing 325 o Extensibility section is missing 327 o IANA section is missing. 329 6. References 331 6.1. Normative References 333 [I-D.ietf-mmusic-rfc2326bis] 334 Schulzrinne, H., "Real Time Streaming Protocol 2.0 335 (RTSP)", draft-ietf-mmusic-rfc2326bis-14 (work in 336 progress), December 2006. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 6.2. Informative References 343 [HSAC] "Hikari Service Architecture Consortium", Web Site http:// 344 web.archive.org/web/20040518075704/http:// 345 www.hikari-sac.org/, October 2007. 347 [Hikari] "Hikari Service Architecture", Web Site http:// 348 www.itu.int/itudoc/itu-t/com13/ipexpert/ipmedia/ 349 71304_pp7.ppt, October 2007. 351 [I-D.ietf-mmusic-rtsp-announce] 352 Zeng, T., "RTSP Announce Method", 353 draft-ietf-mmusic-rtsp-announce-01 (work in progress), 354 February 2005. 356 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 357 Streaming Protocol (RTSP)", RFC 2326, April 1998. 359 Appendix A. Design Choices for Asynchronous Notifications 361 Appendix A of [I-D.ietf-mmusic-rtsp-announce] discusses several 362 design choices for implementing the ANNOUNCE method semantics with 363 other methods of RTSP and also RTP. We deem the arguments described 364 as still valid and also applicable for the in this memo discussing 365 the ANNOUNCE method. 367 Authors' Addresses 369 Tetsuya Ura 370 Nippon Telegraph and Telephone Corporation 371 1-1 Hikarinooka 372 Yokosuka-Shi Kanagawa 239-0847 373 Japan 375 Phone: +81 46 859 3780 376 Email: ura.tetsuya@lab.ntt.co.jp 378 Kenshin Oku 379 Nippon Telegraph and Telephone Corporation 380 1-1 Hikarinooka 381 Yokosuka-Shi Kanagawa 239-0847 382 Japan 384 Phone: +81 46 859 2528 385 Email: oku.kenshin@lab.ntt.co.jp 387 Hiromi Harada 388 Hitachi, Ltd. 389 890 Kashimada 390 Saiwai-ku Kawasaki-Shi Kanagawa 212-8567 391 Japan 393 Phone: +81 44 549 1578 394 Email: hiromi.harada.jv@hitachi.com 396 Akira Kobayashi 397 NEC Corporation 398 11-5 Shibaura 2-chone 399 Minato-ku, Tokyo 108-8557 400 Japan 402 Phone: +81 3 5476 1084 403 Email: a-kobayasi@ce.jp.nec.com 404 Martin Stiemerling 405 NEC Europe Ltd. - NEC Laboratories Europe 406 Kurfuerstenanlage 36 407 Heidelberg 69115 408 Germany 410 Phone: +49 6221 4342 113 411 Fax: +49 6221 4342 155 412 Email: stiemerling@nw.neclab.eu 413 URI: http://www.netlab.nec.de/ 415 Full Copyright Statement 417 Copyright (C) The IETF Trust (2007). 419 This document is subject to the rights, licenses and restrictions 420 contained in BCP 78, and except as set forth therein, the authors 421 retain all their rights. 423 This document and the information contained herein are provided on an 424 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 425 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 426 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 427 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 428 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 429 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Intellectual Property 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 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 of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 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 453 ietf-ipr@ietf.org. 455 Acknowledgment 457 Funding for the RFC Editor function is provided by the IETF 458 Administrative Support Activity (IASA).