idnits 2.17.1 draft-sheedy-mmusic-rtsp-ext-01.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 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? '2' on line 109 looks like a reference -- Missing reference section? '3' on line 112 looks like a reference -- Missing reference section? '4' on line 116 looks like a reference -- Missing reference section? '5' on line 128 looks like a reference -- Missing reference section? '6' on line 132 looks like a reference -- Missing reference section? '7' on line 189 looks like a reference -- Missing reference section? '8' on line 192 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Expires: 12 January 2001 3 Sean Sheedy 4 nCUBE Corporation 6 RTSP Extensions: 7 Additional Transports and Performance Enhancements 9 draft-sheedy-mmusic-rtsp-ext-01.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 that 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 [2]. 110 These enhancements were developed in collaboration with Oracle 111 Corporation, who has also incorporated similar features in their 112 RTSP server [3]. The remainder of this document proposes a set of 113 enhancements to the RTSP standard based on both of these 114 implementations. 116 This document does not address extensions to the SDP standard [4] 117 that may also be required. 119 2 Transports and Lower Transports 121 Other media delivery mechanisms besides RTP are used in many 122 commercial video-on-demand deployments. To support this, new 123 transports and lower transports in addition to the current standard 124 RTP and UDP are needed. 126 The names and address syntax for these transports and lower 127 transports are intended to match those in proposed extensions to SDP 128 syntax [5]. 130 2.1 Transports 132 MPEG-2 is used extensively for high bandwidth video [6]. An 133 enhancement to the "transport-protocol" field in the "Transport" 134 header to support this is: 136 MP2T MPEG-2 Transport 138 The new syntax of "transport-protocol" would then be: 140 transport-protocol = "RTP" | "MP2T" 142 2.2 Lower Transports 144 Similarly, TCP or UDP are not always used as lower transports. 145 Enhancements to the "lower-transport" field are: 147 AAL5 ATM Adaptation Layer 5 148 ASI DVB Asynchronous Serial Interface 150 QAM Quadrature Amplitude Modulation 152 The new syntax of "lower-transport" would then be: 154 lower-transport = "TCP" | "UDP" | "AAL5" | "ASI" | "QAM" 156 (Note that end user RTSP clients typically don't request a DVB-ASI 157 lower transport. This is primarily used by bridging servers that 158 are also controlling external hardware such as QAM modulators.) 160 2.3 Destinations 162 To handle the additional lower transport types, the syntax of the 163 "destination" transport parameter needs to be enhanced. In 164 particular, many lower transports described in section 2.2 use 165 addresses that are not globally unique, but are unique only within a 166 particular physical channel. The destination "address" field should 167 contain an optional identifier string at the beginning to allow 168 sufficiently intelligent clients (such as bridging servers) to 169 disambiguate between physical channels. 171 The formal syntax for the expanded "destination" addresses is: 173 address = [ id-string ":" ] type-address 175 type-address = host 176 | atm-address 177 | qam-address 179 id-string = 1*( ALPHA | DIGIT | "_" ) 181 (Note that QAM and DVB-ASI addressing are identical, and both are 182 covered by the "qam-address" rule.) 184 The AVP profile is used with all of these lower transports. The 185 behavior specified by the AVP profile is defined by existing 186 standards, and depends upon the lower transport type: 188 AAL5 The ITU H.222.1 standard for MPEG delivery over 189 ATM [7] 191 ASI The Digital Video Broadcasting - Cable standard 192 QAM [8] 194 2.3.1 ATM Address 196 The destination address for ATM may be either an ATM permanent 197 virtual circuit address or an ATM switched virtual circuit address: 199 atm-address = atm-pvc-address 200 | atm-svc-address 202 2.3.1.1 ATM PVC Address 204 The destination address for an ATM permanent virtual circuit is the 205 VPI and VCI of the client, and the port number on the server of the 206 physical trunk that connects to the client. Numbers may be 207 specified in either decimal or hexadecimal (preceded by "0x"): 209 atm-pvc-address = atm-port "/" vpi "/" vci 211 atm-port = 1*5(DIGIT) 212 | "0x" 1*4(HEX) 213 vpi = 1*5(DIGIT) 214 | "0x" 1*4(HEX) 215 vci = 1*5(DIGIT) 216 | "0x" 1*4(HEX) 218 For example, to use ATM permanent virtual circuits a client may 219 specify a Transport header like the following: 221 Transport: MP2T/AVP/AAL5;unicast;destination=0/0/40 223 2.3.1.2 ATM SVC Address 225 The destination address for an ATM switched virtual circuit is the 226 20-byte network service access point (NSAP) address, specified as 40 227 hex characters without a "0x" prefix. Optionally, dots may be 228 included after 16-bit fields, with the first dot following an 8-bit 229 field: 231 atm-svc-address = 20*20(HEX) 232 | 2*2(HEX) 9*9( "." 4*4(HEX) ) "." 2*2(HEX) 234 For example, to use ATM switched virtual circuits a client may 235 specify a Transport header like the following: 237 Transport: MP2T/AVP/AAL5;unicast; 238 destination=47000580ffe1000000f21a360b00204821490f01 240 2.3.2 QAM and DVB-ASI Addresses 242 The destination address for QAM or DVB-ASI is a server-specific 243 channel number (note that this is not the RF channel number) and 244 MPEG-2 program number specified in decimal: 246 qam-address = channel-number "." program-number 248 channel-number = 1*3(DIGIT) 249 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/AVP/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/AVP/ASI;unicast;destination=dac00:0.75 260 2.4 Client Identification 262 For most video-on-demand environments, clients cannot be allowed to 263 specify a transport destination address. In non-IP delivery 264 environments, they typically do not have sufficient knowledge of the 265 network topology to properly specify an address. In all 266 environments, allowing clients to choose an address presents 267 security problems. Further, in many non-IP delivery environments 268 (such as cable systems using QAM and DOCSIS), valid transport 269 addresses cannot be derived from the IP address of the client. 271 To resolve these problems, the client must be able to identify 272 itself to the media server. This can be accomplished by adding a 273 new Transport parameter, "client". The argument to "client" is a 274 deployment-specific string that uniquely identifies a client. 275 Identity information included in the string may be, for example, a 276 smart card ID for a set top box and the optical node to which the 277 set top box is connected. 279 The formal syntax for the "client" parameter is: 281 client = "client" "=" client-id 282 client-id = token 284 3 Reuse of Transports 286 In some environments, such as commercial ATM or QAM deployments, 287 transport properties do not change from presentation to 288 presentation, and setting up sessions is expensive, in terms of both 289 server loading and client perceived latency. The Web browsing model 290 of creating a transport for each presentation works well in many 291 Internet delivery environments. In a non-IP delivery environment 292 with dedicated media delivery bandwidth, however, using a single 293 transport for several sequential presentations provides a better end 294 user experience. 296 Allowing a single transport to handle multiple sequential 297 presentations requires extensions in the following areas: 299 - Presentation URI's 301 - Transport parameters 302 3.1 Presentation URI Enhancements 304 Reusing an existing transport for different presentations requires a 305 mechanism to change the presentation URI, and URI wildcarding to 306 allow clients to control playout in cases when the currently active 307 presentation on the server is not known precisely. 309 3.1.1 Changing Presentation URI 311 To play a different presentation on an existing transport, the 312 client may specify a different presentation URI on a PLAY method 313 request than was used in the initial SETUP request. If a PLAY is 314 requested with a different presentation URI than that most recently 315 used in the session, the presentation specified by the new URI will 316 be played over the existing session's transport. 318 For a PLAY request with a new presentation URI to succeed, 319 sufficient bandwidth must already be available in the existing 320 transport. This can be reserved with an extension transport 321 parameter on the initial SETUP of the session ("bandwidth", 322 described in section 3.2), or can be allocated with a new SETUP 323 request. 325 Changing a presentation URI is only allowed if the server supports 326 aggregate control of both the current presentation and the new 327 presentation. If this is not the case, the server must respond with 328 error 459, "Aggregate Operation Not Allowed". 330 If the new URI requested by a client is not a presentation URI, the 331 server must respond with error 460, "Only Aggregate Operation 332 Allowed". 334 3.1.2 Wildcard Presentation URI 336 If a client uses queued PLAY requests with different URI's, it may 337 not be able to determine which presentation is active at any 338 particular time. To handle this case, an asterisk (*) for the URI 339 matches whatever presentation URI, if any, is currently active. 340 Such a wild card asterisk is legal only for the following methods: 342 PLAY 343 PAUSE 344 TEARDOWN 345 GET_PARAMETER 346 SET_PARAMETER 348 Wildcard URI's may not be used with SETUP requests. If a client 349 uses a wildcard URI in a SETUP request, the server must respond with 350 an error 404, "Not Found". 352 3.1.2.1 URI Response Header 354 In a response to a request containing a wildcard URI, the server 355 must include a URI header its response to indicate the actual 356 presentation URI affected by the request. The syntax of the URI 357 response header is: 359 URI-Response = "URI" ":" absolute_URI 361 3.2 bandwidth Transport Parameter 363 A client may use the "bandwidth" Transport parameter to reserve 364 bandwidth for a transport. Its argument is a decimal number 365 specifying the bandwidth to reserve in bits per second. If no 366 bandwidth parameter is given, it implies that the media server will 367 use the bit rate of the presentation specified in the SETUP 368 request's URI for the bandwidth of the transport. 370 The formal syntax for the "bandwidth" parameter is: 372 bandwidth = "bandwidth" "=" 1*DIGIT 374 4 PLAY Queue Enhancements 376 Requiring all new PLAY requests to be queued when another PLAY 377 request is active makes low-latency implementation of fast forward 378 and rewind difficult; it requires multiple requests to the media 379 server to stop the current PLAY and start the new one. Further, it 380 makes seamless transitions between normal and scaled play 381 impossible, since the current PLAY must be stopped, resulting in a 382 gap in the media delivery, before the new PLAY can be started. 384 Similarly, requiring all PAUSE requests to flush the queue of PLAY 385 requests is awkward. This forces a client to remember and reissue 386 all previously queued PLAY requests when it restarts a stream after 387 a PAUSE. 389 These problems can be resolved by allowing clients to specify the 390 type of queuing behavior they desire on each request. The proposed 391 mechanism uses a new header "Queue-Control" with two options for 392 specifying queueing behavior. The syntax is: 394 Queue-Control = "Queue-Control" ":" queue-directive 395 *(";" queue-directive) 396 queue-directive = "play-now" 397 | "no-flush" 399 4.1 play-now Directive 401 A client may use the play-now directive with either a SETUP or PLAY 402 method. 404 4.1.1 play-now with PLAY 406 When used in a PLAY request, the play-now directive indicates that 407 the PLAY operation should be performed immediately rather than 408 queuing it. Using play-now in a PLAY request causes any queued PLAY 409 requests to be discarded unless the no-flush directive is also 410 included. 412 4.1.2 play-now with SETUP 414 When added to a SETUP request, the play-now directive indicates that 415 the client wants streaming to begin immediately (i.e., possibly even 416 before the SETUP response is sent to the client). This allows the 417 client to avoid waiting for the response from SETUP and then issuing 418 a PLAY command, but has some practical limitations. 420 The play-now directive with SETUP is not useful in those 421 environments where the client requires information contained in the 422 SETUP response before it can start decoding the media stream. For 423 example, if a set top box needs the SETUP response to know which 424 channel to tune to, it will typically need to issue a separate PLAY 425 command after it has tuned to the proper channel. 427 If the play-now directive is included in a SETUP request, Range, 428 Scale and Speed headers may also be included. 430 4.2 no-flush Directive 432 A client may use the no-flush directive with either a PAUSE or PLAY 433 method. When added to either request, it prevents queued PLAY 434 requests from being discarded. 436 5 Server State Changes 438 Most clients need to track the state of the media server while the 439 server is streaming. The most critical state change to clients 440 occurs when the media server encounters the end of a presentation 441 (or the beginning when rewinding), and stops streaming. There are 442 currently no standard mechanisms for detecting this in the RTSP 443 specification. Problems clients encounter in the current 444 architecture include: 446 - Polling for the current media server state wastes network 447 bandwidth, and introduces unacceptable latencies in detecting 448 state transitions. 450 - In non-IP delivery environments, the transport typically 451 remains allocated even if no media is being delivered. This 452 means that a client cannot watch for the server to close the 453 transport to signal the end of media delivery. 455 - Watching for the incoming media to stop is unreliable. Short 456 timeouts can trigger a false end of media detection if the 457 media flow is temporarily delayed. Long timeouts introduce 458 unacceptable latencies. Clients are unable to distinguish 459 between a normal end of media and an error condition that 460 resulted in the media delivery stopping. 462 These problems can be remedied by a client callback mechanism. The 463 proposed mechanism uses the ANNOUNCE method sent from the server to 464 the client, along with a new header which contains the details of 465 media server state transitions. 467 5.1 ANNOUNCE Callbacks 469 If desired by the client, an ANNOUNCE request can be sent 470 asynchronously from the server to the client to notify it of any 471 changes in a session state. ANNOUNCE requests are only sent to a 472 client if the client used the May-Notify header in its SETUP request 473 for the session (section 5.2). The nature and time of the event 474 causing the stream state change are contained in the Notice header 475 (section 5.3). 477 An ANNOUNCE request will only be sent if the session is currently 478 associated with an open persistent connection to the client. If the 479 session is not associated with a connection to the client, the state 480 change notification will be returned in the next GET_PARAMETER 481 response for the session. 483 5.2 May-Notify Header 485 The May-Notify header may be included in a SETUP request. 487 If a client includes the May-Notify header in a SETUP request, the 488 server will notify the client asynchronously of any stream state 489 changes by sending it an ANNOUNCE request (section 5.1). If this 490 header is not included, state changes are returned to the client as 491 part of a GET_PARAMETER response. In both cases, the state change 492 is reported with a Notice header (section 5.3). 494 5.3 Notice Header 496 The Notice header contains media server state change information for 497 a session, such as errors encountered during play or reaching the 498 end of the stream. It may only originate from a media server, and 499 is not recognized in client requests. The Notice header is sent 500 from the server to a client via either an ANNOUNCE request or a 501 GET_PARAMETER response (section 5.1). 503 The formal syntax for the Notice header is: 505 Notice = "Notice" ":" notify *("," notify) 506 notify = event-code SP """ event-phrase """ SP 507 "event-date" "=" utc-time 509 event-code = 4DIGIT 511 event-phrase = * 513 Event codes and phrases which may be returned by the server are: 515 Code Message 517 1103 Stream Stalled 519 1104 Stream Resumed 521 2101 End-of-Stream Reached 523 2103 Transition 525 2104 Start-of-Stream Reached 527 2306 Continuous Feed Terminated 529 4401 Error Reading Media Data 531 5201 Server Resources Unavailable 533 5401 Stream Failure 535 5402 Session Terminated by Server 537 5403 Server Shutting Down 539 5501 Internal Server Error 541 6 Miscellaneous 543 6.1 Reason Header 545 A client may wish to inform the server why it has chosen to tear 546 down a session. This is often useful in diagnosing server or 547 network problems. This is accomplished with the Reason header. The 548 Reason header is only valid in TEARDOWN requests. 550 How much of the Reason header message is saved by the media server, 551 or whether the message is saved at all, is up to the discretion of 552 the media server. Implementers of media servers should place limits 553 on the message length and message frequency to prevent the Reason 554 header from being used in denial-of-service attacks. 556 The formal syntax of the Reason header is: 558 Reason = "Reason" ":" reason-phrase 559 reason-phrase = * 561 6.2 Looping Ranges 563 Continuous looping play of a presentation is a frequent requirement 564 in commercial environments. This is typically used for movie 565 trailers, etc. 567 To support this, the Range header can be enhanced to allow clients 568 to ask the media server to continuously loop a presentation. The 569 formal syntax of the extended Range header is: 571 Range = "Range" ":" 1\#ranges-specifier *(range-option) 572 range-option = ";" "time" "=" utc-time 573 | ";" "loop" [ "=" loop-count ] 574 loop-count = 1*DIGIT 576 Adding the "loop" option to a Range header causes the specified 577 range within the media to loop for "loop-count" iterations, or 578 forever if no "loop-count" is specified. 580 A PAUSE request or another PLAY request for the session will stop 581 the looping. A PAUSE request will terminate the loop immediately. 582 A queued PLAY request (without the play-now directive, section 4.1) 583 will terminate the loop at the end of the current iteration. A PLAY 584 request with the play-now directive will terminate the loop 585 immediately. 587 6.3 Additional Status Codes 589 The following two standard status codes should be added: 591 Code Message 593 463 Destination Required 595 464 Unable to Visual Scan 597 Code 463 indicates that the media server was unable to select an 598 appropriate transport destination address for the client, and that 599 the client must supply one explicitly. It may only be returned in 600 SETUP responses. 602 Code 464 may only be returned in response to a PLAY request, which 603 includes a scale other than 1. It indicates that the server is 604 unable to stream the media at a rate other than normal speed 605 forward. This may be a temporary condition caused, for example, by 606 unusually heavy loading on the media server. It may also be a 607 permanent condition due, for example, to media encoding limitations 608 or media server policy. 610 6.4 Stream Parameters 612 Standard parameters need to be defined for the GET_PARAMETER method 613 to be generally useful. Proposed standard parameters are: 615 state The current server protocol state. Possible 616 returned values are: 618 playing 619 ready 621 position The current stream position. The position is 622 the number of seconds from the beginning of 623 the media, in npt format. 625 scale The current stream scale. 627 Appendix A: Author's Address 629 Sean Sheedy 630 nCUBE Corporation 631 1825 NW 167th Place 632 Beaverton, OR 97006 633 USA 635 E-mail: seans@ncube.com 637 References 639 1. Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 640 Protocol (RTSP)", RFC 2326, April 1998. 642 2. nCUBE Corporation, "nCUBE RTSP Implementation and Extensions", 643 January 2000. 645 3. Oracle Corporation, "Custom Video Client Developer's Guide, Release 646 3.2", September 1999. 648 4. Handley, M., and V. Jacobson, "SDP: Session Description Protocol", 649 RFC 2327, April 1998. 651 5. Kumar, R. and M. Mostafa, "Conventions for the use of the Session 652 Description Protocol (SDP) for ATM Bearer Connections", draft- 653 rajeshkumar-mmusic-sdp-atm-02.txt, July 2000. 655 6. International Telecommunication Union, "Generic Coding of Moving 656 Pictures and Associated Audio Information: Systems", H.222.0, July 657 1995. 659 7. International Telecommunication Union, "Multimedia Multiplex and 660 Synchronization for Audiovisual Communication in ATM Environments", 661 H.222.1, March 1996. 663 8. European Telecommunications Standards Institute, "Digital Video 664 Broadcasting: Framing Structure, Channel Coding and Modulation For 665 Cable Systems", EN 300 429, October 1997.