idnits 2.17.1 draft-whitehead-mmusic-sip-for-streaming-media-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 562. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 12, 2008) is 5828 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-18 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Whitehead 3 Internet-Draft Verizon Laboratories Inc. 4 Intended status: Informational M. Montpetit 5 Expires: November 13, 2008 Motorola 6 X. Marjou 7 France Telecom 8 S. Ganesan 9 Motorola 10 J. Lindquist 11 Ericsson 12 May 12, 2008 14 Media Playback Control Protocol Requirements 15 draft-whitehead-mmusic-sip-for-streaming-media-05 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on November 13, 2008. 42 Abstract 44 The media playback control functionality controls the delivery of 45 streaming media by the means of commands like pause, fast forward, 46 fast rewind, slow forward, slow rewind. This document presents some 47 of the requirements for a media control protocol that does not 48 contain any session setup semantics in it. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Characteristics . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Use Case Descriptions . . . . . . . . . . . . . . . . . . 4 57 3.3. Server Control of Streaming Session . . . . . . . . . . . 5 58 3.4. Remote Access to Private/Firewalled Video Content . . . . 5 59 3.5. VOD services that requires resource or QOS-guarantees . . 5 60 3.6. Intelligent selection of media encoding . . . . . . . . . 6 61 3.7. Voice/video mailbox . . . . . . . . . . . . . . . . . . . 6 62 3.8. Motion Detection . . . . . . . . . . . . . . . . . . . . . 6 63 3.9. Video Subscriptions . . . . . . . . . . . . . . . . . . . 6 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Considerations for session control protocol . . . . . . . . . 7 66 6. Call Flows of Use Cases . . . . . . . . . . . . . . . . . . . 8 67 6.1. Content on Demand Session Initiation . . . . . . . . . . . 8 68 6.2. Content on Demand Session Termination . . . . . . . . . . 9 69 6.3. Activation of trick play of linear TV Session 70 Modification . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.4. Deactivation of trick play of linear TV Session 72 Modification . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Normative references . . . . . . . . . . . . . . . . . . . 11 78 10.2. Informative references . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Intellectual Property and Copyright Statements . . . . . . . . . . 13 82 1. Introduction 84 This document defines the requirements for a media control protocol 85 distinct from the session control protocol for Content on demand 86 media streams. 88 Historically media stream delivery has been controlled by RTSP as 89 both the session set up protocol as well as the media control 90 protocol. RTSP [RFC2326] and its successor [RFC2326bis] define 91 semantics for both session setup as well as media control, with 92 commands like pause, Rewind etc. 94 Similarly SIP has been the protocol of choice for end to end session 95 establishment and rendezvous [RFC3261]. These functionalities in the 96 context of conversational services has been the main raison d'etre 97 and forte of SIP. 99 There exist environments, circumstances and use cases where it is 100 desirable to use SIP for session establishment and rendezvous, while 101 retaining RTSP's capabilities for media and play back control. Such 102 circumstances are increasing in number given that user agents with 103 wide ranging capabilities are become much more common in deployments. 104 Good Integration with existing RTSP deployments is also desirable 105 under these conditions. 107 Section 3 describes some use cases that motivate this work. 109 Section 4 lays out the requirements for a media control protocol, 110 ideally some form of lightweight RTSP without its session 111 establishment semantics, that can be used with a session 112 establishment and rendezvous protocol. 114 2. Terminology 116 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 117 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 118 and "OPTIONAL" are to be interpreted as described in RFC 2119 119 [RFC2119]. 121 3. Use Case Scenarios 123 The scope of scenarios for this document includes applications with 124 the following characteristics: content-on-demand, streaming media, 125 unicast-media streams, live or recorded content, ubiquitous access 126 (any-device, any-access). 128 While of interest, non-streaming media applications, such as 129 downloaded media services, are outside the scope of this document. 131 3.1. Characteristics 133 For the purposes of this document, the term 'controlled streaming 134 media application' represents a class of applications with the 135 following characteristics: 136 o Multiple servers that can be a source of content but showing up as 137 a single muxed stream at the client. 138 o One or more clients can receive the content. 139 o The media stream(s) needs to be delivered isochronously, in the 140 most common case: the client intends to begin rendering the media 141 before delivery is complete. 142 o Less common but equally valid, the server does not have resources 143 to buffer content until the client is ready to receive it, e.g., a 144 live feed. 145 o A session exists between source (e.g. server or peer) and 146 destination (e.g. client or peer). 147 o The session is established, managed, and terminated through the 148 use of a signaling protocol, in which control messages are 149 exchanged (either directly or indirectly) between the source and 150 the destination referred to as 'session signaling'. 151 o The application supports media stream control. The client(s), or 152 a proxy element acting on behalf of the client(s), has the ability 153 to manipulate the media stream (or other aspect of the 154 application) via signaling. This is referred to as media control 155 signaling (or application signaling ). 157 3.2. Use Case Descriptions 159 As IP-based broadband data services have continued to develop and 160 expand, opportunities for streaming media applications have also 161 proliferated and expanded beyond the traditional framework. This 162 section describes several streaming media application use case 163 scenarios. These scenarios illustrate the variety of conditions and 164 environments in which streaming media applications need to operate. 166 Use cases are used with the purpose of clarifying the 'streaming 167 media application' and to explore the application space. The 168 objectives are to: 169 o Clarify the frame / scope the discussion. 170 o Illustrate some of usage scenarios. 171 o Identify some of the key attributes that characterize these use 172 cases. 174 3.3. Server Control of Streaming Session 176 During a streaming session, the operator may want to redirect or move 177 pending sessions in order to for e.g., upgrade the server. 178 Therefore, the server will initiate a session redirect. Another use 179 case of Server control operation is when the server decides to 180 initiate a session to the user, based on user preconfigured-settings 181 (e.g. reminders). Further, sessions that are indefinitely paused by 182 the client need to be terminated and server resources reclaimed at 183 the operators discretion. This would also be true for sessions where 184 the client may have become unresponsive. 186 3.4. Remote Access to Private/Firewalled Video Content 188 In this use case, the user, while not on his home network, wants to 189 access content that is stored on his personal or home network, e.g., 190 a pre-recorded show on a PVR device, or a monitoring camera at his or 191 her home location that is capable of providing a live feed as well as 192 record it locally as a PVR asset. 194 In the case of a live monitoring camera in a home network, the user 195 wishes to transition from watching a live stream of the feed to being 196 able to move backwards and forwards using media control commands on 197 the stored content of the monitoring device. This translates 198 logically to transitioning from watching live TV programming to Time 199 shifted TV or PVR type of viewing. Being able to do it in the 200 context of the same session is desirable. 202 In the case of a home network based PVR, it is more than likely that 203 the home gateway is not set up to be an inbound device for various 204 session setup requests to enable the external client to traverse the 205 protocol unaware IP NAT device commonly found at the edge of home 206 networks. 208 In both these cases, the video server is behind a firewall. In the 209 first case, the transition from one mode (live feed) to another 210 (COD), would entail multiple messages for staying within a session. 211 Also, the client being exterior to the firewall, needs to establish a 212 TCP connection from "out" to "in". RTSP as in stands currently does 213 not deal with these adequately. A rendezvous capable protocol like 214 SIP could provide this in addition to client identity and location. 216 3.5. VOD services that requires resource or QOS-guarantees 218 Consider a Video on Demand (stored video) service provided as a 219 unicast session to an end user device from a server. The user 220 requests a VOD movie. If the operator uses a network proxy to 221 request and guarentee QoS for the delivery of the movie from the 222 server to the client, currently RTSP does not provide the means of 223 guarenteeing that all subsequent messages that form part of the RTSP 224 session will go through the network proxy that manages the QoS. In 225 this particular use case, an end to end session setup and management 226 protocol would be helpful. 228 3.6. Intelligent selection of media encoding 230 A user orders content to be delivered to its current device. The 231 content could exist in different format (e.g. standard definition or 232 high definition) or encoding (e.g. MPEG2, MPEG4, ...). In addition 233 the device can be located behing different types of access networks, 234 which implies bandwidth constraints. The selection of media encoding 235 can be adjusted to accomodate these multiple characteristics. 237 3.7. Voice/video mailbox 239 The control of the server may be extended to a voice/video mailbox 240 system. In addition to controlling the playing of the messages and 241 fast forward or rewind similar to content on demand with a couple of 242 additional commands to delete or save messages it is possible o have 243 access to a mailbox system. THe mailbox may be located in the home 244 or in the network accessed from the home. If the mailbox is at home 245 then it is possible to remotely access to the messages. 247 3.8. Motion Detection 249 Motion-detecting or pattern-matching cameras may need to call a human 250 when motion/pattern is detected and may also have a buffer, which 251 allow the human to place pause/rewind commands. 253 3.9. Video Subscriptions 255 A user subscribes on a webpage to get all new local high-school 256 football games, or Voipsa blue-box podcasts. He wants his DVR/TV to 257 pop up with the option to play them immediately, or record them to 258 DVR, or neither. The high-school football game is not available from 259 cable TV, so the DVR doesn't have a schedule to know when to get it 260 by itself. Of course this could be done with an off-line indication, 261 such as email, but it would be nice if his DVR didn't need to support 262 email. 264 4. Requirements 266 This section outlines the key requirements that need to be satisfied 267 in order to have a media control protocol acting as a control stream 268 within a multimedia session. 270 REQ-1 The media control protocol must support commands such as play, 271 pause, rewind, forward, fast rewind, fast forward, slow 272 rewind, and slow forward. 274 REQ-2 It must be possible to negotiate the media control protocol of 275 a media stream. 277 REQ-3 If the media control protocol does not apply to all media 278 streams of a given session, it must be possible to indicate 279 the specific media streams that are under the scope of the 280 trick-play control protocol. 282 REQ-4 The media control protocol must allow for asynchronous media 283 event notifications (e.g.: end-of-stream)". 285 REQ-5 The protocol SHOULD work over TCP. 287 REQ-6 The media stream, or media control server, to be controlled by 288 the client may be located in the network or in the home 289 network. 291 REQ-7 The media control protocol shall consider additional commands 292 not available in RTSP to control the media in the server. 293 Examples of such commands are deletion or saving of voice 294 messages. 296 5. Considerations for session control protocol 298 This section raises a number of areas that need consideration while 299 developing new standards for the use cases: 301 1. RTSP protocol assumes a media server is located in the network 302 and not in the home. The session protocol shall be possible to 303 establish a relationship that allows for control of media resoruces 304 in both the home and network. 306 2. The session protocol shall be able to handle NAT and not affect 307 the call flows being defined. 309 3. If assuming SIP for session protocol there is a well accepted 310 architecture defined called IMS, IP Multimedia Solution, which is 311 accepted by a number of standard organizations like 3GPP, ETSI 312 TISPAN, ATIS, etc. There is a number of services have been defined 313 using the architecture like telephony, push to talk, presence, 314 messaging, chat and IPTV. 316 4. In conjunction with IMS there is a resource and admition control 317 architecture called RACS defined in ETSI TISPAN which helps ensure 318 QoS for services defined over IMS and addresses reuse of network 319 resources. What is of special interest is bandwidth reservation is 320 addressed for unicast and multicast media streams as well as handling 321 of multicast addresses used for IPTV. 323 5. IMS also provides additional authentication mechanisms which 324 allow alternatives for HTTP Digest like the Authentication and Key 325 Agreement mechanism (AKA). 327 6. The session protocol shall allow server initiated control of 328 streaming sessions such as server-initiated session terminations. 329 RTSP TEARDOWNs are from client to server only. 331 6. Call Flows of Use Cases 333 6.1. Content on Demand Session Initiation 335 For content on demand the session initiation established two media 336 streams, one for media control channel and one for media delivery 337 channel between the entities Media Control Client and Server. All 338 required information for establishing the two channels are conveyed 339 in the session initiation. 341 The proxy acts as back-to-back user agent for the session control. 342 The proxy may open pin-holes for the media control channel and 343 protocol. The proxy is used to protect the core network which the 344 Media Control Server is located. 346 Media Control Client Proxy Media Control Server 347 | | | 348 1. |--- session initiation --->| | 349 2. | |--- session initiation --->| 350 3. | |<-- confirm initiation ----| 351 4. |<-- confirm initiation ----| | 352 5. |<-- Media control channel established ---------------->| 353 | | 354 6. |=== request play media ===============================>| 355 7. |<== confirm play media ================================| 356 | | 357 8. |<-- Media delivery channel established --------------->| 359 The Media Control Client or Server do not need to be strickly located 360 in a home for the Client and the network for the Server. The roles 361 may reversed. The Client may be located in the network as a remote 362 user attempting to access the content in the home; the Server is then 363 located in the home. 365 Other use cases compared to content on demand may be supported that 366 follow theses sequences. For example voice/video mailbox may be 367 supported. 369 6.2. Content on Demand Session Termination 371 When content on demand is terminated either the media control client 372 or server may initiate a session termination. Pin-holes that may 373 previously have been established are closed. 375 Media Control Client Proxy Media Control Server 376 | | | 377 1. |--- session termination -->| | 378 2. | |--- session termination -->| 379 3. | |<-- confirm termination ---| 380 4. |<-- confirm termination ---| | 382 Alternatively the server may terminate the session. 384 Media Control Client Proxy Media Control Server 385 | | | 386 1. | |<--- session termination --| 387 2. |<--- session termination --| | 388 3. |--- confirm termination--->| | 389 4. | |--- confirm termination -->| 391 6.3. Activation of trick play of linear TV Session Modification 393 The first 5 steps setup linear TV and a multicast media delivery 394 channel. If proxy is aware of the bandwidth limitations for the 395 client it may reserve the required bandwidth for the session. Note 396 that parallel sessions may be established for the same client to 397 convey multiple linear TV channels at the same time. 399 When the user pauses live TV the same session is used to modify the 400 media requirements from a multicast media channel to a media control 401 and unicast media channels. If session modification is successful 402 then the live TV is paused. If unsuccessful then the linear TV is 403 maintained without affecting the use viewing experience. By 404 performing the action within the same session network resources are 405 not released when transitioning between multicast and unicast 406 otherwise there is a risk that resources are not anymore available if 407 trying to reestablish the previous session. 409 Media Control Client Proxy Media Control Server 410 | | | 411 1. |--- session initiation --->| | 412 2. | |--- session initiation --->| 413 3. | |<-- confirm initiation ----| 414 4. |<-- confirm initiation ----| | 415 5. |<-- Multicast media delivery channel established ----->| 416 | | 417 6. User pauses live TV 418 7. |--- session modification ->| | 419 8. | |--- session modification ->| 420 9. | |<-- confirm modification --| 421 10. |<-- confirm modification --| | 422 11. |<-- Media control channel established ---------------->| 423 12. |=== request pause media ==============================>| 424 13. |<== confirm pause media ===============================| 425 14. |<-- Unicast media delivery channel established ------->| 427 6.4. Deactivation of trick play of linear TV Session Modification 429 When the user switches TV channels or catches up with live TV then 430 the session modification is performed and media requirements are 431 changed from a media control and unicast media channels to a multicat 432 media channel. Note that if user chooses to end viewing session 433 termination is performed directly with modification. 435 Media Control Client Proxy Media Control Server 436 | | | 437 1. |<-- Unicast media delivery channel ongoing ------------>| 438 | | 439 2. |--- session modification ->| | 440 3. | |--- session modification -->| 441 4. | |<-- confirm modification ---| 442 5. |<-- confirm modification --| | 443 | | 444 6. |<-- Multicast media delivery channel established ------>| 446 7. Security Considerations 448 T.B.D. 450 8. IANA Considerations 452 This document has no actions for IANA. 454 9. Acknowledgements 456 Thanks to Christer Holmberg from Ericsson, Priya Rajagopal from 457 Motorola , Mikhael Said from France Telecom, Dan Wing from Cisco, and 458 Hadriel Kaplan from Acme Packet. 460 10. References 462 10.1. Normative references 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 10.2. Informative references 469 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 470 Streaming Protocol (RTSP)", RFC 2326, April 1998. 472 [RFC2326bis] 473 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 474 and M. Stiemerling, "Real Time Streaming Protocol 2.0 475 (RTSP)", draft-ietf-mmusic-rfc2326bis-18 (work in 476 progress), November 2007. 478 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 479 A., Peterson, J., Sparks, R., Handley, M., and E. 480 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 481 June 2002. 483 Authors' Addresses 485 Steven Whitehead 486 Verizon Laboratories Inc. 487 40 Sylvan Road 488 Waltham, MA 02451 489 USA 491 Email: steven.d.whitehead@verizon.com 492 Marie-Jose Montpetit 493 Motorola 494 900 Chelmsford Street 495 Lowell, MA 01851 496 USA 498 Email: mmontpetit@motorola.com 500 Xavier Marjou 501 France Telecom 502 Rue Pierre Marzin 503 Lannion, Brittany 22307 504 France 506 Email: xavier.marjou@orange-ftgroup.com 508 Sam Ganesan 509 Motorola 510 80 Central Street 511 Boxborough, MA 01719 512 US 514 Email: sam.ganesan@motorola.com 516 Jan Lindquist 517 Ericsson 518 Tellusborgsvaegen 83-87 519 Hagersten, Hagersten 12637 520 Sweden 522 Email: jan.lindquist@ericsson.com 524 Full Copyright Statement 526 Copyright (C) The IETF Trust (2008). 528 This document is subject to the rights, licenses and restrictions 529 contained in BCP 78, and except as set forth therein, the authors 530 retain all their rights. 532 This document and the information contained herein are provided on an 533 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 534 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 535 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 536 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 537 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 538 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 540 Intellectual Property 542 The IETF takes no position regarding the validity or scope of any 543 Intellectual Property Rights or other rights that might be claimed to 544 pertain to the implementation or use of the technology described in 545 this document or the extent to which any license under such rights 546 might or might not be available; nor does it represent that it has 547 made any independent effort to identify any such rights. Information 548 on the procedures with respect to rights in RFC documents can be 549 found in BCP 78 and BCP 79. 551 Copies of IPR disclosures made to the IETF Secretariat and any 552 assurances of licenses to be made available, or the result of an 553 attempt made to obtain a general license or permission for the use of 554 such proprietary rights by implementers or users of this 555 specification can be obtained from the IETF on-line IPR repository at 556 http://www.ietf.org/ipr. 558 The IETF invites any interested party to bring to its attention any 559 copyrights, patents or patent applications, or other proprietary 560 rights that may cover technology that may be required to implement 561 this standard. Please address the information to the IETF at 562 ietf-ipr@ietf.org.