| TOC |
|
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.
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 (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 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.
1.
Introduction
2.
Document Conventions
3.
The MODIFY Method
3.1.
The Target Header Field
3.2.
Header Field Support for MODIFY Method
3.3.
Overview of Operation
3.4.
Determining support for session target modification
3.5.
MODIFY method handling
3.5.1.
Sending a session modification request
3.5.2.
Processing a session modification request
4.
Examples
4.1.
Session Transfer
4.2.
Session Sharing
5.
Security Considerations
6.
IANA Considerations
6.1.
MODIFY Method Registration
6.2.
Target Header Registration
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
Appendix A.
Examples
A.1.
Media Session Transfer
A.2.
Media Session Sharing
Appendix B.
Changes to RTSP Protocol State Machine
§
Author's Address
| TOC |
The RTSP [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) 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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) 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.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
MODIFY is a RTSP method as defined by [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.). 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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) 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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) defining the semantics of RTSP MODIFY method.
+---------------+----------------+--------+---------+------+ | method | direction | object | acronym | Body | +---------------+----------------+--------+---------+------+ | MODIFY | C -> S | P,S | MOD | R | +---------------+----------------+--------+---------+------+
| TOC |
Target is a RTSP header field as defined by [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.). 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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.).
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ | 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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.).
+------------------+---------+-------+-----+-----+-----+-----+ | Header | Where | Proxy | GPR | SPR | RDR | PNY | +------------------+---------+-------+-----+-----+-----+-----+ | Target | R | | o | - | o | o | +------------------+---------+-------+-----+-----+-----+-----+
Example
Target: "Home-TV" <rtsp://television@home.domain.com>
| TOC |
This table adds a column to Table 9 of [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.).
+------------------+-------+-----+
| 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 |
| | | |
| 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 | |
+------------------+-------+-----+
This table adds a column to Table 10 of [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.).
+---------------+--------+------+
| 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 | |
| | | |
| 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 | |
| | | |
| Via | R | amr |
| | | |
| Via | c | dr |
| | | |
| WWW- | 401 | |
| Authenticate | | |
+---------------+--------+------+
| TOC |
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.
| TOC |
The content streaming session origination happens as per procedures defined in
[1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.). 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 (Sending a session modification request).
| TOC |
| TOC |
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 device.
The RTSP device initiating the MODIFY request SHALL add the Require header defined in
[1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) 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 (The Target Header Field),
containing the target device address to or with whom the session is being transferred to or shared with.
| TOC |
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.
| TOC |
| TOC |
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" <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
| TOC |
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
| TOC |
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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) discusses security mechanisms for achieving these functions.
| TOC |
| TOC |
As per Section 22.2.2 of [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.), 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.
| TOC |
As per Section 22.4.2 of [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.), 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.
| TOC |
None
| TOC |
| TOC |
| [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 (TXT). |
| [2] | Schulzrinne, H., Rao, A., and R. Lanphier, “Real Time Streaming Protocol (RTSP),” RFC 2326, April 1998 (TXT). |
| TOC |
| [3] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| TOC |
This section adds additional examples to Appendix A of [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.).
| TOC |
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 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
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
.........................................
...............
| TOC |
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.
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
...............
| TOC |
This table adds a row to Table 13 of [1] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) 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] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” July 2010.) 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 | +-------------+------------------------+---------+------------------+
| TOC |
| Ranjit Avasarala | |
| Motorola India Pvt Ltd | |
| Bagamane Tech Park, C V Raman Nagar | |
| Bangalore 560093 | |
| India | |
| Email: | ranjit@motorola.com |