MMUSIC R. Avasarala Internet-Draft Motorola Inc Updates: RFC2326 September 1, 2010 (if approved) Intended status: Standards Track Expires: March 5, 2011 RTSP MODIFY Method draft-avasarala-mmusic-rtsp-modify-00.txt Abstract This specification defines the new MODIFY method for the Real Time Streaming Protocol (RTSP). MODIFY method allows a RTSP client to indicate to the RTSP server to modify a particular session. Using MODIFY method, a client can indicate to either transfer or share a particular streaming session with other RTSP device. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 5, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Avasarala Expires March 5, 2011 [Page 1] Internet-Draft The RTSP MODIFY Method September 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 3. The MODIFY Method . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The Target Header Field . . . . . . . . . . . . . . . . . 4 3.2. Header Field Support for MODIFY Method . . . . . . . . . . 5 3.3. Overview of Operation . . . . . . . . . . . . . . . . . . 9 3.4. Determining support for session target modification . . . 9 3.5. MODIFY method handling . . . . . . . . . . . . . . . . . . 9 3.5.1. Sending a session modification request . . . . . . . . 9 3.5.2. Processing a session modification request . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Session Transfer . . . . . . . . . . . . . . . . . . . . . 10 4.2. Session Sharing . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. MODIFY Method Registration . . . . . . . . . . . . . . . . 11 6.2. Target Header Registration . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 A.1. Media Session Transfer . . . . . . . . . . . . . . . . . . 12 A.2. Media Session Sharing . . . . . . . . . . . . . . . . . . 14 Appendix B. Changes to RTSP Protocol State Machine . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Avasarala Expires March 5, 2011 [Page 2] Internet-Draft The RTSP MODIFY Method September 2010 1. Introduction The RTSP [1] defines the SETUP method for the RTSP clients to establish streaming sessions with RTSP servers. The SETUP method could also be used for session modification when sent in the middle of a streaming session. However this SETUP can only be used for changing transport parameters as mentioned in Section 13.3.1 of [1] and not for changing the target device. Now a days with users having multiple devices like mobiles, TV, etc it would become necessary to facilitate sharing or transfer of content streaming sessions across devices. As a result in order to facilitate the sharing or transfer of content streaming sessions among RTSP based devices, there is a need for a mechanism within the RTSP protocol to facilitate this procedure. The MODIFY method defined in this document fulfills the need and provides a mechanism for the primary RTSP client to initiate a streaming session sharing or transfer with another device. 2. Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. 3. The MODIFY Method MODIFY is a RTSP method as defined by [1]. The MODIFY method indicates that the RTSP Client intends to modify certain parameters of the current streaming session (identified by the RTSP URL).The modifications could be a request to the RTSP Server to redirect or the share the content streaming session with another RTSP Client. This table adds a row to Table 7 of [1] indicating the MODIFY Method definitions. +---------------+-----------+--------+-------------+-------------+ | method | direction | object | Server req. | Client req. | +---------------+-----------+--------+-------------+-------------+ | MODIFY | C -> S | P,S | required | required | +---------------+-----------+--------+-------------+-------------+ This table adds a row to Table 8 of [1] defining the semantics of RTSP MODIFY method. Avasarala Expires March 5, 2011 [Page 3] Internet-Draft The RTSP MODIFY Method September 2010 +---------------+----------------+--------+---------+------+ | method | direction | object | acronym | Body | +---------------+----------------+--------+---------+------+ | MODIFY | C -> S | P,S | MOD | R | +---------------+----------------+--------+---------+------+ 3.1. The Target Header Field Target is a RTSP header field as defined by [1]. and provides a URL to reference to the target device. Target = ("Target" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) The following should be interpreted as if it appeared in Table 10 of [1]. +------------------+-------+-----+----+-----+-----+-----+-----+-----+ | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | | | | xy | S | | | | | | +------------------+-------+-----+----+-----+-----+-----+-----+-----+ | Target | R | - | - | - | - | - | - | - | +------------------+-------+-----+----+-----+-----+-----+-----+-----+ The following should be interpreted as if it appeared in Table 12 of [1]. +------------------+---------+-------+-----+-----+-----+-----+ | Header | Where | Proxy | GPR | SPR | RDR | PNY | +------------------+---------+-------+-----+-----+-----+-----+ | Target | R | | o | - | o | o | +------------------+---------+-------+-----+-----+-----+-----+ Example Target: "Home-TV" Avasarala Expires March 5, 2011 [Page 4] Internet-Draft The RTSP MODIFY Method September 2010 3.2. Header Field Support for MODIFY Method This table adds a column to Table 9 of [1]. +------------------+-------+-----+ | Header | Where | MOD | | | | | +------------------+-------+-----+ | Accept | R | o | | | | | | Accept-Credentia | R | o | | ls | | | | | | | | Accept-Encoding | R | o | | | | | | Accept-Language | R | o | | | | | | Accept-Ranges | R | o | | | | | | Accept-Ranges | r | o | | | | | | Accept-Ranges | 456 | o | | | | | | Allow | r | o | | | | | | Allow | 405 | o | | | | | | Authorization | R | o | | | | | | Bandwidth | R | o | | | | | | Blocksize | R | o | | | | | | Cache-Control | | o | | | | | | Connection | | o | | | | | | Connection-Crede | 470,4 | o | | ntials | 07 | | | | | o | | Content-Base | r | | | | | o | | Content-Base | 4xx,5 | | | | xx | o | | | | | | Content-Encoding | R | o | | | | | Avasarala Expires March 5, 2011 [Page 5] Internet-Draft The RTSP MODIFY Method September 2010 | Content-Encoding | r | o | | | | | | Content-Encoding | 4xx,5 | o | | | xx | | | | | | | Content-Language | R | o | | | | | | Content-Language | r | o | | | | | | Content-Language | 4xx,5 | o | | | xx | | | | | | | Content-Length | r | o | | | | | | Content-Length | 4xx,5 | o | | | xx | | | | | | | Content-Location | r | o | | | | | | Content-Location | 4xx,5 | o | | | xx | | | | | | | Content-Type | r | o | | | | | | Content-Type | 4xx,5 | o | | | xx | | | | | | | CSeq | Rc | m | | | | | | Date | | am | | | | | | Expires | r | r | | | | | | From | R | r | | | | | | If-Match | R | r | | | | | | If-Modified-Sinc | R | r | | e | | | | | | | | If-None-Match | R | r | | | | | | Last-Modified | r | r | | | | | | Location | 3rr | | +------------------+-------+-----+ Avasarala Expires March 5, 2011 [Page 6] Internet-Draft The RTSP MODIFY Method September 2010 This table adds a column to Table 10 of [1]. +---------------+--------+------+ | Header | Where | MOD | | | | | +---------------+--------+------+ | Media- | | o | | Properties | | | | | | o | | Media-Range | | | | | | | | MTag | r | o | | | | | | Pipelined- | | o | | Requests | | | | | | | | Proxy- | 407 | amr | | Authenticate | | | | | | | | Proxy- | R | rd | | Authorization | | | | | | | | Proxy- | R | ar | | Require | | | | | | | | Proxy- | r | r | | Require | | | | | | | | Proxy- | R | amr | | Supported | | | | | | | | Proxy- | r | | | Supported | | | | | | | | Public | r | amr | | | | | | Public | 501 | amr | | | | | | Range | R | | | | | | | Range | r | | | | | | | Terminate-Rea | R | r | | son | | | | | | | | Referrer | R | | | | | | Avasarala Expires March 5, 2011 [Page 7] Internet-Draft The RTSP MODIFY Method September 2010 | Request- | R | | | Status | | | | | | | | Require | R | m | | | | | | Retry-After | 3rr,50 | | | | 3 | | | | | | | Retry-After | 413 | | | | | | | RTP-Info | r | | | | | | | Scale | R | r | | | | | | Scale | r | amr | | | | | | Seek-Style | R | | | | | | | Seek-Style | r | | | | | | | Server | R | r | | | | | | Server | r | r | | | | | | Session | R | r | | | | | | Session | r | r | | | | | | Speed | R | admr | | | | | | Speed | r | admr | | | | | | Supported | R | amr | | | | | | Supported | r | amr | | | | | | Timestamp | R | admr | | | | | | Timestamp | c | admr | | | | | | Transport | | mr | | | | | | Unsupported | r | | | | | | | User-Agent | R | | | | | | | Vary | r | | | | | | Avasarala Expires March 5, 2011 [Page 8] Internet-Draft The RTSP MODIFY Method September 2010 | Via | R | amr | | | | | | Via | c | dr | | | | | | WWW- | 401 | | | Authenticate | | | +---------------+--------+------+ 3.3. Overview of Operation Operation of this extension is straightforward. The RTSP client begins with a SETUP request which proceeds normally. Once the content streaming session is in progress, then the RTSP client can generate a RTSP MODIFY method that contains the required operation to be performed and the target device for the purposes of modifying the session target i.e. either adding a new target by sharing the session with that device or by changing the target by transferring the session to that target. The response to a MODIFY request would be a final response indicating that the operation is successful or a suitable error response indicating failure. The Allow header could be used to indicate support for the MODIFY method. The usage of MODIFY method SHALL be restricted to only changing the target of content streaming session and not for any other modifications. 3.4. Determining support for session target modification The content streaming session origination happens as per procedures defined in [1]. However a RTSP server compliant to this specification SHOULD list the method MODIFY in the Public header field in the 200 final response sent to the OPTIONS request. If the Public header in the 2xx response from RTSP server contains MODIFY method, it indicates that the RTSP server supports session modification procedures for changing the target and the RTSP client can follow the procedures of Section 3.5.1. 3.5. MODIFY method handling 3.5.1. Sending a session modification request The MODIFY request would be constructed as would any other request within a particular streaming session on a particular URI and only when a particular streaming session is active. The RTSP client initiates the MODIFY method request when it wants to either transfer or share the ongoing streaming session to or with another RTSP client Avasarala Expires March 5, 2011 [Page 9] Internet-Draft The RTSP MODIFY Method September 2010 device. The RTSP device initiating the MODIFY request SHALL add the Require header defined in [1] with the proposed option-tag values "Transfer" or "Share" to indicate the action to be taken. The RTSP device SHALL also add the proposed Target header as described in Section 3.1, containing the target device address to or with whom the session is being transferred to or shared with. 3.5.2. Processing a session modification request The MODIFY request is processed as a mid session request. The streaming server looks at the RTSP Require header present in the MODIFY request and determines the corresponding action that needs to be taken. Then the server looks for the Target header and determines the new target device. If the MODIFY is received without the mandatory headers: "Require" and "Target", then the server SHALL reject the MODIFY with a 400 Bad Request and a Reason-Phrase as "Missing Require header field". In addition if the Require header field has values other than "Transfer" or "Share", then the server SHALL reject the MODIFY with a 456 or a 400 Bad Request response. 4. Examples 4.1. Session Transfer This sections presents an example call flows between a RTSP client and Server for a session transfer scenario. C->S: MODIFY rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Require: Transfer Target: "User-TV" Now if the server supports MODIFY method, it sends a 200 OK response S->C: RTSP/2.0 200 OK CSeq: 302 Session: 47112344 Avasarala Expires March 5, 2011 [Page 10] Internet-Draft The RTSP MODIFY Method September 2010 4.2. Session Sharing This sections presents an example call flows between a RTSP client and Server for a session transfer scenario. C->S: MODIFY rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Require: Sharing Target: "User-TV" user-tv@domain.com> Now if the server supports MODIFY method, it sends a 200 OK response S->C: RTSP/2.0 200 OK CSeq: 302 Session: 47112344 5. Security Considerations The security considerations for the MODIFY method are identical to those of SETUP and PLAY methods. It is important that the MODIFY be integrity protected and authenticated as coming from the same source as the SETUP and PLAY requests. [1] discusses security mechanisms for achieving these functions. 6. IANA Considerations 6.1. MODIFY Method Registration As per Section 22.2.2 of [1], this specification registers the RTSP MODIFY method. The information to be added to the registry is: RFCXXXX: This specification serves as registration for the MODIFY method. Method Name: MODIFY Reason Phrase: Not applicable. Avasarala Expires March 5, 2011 [Page 11] Internet-Draft The RTSP MODIFY Method September 2010 6.2. Target Header Registration As per Section 22.4.2 of [1], this specification registers the RTSP Target header for use with RTSP methods. The information to be added to the registry is: RFCXXXX: This specification serves as registration for the Target header. Header Name: Target Reason Phrase: Not applicable. 7. Acknowledgements None 8. References 8.1. Normative References [1] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-24 (work in progress), July 2010. [2] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. 8.2. Informative References [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Appendix A. Examples This section adds additional examples to Appendix A of [1]. A.1. Media Session Transfer This is an example of transferring a media streaming session from one RTSP device to another. For the purpose of this example, the source RTSP device is the device that actually originated the RTSP streaming session with the server, while the destination RTSP device is the Avasarala Expires March 5, 2011 [Page 12] Internet-Draft The RTSP MODIFY Method September 2010 target device to which the RTSP streaming session would be transferred. Here the source RTSP device that wants to transfer the RTSP session to the destination device, generates a RTSP MODIFY method request specifying its intention to transfer the session in the RTSP Require header and the address of the destination device in the RTSP Target header. The RTSP server upon receiving the MODIFY request from the source device would use any available mechanism to indicate to the destination device about a pending session request. The destination device would then setup a streaming session with the server. The flow of messages depicting this mechanism is shown below. For the purpose of the message flow, C means source RTSP device, S means RTSP server and D means RTSP destination device C->S: MODIFY rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Require: Transfer Target: "D" D@domain.com> Now S would indicate to D about a pending session for D. D->S: DESCRIBE rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient S->D: RTSP/2.0 200 OK CSeq: 1 Server: PhonyServer/1.0 Date: Thu, 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 271 Content-Base: rtsp://example.com/movie/ Expires: 24 Jan 1997 15:35:06 GMT v=0 o=- 2890844256 2890842807 IN IP4 198.51.100.5 s=RTSP Session i=An Example of RTSP Session Usage e=adm@example.com c=IN IP4 0.0.0.0 a=control: * a=range: npt=0-0:10:34.10 t=0 0 Avasarala Expires March 5, 2011 [Page 13] Internet-Draft The RTSP MODIFY Method September 2010 m=audio 0 RTP/AVP 0 a=control: trackID=1 m=video 0 RTP/AVP 26 a=control: trackID=4 D->S SETUP rtsp://example.com/movie RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Accept-Ranges: NPT, SMPTE, UTC Pipelined-Requests: 7654 S->C TEARDOWN rtsp://example.com/movie RTSP/2.0 ......................................... ............... A.2. Media Session Sharing This is an example of sharing a media streaming session with another RTSP device. For the purpose of this example, the source RTSP device is the device that actually originated the RTSP streaming session with the server, while the destination RTSP device is the target device with which the RTSP streaming session would be shared. Here the source RTSP device that wants to share the RTSP session with the destination device, generates a RTSP MODIFY method request specifying its intention to share the session in the RTSP Require header and the address of the destination device in the RTSP Target header. The RTSP server upon receiving the MODIFY request from the source device would use any available mechanism to indicate to the destination device about a pending session request. The destination device would then setup a streaming session with the server. The flow of messages depicting this mechanism is shown below. Avasarala Expires March 5, 2011 [Page 14] Internet-Draft The RTSP MODIFY Method September 2010 For the purpose of the message flow, C means source RTSP device, S means RTSP server and D means RTSP destination device C->S: MODIFY rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Require: Share Target: "D" D@domain.com> Now S would indicate to D about a pending session for D. D->S: DESCRIBE rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient S->D: RTSP/2.0 200 OK CSeq: 1 Server: PhonyServer/1.0 Date: Thu, 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 271 Content-Base: rtsp://example.com/movie/ Expires: 24 Jan 1997 15:35:06 GMT v=0 o=- 2890844256 2890842807 IN IP4 198.51.100.5 s=RTSP Session i=An Example of RTSP Session Usage e=adm@example.com c=IN IP4 0.0.0.0 a=control: * a=range: npt=0-0:10:34.10 t=0 0 m=audio 0 RTP/AVP 0 a=control: trackID=1 m=video 0 RTP/AVP 26 a=control: trackID=4 D->S SETUP rtsp://example.com/movie RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Accept-Ranges: NPT, SMPTE, UTC Pipelined-Requests: 7654 ............... Avasarala Expires March 5, 2011 [Page 15] Internet-Draft The RTSP MODIFY Method September 2010 Appendix B. Changes to RTSP Protocol State Machine This table adds a row to Table 13 of [1] defining the role of RTSP MODIFY method in state-machine changing events. +---------------+-----------------+---------------------------------+ | Event | Prerequisite | Response | +---------------+-----------------+---------------------------------+ | MODIFY | Session needs to| 200, 4xx | | | be setup | | +---------------+-----------------+---------------------------------+ This table adds a row to Table 15 of [1] defining the role of RTSP MODIFY method in state Ready. +-------------+------------------------+---------+------------------+ | Action | Requisite | New | Response | | | | State | | +-------------+------------------------+---------+------------------+ | MODIFY | Require: Transfer | Ready | 200 | | | | | session TEARDOWN | | | | | | | MODIFY | Require: share | Ready | 200 | +-------------+------------------------+---------+------------------+ Author's Address Ranjit Avasarala Motorola India Pvt Ltd Bagamane Tech Park, C V Raman Nagar Bangalore 560093 India Email: ranjit@motorola.com Avasarala Expires March 5, 2011 [Page 16]