idnits 2.17.1 draft-sheedy-mmusic-rtsp-ext-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Missing reference section? '1' on line 50 looks like a reference -- Missing reference section? '3' on line 109 looks like a reference -- Missing reference section? '4' on line 112 looks like a reference -- Missing reference section? '5' on line 125 looks like a reference -- Missing reference section? '6' on line 165 looks like a reference -- Missing reference section? '7' on line 168 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Expires: 10 September 2000 3 Sean Sheedy 4 nCUBE Corporation 6 RTSP Extensions: 7 Additional Transports and Performance Enhancements 9 draft-sheedy-mmusic-rtsp-ext-00.txt 11 Status of this memo 13 This document is an Internet-Draft and is in full 14 conformance with all provisions of Section 10 of 15 RFC2026. 17 Internet-Drafts are working documents of the 18 Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may 20 also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a 24 maximum of six months and may be updated, replaced, 25 or obsoleted by other documents at any time. It is 26 inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed 31 at http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can 34 be accessed at http://www.ietf.org/shadow.html. 36 Abstract 38 This document proposes enhancements to the RTSP 39 protocol for broadcast quality non-IP based video- 40 on-demand applications. Additional transports for 41 non-IP delivery of media streams are proposed, 42 along with control extensions to reduce latency. 43 These proposals are based on nCUBE Corporation's 44 and Oracle Corporation's experience with their 45 existing media servers. 47 1 Introduction 49 nCUBE Corporation has developed a media server using the RTSP 50 standard [1] for its video-on-demand (VOD) platform, the MediaCUBE 51 4. The platform is designed for large-scale deployments of 52 broadcast quality interactive video. It is being used currently in 53 several commercial deployments worldwide, with many more deployments 54 scheduled in the near future. 56 nCUBE's experience to date with the RTSP protocol has been positive. 57 The basic protocol is flexible enough to work in a large-scale, 58 high-bandwidth environment. The HTTP-like syntax has proven easy 59 for client developers to implement. The flexibility provided by the 60 syntax and the facilities for extensions have proven invaluable in 61 deploying RTSP in an environment somewhat different from that for 62 which it was originally designed. 64 A typical broadcast quality environment differs from the Internet 65 environment in several ways: 67 - Transports and lower transports 69 Although IP protocols are often used for control connections, 70 broadcast quality video-on-demand installations often do not 71 use IP protocols (such as UDP and RTP) for the actual delivery 72 of a presentation (which is usually an aggregation of media 73 streams). Typically, MPEG-2 transport streams are carried on a 74 lower transport which natively supports MPEG-2, such as AAL5 75 (over ATM) or QAM. 77 - Multiplexing RTSP clients 79 Supporting non-RTSP clients (e.g., many currently-available set 80 top boxes) requires a bridging server that speaks the client's 81 native protocol and, in turn, acts as an RTSP client of the 82 media server. Such bridging servers typically make transport 83 address and bandwidth assignments for the clients, and often 84 need to coordinate these decisions with external hardware 85 devices such as QAM modulators and up converters. 87 - Limited capability clients 89 Video-on-demand clients in the home (such as specialized set 90 top boxes) are under tremendous price pressures. Consequently, 91 their capabilities are often much more limited than even low- 92 end general-purpose computers. Memory is typically very 93 limited (on the order of 8 megabytes), and the media streams 94 are discarded immediately once they have been decoded. Many 95 hardware decoders are sensitive to timing jitter and 96 discontinuities in video or audio elementary streams. 98 - Latency 100 Low latency, particularly for stream control requests such as 101 pause or fast forward, is critical to the satisfaction of many 102 home users of video-on-demand services. End users of a home 103 VOD service are a cross section of cable television customers, 104 and are often not computer savvy. Their standard of comparison 105 for the responsiveness of a media server is their VCR or DVD 106 player, not a computer web browser accessing the Internet. 108 nCUBE Corporation has added some extensions to the RTSP standard, 109 which address the requirements of this different environment [3]. 110 These enhancements were developed in collaboration with Oracle 111 Corporation, who has also incorporated similar features in their 112 RTSP server [4]. The remainder of this document proposes a set of 113 enhancements to the RTSP standard based on both of these 114 implementations. 116 2 Transports, Profiles, and Lower Transports 118 Other media delivery mechanisms besides RTP are used in many 119 commercial video-on-demand deployments. To support this, new 120 transports, profiles, and lower transports in addition to the 121 current standard RTP/AVP/UDP are needed. 123 2.1 Transports 125 MPEG-2 is used extensively for high bandwidth video [5]. An 126 enhancement to the "transport-protocol" field in the "Transport" 127 header to support this is: 129 MP2T MPEG-2 Transport 131 The new syntax of "transport-protocol" would then be: 133 transport-protocol = "RTP" | "MP2T" 135 2.2 Lower Transports 137 Similarly, TCP or UDP are not always used as lower transports. 138 Enhancements to the "lower-transport" field are: 140 AAL5-PVC ATM permanent virtual circuit 142 AAL5-SVC ATM switched virtual circuit 144 ASI DVB Asynchronous Serial Interface (ASI) 146 QAM Quadrature Amplitude Modulation(QAM) 148 The new syntax of "lower-transport" would then be: 150 lower-transport = "TCP" | "UDP" | "AAL5-PVC" | "AAL5-SVC" | 151 "ASI" | "QAM" 152 (Note that end user RTSP clients typically don't request a DVB-ASI 153 lower transport. This is primarily used by bridging servers that 154 are also controlling external hardware such as QAM modulators.) 156 This proposal makes no distinction between QAM64 and QAM256. Making 157 such a distinction may be desirable. 159 2.3 Profiles 161 Since AVP is intertwined with RTP, additional profiles are needed. 162 Enhancements to the "profile" file are: 164 H2221 The ITU H.222.1 standard for MPEG delivery over 165 ATM [6]. The default lower transport is AAL5-SVC. 167 DVBC The Digital Video Broadcasting - Cable standard 168 [7]. The default lower transport is QAM. 170 The new syntax of "profile" would then be: 172 profile = "AVP" | "H2221" | "DVBC" 174 2.4 Transport/Profile/Lower-Transport Combinations 176 Only the following combinations of protocols, profiles, and lower 177 transports are meaningful: 179 MP2T/H2221/AAL5-PVC 180 MP2T/H2221/AAL5-SVC 181 MP2T/DVBC/QAM 182 MP2T/DVBC/ASI 184 2.5 Destinations 186 To handle the additional lower transport types, the syntax of the 187 "destination" transport parameter needs to be enhanced. In 188 particular, most lower transports in section 2.2 use addresses that 189 are not globally unique, but are unique only within a particular 190 physical channel. The destination "address" field should contain an 191 optional identifier string at the beginning to allow sufficiently 192 intelligent clients (such as bridging servers) to disambiguate 193 between physical channels. 195 The formal syntax for the expanded "destination" addresses is: 197 address = [ id-string ":" ] type-address 199 type-address = host 200 | atm-pvc-address 201 | atm-svc-address 202 | qam-address 204 id-string = 1*( ALPHA | DIGIT | "_" ) 205 (Note that QAM and DVB-ASI addressing are identical, and both are 206 covered by the "qam-address" rule.) 208 2.5.1 ATM PVC Address 210 The destination address for an ATM permanent virtual circuit is the 211 VPI and VCI of the client, specified in decimal: 213 atm-pvc-address = vpi "." vci 215 vpi = 1*5(DIGIT) 216 vci = 1*5(DIGIT) 218 For example, to use ATM permanent virtual circuits a client may 219 specify a Transport header like the following: 221 Transport: MP2T/H2221/AAL5-PVC;unicast;destination=atm00:0.40 223 2.5.2 ATM SVC Address 225 The destination address for an ATM switched virtual circuit is the 226 20-byte service access point address, specified in hexadecimal: 228 atm-svc-address = 20*20(HEX) 230 For example, to use ATM switched virtual circuits a client may 231 specify a Transport header like the following: 233 Transport: MP2T/H2221/AAL5-SVC;unicast; 234 destination=47000580ffe1000000f21a360b00204821490f01 236 Many vendors include dots (.) in service access point addresses. It 237 may be desirable to allow this. 239 2.5.3 QAM and DVB-ASI Addresses 241 The destination address for QAM or DVB-ASI is a server-specific 242 channel number (note that this is not the RF channel number) and 243 MPEG-2 program number specified in decimal: 245 qam-address = channel-number "." program-number 247 channel-number = 1*3(DIGIT) 248 program-number = 1*5(DIGIT) 250 For example, to use QAM a client may specify a Transport header like 251 the following: 253 Transport: MP2T/DVBC/QAM;unicast;destination=cim00:0.75 255 For example, to use DVB-ASI a client may specify a Transport header 256 like the following: 258 Transport: MP2T/DVBC/ASI;unicast;destination=dac00:0.75 259 2.6 Client Identification 261 For most video-on-demand environments, clients cannot be allowed to 262 specify a transport destination address. In non-IP delivery 263 environments, they typically do not have sufficient knowledge of the 264 network topology to properly specify an address. In all 265 environments, allowing clients to choose an address presents 266 security problems. Further, in many non-IP delivery environments 267 (such as cable systems using QAM and DOCSIS), valid transport 268 addresses cannot be derived from the IP address of the client. 270 To resolve these problems, the client must be able to identify 271 itself to the media server. This can be accomplished by adding a 272 new Transport parameter, "client". The argument to "client" is a 273 deployment-specific string that uniquely identifies a client. 274 Identity information included in the string may be, for example, a 275 smart card ID for a set top box and the optical node to which the 276 set top box is connected. 278 The formal syntax for the "client" parameter is: 280 client = "client" "=" client-id 281 client-id = token 283 3 Reuse of Transports 285 Typically, the setup and teardown of a transport are the most 286 expensive media server operations, both in terms of server loading 287 and client perceived latency. The Web browsing model of creating a 288 transport for each presentation works well in many Internet delivery 289 environments. In a non-IP delivery environment with dedicated media 290 delivery bandwidth, however, using a single transport for several 291 sequential presentations provides a better end user experience. 293 Allowing a single transport to handle multiple sequential 294 presentations requires extensions in the following areas: 296 - URI's 298 - Transport parameters 300 3.1 URI Enhancements 302 To allow a single transport to be used for different presentations, 303 the client may specify a different URI on a PLAY method request than 304 was used in the initial SETUP request. If a PLAY is requested with 305 a different URI than that most recently used in the session, the 306 presentation specified by the new URI will be played over the 307 existing session's transport. 309 For a PLAY request with a new URI to succeed, sufficient bandwidth 310 must already be available in the existing transport. This can be 311 reserved with an extension transport parameter on the initial SETUP 312 of the session ("bandwidth", described in section 3.2), or can be 313 allocated with a new SETUP request. 315 If a client uses queued PLAY requests with different URI's, it may 316 not be able to determine which presentation is active at any 317 particular time. To handle this case, an asterisk (*) for the URI 318 matches whatever presentation, if any, is currently active. Such a 319 wild card asterisk is legal for the following methods: 321 PLAY 322 PAUSE 323 TEARDOWN 324 GET_PARAMETER 325 SET_PARAMETER 327 3.2 bandwidth Transport Parameter 329 A client may use the "bandwidth" Transport parameter to reserve 330 bandwidth for a transport. Its argument is a decimal number 331 specifying the bandwidth to reserve in bits per second. If no 332 bandwidth parameter is given, it implies that the media server will 333 use the bit rate of the presentation specified in the SETUP 334 request's URI for the bandwidth of the transport. 336 The formal syntax for the "bandwidth" parameter is: 338 bandwidth = "bandwidth" "=" 1*DIGIT 340 4 PLAY Queue Enhancements 342 Requiring all new PLAY requests to be queued when another PLAY 343 request is active makes low-latency implementation of fast forward 344 and rewind difficult; it requires multiple requests to the media 345 server to stop the current PLAY and start the new one. Further, it 346 makes seamless transitions between normal and scaled play 347 impossible, since the current PLAY must be stopped, resulting in a 348 gap in the media delivery, before the new PLAY can be started. 350 Similarly, requiring all PAUSE requests to flush the queue of PLAY 351 requests is awkward. This forces a client to remember and reissue 352 all previously queued PLAY requests when it restarts a stream after 353 a PAUSE. 355 These problems can be resolved by allowing clients to specify the 356 type of queuing behavior they desire on each request. The proposed 357 mechanism uses two new headers: 359 Play-Now 360 No-Flush 362 4.1 Play-Now Header 364 A client may use the Play-Now header with either a SETUP or PLAY 365 method. 367 4.1.1 Play-Now with PLAY 369 When used in a PLAY request, this header indicates that the PLAY 370 operation should be performed immediately rather than queuing it. 371 Using Play-Now in a PLAY request causes any queued PLAY requests to 372 be discarded unless the No-Flush header is also included. 374 4.1.2 Play-Now with SETUP 376 When added to a SETUP request, this header indicates that the client 377 wants streaming to begin immediately (i.e., possibly even before the 378 SETUP response is sent to the client). This allows the client to 379 avoid waiting for the response from SETUP and then issuing a PLAY 380 command, but has some practical limitations. 382 Play-Now with SETUP is not useful in those environments where the 383 client requires information contained in the SETUP response before 384 it can start decoding the media stream. For example, if a set top 385 box needs the SETUP response to know which channel to tune to, it 386 will typically need to issue a separate PLAY command after it has 387 tuned to the proper channel. 389 If the Play-Now header is included in a SETUP request, Range and 390 Scale headers may also be included. 392 4.2 No-Flush Header 394 A client may use the No-Flush header with either a PAUSE or PLAY 395 method. When added to either request, it prevents queued PLAY 396 requests from being discarded. 398 4.3 Alternate Approach 400 An alternate approach to providing the same functionality would be 401 to define a single header with directives along the lines of the 402 Cache-Control header. An example of the syntax is: 404 Queue-Control = "Queue-Control" ":" queue-directive 405 *(";" queue-directive) 406 queue-directive = "play-now" 407 | "no-flush" 409 5 Server State Changes 411 Most clients need to track the state of the media server while the 412 server is streaming. The most critical state change to clients 413 occurs when the media server encounters the end of a presentation 414 (or the beginning when rewinding), and stops streaming. There are 415 currently no standard mechanisms for detecting this in the RTSP 416 specification. Problems clients encounter in the current 417 architecture include: 419 - Polling for the current media server state wastes network 420 bandwidth, and introduces unacceptable latencies in detecting 421 state transitions. 423 - In non-IP delivery environments, the transport typically 424 remains allocated even if no media is being delivered. This 425 means that a client cannot watch for the server to close the 426 transport to signal the end of media delivery. 428 - Watching for the incoming media to stop is unreliable. Short 429 timeouts can trigger a false end of media detection if the 430 media flow is temporarily delayed. Long timeouts introduce 431 unacceptable latencies. Clients are unable to distinguish 432 between a normal end of media and an error condition that 433 resulted in the media delivery stopping. 435 These problems can be remedied by a client callback mechanism. The 436 proposed mechanism uses the ANNOUNCE method sent from the server to 437 the client, along with a new header which contains the details of 438 media server state transitions. 440 5.1 ANNOUNCE Callbacks 442 If desired by the client, an ANNOUNCE request can be sent 443 asynchronously from the server to the client to notify it of any 444 changes in a session state. ANNOUNCE requests are only sent to a 445 client if the client used the May-Notify header in its SETUP request 446 for the session (section 5.2). The nature and time of the event 447 causing the stream state change are contained in the Notice header 448 (section 5.3). 450 An ANNOUNCE request will only be sent if the session is currently 451 associated with an open persistent connection to the client. If the 452 session is not associated with a connection to the client, the state 453 change notification will be returned in the next GET_PARAMETER 454 response for the session. 456 Alternate approaches would be to use GET_PARAMETER or SET_PARAMETER 457 for callbacks, or to define a new method. 459 5.2 May-Notify Header 461 The May-Notify header may be included in a SETUP request. 463 If a client includes the MayNotify header in a SETUP request, the 464 server will notify the client asynchronously of any stream state 465 changes by sending it an ANNOUNCE request (section 5.1). If this 466 header is not included, state changes are returned to the client as 467 part of a GET_PARAMETER response. In both cases, the state change 468 is reported with a Notice header (section 5.3). 470 5.3 Notice Header 472 The Notice header contains media server state change information for 473 a session, such as errors encountered during play or reaching the 474 end of the stream. It may only originate from a media server, and 475 is not recognized in client requests. The Notice header is sent 476 from the server to a client via either an ANNOUNCE request or a 477 GET_PARAMETER response (section 5.1). 479 The formal syntax for the Notice header is: 481 Notice = "Notice" ":" notify *("," notify) 483 notify = event-code SP """ event-phrase """ SP 484 "event-date" "=" utc-time 486 event-code = 4DIGIT 488 event-phrase = * 490 Event codes and phrases which may be returned by the server are: 492 Code Message 494 1103 Stream Stalled 496 1104 Stream Resumed 498 2101 End-of-Stream Reached 500 2103 Transition 502 2104 Start-of-Stream Reached 504 2306 Continuous Feed Terminated 506 4401 Error Reading Media Data 508 5201 Server Resources Unavailable 510 5401 Stream Failure 512 5402 Session Terminated by Server 514 5403 Server Shutting Down 516 5501 Internal Server Error 518 6 Miscellaneous 520 6.1 Reason Header 522 A client may wish to inform the server why it has chosen to tear 523 down a session. This is often useful in diagnosing server or 524 network problems. This is accomplished with the Reason header. The 525 Reason header is only valid in TEARDOWN requests. 527 How much of the Reason header message is saved by the media server, 528 or whether the message is saved at all, is up to the discretion of 529 the media server. Implementers of media servers should place limits 530 on the message length and message frequency to prevent the Reason 531 header from being used in denial-of-service attacks. 533 The formal syntax of the Reason header is: 535 Reason = "Reason" ":" reason-phrase 536 reason-phrase = * 538 6.2 Looping Ranges 540 Continuous looping play of a presentation is a frequent requirement 541 in commercial environments. This is typically used for movie 542 trailers, etc. 544 To support this, the Range header can be enhanced to allow clients 545 to ask the media server to continuously loop a presentation. The 546 formal syntax of the extended Range header is: 548 Range = "Range" ":" 1\#ranges-specifier *(range-option) 549 range-option = ";" "time" "=" utc-time 550 | ";" "loop" [ "=" loop-count ] 551 loop-count = 1*DIGIT 553 Adding the "loop" option to a Range header causes the specified 554 range within the media to loop for "loop-count" iterations, or 555 forever if no "loop-count" is specified. 557 A PAUSE request or another PLAY request for the session will stop 558 the looping. A PAUSE request will terminate the loop immediately. 559 A queued PLAY request (without the Play-Now header, section 4.1) 560 will terminate the loop at the end of the current iteration. A PLAY 561 request with the Play-Now header will terminate the loop 562 immediately. 564 6.3 Additional Status Codes 566 The following two standard status codes should be added: 568 Code Message 570 463 Destination Required 572 464 Unable to Visual Scan 574 Code 463 indicates that the media server was unable to select an 575 appropriate transport destination address for the client, and that 576 the client must supply one explicitly. It may only be returned in 577 SETUP responses. 579 Code 464 may only be returned in response to a PLAY request, which 580 includes a scale other than 1. It indicates that the server is 581 unable to stream the media at a rate other than normal speed 582 forward. This may be a temporary condition caused, for example, by 583 unusually heavy loading on the media server. It may also be a 584 permanent condition due, for example, to media encoding limitations 585 or media server policy. 587 6.4 Stream Parameters 589 Standard parameters need to be defined for the GET_PARAMETER method 590 to be generally useful. Proposed standard parameters are: 592 stream_state The current stream state. Possible 593 returned values are: 595 playing 596 ready 598 position The current stream position. The position 599 is the number of seconds from the 600 beginning of the media in npt format. 602 Appendix A: Author's Address 604 Sean Sheedy 605 nCUBE Corporation 606 1825 NW 167th Place 607 Beaverton, OR 97006 608 USA 610 E-mail: seans@ncube.com 612 References 614 1. Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 615 Protocol (RTSP)", RFC 2326, April 1998. 617 2. Handley, M., and V. Jacobson, "SDP: Session Description Protocol", 618 RFC 2327, April 1998. 620 3. nCUBE Corporation, "nCUBE RTSP Implementation and Extensions", 621 January 2000. 623 4. Oracle Corporation, "Custom Video Client Developer's Guide, Release 624 3.2", September 1999. 626 5. International Telecommunication Union, "Generic Coding of Moving 627 Pictures and Associated Audio Information: Systems", H.222.0, July 628 1995. 630 6. International Telecommunication Union, "Multimedia Multiplex and 631 Synchronization for Audiovisual Communication in ATM Environments", 632 H.222.1, March 1996. 634 7. European Telecommunications Standards Institute, "Digital Video 635 Broadcasting: Framing Structure, Channel Coding and Modulation For 636 Cable Systems", EN 300 429, October 1997.