idnits 2.17.1 draft-stiemerling-rtsp-announce-01.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 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 476. 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 227 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 (February 25, 2008) is 5876 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-16 -- 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: August 28, 2008 H. Harada 6 Hitachi 7 A. Kobayashi 8 NEC Corp. 9 M. Stiemerling (Ed.) 10 NEC Europe Ltd. 11 February 25, 2008 13 RTSP 2.0 Asynchronous Notification 14 draft-stiemerling-rtsp-announce-01 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 August 28, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 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 notify clients about 79 asynchronous events occurring during an RTSP session. Such 80 asynchronous events are, for example, end of session, end of stream 81 or change (redirect) of the RTSP server. While redirecting RTSP 82 clients to a different RTSP server is well-described in RTSP 1.0 83 [RFC2326] and RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], end of stream or 84 end of session by the server is not defined. This memo aims at 85 changing RTSP 2.0 but not RTSP 1.0. 87 Some RTSP 1.0 deployments are extending the ANNOUNCE method of 88 [RFC2326], which is defined as: 90 When sent from client to server, ANNOUNCE posts the description of 91 a presentation or media object identified by the request URL to a 92 server. When sent from server to client, ANNOUNCE updates the 93 session description in real-time. 95 These implementations use ANNOUNCE to send asynchronous notifications 96 for RTSP sessions from an RTSP server to RTSP clients. The ANNOUNCE 97 method is extended by adding a reason header, to indicate end of 98 stream reason to the clients. However, this extension of the 99 ANNOUNCE method is not standardised. 101 An example for a deployment using the extended ANNOUNCE method is the 102 Hikari service provided by NTT in Japan [Hikari]. This service is 103 based on the Hikari Service Architecture (HSA), developed by the 104 Hikari Service Architecture Consortium (HSAC, [HSAC]) in Japan. NB: 105 The consortium itself was closed, as the service specification was 106 completed, and the specification is currently used. HSA is actually 107 using the ANNOUNCE method as described above but does not use the 108 client to server mode of it. According to discussions during the 109 IETF#70 meeting, several other deployments (namely cable 110 deployments), are also using ANNOUNCE this way. 112 The ANNOUNCE method has been removed in RTSP 2.0 113 [I-D.ietf-mmusic-rfc2326bis], thus also having removed this way of 114 sending asynchronous notifications to clients. The current way in 115 RTSP 2.0 of sending end of stream notifications is using the REDIRECT 116 method (see Section 11.9): 118 The lack of a Location header in any REDIRECT request is 119 indicative of the server no longer being able to fulfil the 120 current request and having no alternatives for the client to 121 continue with its normal operation. It is akin to a server 122 initiated TEARDOWN that applies both to sessions as well as the 123 general connection associated with that client. 125 The REDIRECT request does not include any reason header why the 126 stream or the RTSP session is actually about to end. Furthermore, 127 REDIRECT seems to be logically the wrong place for such a stream or 128 session termination. 130 Given the lack of a good and extensible semantics in the current RTSP 131 2.0 draft for sending asynchronous notifications, we propose a new 132 method in the next section. The next section also discusses two 133 different ways of including the new method in the RTSP 2.0 134 specification. 136 There was already an attempt to re-introduce the ANNOUNCE method 137 described in [I-D.ietf-mmusic-rtsp-announce]. The goal of this draft 138 was to revive ANNOUNCE for end of stream and change of session 139 description. This memo deliberately reuses some of ideas of 140 [I-D.ietf-mmusic-rtsp-announce] but nothing related to change of 141 session description. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Definition of Method 149 This section defines a new method for RTSP servers to asynchronously 150 ANNOUNCE clients about end of stream or end of RTSP session with a 151 reason code. The new method is called ANNOUNCE, but any other 152 suitable name is also possible (e.g., HALT, STOP, BYE), i.e., it is 153 subject to further discussions. 155 There are actually two ways of adding this extension to the RTSP 156 protocol. First, the ANNOUNCE method could be added directly to the 157 core RTSP protocol or, second, it could be added as an extension to 158 the core RTSP protocol. This is also subject to WG discussions. 160 The ANNOUNCE method is a mechanism for RTSP servers to signal RTSP 161 clients about end of stream or end of RTSP session events. ANNOUNCE 162 is an RTSP request that can only be sent from servers to clients, 163 thus requiring a persistent connection between server and client. 164 Otherwise there is no way for the server to send this request method 165 to the client. Therefore, clients are required to keep the RTSP 166 connection to the server open at all times of an RTSP session. 168 Here is an example RTSP conversation in which an RTSP server 169 announces an end of stream event for a media stream using a non- 170 aggregate URI. 172 S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/2.0 173 CSeq: 99 174 Session: 12345678 175 Notice: 2101 End-Of-Stream 176 Range: npt=0-200 177 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102 179 C->S: RTSP/2.0 200 OK 180 CSeq: 99 181 Session: 12345678 183 2.1. Normative Definitions 185 The request-URI of an ANNOUNCE request can be either aggregate or 186 non-aggregate URI. 188 An ANNOUNCE request must include "CSeq" header and "Notice". It MAY 189 include the following optional headers: 191 "Range", 193 "Session", 195 "RTP-Info". 197 An ANNOUNCE request MAY include an entity body, in which case it MUST 198 follow the rules for entity body defined in Section 8.2 of 199 [I-D.ietf-mmusic-rfc2326bis]. The entity body can be used to convey 200 further details specific to an event type. If the event type is end- 201 of-stream or session termination announcement, the entity body MAY 202 contain "text/parameter" content type that conveys the reason of the 203 event. 205 ANNOUNCE does not affect RTSP session state if the event type is 206 "2101 End of Stream" but does affect the RTSP session state if the 207 event type is "3000 End of Session". If a receiver does not 208 understand any of the headers in an ANNOUNCE request, it simply 209 ignores those headers. 211 The next section defines a new RTSP headers for ANNOUNCE method: 212 "Notice". 214 2.2. Notice Header 216 This section defines a new mandatory header. The Notice header is 217 identifying the type of event pertaining to the ANNOUNCE request. 219 The Notice header is defined in ABNF as: 221 Notice = "Notice" ":" Notice 222 Notice = Notice-code SP Notice-string 223 Notice-code = 4DIGITS 224 Notice-string = token 226 where: 227 -- token is defined in section 17 of [RTSP_NEW]. 229 The "Notice" header applies only the ANNOUNCE method, which is sent 230 from server to client. 232 The following pairs for Notice-code and Notice-string are defined in 233 this memo. 235 +-------------+-------------------------+---------------------------+ 236 | Notice-code | Notice-string | Description | 237 +-------------+-------------------------+---------------------------+ 238 | 1103 | Playout Stalled | -/- | 239 | | | | 240 | 1104 | Playout Resumed | Temporarily stopped | 241 | | | | 242 | 2101 | End-of-Stream Reached | Content terminated | 243 | | | | 244 | 2103 | Transition | In transition | 245 | | | | 246 | 2104 | Start-of-Stream Reached | Returned to the initial | 247 | | | content | 248 | | | | 249 | 2306 | Continuous Feed | Live finished | 250 | | Terminated | | 251 | | | | 252 | 2401 | Ticket Expired | Viewing right expired | 253 | | | | 254 | 4400 | Error Reading Content | Data read error | 255 | | Data | | 256 | | | | 257 | 5200 | Server Resource | Resource cannot be | 258 | | Unavailable | obtained | 259 | | | | 260 | 5401 | Downstream Failure | Stream could not be | 261 | | | obtained | 262 | | | | 263 | 5402 | Client Session | -/- | 264 | | Terminated | | 265 | | | | 266 | 5403 | Server Shutting Down | -/- | 267 | | | | 268 | 5404 | Internal Server Error | -/- | 269 | | | | 270 | 5501 | End-of-Window_term | -/- | 271 | | | | 272 | 5502 | End-of-Contract_term | -/- | 273 +-------------+-------------------------+---------------------------+ 275 Table 1: The Notice values 277 If "Notice" is "2101 End-Of-Stream", the optional RTP-Info header 278 SHOULD contain the "seq" attribute that indicates the sequence number 279 of the next RTP packet. 281 2.3. Limitations of ANNOUNCE 283 The server to client ANNOUNCE method is issued only if the server has 284 the means to contact the client when it has information to push. 285 This may not be possible if the RTSP connection between server and 286 client is not persistent. In such cases, the server will simply skip 287 the sending of ANNOUNCE requests. The server MUST NOT queue up the 288 ANNOUNCE requests to be sent when client eventually connects. Such a 289 queue would unnecessarily complicate server implementations. 291 3. Feature Tag 293 The support of the ANNOUNCE method is represented by this feature 294 tag: 296 method.announce 298 This feature tag applies to both servers and proxies. 300 Implementations claiming "method.announce" feature tag MUST support 301 the new "Notice" header defined in previous section. 303 4. Security Considerations 305 This initial version of this memo does not have yet any security 306 considerations, but they will be added with the next revision. 308 5. Conclusion 310 This memo is work in progress and is requesting feedback from the 311 MMUSIC working group. The first version of this draft has been 312 presented and discussed during the IETF370 meeting. There has been 313 no final conclusion during and after the meeting on how to proceed 314 w.r.t. to end of stream and end of session notifications. 316 During the IETF#70 meeting three different "semantics" for ANNOUNCE 317 have been discussed: 319 o notification of end of stream; This should be incorporated, may be 320 even in as an explicit method due to implementers. There was 321 additional support for having this kind of notifications. 323 o "session-type" notifications: "sorry, cant serve you anymore": It 324 is believed that this is covered well in ther current 325 specifcation. 327 o move an RTSP session from one server host to another: well-done by 328 the current specification. 330 This memo needs to be further discussed to clarify these open issues: 332 o Should the proposed mechanism can be integrated in the current 333 RTSP 2.0 specification or if it should be defined as an extension 334 to the current RTSP 2.0 specification? 336 o The text mentions just RTSP server, but never clarifies the role 337 of ANNOUNCE w.r.t. RTSP proxies; 339 o Is the name ANNOUNCE appropriate for this method? 341 o The entity body should be better specified 343 o The only real reason codes are not very helpful yet. 345 o Exemplifying use cases are missing 347 o Extensibility section is missing 349 o IANA section is missing. 351 6. References 353 6.1. Normative References 355 [I-D.ietf-mmusic-rfc2326bis] 356 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 357 and M. Stiemerling, "Real Time Streaming Protocol 2.0 358 (RTSP)", draft-ietf-mmusic-rfc2326bis-16 (work in 359 progress), November 2007. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 6.2. Informative References 366 [HSAC] "Hikari Service Architecture Consortium", Web Site http:// 367 web.archive.org/web/20040518075704/http:// 368 www.hikari-sac.org/, October 2007. 370 [Hikari] "Hikari Service Architecture", Web Site http:// 371 www.itu.int/itudoc/itu-t/com13/ipexpert/ipmedia/ 372 71304_pp7.ppt, October 2007. 374 [I-D.ietf-mmusic-rtsp-announce] 375 Zeng, T., "RTSP Announce Method", 376 draft-ietf-mmusic-rtsp-announce-01 (work in progress), 377 February 2005. 379 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 380 Streaming Protocol (RTSP)", RFC 2326, April 1998. 382 Appendix A. Design Choices for Asynchronous Notifications 384 Appendix A of [I-D.ietf-mmusic-rtsp-announce] discusses several 385 design choices for implementing the ANNOUNCE method semantics with 386 other methods of RTSP and also RTP. We deem the arguments described 387 as still valid and also applicable for the in this memo discussing 388 the ANNOUNCE method. 390 Authors' Addresses 392 Tetsuya Ura 393 Nippon Telegraph and Telephone Corporation 394 1-1 Hikarinooka 395 Yokosuka-Shi Kanagawa 239-0847 396 Japan 398 Phone: +81 46 859 3780 399 Email: ura.tetsuya@lab.ntt.co.jp 401 Kenshin Oku 402 Nippon Telegraph and Telephone Corporation 403 1-1 Hikarinooka 404 Yokosuka-Shi Kanagawa 239-0847 405 Japan 407 Phone: +81 46 859 2528 408 Email: oku.kenshin@lab.ntt.co.jp 410 Hiromi Harada 411 Hitachi, Ltd. 412 890 Kashimada 413 Saiwai-ku Kawasaki-Shi Kanagawa 212-8567 414 Japan 416 Phone: +81 44 549 1578 417 Email: hiromi.harada.jv@hitachi.com 419 Akira Kobayashi 420 NEC Corporation 421 11-5 Shibaura 2-chone 422 Minato-ku, Tokyo 108-8557 423 Japan 425 Phone: +81 3 5476 1084 426 Email: a-kobayasi@ce.jp.nec.com 427 Martin Stiemerling 428 NEC Laboratories Europe 429 Kurfuerstenanlage 36 430 Heidelberg 69115 431 Germany 433 Phone: +49 6221 4342 113 434 Fax: +49 6221 4342 155 435 Email: stiemerling@nw.neclab.eu 436 URI: http://www.netlab.nec.de/ 438 Full Copyright Statement 440 Copyright (C) The IETF Trust (2008). 442 This document is subject to the rights, licenses and restrictions 443 contained in BCP 78, and except as set forth therein, the authors 444 retain all their rights. 446 This document and the information contained herein are provided on an 447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 449 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 450 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 451 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 454 Intellectual Property 456 The IETF takes no position regarding the validity or scope of any 457 Intellectual Property Rights or other rights that might be claimed to 458 pertain to the implementation or use of the technology described in 459 this document or the extent to which any license under such rights 460 might or might not be available; nor does it represent that it has 461 made any independent effort to identify any such rights. Information 462 on the procedures with respect to rights in RFC documents can be 463 found in BCP 78 and BCP 79. 465 Copies of IPR disclosures made to the IETF Secretariat and any 466 assurances of licenses to be made available, or the result of an 467 attempt made to obtain a general license or permission for the use of 468 such proprietary rights by implementers or users of this 469 specification can be obtained from the IETF on-line IPR repository at 470 http://www.ietf.org/ipr. 472 The IETF invites any interested party to bring to its attention any 473 copyrights, patents or patent applications, or other proprietary 474 rights that may cover technology that may be required to implement 475 this standard. Please address the information to the IETF at 476 ietf-ipr@ietf.org. 478 Acknowledgment 480 Funding for the RFC Editor function is provided by the IETF 481 Administrative Support Activity (IASA).