Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-34
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7826.
|
|
---|---|---|---|
Authors | Henning Schulzrinne , Anup Rao , Rob Lanphier , Magnus Westerlund , Martin Stiemerling | ||
Last updated | 2013-06-10 (Latest revision 2013-04-04) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
by Elwyn Davies
Ready w/issues
GENART Last Call review
by Robert Sparks
Ready w/issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Flemming Andreasen | ||
Shepherd write-up | Show Last changed 2013-05-08 | ||
IESG | IESG state | Became RFC 7826 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Gonzalo Camarillo | ||
IESG note | ** No value found for 'doc.notedoc.note' ** | ||
Send notices to | mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-rfc2326bis@tools.ietf.org | ||
IANA | IANA review state | IANA - Not OK |
draft-ietf-mmusic-rfc2326bis-34
Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 number as the original (i.e., the sequence number is not incremented for retransmissions of the same request). For each new RTSP request the CSeq value MUST be incremented by one. The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its request to a server and the server has another when sending request to the client. Each requester and responder is identified with its socket address (IP address and port number). Proxies that aggregate several sessions on the same transport will have to ensure that the requests sent towards a particular server have a joint sequence number space, i.e., they will regularly need to renumber the CSeq header field in requests (from proxy to server) and responses (from server to proxy) to fulfill the rules for the header. The proxy MUST increase the CSeq by one for each request it transmits, without regard of different sessions. Example: CSeq: 239 18.20. Date The Date header field represents the date and time at which the message was originated. The inclusion of the Date header in RTSP message follows these rules: o An RTSP message, sent either by the client or the server, containing a body MUST include a Date header, if the sending host has a clock; o Clients and servers are RECOMMENDED to include a Date header in all other RTSP messages, if the sending host has a clock; o If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, this rule MUST be followed: Some origin server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource). A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that Schulzrinne, et al. Expires October 6, 2013 [Page 141] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 recipient. An RTSP implementation without a clock MUST NOT cache responses without revalidating them on every use. An RTSP cache, especially a shared cache, SHOULD use a mechanism, such as NTP, to synchronize its clock with a reliable external standard. The RTSP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the message body is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value. 18.21. Expires The Expires message-header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method: DESCRIBE response: The Expires header indicates a date and time after which the presentation description (body) SHOULD be considered stale. SETUP response: The Expires header indicate a date and time after which the media stream SHOULD be considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or an user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the message body). See Section 16 for further discussion of the expiration model. The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time. The format is an absolute date and time as defined by RTSP-date. An example of its use is Expires: Thu, 01 Dec 1994 16:00:00 GMT RTSP/2.0 clients and caches MUST treat other invalid date formats, especially including the value "0", as having occurred in the past (i.e., already expired). To mark a response as "already expired," an origin server should use an Expires date that is equal to the Date header value. To mark a response as "never expires," an origin server SHOULD use an Expires Schulzrinne, et al. Expires October 6, 2013 [Page 142] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 date approximately one year from the time the response is sent. RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in the future. 18.22. From The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by "mailbox" in [RFC1123]. This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end. The Internet e-mail address in this field MAY be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used. The client SHOULD NOT send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request. 18.23. If-Match The If-Match request-header field is especially useful for ensuring the integrity of the presentation description, independent of how the presentation description was received. The presentation description can be fetched via means external to RTSP (such as HTTP) or via the DESCRIBE message. In the case of retrieving the presentation description via RTSP, the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message. By including the MTag given in or with the session description in an If-Match header part of the SETUP request, the client ensures that resources set up are matching the description. A SETUP request with the If-Match header for which the MTag validation check fails, MUST generate a response using 412 (Precondition Failed). This validation check is also very useful if a session has been Schulzrinne, et al. Expires October 6, 2013 [Page 143] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 redirected from one server to another. 18.24. If-Modified-Since The If-Modified-Since request-header field is used with the DESCRIBE and SETUP methods to make them conditional. If the requested variant has not been modified since the time specified in this field, a description will not be returned from the server (DESCRIBE) or a stream will not be set up (SETUP). Instead, a 304 (Not Modified) response MUST be returned without any message-body. An example of the field is: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 18.25. If-None-Match This request header can be used with one or several message body tags to make DESCRIBE requests conditional. A client that has one or more message bodies previously obtained from the resource, can verify that none of those entities is current by including a list of their associated message body tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. As a special case, the value "*" matches any current entity of the resource. If any of the message body tags match the message body tag of the message body that would have been returned in the response to a similar DESCRIBE request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. Instead, if the request method was DESCRIBE, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related header fields (particularly MTag) of one of the message bodies that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed). See Section 16.1.3 for rules on how to determine if two message body tags match. If none of the message body tags match, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no message body tags match, then the server MUST NOT return a 304 (Not Modified) response. Schulzrinne, et al. Expires October 6, 2013 [Page 144] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See Section 16.1.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) The result of a request having both an If-None-Match header field and an If-Match header field is unspecified and MUST be considered an illegal request. 18.26. Last-Modified The Last-Modified message-header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. For the method DESCRIBE, the header field indicates the last modification date and time of the description, for SETUP that of the media stream. An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date. An origin server SHOULD obtain the Last-Modified value of the message body as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the message body's modification time, especially if the message body changes near the time that the response is generated. RTSP servers SHOULD send Last-Modified whenever feasible. 18.27. Location The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Note: The Content-Location header field (Section 18.17) differs from Location in that the Content-Location identifies the original location of the message body enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also, see Section 16.2 for cache requirements of some methods. Schulzrinne, et al. Expires October 6, 2013 [Page 145] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 18.28. Media-Properties This general header is used in SETUP response or PLAY_NOTIFY requests to indicate the media's properties that currently are applicable to the RTSP session. PLAY_NOTIFY MAY be used to modify these properties at any point. However, the client SHOULD have received the update prior to any action related to the new media properties take effect. For aggregated sessions, the Media-Properties header will be returned in each SETUP response. The header received in the latest response is the one that applies on the whole session from this point until any future update. The header MAY be included without value in GET_PARAMETER requests to the server with a Session header included to query the current Media-Properties for the session. The responder MUST include the current session's media properties. The media properties expressed by this header is the one applicable to all media in the RTSP session. For aggregated sessions, the header expressed the combined media-properties. As a result, aggregation of media MAY result in a change of the media properties, and thus the content of the Media-Properties header contained in subsequent SETUP responses. The header contains a list of property values that are applicable to the currently setup media or aggregate of media as indicated by the RTSP URI in the request. No ordering is enforced within the header. Property values should be grouped into a single group that handles a particular orthogonal property. Values or groups that express multiple properties SHOULD NOT be used. The list of properties that can be expressed MAY be extended at any time. Unknown property values MUST be ignored. This specification defines the following 4 groups and their property values: Random Access: Random-Access: Indicates that random access is possible. May optionally include a floating point value in seconds indicating the longest duration between any two random access points in the media. Begining-Only: Seeking is limited to the beginning only. No-Seeking: No seeking is possible. Schulzrinne, et al. Expires October 6, 2013 [Page 146] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Content Modifications: Immutable: The content will not be changed during the life-time of the RTSP session. Dynamic: The content may be changed based on external methods or triggers Time-Progressing The media accessible progresses as wallclock time progresses. Retention: Unlimited: Content will be retained for the duration of the life- time of the RTSP session. Time-Limited: Content will be retained at least until the specified wallclock time. The time must be provided in the absolute time format specified in Section 4.6. Time-Duration Each individual media unit is retained for at least the specified time duration. This definition allows for retaining data with a time based sliding window. The time duration is expressed as floating point number in seconds. 0.0 is a valid value as this indicates that no data is retained in a time-progressing session. Supported Scale: Scales: A quoted comma separated list of one or more decimal values or ranges of scale values supported by the content in arbitrary order. A range has a start and stop value separated by a colon. A range indicates that the content supports fine grained selection of scale values. Fine grained allows for steps at least as small as one tenth of a scale value. A content is considered to support fine grained selection when the server in response to a given scale value can produce content with an actual scale that is less than 1 tenth of scale unit, i.e., 0.1, from the requested value. Negative values are supported. The value 0 has no meaning and MUST NOT be used. Examples of this header for on-demand content and a live stream without recording are: Schulzrinne, et al. Expires October 6, 2013 [Page 147] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 On-demand: Media-Properties: Random-Access=2.5s, Unlimited, Immutable, Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" Live stream without recording/timeshifting: Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 18.29. Media-Range The Media-Range general header is used to give the range of the media at the time of sending the RTSP message. This header MUST be included in SETUP response, and PLAY and PAUSE response for media that are Time-Progressing, and PLAY and PAUSE response after any change for media that are Dynamic, and in PLAY_NOTIFY request that are sent due to Media-Property-Update. Media-Range header without any range specifications MAY be included in GET_PARAMETER requests to the server to request the current range. The server MUST in this case include the current range at the time of sending the response. The header MUST include range specifications for all time formats supported for the media, as indicated in Accept-Ranges header (Section 18.5) when setting up the media. The server MAY include more than one range specification of any given time format to indicate media that has non-continuous range. For media that has the Time-Progressing property, the Media-Range values will only be valid for the particular point in time when it was issued. As wallclock progresses so will also the media range. However, it shall be assumed that media time progresses in direct relationship to wallclock time (with the exception of clock skew) so that a reasonably accurate estimation of the media range can be calculated. 18.30. MTag The MTag response header MAY be included in DESCRIBE, GET_PARAMETER or SETUP responses. The message body tags (Section 4.8) returned in a DESCRIBE response, and the one in SETUP refers to the presentation, i.e. both the returned session description and the media stream. This allows for verification that one has the right session description to a media resource at the time of the SETUP request. However, it has the disadvantage that a change in any of the parts results in invalidation of all the parts. If the MTag is provided both inside the message body, e.g. within the "a=mtag" attribute in SDP, and in the response message, then both tags MUST be identical. It is RECOMMENDED that the MTag is primarily given in the RTSP response message, to ensure that caches can use the Schulzrinne, et al. Expires October 6, 2013 [Page 148] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 MTag without requiring content inspection. However, for session descriptions that are distributed outside of RTSP, for example using HTTP, etc. it will be necessary to include the message body tag in the session description as specified in Appendix D.1.9. SETUP and DESCRIBE requests can be made conditional upon the MTag using the headers If-Match (Section 18.23) and If-None-Match ( Section 18.25). 18.31. Notify-Reason The Notify Reason header is solely used in the PLAY_NOTIFY method. It indicates the reason why the server has sent the asynchronous PLAY_NOTIFY request (see Section 13.5). 18.32. Pipelined-Requests The Pipelined-Requests general header is used to indicate that a request is to be executed in the context created by a previous request(s). The primary usage of this header is to allow pipelining of SETUP requests so that any additional SETUP request after the first one does not need to wait for the session ID to be sent back to the requesting agent. The header contains a unique identifier that is scoped by the persistent connection used to send the requests. Upon receiving a request with the Pipelined-Requests the responding agent MUST look up if there exists a binding between this Pipelined- Requests identifier for the current persistent connection and an RTSP session ID. If that exists then the received request is processed the same way as if it contained the Session header with the found session ID. If there does not exist a mapping and no Session header is included in the request, the responding agent MUST create a binding upon the successful completion of a session creating request, i.e. SETUP. A binding MUST NOT be created, if the request failed to create an RTSP session. In case the request contains both a Session header and the Pipelined-Requests header the Pipelined-Requests MUST be ignored. Note: Based on the above definition at least the first request containing a new unique Pipelined-Requests will be required to be a SETUP request (unless the protocol is extended with new methods of creating a session). After that first one, additional SETUP requests or request of any type using the RTSP session context may include the Pipelined-Requests header. When responding to any request that contained the Pipelined-Requests header the server MUST also include the Session header when a binding to a session context exist. An RTSP agent that knows the session ID Schulzrinne, et al. Expires October 6, 2013 [Page 149] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 SHOULD NOT use the Pipelined-Requests header in any request and only use the Session header. This as the Session identifier is persistent across transport contexts, like TCP connections, which the Pipelined- Requests identifier is not. The RTSP agent sending the request with a Pipelined-Requests header has the responsibility for using a unique and previously unused identifier within the transport context. Currently only a TCP connection is defined as such transport context. A server MUST delete the Pipelined-Requests identifier and its binding to a session upon the termination of that session. Despite the previous mandate, RTSP agents are RECOMMENDED to not reuse identifiers to allow for better error handling and logging. RTSP Proxies may need to translate Pipelined-Requests identifier values from incoming requests to outgoing to allow for aggregation of requests onto a persistent connection. 18.33. Proxy-Authenticate The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. The HTTP access authentication process is described in [RFC2617]. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and SHOULD NOT be passed on to downstream agents. However, an intermediate proxy might need to obtain its own credentials by requesting them from the downstream agent, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header field. 18.34. Proxy-Authorization The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. The HTTP access authentication process is described in [RFC2617]. Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy Schulzrinne, et al. Expires October 6, 2013 [Page 150] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 if that is the mechanism by which the proxies cooperatively authenticate a given request. 18.35. Proxy-Require The Proxy-Require request-header field is used to indicate proxy- sensitive features that MUST be supported by the proxy. Any Proxy- Require header features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client using the Unsupported header. The proxy MUST use the 551 (Option Not Supported) status code in the response. Any feature-tag included in the Proxy-Require does not apply to the end-point (server or client). To ensure that a feature is supported by both proxies and servers the tag needs to be included in also a Require header. See Section 18.41 for more details on the mechanics of this message and a usage example. See discussion in the proxies section (Section 15.1) about when to consider that a feature requires proxy support. Example of use: Proxy-Require: play.basic 18.36. Proxy-Supported The Proxy-Supported header field enumerates all the extensions supported by the proxy using feature-tags. The header carries the intersection of extensions supported by the forwarding proxies. The Proxy-Supported header MAY be included in any request by a proxy. It MUST be added by any proxy if the Supported header is present in a request. When present in a request, the receiver MUST in the response copy the received Proxy-Supported header. The Proxy-Supported header field contains a list of feature-tags applicable to proxies, as described in Section 4.7. The list is the intersection of all feature-tags understood by the proxies. To achieve an intersection, the proxy adding the Proxy-Supported header includes all proxy feature-tags it understands. Any proxy receiving a request with the header, MUST check the list and removes any feature-tag(s) it does not support. A Proxy-Supported header present in the response MUST NOT be touched by the proxies. Example: Schulzrinne, et al. Expires October 6, 2013 [Page 151] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech User-Agent: PhonyClient/1.2 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech Proxy-Supported: proxy-foo, proxy-bar, proxy-blech Via: 2.0 pro.example.com P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech Proxy-Supported: proxy-foo, proxy-blech Via: 2.0 pro.example.com, 2.0 prox2.example.com S->C: RTSP/2.0 200 OK Supported: foo, bar, baz Proxy-Supported: proxy-foo, proxy-blech Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Via: 2.0 pro.example.com, 2.0 prox2.example.com 18.37. Public The Public response header field lists the set of methods supported by the response sender. This header applies to the general capabilities of the sender and its only purpose is to indicate the sender's capabilities to the recipient. The methods listed may or may not be applicable to the Request-URI; the Allow header field (Section 18.6) MAY be used to indicate methods allowed for a particular URI. Example of use: Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN In the event that there are proxies between the sender and the recipient of a response, each intervening proxy MUST modify the Public header field to remove any methods that are not supported via that proxy. The resulting Public header field will contain an intersection of the sender's methods and the methods allowed through by the intervening proxies. In general, proxies should allow all methods to transparently pass through from the sending RTSP agent to the receiving RTSP agent, but there may be cases where this is not desirable for a given proxy. Modification of the Public response header field by the intervening proxies ensures that the request sender gets an accurate response indicating the methods that can be used on the target agent via the proxy chain. Schulzrinne, et al. Expires October 6, 2013 [Page 152] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 18.38. Range The Range header specifies a time range in PLAY (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be included in GET_PARAMETER requests from the client to the server with only a Range format and no value to request the current media position, whether the session is in Play or Ready state in the included format. The server SHALL, if supporting the range format, respond with the current playing point or pause point as the start of the range. If an explicit stop point was used in the previous PLAY request, then that value shall be included as stop point. Note that if the server is currently under any type of media playback manipulation affecting the interpretation of Range, like Scale, that is also required to be included in any GET_PARAMETER response to provide complete information. The range can be specified in a number of units. This specification defines smpte (Section 4.4), npt (Section 4.5), and clock (Section 4.6) range units. While byte ranges [H14.35.1] and other extended units MAY be used, their behavior is unspecified since they are not normally meaningful in RTSP. Servers supporting the Range header MUST understand the NPT range format and SHOULD understand the SMPTE range format. If the Range header is sent in a time format that is not understood, the recipient SHOULD return 456 (Header Field Not Valid for Resource) and include an Accept-Ranges header indicating the supported time formats for the given resource. Example: Range: clock=19960213T143205Z- The Range header contains a range of one single range format. A range is a half-open interval with a start and an end point, including the start point, but excluding the end point. A range may either be fully specified with explicit values for start point and end point, or have either start or end point be implicit. An implicit start point indicates the session's pause point, and if no pause point is set the start of the content. An implicit end point indicates the end of the content. The usage of both implicit start and end point is not allowed in the same range header, however, the exclusion of the range header has that meaning, i.e. from pause point (or start) until end of content. Regarding the half-open intervals; a range of A-B starts exactly at time A, but ends just before B. Only the start time of a media unit such as a video or audio frame is relevant. For example, assume that video frames are generated every 40 ms. A range of 10.0-10.1 would include a video frame starting at 10.0 or later Schulzrinne, et al. Expires October 6, 2013 [Page 153] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 time and would include a video frame starting at 10.08, even though it lasted beyond the interval. A range of 10.0-10.08, on the other hand, would exclude the frame at 10.08. Please note the difference between NPT time scales' "now" and an implicit start value. Implicit value reference the current pause- point. While "now" is the currently ongoing time. In a time- progressing session with recording (retention for some or full time) the pause point may be 2 min into the session while now could be 1 hour into the session. By default, range intervals increase, where the second point is larger than the first point. Example: Range: npt=10-15 However, range intervals can also decrease if the Scale header (see Section 18.44) indicates a negative scale value. For example, this would be the case when a playback in reverse is desired. Example: Scale: -1 Range: npt=15-10 Decreasing ranges are still half open intervals as described above. Thus, for range A-B, A is closed and B is open. In the above example, 15 is closed and 10 is open. An exception to this rule is the case when B=0 in a decreasing range. In this case, the range is closed on both ends, as otherwise there would be no way to reach 0 on a reverse playback for formats that have such a notion, like NPT and SMPTE. Example: Scale: -1 Range: npt=15-0 In this range both 15 and 0 are closed. A decreasing range interval without a corresponding negative Scale header is not valid. 18.39. Referrer The Referrer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. The URI refers to that of the presentation description, typically retrieved via HTTP. The Referrer Schulzrinne, et al. Expires October 6, 2013 [Page 154] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referrer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard. If the field value is a relative URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment. Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referrer field is sent. For example, a streaming client could have a toggle switch for openly/anonymously, which would respectively enable/disable the sending of Referrer and From information. Clients SHOULD NOT include a Referrer header field in a (non-secure) RTSP request if the referring page was transferred with a secure protocol. 18.40. Request-Status This request header is used to indicate the end result for requests that takes time to complete, such a PLAY (Section 13.4). It is sent in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report how the PLAY request concluded, either in success or in failure. The header carries a reference to the request it reports on using the CSeq number for the session indicated by the Session header in the request. It provides both a numerical status code (according to Section 8.1.1) and a human readable reason phrase. Example: Request-Status: cseq=63 status=500 reason="Media data unavailable" 18.41. Require The Require request-header field is used by clients to ensure that the other end-point supports features that are required in respect to this request. It can also be used to query if the other end-point supports certain features, however, the use of the Supported (Section 18.49) is much more effective in this purpose. The server MUST respond to this header by using the Unsupported header to negatively acknowledge those feature-tags which are NOT supported. The response MUST use the error code 551 (Option Not Supported). This header does not apply to proxies, for the same functionality in respect to proxies see Proxy-Require header (Section 18.35) with the exception of media modifying proxies. Media modifying proxies, due Schulzrinne, et al. Expires October 6, 2013 [Page 155] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 to their nature of handling media in a way that is very similar to a server, do need to understand also the server features to correctly serve the client. This is to make sure that the client-server interaction will proceed without delay when all features are understood by both sides, and only slow down if features are not understood (as in the example below). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes state ambiguity when the client requires features that the server does not understand. Example (Not complete): C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 CSeq: 302 Require: funky-feature Funky-Parameter: funkystuff S->C: RTSP/2.0 551 Option not supported CSeq: 302 Unsupported: funky-feature In this example, "funky-feature" is the feature-tag which indicates to the client that the fictional Funky-Parameter field is required. The relationship between "funky-feature" and Funky-Parameter is not communicated via the RTSP exchange, since that relationship is an immutable property of "funky-feature" and thus should not be transmitted with every exchange. Proxies and other intermediary devices MUST ignore this header. If a particular extension requires that intermediate devices support it, the extension should be tagged in the Proxy-Require field instead (see Section 18.35). See discussion in the proxies section (Section 15.1) about when to consider that a feature requires proxy support. 18.42. Retry-After The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing the redirected request. The value of this field can be either an RTSP-date or an integer number of seconds (in decimal) after the time of the response. Example: Schulzrinne, et al. Expires October 6, 2013 [Page 156] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120 In the latter example, the delay is 2 minutes. 18.43. RTP-Info The RTP-Info general header field is used to set RTP-specific parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY and GET_PARAMETER requests. For streams using RTP as transport protocol the RTP-Info header SHOULD be part of a 200 response to PLAY. The exclusion of the RTP-Info in a PLAY response for RTP transported media will result in that a client needs to synchronize the media streams using RTCP. This may have negative impact as the RTCP can be lost, and does not need to be particularly timely in its arrival. Also functionality as informing the client from which packet a seek has occurred is affected. The RTP-Info MAY be included in SETUP responses to provide synchronization information when changing transport parameters, see Section 13.3. The RTP-Info header and the Range header MAY be included in a GET_PARAMETER request from client to server without any values to request the current playback point and corresponding RTP synchronization information. When the RTP-Info header is included in a Request also the Range header MUST be included (Note, Range header only MAY be used). The server response SHALL include both the Range header and the RTP-Info header. If the session is in Play state, then the value of the Range header SHALL be filled in with the current playback point and with the corresponding RTP-Info values. If the server is another state, no values are included in the RTP- Info header. The header is included in PLAY_NOTIFY requests with the Notify-Reason of end-of-stream to provide RTP information about the end of the stream. The header can carry the following parameters: url: Indicates the stream URI for which the following RTP parameters correspond, this URI MUST be the same as used in the SETUP request for this media stream. Any relative URI MUST use the Request-URI as base URI. This parameter MUST be present. ssrc: The Synchronization source (SSRC) that the RTP timestamp and sequence number provided applies to. This parameter MUST be present. Schulzrinne, et al. Expires October 6, 2013 [Page 157] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 seq: Indicates the sequence number of the first packet of the stream that is direct result of the request. This allows clients to gracefully deal with packets when seeking. The client uses this value to differentiate packets that originated before the seek from packets that originated after the seek. Note that a client may not receive the packet with the expressed sequence number, and instead packets with a higher sequence number, due to packet loss or reordering. This parameter is RECOMMENDED to be present. rtptime: MUST indicate the RTP timestamp value corresponding to the start time value in the Range response header, or if not explicitly given the implied start point. The client uses this value to calculate the mapping of RTP time to NPT or other media timescale. This parameter SHOULD be present to ensure inter-media synchronization is achieved. There exists no requirement that any received RTP packet will have the same RTP timestamp value as the one in the parameter used to establish synchronization. A mapping from RTP timestamps to NTP timestamps (wallclock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP timestamps to media clock time (NPT, etc.). Furthermore, in order to ensure that this information is available at the necessary time (immediately at startup or after a seek), and that it is delivered reliably, this mapping is placed in the RTSP control channel. In order to compensate for drift for long, uninterrupted presentations, RTSP clients should additionally map NPT to NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping. Example: Schulzrinne, et al. Expires October 6, 2013 [Page 158] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Range:npt=3.25-15 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; rtptime=12345678,url="rtsp://example.com/foo/video" ssrc=9A9DE123:seq=30211;rtptime=29567112 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video a 90kHz RTP timestamp clock. Then the media synchronization is depicted in the following way. NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 Audio PA A Video V PV X: NPT time value = 3.25, from Range header. A: RTP timestamp value for Audio from RTP-Info header (12345678). V: RTP timestamp value for Video from RTP-Info header (29567112). PA: RTP audio packet carrying an RTP timestamp of 12344878. Which corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 PV: RTP video packet carrying an RTP timestamp of 29573412. Which corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 18.44. Scale A scale value of 1 indicates normal play at the normal forward viewing rate. If not 1, the value corresponds to the rate with respect to normal viewing rate. For example, a ratio of 2 indicates twice the normal viewing rate ("fast forward") and a ratio of 0.5 indicates half the normal viewing rate. In other words, a ratio of 2 has content time increase at twice the playback time. For every second of elapsed (wallclock) time, 2 seconds of content time will be delivered. A negative value indicates reverse direction. For certain media transports this may require certain considerations to work consistent, see Appendix C.1 for description on how RTP handles this. The transmitted data rate SHOULD NOT be changed by selection of a different scale value. The resulting bit-rate should be reasonably close to the nominal bit-rate of the content for Scale = 1. The server has to actively manipulate the data when needed to meet the bitrate constraints. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio, or completely mute the audio. The server and content may restrict the range of scale values that it supports. The supported values are indicated by the Media-Properties header (Section 18.28). The client SHOULD only indicate request Schulzrinne, et al. Expires October 6, 2013 [Page 159] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 values to be supported. However, as the values may change as the content progresses a requested value may no longer be valid when the request arrives. Thus, a non-supported value in a request does not generate an error, only forces the server to choose the closest value. The response MUST always contain the actual scale value chosen by the server. If the server does not implement the possibility to scale, it will not return a Scale header. A server supporting Scale operations for PLAY MUST indicate this with the use of the "play.scale" feature-tag. When indicating a negative scale for a reverse playback, the Range header MUST indicate a decreasing range as described in Section 18.38. Example of playing in reverse at 3.5 times normal rate: Scale: -3.5 Range: npt=15-10 18.45. Seek-Style When a client sends a PLAY request with a Range header to perform a random access to the media, the client does not know if the server will pick the first media samples or the first random access point prior to the request range. Depending on use case, the client may have a strong preference. To express this preference and provide the client with information on how the server actually acted on that preference the Seek-Style header is defined. Seek-Style is a general header that MAY be included in any PLAY request to indicate the client's preference for any media stream that has random access properties. The server MUST always include the header in any PLAY response for media with random access properties to indicate what policy was applied. A server that receives an unknown Seek-Style policy MUST ignore it and select the server default policy. A client receiving an unknown policy MUST ignore it and use the Range header and any media synchronization information as basis to determine what the server did. This specification defines the following seek policies that may be requested (see also Section 4.9.1): RAP: Random Access Point (RAP) is the behavior of requesting the server to locate the closest previous random access point that exists in the media aggregate and deliver from that. By requesting a RAP, media quality will be the best possible as all media will be delivered from a point where full media state can be established in the media decoder. Schulzrinne, et al. Expires October 6, 2013 [Page 160] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the above RAP behavior. This policy is primarily intended for cases where there is larger distance between the random access points in the media. CoRAP is conditioned on that there is a Random Access Point closer to the requested start point than to the current pause point. This policy assumes that the media state existing prior to the pause is usable if delivery is continued. If the client or server knows that this is not the fact the RAP policy should be used. In other words: in most cases when the client requests a start point prior to the current pause point, a valid decoding dependency chain from the media delivered prior to the pause and to the requested media unit will not exist. If the server searched to a random access point the server MUST return the CoRAP policy in the Seek-Style header and adjust the Range header to reflect the position of the picked RAP. In case the random access point is further away and the server selects to continue from the current pause point it MUST include the "Next" policy in the Seek-Style header and adjust the Range header start point to the current pause point. First-Prior: The first-prior policy will start delivery with the media unit that has a playout time first prior to the requested time. For discrete media that would only include media units that would still be rendered at the request time. For continuous media that is media that will be rendered during the requested start time of the range. Next: The next media units after the provided start time of the range. For continuous framed media that would mean the first next frame after the provided time. For discrete media the first unit that is to be rendered after the provided time. The main usage for this case is when the client knows it has all media up to a certain point and would like to continue delivery so that a complete non-interrupted media playback can be achieved. Example of such scenarios include switching from a broadcast/multicast delivery to a unicast based delivery. This policy MUST only be used on the client's explicit request. Please note that these expressed preferences exist for optimizing the startup time or the media quality. The "Next" policy breaks the normal definition of the Range header to enable a client to request media with minimal overlap, although some may still occur for aggregated sessions. RAP and First-Prior both fulfill the requirement of providing media from the requested range and forward. However, unless RAP is used, the media quality for many media codecs using predictive methods can be severely degraded unless additional data is available as, for example, already buffered, or through other side channels. Schulzrinne, et al. Expires October 6, 2013 [Page 161] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 18.46. Server The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application. Example: Server: PhonyServer/1.0 If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (Section 18.55). If the response is generated by the proxy, the proxy application MUST return the Server response-header as previously returned by the server. 18.47. Session The Session request-header and response-header field identifies an RTSP session. An RTSP session is created by the server as a result of a successful SETUP request and in the response the session identifier is given to the client. The RTSP session exists until destroyed by a TEARDOWN, REDIRECT or timed out by the server. The session identifier is chosen by the server (see Section 4.3) and MUST be returned in the SETUP response. Once a client receives a session identifier, it MUST be included in any request related to that session. This means that the Session header MUST be included in a request, using the following methods: PLAY, PAUSE, and TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and REDIRECT, and MUST NOT be included in DESCRIBE. The Session header MUST NOT be included in the following methods, if these requests are pipelined and if the session identifier is not yet known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and GET_PARAMETER. In an RTSP response the session header MUST be included in methods, SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if included in the request of the following methods it MUST also be included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. Note that a session identifier identifies an RTSP session across transport sessions or connections. RTSP requests for a given session can use different URIs (Presentation and media URIs). Note, that there are restrictions depending on the session which URIs that are Schulzrinne, et al. Expires October 6, 2013 [Page 162] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 acceptable for a given method. However, multiple "user" sessions for the same URI from the same client will require use of different session identifiers. The session identifier is needed to distinguish several delivery requests for the same URI coming from the same client. The response 454 (Session Not Found) MUST be returned if the session identifier is invalid. The header MAY include the session timeout period. If not explicitly provided this value is set to 60 seconds. As this affects how often session keep-alives are needed values smaller than 30 seconds are not recommended. However, larger than default values can be useful in applications of RTSP that have inactive but established sessions for longer time periods. 60 seconds was chosen as session timeout value due to: Resulting in not too frequent keep-alive messages and having low sensitivity to variations in request response timing. If one reduces the timeout value to below 30 seconds the corresponding request response timeout becomes a significant part of the session timeout. 60 seconds also allows for reasonably rapid recovery of committed server resources in case of client failure. 18.48. Speed The Speed request-header field requests the server to deliver specific amounts of nominal media time per unit of delivery time, contingent on the server's ability and desire to serve the media stream at the given speed. The client requests the delivery speed to be within a given range with a lower and upper bound. The server SHALL deliver at the highest possible speed within the range, but not faster than the upper-bound, for which the underlying network path can support the resulting transport data rates. As long as any speed value within the given range can be provided the server SHALL NOT modify the media quality. Only if the server is unable to deliver media at the speed value provided by the lower bound shall it reduce the media quality. Implementation of the Speed functionality by the server is OPTIONAL. The server can indicate its support through a feature-tag, play.speed. The lack of a Speed header in the response is an indication of lack of support of this functionality. The speed parameter values are expressed as a positive decimal value, e.g., a value of 2.0 indicates that data is to be delivered twice as fast as normal. A speed value of zero is invalid. The range is Schulzrinne, et al. Expires October 6, 2013 [Page 163] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 specified in the form "lower bound - upper bound". The lower bound value may be smaller or equal to the upper bound. All speeds may not be possible to support. Therefore the server MAY modify the requested values to the closest supported. The actual supported speed MUST be included in the response. Note, however, that the use cases may vary and that Speed value ranges such as 0.7 - 0.8, 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. Example: Speed: 1.0-2.5 Use of this header changes the bandwidth used for data delivery. It is meant for use in specific circumstances where delivery of the presentation at a higher or lower rate is desired. The main use cases are buffer operations or local scale operations. Implementors should keep in mind that bandwidth for the session may be negotiated beforehand (by means other than RTSP), and therefore re-negotiation may be necessary. To perform Speed operations the server needs to ensure that the network path can support the resulting bit-rate. Thus the media transport needs to support feedback so that the server can react and adapt to the available bitrate. 18.49. Supported The Supported header enumerates all the extensions supported by the client or server using feature tags. The header carries the extensions supported by the message sending client or server. The Supported header MAY be included in any request. When present in a request, the receiver MUST respond with its corresponding Supported header. Note that the Supported header is also included in 4xx and 5xx responses. The Supported header contains a list of feature-tags, described in Section 4.7, that are understood by the client or server. Example: C->S: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK Supported: bar, blech, baz Schulzrinne, et al. Expires October 6, 2013 [Page 164] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 18.50. Terminate-Reason The Terminate-Reason request header allows the server when sending a REDIRECT or TEARDOWN request to provide a reason for the session termination and any additional information. This specification identifies three reasons for Redirections and may be extended in the future: Server-Admin: The server needs to be shutdown for some administrative reason. Session-Timeout: A client's session is kept alive for extended periods of time and the server has determined that it needs to reclaim the resources associated with this session. Internal-Error An internal error that is impossible to recover from has occurred forcing the server to terminate the session. The Server may provide additional parameters containing information around the redirect. This specification defines the following ones. time: Provides a wallclock time when the server will stop provide any service. user-msg: An UTF-8 text string with a message from the server to the user. This message SHOULD be displayed to the user. 18.51. Timestamp The Timestamp general-header describes when the agent sent the request. The value of the timestamp is of significance only to the agent and may use any timescale. The responding agent MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that has elapsed since it has received the request. The timestamp can be used by the agent to compute the round-trip time to the responding agent so that it can adjust the timeout value for retransmissions when running over an unreliable protocol. It also resolves retransmission ambiguities for unreliable transport of RTSP. Note that the present specification provides only for reliable transport of RTSP messages. The Timestamp general-header is specified in case the protocol is extended in the future to use unreliable transport. Schulzrinne, et al. Expires October 6, 2013 [Page 165] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 18.52. Transport The Transport request and response header indicates which transport protocol is to be used and configures its parameters such as destination address, compression, multicast time-to-live and destination port for a single stream. It sets those values not already determined by a presentation description. A Transport request header MAY contain a list of transport options acceptable to the client, in the form of multiple transport specification entries. Transport specifications are comma separated, listed in decreasing order of preference. Parameters may be added to each transport specification, separated by a semicolon. The server MUST return a Transport response-header in the response to indicate the values actually chosen if any. If the transport specification is not supported, no transport header is returned and the request MUST be responded using the status code 461 (Unsupported Transport) (Section 17.4.26). In case more than one transport specification was present in the request, the server MUST return the single (transport- spec) which was actually chosen, if any. The number of transport- spec entries is expected to be limited as the client will get guidance on what configurations that are possible from the presentation description. The Transport header MAY also be used in subsequent SETUP requests to change transport parameters. A server MAY refuse to change parameters of an existing stream. A transport specification may only contain one of any given parameter within it. Parameters MAY be given in any order. Additionally, it may only contain either of the unicast or the multicast transport type parameter. All parameters need to be understood in a transport specification, if not, the transport specification MUST be ignored. An RTSP proxy of any type that uses or modifies the transport specification, e.g. access proxy or security proxy, MUST remove specifications with unknown parameters before forwarding the RTSP message. If that results in no remaining transport specification the proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26) response without any Transport header. The Transport header is restricted to describing a single media stream. (RTSP can also control multiple streams as a single entity.) Making it part of RTSP rather than relying on a multitude of session description formats greatly simplifies designs of firewalls. The general syntax for the transport specifier is a list of slash separated tokens: Schulzrinne, et al. Expires October 6, 2013 [Page 166] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Value1/Value2/Value3... Which for RTP transports take the form: RTP/profile/lower-transport. The default value for the "lower-transport" parameters is specific to the profile. For RTP/AVP, the default is UDP. There are two different methods for how to specify where the media should be delivered for unicast transport: dest_addr: The presence of this parameter and its values indicates the destination address or addresses (host address and port pairs for IP flows) necessary for the media transport. No dest_addr: The lack of the dest_addr parameter indicates that the server MUST send media to same address for which the RTSP messages originates. The choice of method for indicating where the media is to be delivered depends on the use case. In some cases the only allowed method will be to use no explicit address indication and have the server deliver media to the source of the RTSP messages. For Multicast there is several methods for specifying addresses but they are different in how they work compared with unicast: dest_addr with client picked address: The address and relevant parameters, like TTL (scope), for the actual multicast group to deliver the media to. There are security implications (Section 21) with this method that need to be addressed if using this method because a RTSP server can be used as a DoS attacker on an existing multicast group. dest_addr using Session Description Information: The information included in the transport header can all be coming from the session description, e.g. the SDP c= and m= line. This mitigates some of the security issues of the previous methods as it is the session provider that picks the multicast group and scope. The client MUST include the information if it is available in the session description. No dest_addr: The behavior when no explicit multicast group is present in a request is not defined. An RTSP proxy will need to take care. If the media is not desired to be routed through the proxy, the proxy will need to introduce the destination indication. Schulzrinne, et al. Expires October 6, 2013 [Page 167] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Below are the configuration parameters associated with transport: General parameters: unicast / multicast: This parameter is a mutually exclusive indication of whether unicast or multicast delivery will be attempted. One of the two values MUST be specified. Clients that are capable of handling both unicast and multicast transmission needs to indicate such capability by including two full transport-specs with separate parameters for each. layers: The number of multicast layers to be used for this media stream. The layers are sent to consecutive addresses starting at the dest_addr address. If the parameter is not included, it defaults to a single layer. dest_addr: A general destination address parameter that can contain one or more address specifications. Each combination of protocol/profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/ AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port. Note, only a single destination parameter per transport spec is intended. The usage of multiple destinations to distribute a single media to multiple entities is unspecified. The client originating the RTSP request MAY specify the destination address of the stream recipient with the host address part of the tuple. When the destination address is specified, the recipient may be a different party than the originator of the request. To avoid becoming the unwitting perpetrator of a remote-controlled denial-of-service attack, a server MUST perform security checks (see Section 21.2.1) and SHOULD log such attempts before allowing the client to direct a media stream to a recipient address not chosen by the server. Implementations cannot rely on TCP as reliable means of client identification. If the server does not allow the host address part of the tuple to be set, it MUST return 463 (Destination Prohibited). The host address part of the tuple MAY be empty, for example ":58044", in cases when only destination port is desired to be specified. Responses to requests including the Transport header with a dest_addr parameter SHOULD include the full destination address that is actually used by the server. The server MUST NOT remove address information present already in the request when responding unless the protocol requires it. Schulzrinne, et al. Expires October 6, 2013 [Page 168] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 src_addr: A general source address parameter that can contain one or more address specifications. Each combination of protocol/ profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/ AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port. This parameter MUST be specified by the server if it transmits media packets from another address than the one RTSP messages are sent to. This will allow the client to verify source address and give it a destination address for its RTCP feedback packets, if RTP is used. The address or addresses indicated in the src_addr parameter SHOULD be used both for sending and receiving of the media streams data packets. The main reasons are threefold: First, indicating the port and source address(s) lets the receiver know where from the packets is expected to originate. Secondly, traversal of NATs is greatly simplified when traffic is flowing symmetrically over a NAT binding. Thirdly, certain NAT traversal mechanisms, needs to know to which address and port to send so called "binding packets" from the receiver to the sender, thus creating an address binding in the NAT that the sender to receiver packet flow can use. This information may also be available through SDP. However, since this is more a feature of transport than media initialization, the authoritative source for this information should be in the SETUP response. mode: The mode parameter indicates the methods to be supported for this session. Currently defined valid values are "PLAY". If not provided, the default is "PLAY". The "RECORD" value was defined in RFC 2326 and is in this specification unspecified but reserved. RECORD and other values may be specified in the future. interleaved: The interleaved parameter implies mixing the media stream with the control stream in whatever protocol is being used by the control stream, using the mechanism defined in Section 14. The argument provides the channel number to be used in the $ block (see Section 14) and MUST be present. This parameter MAY be specified as an interval, e.g., interleaved=4-5 in cases where the transport choice for the media stream requires it, e.g., for RTP with RTCP. The channel number given in the request is only a guidance from the client to the server on what channel number(s) to use. The server MAY set any valid channel number in the response. The declared channel(s) are bi-directional, so both end-parties MAY send Schulzrinne, et al. Expires October 6, 2013 [Page 169] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 data on the given channel. One example of such usage is the second channel used for RTCP, where both server and client send RTCP packets on the same channel. This allows RTP/RTCP to be handled similarly to the way that it is done with UDP, i.e., one channel for RTP and the other for RTCP. MIKEY: This parameter is used in conjunction with transport specifications that can utilize MIKEY [RFC3830] for security context establishment. So far only the SRTP based RTP profiles SAVP and SAVPF can utilize MIKEY and this is defined in Appendix C.1.4.1. This parameter can be included both in request and response messages. The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before being included in the value part of the parameter. Multicast-specific: ttl: multicast time-to-live for IPv4. When included in requests the value indicate the TTL value that the client requests the server to use. In a response, the value actually being used by the server is returned. A server will need to consider what values that are reasonable and also the authority of the user to set this value. Corresponding functions are not needed for IPv6 as the scoping is part of the IPv6 multicast address [RFC4291]. RTP-specific: These parameters MAY only be used if the media transport protocol is RTP. ssrc: The ssrc parameter, if included in a SETUP response, indicates the RTP SSRC [RFC3550] value(s) that will be used by the media server for RTP packets within the stream. It is expressed as an eight digit hexadecimal value. The ssrc parameter MUST NOT be specified in requests. The functionality of specifying the ssrc parameter in a SETUP request is deprecated as it is incompatible with the specification of RTP in RFC 3550[RFC3550]. If the parameter is included in the Transport header of a SETUP request, the server SHOULD ignore it, and choose appropriate SSRCs for the stream. The server SHOULD set the ssrc parameter in the Transport header of the response. Schulzrinne, et al. Expires October 6, 2013 [Page 170] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing [RFC5761] on a single underlying transport stream / flow. The presence of this parameter in a SETUP request indicates the client's support and requires the server to use RTP and RTCP multiplexing. The client SHALL only include one transport stream in the Transport header specification. To provide the server with a choice between using RTP/RTCP multiplexing or not, two different transport header specifications must be included. The parameters setup and connection defined below MAY only be used if the media transport protocol of the lower-level transport is connection-oriented (such as TCP). However, these parameters MUST NOT be used when interleaving data over the RTSP control connection. setup: Clients use the setup parameter on the Transport line in a SETUP request, to indicate the roles it wishes to play in a TCP connection. This parameter is adapted from [RFC4145]. We discuss the use of this parameter in RTP/AVP/TCP non- interleaved transport in Appendix C.2.2; the discussion below is limited to syntactic issues. Clients may specify the following values for the setup parameter: ["active:"] The client will initiate an outgoing connection. ["passive":] The client will accept an incoming connection. ["actpass":] The client is willing to accept an incoming connection or to initiate an outgoing connection. If a client does not specify a setup value, the "active" value is assumed. In response to a client SETUP request where the setup parameter is set to "active", a server's 2xx reply MUST assign the setup parameter to "passive" on the Transport header line. In response to a client SETUP request where the setup parameter is set to "passive", a server's 2xx reply MUST assign the setup parameter to "active" on the Transport header line. In response to a client SETUP request where the setup parameter is set to "actpass", a server's 2xx reply MUST assign the setup parameter to "active" or "passive" on the Transport header line. Note that the "holdconn" value for setup is not defined for Schulzrinne, et al. Expires October 6, 2013 [Page 171] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTSP use, and MUST NOT appear on a Transport line. connection: Clients use the setup parameter on the Transport line in a SETUP request, to indicate the SETUP request prefers the reuse of an existing connection between client and server (in which case the client sets the "connection" parameter to "existing"), or that the client requires the creation of a new connection between client and server (in which cast the client sets the "connection" parameter to "new"). Typically, clients use the "new" value for the first SETUP request for a URL, and "existing" for subsequent SETUP requests for a URL. If a client SETUP request assigns the "new" value to "connection", the server response MUST also assign the "new" value to "connection" on the Transport line. If a client SETUP request assigns the "existing" value to "connection", the server response MUST assign a value of "existing" or "new" to "connection" on the Transport line, at its discretion. The default value of "connection" is "existing", for all SETUP requests (initial and subsequent). The combination of transport protocol, profile and lower transport needs to be defined. A number of combinations are defined in the Appendix C. Below is a usage example, showing a client advertising the capability to handle multicast or unicast, preferring multicast. Since this is a unicast-only stream, the server responds with the proper transport parameters for unicast. Schulzrinne, et al. Expires October 6, 2013 [Page 172] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 CSeq: 302 Transport: RTP/AVP;multicast;mode="PLAY", RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ "192.0.2.5:3457";mode="PLAY" Accept-Ranges: NPT, SMPTE, UTC User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 302 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: 47112344 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ "192.0.2.224:6257";mode="PLAY" Accept-Ranges: NPT Media-Properties: Random-Access=0.6, Dynamic, Time-Limited=20081128T165900 18.53. Unsupported The Unsupported response-header lists the features not supported by the responding RTSP agent. In the case where the feature was specified via the Proxy-Require field (Section 18.35), if there is a proxy on the path between the client and the server, the proxy MUST send a response message with a status code of 551 (Option Not Supported). The request MUST NOT be forwarded. See Section 18.41 for a usage example. 18.54. User-Agent The User-Agent general-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application. Example: User-Agent: PhonyClient/1.2 Schulzrinne, et al. Expires October 6, 2013 [Page 173] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 18.55. Via The Via general-header field MUST be used by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. The field is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain. Multiple Via field values represents each proxy that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications. Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by default, forward the names and ports of hosts within the private/ protected region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the via-received of any host behind the firewall/NAT SHOULD be replaced by an appropriate pseudonym for that host. For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical sent-protocol values into a single such entry. Applications MUST NOT combine entries which have different received-protocol values. 18.56. WWW-Authenticate The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. The HTTP access authentication process is described in [RFC2617]. User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters. Schulzrinne, et al. Expires October 6, 2013 [Page 174] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 19. Security Framework The RTSP security framework consists of two high level components: the pure authentication mechanisms based on HTTP authentication, and the message transport protection based on TLS, which is independent of RTSP. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security for HTTP is re-used to a large extent. 19.1. RTSP and HTTP Authentication RTSP and HTTP share common authentication schemes, and thus follow the same usage guidelines as specified in [RFC2617] and also in [H15]. Servers SHOULD implement both basic and digest [RFC2617] authentication. Clients MUST implement both basic and digest authentication [RFC2617] so that a server that requires the client to authenticate can trust that the capability is present. It should be stressed that using the HTTP authentication alone does not provide full control message security. Therefore, in environments requiring tighter security for the control messages, TLS SHOULD be used, see Section 19.2. 19.2. RTSP over TLS RTSP agents MUST implement RTSP over TLS as defined in this section and the next Section 19.3. RTSP MUST follow the same guidelines with regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. RTSP over TLS is separated from unsecured RTSP both on URI level and port level. Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier MUST be used to signal RTSP over TLS. If no port is given in a URI with the "rtsps" scheme, port 322 MUST be used for TLS over TCP/IP. When a client tries to setup an insecure channel to the server (using the "rtsp" URI), and the policy for the resource requires a secure channel, the server MUST redirect the client to the secure service by sending a 301 redirect response code together with the correct Location URI (using the "rtsps" scheme). A user or client MAY upgrade a non secured URI to a secured by changing the scheme from "rtsp" to "rtsps". A server implementing support for "rtsps" MUST allow this. It should be noted that TLS allows for mutual authentication (when using both server and client certificates). Still, one of the more common ways TLS is used is to only provide server side authentication (often to avoid client certificates). TLS is then used in addition to HTTP authentication, providing transport security and server Schulzrinne, et al. Expires October 6, 2013 [Page 175] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 authentication, while HTTP Authentication is used to authenticate the client. RTSP includes the possibility to keep a TCP session up between the client and server, throughout the RTSP session lifetime. It may be convenient to keep the TCP session, not only to save the extra setup time for TCP, but also the extra setup time for TLS (even if TLS uses the resume function, there will be almost two extra round trips). Still, when TLS is used, such behavior introduces extra active state in the server, not only for TCP and RTSP, but also for TLS. This may increase the vulnerability to DoS attacks. In addition to these recommendations, Section 19.3 gives further recommendations of TLS usage with proxies. 19.3. Security and Proxies The nature of a proxy is often to act as a "man-in-the-middle", while security is often about preventing the existence of a "man-in-the- middle". This section provides clients with the possibility to use proxies even when applying secure transports (TLS) between the RTSP agents. The TLS proxy mechanism allows for server and proxy identification using certificates. However, the client cannot be identified based on certificates. The client needs to select between using the procedure specified below or using a TLS connection directly (by-passing any proxies) to the server. The choice may be dependent on policies. There are basically two categories of proxies, the transparent proxies (of which the client is not aware) and the non-transparent proxies (of which the client is aware), see Section 15 for an introduction to RTSP proxies. An infrastructure based on proxies requires that the trust model is such that both client and servers can trust the proxies to handle the RTSP messages correctly. To be able to trust a proxy, the client and server also needs to be aware of the proxy. Hence, transparent proxies cannot generally be seen as trusted and will not work well with security (unless they work only at transport layer). In the rest of this section any reference to proxy will be to a non-transparent proxy, which inspects or manipulates the RTSP messages. HTTP Authentication is built on the assumption of proxies and can provide user-proxy authentication and proxy-proxy/server authentication in addition to the client-server authentication. When TLS is applied and a proxy is used, the client will connect to the proxy's address when connecting to any RTSP server. This implies that for TLS, the client will authenticate the proxy server and not Schulzrinne, et al. Expires October 6, 2013 [Page 176] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 the end server. Note that when the client checks the server certificate in TLS, it MUST check the proxy's identity (URI or possibly other known identity) against the proxy's identity as presented in the proxy's Certificate message. The problem is that for a proxy accepted by the client, the proxy needs to be provided information on which grounds it should accept the next-hop certificate. Both the proxy and the user may have rules for this, and the user should have the possibility to select the desired behavior. To handle this case, the Accept-Credentials header (See Section 18.2) is used, where the client can request the proxy/ proxies to relay back the chain of certificates used to authenticate any intermediate proxies as well as the server. The assumption that the proxies are viewed as trusted, gives the user a possibility to enforce policies to each trusted proxy of whether it should accept the next agent in the chain. However, it should be noted that not all deployments will return the chain of certificates used to authenticate any intermediate proxies as well as the server. An operator of such a deployment may want to hide its topology from the client. It should be noted well that the client does not have any insight into the proxy's operation. Even if the proxy is trusted, it can still return an incomplete chain of certificates. A proxy MUST use TLS for the next hop if the RTSP request includes a "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between client and proxy, or between proxy and proxy), even if the resource and the end server are not required to use it. The proxy MUST, when initiating the next hop TLS connection, use the incoming TLS connections cipher suite list, only modified by removing any cipher suites that the proxy does not support. In case a proxy fails to establish a TLS connection due to cipher suite mismatch between proxy and next hop proxy or server, this is indicated using error code 472 (Failure to establish secure connection). 19.3.1. Accept-Credentials The Accept-Credentials header can be used by the client to distribute simple authorization policies to intermediate proxies. The client includes the Accept-Credentials header to dictate how the proxy treats the server/next proxy certificate. There are currently three methods defined: Any, which means that the proxy (or proxies) MUST accept whatever certificate presented. This is of course not a recommended option to use, but may be useful in certain circumstances (such as testing). Schulzrinne, et al. Expires October 6, 2013 [Page 177] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Proxy, which means that the proxy (or proxies) MUST use its own policies to validate the certificate and decide whether to accept it or not. This is convenient in cases where the user has a strong trust relation with the proxy. Reasons why a strong trust relation may exist are; personal/company proxy, proxy has a out-of-band policy configuration mechanism. User, which means that the proxy (or proxies) MUST send credential information about the next hop to the client for authorization. The client can then decide whether the proxy should accept the certificate or not. See Section 19.3.2 for further details. If the Accept-Credentials header is not included in the RTSP request from the client, then the "Proxy" method MUST be used as default. If another method than the "Proxy" is to be used, then the Accept- Credentials header MUST be included in all of the RTSP requests from the client. This is because it cannot be assumed that the proxy always keeps the TLS state or the user's previous preference between different RTSP messages (in particular if the time interval between the messages is long). With the "Any" and "Proxy" methods the proxy will apply the policy as defined for each method. If the policy does not accept the credentials of the next hop, the proxy MUST respond with a message using status code 471 (Connection Credentials not accepted). An RTSP request in the direction server to client MUST NOT include the Accept-Credentials header. As for the non-secured communication, the possibility for these requests depends on the presence of a client established connection. However, if the server to client request is in relation to a session established over a TLS secured channel, it MUST be sent in a TLS secured connection. That secured connection MUST also be the one used by the last client to server request. If no such transport connection exists at the time when the server desires to send the request, the server MUST discard the message. Further policies MAY be defined and registered, but should be done so with caution. 19.3.2. User approved TLS procedure For the "User" method, each proxy MUST perform the following procedure for each RTSP request: o Setup the TLS session to the next hop if not already present (i.e. run the TLS handshake, but do not send the RTSP request). Schulzrinne, et al. Expires October 6, 2013 [Page 178] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o Extract the peer certificate chain for the TLS session. o Check if a matching identity and hash of the peer certificate is present in the Accept-Credentials header. If present, send the message to the next hop, and conclude these procedures. If not, go to the next step. o The proxy responds to the RTSP request with a 470 or 407 response code. The 407 response code MAY be used when the proxy requires both user and connection authorization from user or client. In this message the proxy MUST include a Connection-Credentials header, see Section 18.12 with the next hop's identity and certificate. The client MUST upon receiving a 470 or 407 response with Connection- Credentials header take the decision on whether to accept the certificate or not (if it cannot do so, the user SHOULD be consulted). If the certificate is accepted, the client has to again send the RTSP request. In that request the client has to include the Accept-Credentials header including the hash over the DER encoded certificate for all trusted proxies in the chain. Example: Schulzrinne, et al. Expires October 6, 2013 [Page 179] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 CSeq: 2 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ "192.0.2.5:4589" Accept-Ranges: NPT, SMPTE, UTC Accept-Credentials: User P->C: RTSP/2.0 470 Connection Authorization Required CSeq: 2 Connection-Credentials: "rtsps://test.example.org"; MIIDNTCCAp... C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 CSeq: 3 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ "192.0.2.5:4589" Accept-Credentials: User "rtsps://test.example.org";sha-256; dPYD7txpoGTbAqZZQJ+vaeOkyH4= Accept-Ranges: NPT, SMPTE, UTC P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 CSeq: 3 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ "192.0.2.5:4589" Via: RTSP/2.0 proxy.example.org Accept-Credentials: User "rtsps://test.example.org";sha-256; dPYD7txpoGTbAqZZQJ+vaeOkyH4= Accept-Ranges: NPT, SMPTE, UTC One implication of this process is that the connection for secured RTSP messages may take significantly more round-trip times for the first message. A complete extra message exchange between the proxy connecting to the next hop and the client results because of the process for approval for each hop. However, if each message contains the chain of proxies that the requester accepts, the remaining message exchange should not be delayed. The procedure of including the credentials in each request rather than building state in each proxy, avoids the need for revocation procedures. Schulzrinne, et al. Expires October 6, 2013 [Page 180] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 20. Syntax The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) as defined in RFC 5234 [RFC5234]. It uses the basic definitions present in RFC 5234. Please note that ABNF strings, e.g. "Accept", are case insensitive as specified in section 2.3 of RFC 5234. The RTSP syntax makes use of the ISO 10646 character set in UTF-8 encoding RFC 3629 [RFC3629]. 20.1. Base Syntax RTSP header values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [RFC2616]. The SWS construct is used when linear white space is optional, generally between tokens and separators. To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a line break. The HCOLON defines this construct. OCTET = %x00-FF ; any 8-bit sequence of data CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" ALPHA = UPALPHA / LOALPHA DIGIT = %x30-39 ; any US-ASCII digit "0".."9" CTL = %x00-1F / %x7F ; any US-ASCII control character ; (octets 0 - 31) and DEL (127) CR = %x0D ; US-ASCII CR, carriage return (13) LF = %x0A ; US-ASCII LF, linefeed (10) SP = %x20 ; US-ASCII SP, space (32) HT = %x09 ; US-ASCII HT, horizontal-tab (9) BACKSLASH = %x5C ; US-ASCII backslash (92) CRLF = CR LF Schulzrinne, et al. Expires October 6, 2013 [Page 181] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space SWS = [LWS] ; Separating White Space HCOLON = *( SP / HT ) ":" SWS TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / BACKSLASH / DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HT token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7A / %x7C / %x7E) ; 1*<any CHAR except CTLs or tspecials> quoted-string = ( DQUOTE *qdtext DQUOTE ) qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII ; No DQUOTE and no "\" quoted-pair = "\\" / ( "\" DQUOTE ) ctext = %x20-27 / %x2A-7E / %x80-FF ; any OCTET except CTLs, "(" and ")" generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string safe = "$" / "-" / "_" / "." / "+" extra = "!" / "*" / "'" / "(" / ")" / "," rtsp-extra = "!" / "*" / "'" / "(" / ")" HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / "a" / "b" / "c" / "d" / "e" / "f" LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" ; lowercase "a-f" Hex reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" unreserved = ALPHA / DIGIT / safe / extra rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra base64 = *base64-unit [base64-pad] base64-unit = 4base64-char base64-pad = (2base64-char "==") / (3base64-char "=") base64-char = ALPHA / DIGIT / "+" / "/" Schulzrinne, et al. Expires October 6, 2013 [Page 182] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 SLASH = SWS "/" SWS ; slash EQUAL = SWS "=" SWS ; equal LPAREN = SWS "(" SWS ; left parenthesis RPAREN = SWS ")" SWS ; right parenthesis COMMA = SWS "," SWS ; comma SEMI = SWS ";" SWS ; semicolon COLON = SWS ":" SWS ; colon MINUS = SWS "-" SWS ; minus/dash LDQUOT = SWS DQUOTE ; open double quotation mark RDQUOT = DQUOTE SWS ; close double quotation mark RAQUOT = ">" SWS ; right angle quote LAQUOT = SWS "<" ; left angle quote TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-CONT = %x80-BF POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] FLOAT = ["-"] POS-FLOAT 20.2. RTSP Protocol Definition 20.2.1. Generic Protocol elements Schulzrinne, et al. Expires October 6, 2013 [Page 183] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTSP-IRI = schemes ":" IRI-rest IRI-rest = ihier-part [ "?" iquery ] ihier-part = "//" iauthority ipath-abempty RTSP-IRI-ref = RTSP-IRI / irelative-ref irelative-ref = irelative-part [ "?" iquery ] irelative-part = "//" iauthority ipath-abempty / ipath-absolute / ipath-noscheme / ipath-empty iauthority = < As defined in RFC 3987> ipath = ipath-abempty ; begins with "/" or is empty / ipath-absolute ; begins with "/" but not "//" / ipath-noscheme ; begins with a non-colon segment / ipath-rootless ; begins with a segment / ipath-empty ; zero characters ipath-abempty = *( "/" isegment ) ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] ipath-noscheme = isegment-nz-nc *( "/" isegment ) ipath-rootless = isegment-nz *( "/" isegment ) ipath-empty = 0<ipchar> isegment = *ipchar [";" *ipchar] isegment-nz = 1*ipchar [";" *ipchar] / ";" *ipchar isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) / ";" *ipchar-nc ; non-zero-length segment without any colon ":" ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" iquery = < As defined in RFC 3987> iunreserved = < As defined in RFC 3987> pct-encoded = < As defined in RFC 3987> Schulzrinne, et al. Expires October 6, 2013 [Page 184] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTSP-URI = schemes ":" URI-rest RTSP-REQ-URI = schemes ":" URI-req-rest RTSP-URI-Ref = RTSP-URI / RTSP-Relative RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel schemes = "rtsp" / "rtsps" / scheme scheme = < As defined in RFC 3986> URI-rest = hier-part [ "?" query ] URI-req-rest = hier-part [ "?" query ] ; Note fragment part not allowed in requests hier-part = "//" authority path-abempty RTSP-Relative = relative-part [ "?" query ] RTSP-REQ-Rel = relative-part [ "?" query ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty authority = < As defined in RFC 3986> query = < As defined in RFC 3986> path = path-abempty ; begins with "/" or is empty / path-absolute ; begins with "/" but not "//" / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> segment = *pchar [";" *pchar] segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@" pchar-nc = unreserved / pct-encoded / sub-delims / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / "=" Schulzrinne, et al. Expires October 6, 2013 [Page 185] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 smpte-range = smpte-type ["=" smpte-range-spec] ; See section 3.4 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) / ( "-" smpte-time ) smpte-type = "smpte" / "smpte-30-drop" / "smpte-25" / smpte-type-extension ; other timecodes may be added smpte-type-extension = "smpte" token smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] npt-range = "npt" ["=" npt-range-spec] npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) npt-time = "now" / npt-sec / npt-hhmmss npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] npt-hh = 1*19DIGIT ; any positive number npt-mm = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59 utc-range = "clock" ["=" utc-range-spec] utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) utc-time = utc-date "T" utc-clock "Z" utc-date = 8DIGIT utc-clock = 6DIGIT [ "." 1*9DIGIT ] feature-tag = token session-id = 1*256( ALPHA / DIGIT / safe ) extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 20.2.2. Message Syntax Schulzrinne, et al. Expires October 6, 2013 [Page 186] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTSP-message = Request / Response ; RTSP/2.0 messages Request = Request-Line *((general-header / request-header / message-header) CRLF) CRLF [ message-body-data ] Response = Status-Line *((general-header / response-header / message-header) CRLF) CRLF [ message-body-data ] Request-Line = Method SP Request-URI SP RTSP-Version CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Method = "DESCRIBE" / "GET_PARAMETER" / "OPTIONS" / "PAUSE" / "PLAY" / "PLAY_NOTIFY" / "REDIRECT" / "SETUP" / "SET_PARAMETER" / "TEARDOWN" / extension-method extension-method = token Request-URI = "*" / RTSP-REQ-URI RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT message-body-data = 1*OCTET Status-Code = "100" ; Continue / "200" ; OK / "301" ; Moved Permanently / "302" ; Found / "303" ; See Other / "304" ; Not Modified / "305" ; Use Proxy / "400" ; Bad Request / "401" ; Unauthorized / "402" ; Payment Required Schulzrinne, et al. Expires October 6, 2013 [Page 187] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 / "403" ; Forbidden / "404" ; Not Found / "405" ; Method Not Allowed / "406" ; Not Acceptable / "407" ; Proxy Authentication Required / "408" ; Request Time-out / "410" ; Gone / "411" ; Length Required / "412" ; Precondition Failed / "413" ; Request Message Body Too Large / "414" ; Request-URI Too Large / "415" ; Unsupported Media Type / "451" ; Parameter Not Understood / "452" ; reserved / "453" ; Not Enough Bandwidth / "454" ; Session Not Found / "455" ; Method Not Valid in This State / "456" ; Header Field Not Valid for Resource / "457" ; Invalid Range / "458" ; Parameter Is Read-Only / "459" ; Aggregate operation not allowed / "460" ; Only aggregate operation allowed / "461" ; Unsupported Transport / "462" ; Destination Unreachable / "463" ; Destination Prohibited / "464" ; Data Transport Not Ready Yet / "465" ; Notification Reason Unknown / "466" ; Key Management Error / "470" ; Connection Authorization Required / "471" ; Connection Credentials not accepted / "472" ; Failure to establish secure connection / "500" ; Internal Server Error / "501" ; Not Implemented / "502" ; Bad Gateway / "503" ; Service Unavailable / "504" ; Gateway Time-out / "505" ; RTSP Version not supported / "551" ; Option not supported / extension-code extension-code = 3DIGIT Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) Schulzrinne, et al. Expires October 6, 2013 [Page 188] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 general-header = Cache-Control / Connection / CSeq / Date / Media-Properties / Media-Range / Pipelined-Requests / Proxy-Supported / Seek-Style / Server / Supported / Timestamp / User-Agent / Via / extension-header request-header = Accept / Accept-Credentials / Accept-Encoding / Accept-Language / Authorization / Bandwidth / Blocksize / From / If-Match / If-Modified-Since / If-None-Match / Notify-Reason / Proxy-Require / Range / Referrer / Request-Status / Require / Scale / Session / Speed / Supported / Terminate-Reason / Transport / extension-header Schulzrinne, et al. Expires October 6, 2013 [Page 189] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 response-header = Accept-Credentials / Accept-Ranges / Connection-Credentials / MTag / Location / Proxy-Authenticate / Public / Range / Retry-After / RTP-Info / Scale / Session / Speed / Transport / Unsupported / WWW-Authenticate / extension-header message-header = Allow / Content-Base / Content-Encoding / Content-Language / Content-Length / Content-Location / Content-Type / Expires / Last-Modified / extension-header 20.2.3. Header Syntax Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-type-range [SEMI accept-params] media-type-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-params = "q" EQUAL qvalue *(SEMI generic-param ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3("0") ] ) Accept-Credentials = "Accept-Credentials" HCOLON cred-decision cred-decision = ("User" [LWS cred-info]) / "Proxy" / "Any" / (token [LWS 1*header-value]) ; For future extensions Schulzrinne, et al. Expires October 6, 2013 [Page 190] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 cred-info = cred-info-data *(COMMA cred-info-data) cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg SEMI base64 hash-alg = "sha-256" / extension-alg extension-alg = token Accept-Encoding = "Accept-Encoding" HCOLON [ encoding *(COMMA encoding) ] encoding = codings [SEMI accept-params] codings = content-coding / "*" content-coding = token Accept-Language = "Accept-Language" HCOLON language *(COMMA language) language = language-range [SEMI accept-params] language-range = language-tag / "*" language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges acceptable-ranges = (range-unit *(COMMA range-unit)) range-unit = "NPT" / "SMPTE" / "UTC" / extension-format extension-format = token Allow = "Allow" HCOLON Method *(COMMA Method) Authorization = "Authorization" HCOLON credentials credentials = ("Digest" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = "username" EQUAL username-value username-value = quoted-string digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = RTSP-REQ-URI message-qop = "qop" EQUAL qop-value cnonce = "cnonce" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX dresponse = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Schulzrinne, et al. Expires October 6, 2013 [Page 191] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT Blocksize = "Blocksize" HCOLON 1*9DIGIT Cache-Control = "Cache-Control" HCOLON cache-directive *(COMMA cache-directive) cache-directive = cache-rqst-directive / cache-rspns-directive cache-rqst-directive = "no-cache" / "max-stale" [EQUAL delta-seconds] / "min-fresh" EQUAL delta-seconds / "only-if-cached" / cache-extension cache-rspns-directive = "public" / "private" / "no-cache" / "no-transform" / "must-revalidate" / "proxy-revalidate" / "max-age" EQUAL delta-seconds / cache-extension cache-extension = token [EQUAL (token / quoted-string)] delta-seconds = 1*19DIGIT Connection = "Connection" HCOLON connection-token *(COMMA connection-token) connection-token = "close" / token Connection-Credentials = "Connection-Credentials" HCOLON cred-chain cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64 Content-Base = "Content-Base" HCOLON RTSP-URI Content-Encoding = "Content-Encoding" HCOLON content-coding *(COMMA content-coding) Content-Language = "Content-Language" HCOLON language-tag *(COMMA language-tag) Content-Length = "Content-Length" HCOLON 1*19DIGIT Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref Content-Type = "Content-Type" HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token composite-type = "message" / "multipart" / extension-token extension-token = ietf-token / x-token Schulzrinne, et al. Expires October 6, 2013 [Page 192] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 ietf-token = token x-token = "x-" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string CSeq = "CSeq" HCOLON cseq-nr cseq-nr = 1*9DIGIT Date = "Date" HCOLON RTSP-date RTSP-date = rfc1123-date ; HTTP-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" Expires = "Expires" HCOLON RTSP-date From = "From" HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = RTSP-REQ-URI / absolute-URI absolute-URI = < As defined in RFC 3986> display-name = *(token LWS) / quoted-string from-param = tag-param / generic-param tag-param = "tag" EQUAL token If-Match = "If-Match" HCOLON ("*" / message-tag-list) message-tag-list = message-tag *(COMMA message-tag) message-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) Last-Modified = "Last-Modified" HCOLON RTSP-date Location = "Location" HCOLON RTSP-REQ-URI Media-Properties = "Media-Properties" HCOLON [media-prop-list] media-prop-list = media-prop-value *(COMMA media-prop-value) media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) / "Begining-Only" / "No-Seeking" / "Immutable" / "Dynamic" Schulzrinne, et al. Expires October 6, 2013 [Page 193] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 / "Time-Progressing" / "Unlimited" / ("Time-Limited" EQUAL utc-time) / ("Time-Duration" EQUAL POS-FLOAT) / ("Scales" EQUAL scale-value-list) / media-prop-ext media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE scale-entry = scale-value / (scale-value COLON scale-value) scale-value = FLOAT Media-Range = "Media-Range" HCOLON [ranges-list] ranges-list = ranges-spec *(COMMA ranges-spec) MTag = "MTag" HCOLON message-tag Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val Notify-Reas-val = "end-of-stream" / "media-properties-update" / "scale-change" / Notify-Reason-extension Notify-Reason-extension = token Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id startup-id = 1*8DIGIT Schulzrinne, et al. Expires October 6, 2013 [Page 194] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list challenge-list = challenge *(COMMA challenge) challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = "realm" EQUAL realm-value realm-value = quoted-string domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref *(1*SP RTSP-REQ-Ref ) RDQUOT nonce = "nonce" EQUAL nonce-value nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ( "true" / "false" ) algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT qop-value = "auth" / "auth-int" / token Proxy-Require = "Proxy-Require" HCOLON feature-tag-list feature-tag-list = feature-tag *(COMMA feature-tag) Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] Public = "Public" HCOLON Method *(COMMA Method) Range = "Range" HCOLON ranges-spec ranges-spec = npt-range / utc-range / smpte-range / range-ext range-ext = extension-format ["=" range-value] range-value = 1*(rtsp-unreserved / quoted-string / ":" ) Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) Request-Status = "Request-Status" HCOLON req-status-info req-status-info = cseq-info LWS status-info LWS reason-info cseq-info = "cseq" EQUAL cseq-nr status-info = "status" EQUAL Status-Code reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE Require = "Require" HCOLON feature-tag-list Schulzrinne, et al. Expires October 6, 2013 [Page 195] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec *(COMMA rtsp-info-spec)] rtsp-info-spec = stream-url 1*ssrc-parameter stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON ri-parameter *(SEMI ri-parameter) ri-parameter = ("seq" EQUAL 1*5DIGIT) / ("rtptime" EQUAL 1*10DIGIT) / generic-param Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds) Scale = "Scale" HCOLON scale-value Seek-Style = "Seek-Style" HCOLON Seek-S-values Seek-S-values = "RAP" / "CoRAP" / "First-Prior" / "Next" / Seek-S-value-ext Seek-S-value-ext = token Server = "Server" HCOLON ( product / comment ) *(LWS (product / comment)) product = token [SLASH product-version] product-version = token comment = LPAREN *( ctext / quoted-pair) RPAREN Session = "Session" HCOLON session-id [ SEMI "timeout" EQUAL delta-seconds ] Speed = "Speed" HCOLON lower-bound MINUS upper-bound lower-bound = POS-FLOAT upper-bound = POS-FLOAT Supported = "Supported" HCOLON [feature-tag-list] Schulzrinne, et al. Expires October 6, 2013 [Page 196] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info TR-Info = TR-Reason *(SEMI TR-Parameter) TR-Reason = "Session-Timeout" / "Server-Admin" / "Internal-Error" / token TR-Parameter = TR-time / TR-user-msg / generic-param TR-time = "time" EQUAL utc-time TR-user-msg = "user-msg" EQUAL quoted-string Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] timestamp-value = *19DIGIT [ "." *9DIGIT ] delay = *9DIGIT [ "." *9DIGIT ] Transport = "Transport" HCOLON transport-spec *(COMMA transport-spec) transport-spec = transport-id *trns-parameter transport-id = trans-id-rtp / other-trans trans-id-rtp = "RTP/" profile ["/" lower-transport] ; no LWS is allowed inside transport-id other-trans = token *("/" token) Schulzrinne, et al. Expires October 6, 2013 [Page 197] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token lower-transport = "TCP" / "UDP" / token trns-parameter = (SEMI ( "unicast" / "multicast" )) / (SEMI "interleaved" EQUAL channel ["-" channel]) / (SEMI "ttl" EQUAL ttl) / (SEMI "layers" EQUAL 1*DIGIT) / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) / (SEMI "mode" EQUAL mode-spec) / (SEMI "dest_addr" EQUAL addr-list) / (SEMI "src_addr" EQUAL addr-list) / (SEMI "setup" EQUAL contrans-setup) / (SEMI "connection" EQUAL contrans-con) / (SEMI "RTCP-mux") / (SEMI "MIKEY" EQUAL MIKEY-Value) / (SEMI trn-param-ext) contrans-setup = "active" / "passive" / "actpass" contrans-con = "new" / "existing" trn-param-ext = par-name [EQUAL trn-par-value] par-name = token trn-par-value = *(rtsp-unreserved / quoted-string) ttl = 1*3DIGIT ; 0 to 255 ssrc = 8HEX channel = 1*3DIGIT ; 0 to 255 MIKEY-Value = base64 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) mode = "PLAY" / token addr-list = quoted-addr *(SLASH quoted-addr) quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE host-port = ( host [":" port] ) / ( ":" port ) extension-addr = 1*qdtext host = < As defined in RFC 3986> port = < As defined in RFC 3986> Schulzrinne, et al. Expires October 6, 2013 [Page 198] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Unsupported = "Unsupported" HCOLON feature-tag-list User-Agent = "User-Agent" HCOLON ( product / comment ) *(LWS (product / comment)) field-name-list = field-name *(COMMA field-name) field-name = token Via = "Via" HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-extension via-ttl = "ttl" EQUAL ttl via-maddr = "maddr" EQUAL host via-received = "received" EQUAL (IPv4address / IPv6address) IPv4address = < As defined in RFC 3986> IPv6address = < As defined in RFC 3986> via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport-prot protocol-name = "RTSP" / token protocol-version = token transport-prot = "UDP" / "TCP" / "TLS" / other-transport other-transport = token sent-by = host [ COLON port ] WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 20.3. SDP extension Syntax This section defines in ABNF the SDP extensions defined for RTSP. See Appendix D for the definition of the extensions in text. control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF a-range-def = "a=range:" ranges-spec CRLF a-mtag-def = "a=mtag:" message-tag CRLF Schulzrinne, et al. Expires October 6, 2013 [Page 199] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 21. Security Considerations The security considerations and threats around RTSP and its usage can be divided into considerations around the signaling protocol itself and the issues related to the media stream delivery. However, when it comes to mitigations of security threats, a threat depending on the media stream delivery may in fact be mitigated by a mechanism in the signaling protocol. There are several chapters and appendix in this document that define security solutions for the protocol. We will reference them when discussing the threats below. But the reader should take special notice of the Security Framework (Section 19) and the specification of how to use SRTP and its key-mangement (Appendix C.1.4) to achieve certain aspects of the media security. 21.1. Signaling Protocol Threats This section focuses on issues related to the signaling protocol. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security considerations outlined in [H15] apply also. Specifically, please note the following: Abuse of Server Log Information: RTSP and HTTP servers will presumably have similar logging mechanisms, and thus should be equally guarded in protecting the contents of those logs, thus protecting the privacy of the users of the servers. See [H15.1.1] for HTTP server recommendations regarding server logs. Transfer of Sensitive Information: There is no reason to believe that information transferred or controlled via RTSP may be any less sensitive than that normally transmitted via HTTP. Therefore, all of the precautions regarding the protection of data privacy and user privacy apply to implementors of RTSP clients, servers, and proxies. See [H15.1.2] for further details. Attacks Based On File and Path Names: Though RTSP URIs are opaque handles that do not necessarily have file system semantics, it is anticipated that many implementations will translate portions of the Request-URIs directly to file system calls. In such cases, file systems SHOULD follow the precautions outlined in [H15.5], such as checking for ".." in path components. Schulzrinne, et al. Expires October 6, 2013 [Page 200] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Personal Information: RTSP clients are often privy to the same information that HTTP clients are (user name, location, etc.) and thus should be equally sensitive. See [H15.1] for further recommendations. Privacy Issues Connected to Accept Headers: Since may of the same "Accept" headers exist in RTSP as in HTTP, the same caveats outlined in [H15.1.4] with regards to their use should be followed. DNS Spoofing: Presumably, given the longer connection times typically associated to RTSP sessions relative to HTTP sessions, RTSP client DNS optimizations should be less prevalent. Nonetheless, the recommendations provided in [H15.3] are still relevant to any implementation which attempts to rely on a DNS-to-IP mapping to hold beyond a single use of the mapping. Location Headers and Spoofing: If a single server supports multiple organizations that do not trust each another, then it MUST check the values of Location and Content-Location header fields in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority. ([H15.4]) In addition to the recommendations in the current HTTP specification (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 2068 [RFC2068], future HTTP specifications may provide additional guidance on security issues. The following are added considerations for RTSP implementations. Session hijacking: Since there is no or little relation between a transport layer connection and an RTSP session, it is possible for a malicious client to issue requests with random session identifiers which could affect other clients of an unsuspecting server. To mitigate this the server SHALL use a large, random and non-sequential session identifier to minimize the possibility of this kind of attack. However, unless the RTSP signaling is always confidentiality protected, e.g. using TLS, an on-path attacker will be able to hijack a session. To prevent session hijacking client authentication needs to be performed and only the authenticated client creating the session SHALL be able to access that session. Schulzrinne, et al. Expires October 6, 2013 [Page 201] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Authentication: Servers SHOULD implement both basic and digest [RFC2617] authentication. In environments requiring tighter security for the control messages, the transport layer mechanism TLS [RFC5246] SHOULD be used. Persistently suspicious behavior: RTSP servers SHOULD return error code 403 (Forbidden) upon receiving a single instance of behavior which is deemed a security risk. RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests from clients which are deemed to be in violation of local security policy. TLS through proxies: If one uses the possibility to connect TLS in multiple legs (Section 19.3) one really needs to be aware of the trust model. That procedure requires full faith and trust in all proxies, which will be identified, that one allows to connect through. They are men in the middle and have access to all that goes on over the TLS connection. Thus it is important to consider if that trust model is acceptable in the actual application. Further discussion of the actual trust model is in Section 19.3. Resource Exhaustion: As RTSP is a stateful protocol and establishes resource usage on the server there is a clear possibility to attack the server by trying to overbook these resources to perform a denial of service attack. This attack can be both against ongoing sessions and to prevent others from establishing sessions. RTSP agents will need to have mechanisms to prevent single peers from consuming extensive amounts of resources. The methods for guarding against this are varied and depends on the agent's role and capabilities and policies. Each implementation has to carefully consider their methods and policies to mitigate this threat. For example regarding handling of connections there are recommendations in Section 10.7. The above threats and considerations have resulted in a set of security functions and mechanisms built into or used by the protocol. The signaling protocol relies on two security features defined in the Security Framework (Section 19) namely client authentication using HTTP authentication and TLS based transport protection of the signaling messages. Both of these mechanisms are required to be implemented by any RTSP agent. A number of different security mitigations have been designed into the protocol and will be present by following the specification as written, for example by ensuring sufficient amount of entropy in the Schulzrinne, et al. Expires October 6, 2013 [Page 202] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 randomly generated session identifiers when not using client authentication to prevent session hijacking. When client authentication is used the protection against hijacking will be strongly improved by scoping the accessible sessions to the one this client identity has created. Some of the above threats are such that the implementation of the RTSP functionality itself needs to consider which policy and strategy it uses to mitigate them. 21.2. Media Stream Delivery Threats The fact that RTSP establishes and controls a media stream delivery results in a set of security issues related to the media streams. This section will attempt to analyze general threats, however the choice of media stream transport protocol, like RTP will result in some differences in threats and what mechanisms that exist to mitigate them. Thus it becomes important that each specification of a new media stream transport and delivery protocol usable by RTSP requires its own security analysis. This section includes one for RTP. The set of general threats from or by the media stream delivery itself are: Concentrated denial-of-service attack: The protocol offers the opportunity for a remote-controlled denial-of-service (DoS) attack, where the media stream is the hammer in that DoS attack. See Section 21.2.1. Media Confidentiality: The media delivery may contain content of any type and it is not possible in general to determine how sensitive this content is from a confidentiality point. Thus it is a strong requirement that any media delivery protocol provides a method for providing confidentiality of the actual media content. In addition to the media level confidentiality it becomes critical that no resource identifiers used in the signaling are exposed to an attacker as they may have human understandable names, or may be also available to the attacker so they can determine the content the user was delivered. Thus also the signaling protocol must provide confidentiality protection of any information related to the media resource. Media Integrity and Authentication: There are several reasons, such as discrediting the target, misinformation of the target, why an attacker will have interest to substitute the media stream sent out from the RTSP server with one of the attacker's creation or selection. Therefore it is important that the media protocol provides mechanisms to verify the source authentication, integrity and prevent replay attacks on the media stream. Schulzrinne, et al. Expires October 6, 2013 [Page 203] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Scope of Multicast: If RTSP is used to control the transmission of media onto a multicast network it is needed to consider the scope that delivery has. RTSP supports the TTL Transport header parameter to indicate this scope for IPv4. IPv6 has a different mechanism for scope boundary. However, such scope control has risks, as it may be set too large and distribute media beyond the intended scope. Below (Section 21.2.2) we do a protocol specific analysis of security considerations for RTP based media transport. In that section we also make clear the requirements on implementing security functions for RTSP agents supporting media delivery over RTP. 21.2.1. Remote Denial of Service Attack The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests. While the attacker's IP address may be known in this case, this is not always useful in prevention of more attacks or ascertaining the attackers identity. Thus, an RTSP server MUST only allow client-specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms. Security mechanisms that are acceptable in an increased generality are: o Verification of the client's identity against a database of known users using RTSP authentication mechanisms (preferably digest authentication or stronger) o A list of addresses that accept to be media destinations, especially considering user identity o Media path based verification The server SHOULD NOT allow the destination field to be set unless a mechanism exists in the system to authorize the request originator to direct streams to the recipient. It is preferred that this authorization be performed by the media recipient (destination) itself and the credentials passed along to the server. However, in certain cases, such as when the recipient address is a multicast group, or when the recipient is unable to communicate with the server in an out-of-band manner, this may not be possible. In these cases the server may chose another method such as a server-resident authorization list to ensure that the request originator has the proper credentials to request stream delivery to the recipient. One solution that performs the necessary verification of acceptance of media suitable for unicast based delivery is the ICE based NAT Schulzrinne, et al. Expires October 6, 2013 [Page 204] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 traversal method described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random passwords and username so that the probability of unintended indication as a valid media destination is very low. In addition the server includes in its STUN requests a cookie (consisting of random material) that the destination echoes back, thus the solution also safe-guards against having an off-path attacker being able to spoof the STUN checks. This leaves this solution vulnerable only to on-path attackers that can see the STUN requests go to the target of attack and thus forge a response. For delivery to multicast addresses there is a need for another solution which is not specified in this memo. 21.2.2. RTP Security analysis RTP is a commonly used media transport protocol and has been the most common choice for RTSP 1.0 implementations. The core RTP protocol has been in use for a long time and it has well-known security properties and the RTP security consideration (Section 9 of [RFC3550]) needs to be reviewed. In perspective of the usage of RTP in context of RTSP the following properties should be noted: Stream Additions: RTP has support for multiple simultaneous media streams in each RTP session. As some use cases require support for non-synchronized adding and removal of media streams and their identifiers an attacker can easily insert additional media streams into a session context that according to protocol design is intended to be played out. Another threat vector is one of denial of service by exhausting the resources of the RTP session receiver, for example by using a large number of SSRC identifiers simultaneously. The strong mitigation of this is to ensure that one cryptographically authenticates any incoming packet flow to the RTP session. Weak mitigations like blocking additional media streams in session contexts easily lead to a denial of service vulnerability in addition to preventing certain RTP extensions or use cases which rely on multiple media streams, such as RTP retransmission [RFC4588] to function. Forged Feedback: The built in RTP control Protocol (RTCP) also offers a large attack surface for a couple of different types of attacks. One venue is to send RTCP feedback to the media sender indicating large amounts of packet loss and thus trigger a media bit-rate adaptation response from the sender resulting in lowered media quality and potentially shut down of the media stream. Another attack is to perform a resource exhaustion attack on the receiver by using many SSRC identifiers to create large state tables and increase the RTCP related processing demands. Schulzrinne, et al. Expires October 6, 2013 [Page 205] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTP/RTCP Extensions: RTP and RTCP extensions generally provide additional and sometimes extremely powerful tools to do denial of service or service disruption. For example the Code Control Message [RFC5104] RTCP extensions enables both locking down the bit-rate to low values and disrupt video quality by requesting Intra frames. Taking into account the above general discussion in Section 21.2 and the RTP specific discussion in this section it is clear that strong security mechanism to protect RTP is necessary to support. Therefore this specification has the following requirements on RTP security functions for all RTSP agents that handles media streams and where the media stream transport is done using RTP. RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] and thus the SAVP profile. In addition the secure AVP profile (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is implemented. This specification requires no additional crypto transforms or configuration values beyond the mandatory to implement in RFC3711, i.e. AES-CM and HMAC-SHA1. The default key-management mechanism which MUST be implemented is the one defined in the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY implementation MUST implement the necessary functions for MIKEY-RSA-R mode [RFC4738] and in addition the SRTP parameter negotiation necessary to negotiate the supported SRTP transforms and parameters. Schulzrinne, et al. Expires October 6, 2013 [Page 206] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 22. IANA Considerations This section sets up a number of registries for RTSP 2.0 that should be maintained by IANA. These registries are separate from any registries existing for RTSP 1.0. For each registry there is a description of what it is required to contain, what specification is needed when adding an entry with IANA, and finally the entries that this document needs to register. See also the Section 2.7 "Extending RTSP". There is also an IANA registration of three SDP attributes. Registries or entries in registries which have been made for RTSP 1.0 are not moved to RTSP 2.0. The registries and entries in registries of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry in a registry is also required in RTSP 2.0, it MUST follow the below defined procedure to allocate the registry or entry in a registry. The sections describing how to register an item uses some of the requirements level described in RFC 5226 [RFC5226], namely "First Come, First Served", "Expert Review, "Specification Required", and "Standards Action". In case a registry requires a contact person, the authors are the contact person for any entries created by this document. A registration request to IANA MUST contain the following information: o A name of the item to register according to the rules specified by the intended registry. o Indication of who has change control over the feature (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium, a particular company or group of companies, or an individual); o A reference to a further description, if available, for example (in decreasing order of preference) an RFC, a published standard, a published paper, a patent filing, a technical report, documented source code or a computer manual; o For proprietary features, contact information (postal and email address); 22.1. Feature-tags Schulzrinne, et al. Expires October 6, 2013 [Page 207] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 22.1.1. Description When a client and server try to determine what part and functionality of the RTSP specification and any future extensions that its counter part implements there is need for a namespace. This registry contains named entries representing certain functionality. The usage of feature-tags is explained in Section 11 and Section 13.1. 22.1.2. Registering New Feature-tags with IANA The registering of feature-tags is done on a first come, first served basis. The name of the feature MUST follow these rules: The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST NOT contain any spaces, or control characters. The registration MUST indicate if the feature-tag applies to clients, servers, or proxies only or any combinations of these. Any proprietary feature MUST have as the first part of the name a vendor tag, which identifies the organization. The registry entries consist of the feature tag, a one paragraph description of what it represents, its applicability (server, client, proxy, any combination) and a reference to its specification where applicable. Examples for a vendor tag describing a proprietary feature are: vendorA.specfeat01 vendorA.specfeat02 22.1.3. Registered entries The following feature-tags are defined in this specification and hereby registered. The change control belongs to the IETF. play.basic: The implementation for delivery and playback operations according to the core RTSP specification, as defined in this memo. Applies for both clients, servers and proxies. play.scale: Support of scale operations for media playback. Applies only for servers. play.speed: Support of the speed functionality for media delivery. Applies only for servers. Schulzrinne, et al. Expires October 6, 2013 [Page 208] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as discussed in Appendix C.1.6.4. Applies for both client and servers and any media caching proxy. This should be represented by IANA as a table with the feature tags, contact person and their references. 22.2. RTSP Methods 22.2.1. Description Methods are described in Section Section 13. Extending the protocol with new methods allow for totally new functionality. 22.2.2. Registering New Methods with IANA A new method MUST be registered through an IETF Standards Action. The reason is that new methods may radically change the protocol's behavior and purpose. A specification for a new RTSP method MUST consist of the following items: o A method name which follows the ABNF rules for methods. o A clear specification what a request using the method does and what responses are expected. Which directions the method is used, C->S or S->C or both. How the use of headers, if any, modifies the behavior and effect of the method. o A list or table specifying which of the IANA registered headers that are allowed to be used with the method in request or/and response. The list or table SHOULD follow the format of tables in Section 18. o Describe how the method relates to network proxies. 22.2.3. Registered Entries This specification, RFCXXXX, registers 10 methods: DESCRIBE, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. The initial table of the registry is provided below. Schulzrinne, et al. Expires October 6, 2013 [Page 209] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Method Directionality Reference ----------------------------------------------------- DESCRIBE C->S [RFCXXXX] GET_PARAMETER C->S, S->C [RFCXXXX] OPTIONS C->S, S->C [RFCXXXX] PAUSE C->S [RFCXXXX] PLAY C->S [RFCXXXX] PLAY_NOTIFY S->C [RFCXXXX] REDIRECT S->C [RFCXXXX] SETUP C->S [RFCXXXX] SET_PARAMETER C->S, S->C [RFCXXXX] TEARDOWN C->S, S->C [RFCXXXX] 22.3. RTSP Status Codes 22.3.1. Description A status code is the three digit number used to convey information in RTSP response messages, see Section 8. The number space is limited and care should be taken not to fill the space. 22.3.2. Registering New Status Codes with IANA A new status code registration follows the policy of IETF Review. A specification for a new status code MUST specify the following: o The registered number. o A description of what the status code means and the expected behavior of the sender and receiver of the code. 22.3.3. Registered Entries RFCXXXX, registers the numbered status code defined in the ABNF entry "Status-Code" except "extension-code" (that defines the syntax allowed for future extensions) in Section 20.2.2. 22.4. RTSP Headers 22.4.1. Description By specifying new headers a method(s) can be enhanced in many different ways. An unknown header will be ignored by the receiving agent. If the new header is vital for a certain functionality, a feature-tag for the functionality can be created and demanded to be used by the counter-part with the inclusion of a Require header carrying the feature-tag. Schulzrinne, et al. Expires October 6, 2013 [Page 210] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 22.4.2. Registering New Headers with IANA Registrations in the registry can be done following the Expert Review policy. A specification SHOULD be provided, preferably an IETF RFC or other Standards Developing Organization specification. The minimal information in a registration request is the header name and the contact information. The specification SHOULD contain the following information: o The name of the header. o An ABNF specification of the header syntax. o A list or table specifying when the header may be used, encompassing all methods, their request or response, the direction (C->S or S->C). o How the header is to be handled by proxies. o A description of the purpose of the header. 22.4.3. Registered entries All headers specified in Section 18 in RFCXXXX are to be registered. The Registry is to include header name and reference. Furthermore the following legacy RTSP headers defined in other specifications are registered with header name, reference and description according to below list. Note: These references may not fulfill all of the above rules for registrations due to their legacy status. o x-wap-profile defined in [TS-26234]. The x-wap-profile request header contains one or more absolute URLs to the requesting agent's device capability profile. o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff request header contains a subset of a device capability profile. o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- warning is a response header that contains error codes explaining to what extent the server has been able to match the terminal request in regards to device capability profile as described using x-wap-profile and x-wap-profile-diff headers. o x-predecbufsize defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 Annex G hypothetical Schulzrinne, et al. Expires October 6, 2013 [Page 211] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 pre-decoder buffer size. o x-initpredecbufperiod defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffering period. o x-initpostdecbufperiod defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 Annex G post- decoder buffering period. o 3gpp-videopostdecbufsize defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 defined post- decoder buffer size usable for H.264 (AVC) video streams. o 3GPP-Link-Char defined in [TS-26234]. This request header provides the RTSP server with the RTSP client's link charateristics as deterimined from the radio interface. The information that can be provided are guaranteed bit-rate, maximum bit-rate and maximum transfer delay. o 3GPP-Adaptation defined in [TS-26234]. This general header is part of the bit-rate adaptation solution specified for PSS. It provides the RTSP client's buffer sizes and target buffer levels to the server and responses are used to acknowledge the support and values. o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is used by PSS RTSP agents to negotiate the quality of experince metrics that a client should gather and report to the server. o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is used by RTSP clients supporting PSS to report the actual values of the metrics gathered in its quality of experince metering. The use of "x-" is NOT RECOMMENDED but the above headers in the register list were defined prior to the clarification. 22.5. Accept-Credentials The security framework's TLS connection mechanism has two registrable entities. 22.5.1. Accept-Credentials policies In Section 19.3.1 three policies for how to handle certificates are specified. Further policies may be defined and MUST be registered with IANA using the following rules: Schulzrinne, et al. Expires October 6, 2013 [Page 212] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o Registering requires an IETF Standards Action o A registration is required to name a contact person. o Name of the policy. o A describing text that explains how the policy works for handling the certificates. This specification registers the following values: Any Proxy User 22.5.2. Accept-Credentials hash algorithms The Accept-Credentials header (See Section 18.2) allows for the usage of other algorithms for hashing the DER records of accepted entities. The registration of any future algorithm is expected to be extremely rare and could also cause interoperability problems. Therefore the bar for registering new algorithms is intentionally placed high. Any registration of a new hash algorithm MUST fulfill the following requirement: o Follow the IETF Standards Action policy. o A definition of the algorithm and its identifier meeting the "token" ABNF requirement. The registered value is: Hash Alg. Id Reference ------------------------ sha-256 [RFCXXXX] 22.6. Cache-Control Cache Directive Extensions There exists a number of cache directives which can be sent in the Cache-Control header. A registry for these cache directives MUST be defined with the following rules: o Registering requires an IETF Standards Action or IESG Approval. o A registration is required to contain a contact person. Schulzrinne, et al. Expires October 6, 2013 [Page 213] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o Name of the directive and a definition of the value, if any. o Specification if it is a request or response directive. o A describing text that explains how the cache directive is used for RTSP controlled media streams. This specification registers the following values: no-cache: public: private: no-transform: only-if-cached: max-stale: min-fresh: must-revalidate: proxy-revalidate: max-age: The registry should be represented as: Name of the directive, contact person and reference. 22.7. Media Properties 22.7.1. Description The media streams being controlled by RTSP can have many different properties. The media properties required to cover the use cases that were in mind when writing the specification are defined. However, it can be expected that further innovation will result in new use cases or media streams with properties not covered by the ones specified here. Thus new media properties can be specified. As new media properties may need a substantial amount of new definitions to correctly specify behavior for this property the bar is intended to be high. Schulzrinne, et al. Expires October 6, 2013 [Page 214] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 22.7.2. Registration Rules Registering a new media property MUST fulfill the following requirements o Follow the Specification Required policy and get the approval of the designated Expert. o Have an ABNF definition of the media property value name that meets "media-prop-ext" definition o A Contact Person for the Registration o Description of all changes to the behavior of the RTSP protocol as result of these changes. 22.7.3. Registered Values This specification registers the 9 values listed in Section 18.28. The registry should be represented as: Name of the media property, contact person and reference. 22.8. Notify-Reason header 22.8.1. Description Notify-Reason values are used for indicating the reason the notification was sent. Each reason has its associated rules on what headers and information that may or must be included in the notification. New notification behaviors need to be specified to enable interoperable usage, thus a specification of each new value is required. 22.8.2. Registration Rules Registrations for new Notify-Reason value MUST fulfill the following requirements o Follow the Specification Required policy and get the approval of the designated Expert. o An ABNF definition of the Notify reason value name that meets "Notify-Reason-extension" definition o A Contact Person for the Registration o Description of which headers shall be included in the request and response, when it should be sent, and any effect it has on the Schulzrinne, et al. Expires October 6, 2013 [Page 215] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 server client state. 22.8.3. Registered Values This specification registers 3 values defined in the Notify-Reas-val ABNF, Section 20.2.3: end-of-stream: This Notify-Reason value indicates the end of a media stream. media-properties-update: This Notify-Reason value allows the server to indicate that the properties of the media has changed during the playout. scale-change: This Notify-Reason value allows the server to notify the client about a change in the Scale of the media. The registry entries should be represented in the registry as: Name, short description, contact and reference. 22.9. Range header formats 22.9.1. Description The Range header (Section 18.38) allows for different range formats. New ones may be registered, but moderation should be applied as it makes interoperability more difficult. 22.9.2. Registration Rules A registration MUST fulfill the following requirements: o Follow the Specification Required policy. o An ABNF definition of the range format that fulfills the "range- ext" definition. o A Contact person for the registration. o Rules for how one handles the range when using a negative Scale. 22.9.3. Registered Values The registry should be represented as: Name of the range format, contact person and reference. This specification registers the following values. Schulzrinne, et al. Expires October 6, 2013 [Page 216] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 npt: Normal Play Time clock: UTC Clock format smpte: SMPTE Timestamps smpte-30-drop: SMPTE Timestamps smpte-25: SMPTE Timestamps 22.10. Terminate-Reason Header The Terminate-Reason header (Section 18.50) has two registries for extensions. 22.10.1. Redirect Reasons Registrations are done under the policy of Expert Review. The registered value needs to follow the Terminate-Reason ABNF, i.e., be a token. The specification needs to provide a definition of what procedures are to be followed when a client receives this redirect reason. This specification registers three values: o Session-Timeout o Server-Admin o Internal-Error The registry should be represented as: Name of the Redirect Reason, contact person and reference. 22.10.2. Terminate-Reason Header Parameters Registrations are done under the policy of Specification Required. The registrations must define a syntax for the parameter that also follows the syntax allowed by the RTSP 2.0 specification. A contact person is also required. This specification registers: o time o user-msg The registry should be represented as: Name of the Terminate Reason, contact person and reference. Schulzrinne, et al. Expires October 6, 2013 [Page 217] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 22.11. RTP-Info header parameters 22.11.1. Description The RTP-Info header (Section 18.43) carries one or more parameter value pairs with information about a particular point in the RTP stream. RTP extensions or new usages may need new types of information. As RTP information that could be needed is likely to be generic enough and to maximize the interoperability, new registration requires Specification Required. 22.11.2. Registration Rules Registrations for new RTP-Info value MUST fulfill the following requirements o Follow the Specification Required policy and get the approval of the designated Expert. o Have an ABNF definition that meets the "generic-param" definition o A Contact Person for the Registration 22.11.3. Registered Values This specification registers the following parameter value pairs: o url o ssrc o seq o rtptime The registry should be represented as: Name of the parameter, contact person and reference. 22.12. Seek-Style Policies 22.12.1. Description New seek policies may be registered, however, a large number of these will complicate implementation substantially. The impact of unknown policies is that the server will not honor the unknown and use the server default policy instead. Schulzrinne, et al. Expires October 6, 2013 [Page 218] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 22.12.2. Registration Rules Registrations of new Seek-Style polices MUST fulfill the following requirements o Follow the Specification Required policy. o Have an ABNF definition of the Seek-Style policy name that meets "Seek-S-value-ext" definition o A Contact Person for the Registration o Description of which headers shall be included in the request and response, when it should be sent, and any affect it has on the server client state. 22.12.3. Registered Values This specification registers 4 values: o RAP o CoRAP o First-Prior o Next The registry should be represented as: Name of the Seek-Style Policy, short description, contact person and reference. 22.13. Transport Header Registries The transport header contains a number of parameters which have possibilities for future extensions. Therefore registries for these need to be defined. 22.13.1. Transport Protocol Specification A registry for the parameter transport-protocol specification MUST be defined with the following rules: o Registering uses the policy of Specification Required. o A contact person or organization with address and email. o A value definition that are following the ABNF syntax definition of "transport-id" Section 20.2.3. Schulzrinne, et al. Expires October 6, 2013 [Page 219] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o A describing text that explains how the registered value are used in RTSP. The registry should be represented as: The protocol ID string, contact person and reference. This specification registers the following values: RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP profile for audio and video conferences with minimal control" [RFC3551] over UDP. The usage is explained in RFC XXXX, Appendix C.1. RTP/AVP/UDP: the same as RTP/AVP. RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is explained in RFC XXXX, Appendix C.1. RTP/AVPF/UDP: the same as RTP/AVPF. RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over UDP. The usage is explained in RFC XXXX, Appendix C.1. RTP/SAVP/UDP: the same as RTP/SAVP. RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in combination with the Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) [RFC5124] over UDP. The usage is explained in RFC XXXX, Appendix C.1. RTP/SAVPF/UDP: the same as RTP/SAVPF. RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP profile for audio and video conferences with minimal control" [RFC3551] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2. RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2. Schulzrinne, et al. Expires October 6, 2013 [Page 220] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2. RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real- time Transport Control Protocol (RTCP)-Based Feedback (RTP/ SAVPF)" [RFC5124] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2. 22.13.2. Transport modes A registry for the transport parameter mode MUST be defined with the following rules: o Registering requires an IETF Standards Action. o A contact person or organization with address and email. o A value definition that are following the ABNF "token" definition Section 20.2.3. o A describing text that explains how the registered value are used in RTSP. This specification registers 1 value: PLAY: See RFC XXXX. 22.13.3. Transport Parameters A registry for parameters that may be included in the Transport header MUST be defined with the following rules: o Registering uses the Specification Required policy. o A value definition that are following the ABNF "token" definition Section 20.2.3. o A describing text that explains how the registered value are used in RTSP. This specification registers all the transport parameters defined in Section 18.52. This is a copy of this list: o unicast Schulzrinne, et al. Expires October 6, 2013 [Page 221] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o multicast o interleaved o ttl o layers o ssrc o mode o dest_addr o src_addr o setup o connection o RTCP-mux o MIKEY 22.14. URI Schemes This specification defines two URI schemes ("rtsp" and "rtsps") and reserves a third one ("rtspu"). These URI schemes are defined in existing registries which are not created by RTSP. Registrations are following RFC 4395[RFC4395]. 22.14.1. The rtsp URI Scheme URI scheme name: rtsp Status: Permanent URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme semantics: The rtsp scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP). RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. Schulzrinne, et al. Expires October 6, 2013 [Page 222] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Encoding considerations: IRIs in this scheme are defined and needs to be encoded as RTSP URIs when used within the RTSP protocol. That encoding is done according to RFC 3987. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC XXXX) Interoperability considerations: The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are: Support for IPV6 literal in host part and future IP literals through RFC 3986 defined mechanism. A new relative format to use in the RTSP protocol elements that is not required to start with "/". Security considerations: All the security threats identified in Section 7 of RFC 3986 apply also to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme. Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Author/Change controller: IETF References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 22.14.2. The rtsps URI Scheme URI scheme name: rtsps Status: Permanent URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme semantics: The rtsps scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP) over TLS. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. Schulzrinne, et al. Expires October 6, 2013 [Page 223] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Encoding considerations: IRIs in this scheme are defined and needs to be encoded as RTSP URIs when used within the RTSP protocol. That encoding is done according to RFC 3987. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC XXXX) Interoperability considerations: The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are: Support for IPV6 literal in host part and future IP literals through RFC 3986 defined mechanism. A new relative format to use in the RTSP protocol elements that is not required to start with "/". Security considerations: All the security threats identified in Section 7 of RFC 3986 apply also to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme. Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Author/Change controller: IETF References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 22.14.3. The rtspu URI Scheme URI scheme name: rtspu Status: Permanent URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme semantics: The rtspu scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP) over unreliable datagram transport. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. Schulzrinne, et al. Expires October 6, 2013 [Page 224] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Encoding considerations: IRIs in this scheme are not defined. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326) Interoperability considerations: The definition of the transport mechanism of RTSP over UDP has interoperability issues. That makes the usage of this scheme problematic. Security considerations: All the security threats identified in Section 7 of RFC 3986 apply also to this scheme. They needs to be reviewed and considered in any implementation utilizing this scheme. Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Author/Change controller: IETF References: RFC 2326 22.15. SDP attributes This specification defines three SDP [RFC4566] attributes that it is requested that IANA register. Schulzrinne, et al. Expires October 6, 2013 [Page 225] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 SDP Attribute ("att-field"): Attribute name: range Long form: Media Range Attribute Type of name: att-field Type of attribute: Media and session level Subject to charset: No Purpose: RFC XXXX Reference: RFC XXXX, RFC 2326 Values: See ABNF definition. Attribute name: control Long form: RTSP control URI Type of name: att-field Type of attribute: Media and session level Subject to charset: No Purpose: RFC XXXX Reference: RFC XXXX, RFC 2326 Values: Absolute or Relative URIs. Attribute name: mtag Long form: Message Tag Type of name: att-field Type of attribute: Media and session level Subject to charset: No Purpose: RFC XXXX Reference: RFC XXXX Values: See ABNF definition 22.16. Media Type Registration for text/parameters Type name: text Subtype name: parameters Required parameters: Optional parameters: charset: The charset parameter is applicable to the encoding of the parameter values. The default charset is UTF-8, if the 'charset' parameter is not present. Encoding considerations: 8bit Security considerations: This format may carry any type of parameters. Some can have security requirements, like privacy, confidentiality or integrity requirements. The format has no built in security protection. For the usage it was defined the Schulzrinne, et al. Expires October 6, 2013 [Page 226] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 transport can be protected between server and client using TLS. However, care must be taken to consider if also the proxies are trusted with the parameters in case hop-by-hop security is used. If stored as file in file systemi, the necessary precautions need to be taken in relation to the parameters requirements including object security such as S/MIME [RFC5751]. Interoperability considerations: This media type was mentioned as a fictional example in [RFC2326], but was not formally specified. This has resulted in usage of this media type which may not match its formal definition. Published specification: RFC XXXX, Appendix F. Applications that use this media type: Applications that use RTSP and have additional parameters they like to read and set using the RTSP GET_PARAMETER and SET_PARAMETER methods. Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Magnus Westerlund (magnus.westerlund@ericsson.com) Intended usage: Common Restrictions on usage: None Author: Magnus Westerlund (magnus.westerlund@ericsson.com) Change controller: IETF Addition Notes: Schulzrinne, et al. Expires October 6, 2013 [Page 227] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 23. References 23.1. Normative References [FIPS-pub-180-2] National Institute of Standards and Technology (NIST), "Federal Information Processing Standards Publications (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Schulzrinne, et al. Expires October 6, 2013 [Page 228] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. Schulzrinne, et al. Expires October 6, 2013 [Page 229] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. [TS-26234] Third Generation Partnership Project (3GPP), "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs; Technical Specification 26.234", December 2002. 23.2. Informative References [I-D.ietf-mmusic-rtsp-nat] Goldberg, J., Westerlund, M., and T. Zeng, "A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)", draft-ietf-mmusic-rtsp-nat-14 (work in progress), November 2012. [ISO.13818-6.1995] Schulzrinne, et al. Expires October 6, 2013 [Page 230] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 International Organization for Standardization, "Information technology - Generic coding of moving pictures and associated audio information - part 6: Extension for digital storage media and control", ISO Draft Standard 13818-6, November 1995. [ISO.8601.2000] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO/IEC Standard 8601, December 2000. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. Schulzrinne, et al. Expires October 6, 2013 [Page 231] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008. [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011. [Stevens98] Stevens, W., "Unix Networking Programming - Volume 1, second edition", 1998. Schulzrinne, et al. Expires October 6, 2013 [Page 232] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix A. Examples This section contains several different examples trying to illustrate possible ways of using RTSP. The examples can also help with the understanding of how functions of RTSP work. However, remember that these are examples and the normative and syntax description in the other sections take precedence. Please also note that many of the examples contain syntax illegal line breaks to accommodate the formatting restriction that the RFC series impose. A.1. Media on Demand (Unicast) This is an example of media on demand streaming of a media stored in a container file. For purposes of this example, a container file is a storage entity in which multiple continuous media types pertaining to the same end-user presentation are present. In effect, the container file represents an RTSP presentation, with each of its components being RTSP controlled media streams. Container files are a widely used means to store such presentations. While the components are transported as independent streams, it is desirable to maintain a common context for those streams at the server end. This enables the server to keep a single storage handle open easily. It also allows treating all the streams equally in case of any priorization of streams by the server. It is also possible that the presentation author may wish to prevent selective retrieval of the streams by the client in order to preserve the artistic effect of the combined media presentation. Similarly, in such a tightly bound presentation, it is desirable to be able to control all the streams via a single control message using an aggregate URI. The following is an example of using a single RTSP session to control multiple streams. It also illustrates the use of aggregate URIs. In a container file it is also desirable to not write any URI parts which are not kept, when the container is distributed, like the host and most of the path element. Therefore this example also uses the "*" and relative URI in the delivered SDP. Also this presentation description (SDP) is not cachable, as the Expires header is set to an equal value with date indicating immediate expiration of its valididty. Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file. Schulzrinne, et al. Expires October 6, 2013 [Page 233] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 M->C: RTSP/2.0 200 OK CSeq: 1 Server: PhonyServer/1.0 Date: Thu, 24 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 271 Content-Base: rtsp://example.com/twister.3gp/ 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 Schulzrinne, et al. Expires October 6, 2013 [Page 234] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 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 M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; ssrc=93CB001E; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001" Session: 12345678 Expires: 24 Jan 1997 15:35:12 GMT Date: 24 Jan 1997 15:35:12 GMT Accept-Ranges: NPT Media-Properties: Random-Access=0.02, Immutable, Unlimited C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Session: 12345678 Accept-Ranges: NPT, SMPTE, UTC M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; ssrc=A813FC13; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; Session: 12345678 Expires: 24 Jan 1997 15:35:13 GMT Date: 24 Jan 1997 15:35:13 GMT Accept-Range: NPT Media-Properties: Random-Access=0.8, Immutable, Unlimited C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Range: npt=30- Seek-Style: RAP Session: 12345678 Schulzrinne, et al. Expires October 6, 2013 [Page 235] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Date: 24 Jan 1997 15:35:14 GMT Session: 12345678 Range: npt=30-634.10 Seek-Style: RAP RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12345;rtptime=3450012, url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 5 User-Agent: PhonyClient/1.2 Session: 12345678 # Pause happens 0.87 seconds after starting to play M->C: RTSP/2.0 200 OK CSeq: 5 Server: PhonyServer/1.0 Date: 24 Jan 1997 15:36:01 GMT Session: 12345678 Range: npt=30.87-634.10 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 6 User-Agent: PhonyClient/1.2 Range: npt=30.87-634.10 Seek-Style: Next Session: 12345678 M->C: RTSP/2.0 200 OK CSeq: 6 Server: PhonyServer/1.0 Date: 24 Jan 1997 15:36:01 GMT Session: 12345678 Range: npt=30.87-634.10 Seek-Style: Next RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12555;rtptime=6330012, url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=55021;rtptime=3132889 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 7 Schulzrinne, et al. Expires October 6, 2013 [Page 236] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 User-Agent: PhonyClient/1.2 Session: 12345678 M->C: RTSP/2.0 200 OK CSeq: 7 Server: PhonyServer/1.0 Date: 24 Jan 1997 15:49:34 GMT A.2. Media on Demand using Pipelining This example is basically the example above (Appendix A.1), but now utilizing pipelining to speed up the setup. It requires only two round trip times until the media starts flowing. First of all, the session description is retrieved to determine what media resources need to be setup. In the second step, one sends the necessary SETUP requests and the PLAY request to initiate media delivery. Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file. C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 M->C: 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/twister.3gp/ Expires: 24 Jan 1997 15:35:06 GMT v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.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 Schulzrinne, et al. Expires October 6, 2013 [Page 237] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 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 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Accept-Ranges: NPT, SMPTE, UTC Pipelined-Requests: 7654 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Range: npt=0- Seek-Style: RAP Pipelined-Requests: 7654 M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; ssrc=93CB001E Session: 12345678 Expires: 24 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT Accept-Ranges: NPT Pipelined-Requests: 7654 Media-Properties: Random-Access=0.2, Immutable, Unlimited M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; ssrc=A813FC13 Session: 12345678 Expires: 24 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT Accept-Range: NPT Schulzrinne, et al. Expires October 6, 2013 [Page 238] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Pipelined-Requests: 7654 Media-Properties: Random-Access=0.8, Immutable, Unlimited M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:14 GMT Session: 12345678 Range: npt=0-623.10 Seek-Style: RAP RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12345;rtptime=3450012, url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889 Pipelined-Requests: 7654 A.3. Media on Demand (Unicast) An alternative example of media on demand with a bit more tweaks is the following. Client C requests a movie distributed from two different media servers A (audio.example.com) and V ( video.example.com). The media description is stored on a web server W. The media description contains descriptions of the presentation and all its streams, including the codecs that are available, dynamic RTP payload types, the protocol stack, and content information such as language or copyright restrictions. It may also give an indication about the timeline of the movie. In this example, the client is only interested in the last part of the movie. Schulzrinne, et al. Expires October 6, 2013 [Page 239] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->W: GET /twister.sdp HTTP/1.1 Host: www.example.com Accept: application/sdp W->C: HTTP/1.1 200 OK Date: Thu, 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 278 Expires: 23 Jan 1998 15:35:06 GMT v=0 o=- 2890844526 2890842807 IN IP4 198.51.100.5 s=RTSP Session e=adm@example.com c=IN IP4 0.0.0.0 a=range:npt=0-1:49:34 t=0 0 m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio.en m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: NPT, SMPTE, UTC A->C: RTSP/2.0 200 OK CSeq: 1 Session: 12345678 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; src_addr="198.51.100.5:5000"/"198.51.100.5:5001" Date: 23 Jan 1997 15:35:12 GMT Server: PhonyServer/1.0 Expires: 24 Jan 1997 15:35:12 GMT Cache-Control: public Accept-Ranges: NPT, SMPTE Media-Properties: Random-Access=0.02, Immutable, Unlimited Schulzrinne, et al. Expires October 6, 2013 [Page 240] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: NPT, SMPTE, UTC V->C: RTSP/2.0 200 OK CSeq: 1 Session: 23456789 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; src_addr="198.51.100.5:5002"/"198.51.100.5:5003" Date: 23 Jan 1997 15:35:12 GMT Server: PhonyServer/1.0 Cache-Control: public Expires: 24 Jan 1997 15:35:12 GMT Accept-Ranges: NPT, SMPTE Media-Properties: Random-Access=1.2, Immutable, Unlimited C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Session: 23456789 Range: smpte=0:10:00- V->C: RTSP/2.0 200 OK CSeq: 2 Session: 23456789 Range: smpte=0:10:00-1:49:23 Seek-Style: First-Prior RTP-Info: url="rtsp://video.example.com/twister/video" ssrc=A17E189D:seq=12312232;rtptime=78712811 Server: PhonyServer/2.0 Date: 23 Jan 1997 15:35:13 GMT Schulzrinne, et al. Expires October 6, 2013 [Page 241] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Session: 12345678 Range: smpte=0:10:00- A->C: RTSP/2.0 200 OK CSeq: 2 Session: 12345678 Range: smpte=0:10:00-1:49:23 Seek-Style: First-Prior RTP-Info: url="rtsp://audio.example.com/twister/audio.en" ssrc=3D124F01:seq=876655;rtptime=1032181 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:13 GMT C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: 12345678 A->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:36:52 GMT C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: 23456789 V->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/2.0 Date: 23 Jan 1997 15:36:52 GMT Even though the audio and video track are on two different servers that may start at slightly different times and may drift with respect to each other over time, the client can perform initial synchronization of the two media using RTP-Info and Range received in the PLAY responses. If the two servers are time synchronized the RTCP packets can also be used to maintain synchronization. Schulzrinne, et al. Expires October 6, 2013 [Page 242] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 A.4. Single Stream Container Files Some RTSP servers may treat all files as though they are "container files", yet other servers may not support such a concept. Because of this, clients needs to use the rules set forth in the session description for Request-URIs, rather than assuming that a consistent URI may always be used throughout. Below is an example of how a multi-stream server might expect a single-stream file to be served: C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 Accept: application/x-rtsp-mh, application/sdp CSeq: 1 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 1 Content-base: rtsp://foo.example.com/test.wav/ Content-type: application/sdp Content-length: 163 Server: PhonyServer/1.0 Date: Thu, 23 Jan 1997 15:35:06 GMT Expires: 23 Jan 1997 17:00:00 GMT v=0 o=- 872653257 872653257 IN IP4 192.0.2.5 s=mu-law wave file i=audio test c=IN IP4 0.0.0.0 t=0 0 a=control: * m=audio 0 RTP/AVP 0 a=control:streamid=0 Schulzrinne, et al. Expires October 6, 2013 [Page 243] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 Transport: RTP/AVP/UDP;unicast; dest_addr=":6970"/":6971";mode="PLAY" CSeq: 2 User-Agent: PhonyClient/1.2 Accept-Ranges: NPT, SMPTE, UTC S->C: RTSP/2.0 200 OK Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; mode="PLAY";ssrc=EAB98712 CSeq: 2 Session: 2034820394 Expires: 23 Jan 1997 16:00:00 GMT Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:07 GMT Accept-Ranges: NPT Media-Properties: Random-Acces=0.5, Immutable, Unlimited C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: 2034820394 S->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:08 GMT Session: 2034820394 Range: npt=0-600 Seek-Style: RAP RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" ssrc=0D12F123:seq=981888;rtptime=3781123 Note the different URI in the SETUP command, and then the switch back to the aggregate URI in the PLAY command. This makes complete sense when there are multiple streams with aggregate control, but is less than intuitive in the special case where the number of streams is one. However, the server has declared the aggregated control URI in the SDP and therefore this is legal. In this case, it is also required that servers accept implementations that use the non-aggregated interpretation and use the individual media URI, like this: Schulzrinne, et al. Expires October 6, 2013 [Page 244] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: 2034820394 A.5. Live Media Presentation Using Multicast The media server M chooses the multicast address and port. Here, it is assumed that the web server only contains a pointer to the full description, while the media server M maintains the full description. C->W: GET /sessions.html HTTP/1.1 Host: www.example.com W->C: HTTP/1.1 200 OK Content-Type: text/html <html> ... <a href "rtsp://live.example.com/concert/audio"> Streamed Live Music performance </a> ... </html> C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 CSeq: 1 Supported: play.basic, play.scale User-Agent: PhonyClient/1.2 M->C: RTSP/2.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 183 Server: PhonyServer/1.0 Date: Thu, 23 Jan 1997 15:35:06 GMT Supported: play.basic v=0 o=- 2890844526 2890842807 IN IP4 192.0.2.5 s=RTSP Session t=0 0 m=audio 3456 RTP/AVP 0 c=IN IP4 233.252.0.54/16 a=control: rtsp://live.example.com/concert/audio a=range:npt=0- Schulzrinne, et al. Expires October 6, 2013 [Page 245] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 CSeq: 2 Transport: RTP/AVP;multicast; dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 Accept-Ranges: NPT, SMPTE, UTC User-Agent: PhonyClient/1.2 M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Date: Thu, 23 Jan 1997 15:35:06 GMT Transport: RTP/AVP;multicast; dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 ;ssrc=4D12AB92/0DF876A3 Session: 0456804596 Accept-Ranges: NPT, UTC Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 CSeq: 3 Session: 0456804596 User-Agent: PhonyClient/1.2 M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:07 GMT Session: 0456804596 Seek-Style: Next Range:npt=1256- RTP-Info: url="rtsp://live.example.com/concert/audio" ssrc=0D12F123:seq=1473; rtptime=80000 A.6. Capability Negotiation This example illustrates how the client and server determine their capability to support a special feature, in this case "play.scale". The server, through the clients request and the included Supported header, learns the client supports RTSP 2.0, and also supports the playback time scaling feature of RTSP. The server's response contains the following feature related information to the client; it supports the basic media delivery functions (play.basic), the extended functionality of time scaling of content (play.scale), and one "example.com" proprietary feature (com.example.flight). The client also learns the methods supported (Public header) by the server for the indicated resource. Schulzrinne, et al. Expires October 6, 2013 [Page 246] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 CSeq: 1 Supported: play.basic, play.scale User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 1 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE Server: PhonyServer/2.0 Supported: play.basic, play.scale, com.example.flight When the client sends its SETUP request it tells the server that it requires support of the play.scale feature for this session by including the Require header. C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", RTP/AVP/TCP;unicast;interleaved=0-1 Require: play.scale Accept-Ranges: NPT, SMPTE, UTC User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 3 Session: 12345678 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; src_addr="198.51.100.5:5000"/"198.51.100.5:5001" Server: PhonyServer/2.0 Accept-Ranges: NPT, SMPTE Media-Properties: Random-Access=0.8, Immutable, Unlimited Schulzrinne, et al. Expires October 6, 2013 [Page 247] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix B. RTSP Protocol State Machine The RTSP session state machine describes the behavior of the protocol from RTSP session initialization through RTSP session termination. The State machine is defined on a per session basis which is uniquely identified by the RTSP session identifier. The session may contain one or more media streams depending on state. If a single media stream is part of the session it is in non-aggregated control. If two or more is part of the session it is in aggregated control. The below state machine is an informative description of the protocols behavior. In case of ambiguity with the earlier parts of this specification, the description in the earlier parts take precedence. B.1. States The state machine contains three states, described below. For each state there exists a table which shows which requests and events are allowed and whether they will result in a state change. Init: Initial state no session exists. Ready: Session is ready to start playing. Play: Session is playing, i.e. sending media stream data in the direction S->C. B.2. State variables This representation of the state machine needs more than its state to work. A small number of variables are also needed and they are explained below. NRM: The number of media streams part of this session. RP: Resume point, the point in the presentation time line at which a request to continue playing will resume from. A time format for the variable is not mandated. B.3. Abbreviations To make the state tables more compact a number of abbreviations are used, which are explained below. Schulzrinne, et al. Expires October 6, 2013 [Page 248] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 IFI: IF Implemented. md: Media PP: Pause Point, the point in the presentation time line at which the presentation was paused. Prs: Presentation, the complete multimedia presentation. RedP: Redirect Point, the point in the presentation time line at which a REDIRECT was specified to occur. SES: Session. B.4. State Tables This section contains a table for each state. The table contains all the requests and events that this state is allowed to act on. The events which are method names are, unless noted, requests with the given method in the direction client to server (C->S). In some cases there exist one or more requisite. The response column tells what type of response actions should be performed. Possible actions that are requested for an event include: response codes, e.g., 200, headers that need to be included in the response, setting of state variables, or setting of other session related parameters. The new state column tells which state the state machine changes to. The response to a valid request meeting the requisites is normally a 2xx (SUCCESS) unless otherwise noted in the response column. The exceptions need to be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occurs, the appropriate response code is to be sent. If the response code is a 4xx the session state is unchanged. A response code of 3rr will result in that the session is ended and its state is changed to Init. A response code of 304 results in no state change. However, there are restrictions to when a 3rr response may be used. A 5xx response does not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error results in the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client knows that the session has ended. For any request message that cannot be responded to within the time defined in Section 10.4, a 100 response must be sent. The server will timeout the session after the period of time specified in the SETUP response, if no activity from the client is Schulzrinne, et al. Expires October 6, 2013 [Page 249] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 detected. Therefore there exists a timeout event for all states except Init. In the case that NRM = 1 the presentation URI is equal to the media URI or a specified presentation URI. For NRM > 1 the presentation URI needs to be other than any of the medias that are part of the session. This applies to all states. +---------------+-----------------+---------------------------------+ | Event | Prerequisite | Response | +---------------+-----------------+---------------------------------+ | DESCRIBE | Needs REDIRECT | 3rr, Redirect | | | | | | DESCRIBE | | 200, Session description | | | | | | OPTIONS | Session ID | 200, Reset session timeout | | | | timer | | | | | | OPTIONS | | 200 | | | | | | SET_PARAMETER | Valid parameter | 200, change value of parameter | | | | | | GET_PARAMETER | Valid parameter | 200, return value of parameter | +---------------+-----------------+---------------------------------+ Table 13: None state-machine changing events The methods in Table 13 do not have any effect on the state machine or the state variables. However, some methods do change other session related parameters, for example SET_PARAMETER which will set the parameter(s) specified in its body. Also all of these methods that allow Session header will also update the keep-alive timer for the session. +------------------+----------------+-----------+-------------------+ | Action | Requisite | New State | Response | +------------------+----------------+-----------+-------------------+ | SETUP | | Ready | NRM=1, RP=0.0 | | | | | | | SETUP | Needs Redirect | Init | 3rr Redirect | | | | | | | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | +------------------+----------------+-----------+-------------------+ Table 14: State: Init The initial state of the state machine, see Table 14 can only be left by processing a correct SETUP request. As seen in the table the two Schulzrinne, et al. Expires October 6, 2013 [Page 250] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 state variables are also set by a correct request. This table also shows that a correct SETUP can in some cases be redirected to another URI and/or server by a 3rr response. +-------------+------------------------+---------+------------------+ | Action | Requisite | New | Response | | | | State | | +-------------+------------------------+---------+------------------+ | SETUP | New URI | Ready | NRM +=1 | | | | | | | SETUP | URI Setup prior | Ready | Change transport | | | | | param | | | | | | | TEARDOWN | Prs URI, | Init | No session hdr, | | | | | NRM = 0 | | | | | | | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | | | | | NRM = 0 | | | | | | | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | | | | | -= 1 | | | | | | | PLAY | Prs URI, No range | Play | Play from RP | | | | | | | PLAY | Prs URI, Range | Play | According to | | | | | range | | | | | | | PLAY | md URI, NRM=1, Range | Play | According to | | | | | range | | | | | | | PLAY | md URI, NRM=1 | Play | Play from RP | | | | | | | PAUSE | Prs URI | Ready | Return PP | | | | | | | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | | | | | | | SC:REDIRECT | No Terminate-Reason | Init | Session is | | | time parameter | | removed | | | | | | | Timeout | | Init | | | | | | | | RedP | | Init | TEARDOWN of | | reached | | | session | +-------------+------------------------+---------+------------------+ Table 15: State: Ready In the Ready state, see Table 15, some of the actions are depending Schulzrinne, et al. Expires October 6, 2013 [Page 251] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 on the number of media streams (NRM) in the session, i.e., aggregated or non-aggregated control. A SETUP request in the Ready state can either add one more media stream to the session or, if the media stream (same URI) already is part of the session, change the transport parameters. TEARDOWN is depending on both the Request-URI and the number of media streams within the session. If the Request- URI is the presentations URI the whole session is torn down. If a media URI is used in the TEARDOWN request and more than one media exists in the session, the session will remain and a session header is returned in the response. If only a single media stream remains in the session when performing a TEARDOWN with a media URI the session is removed. The number of media streams remaining after tearing down a media stream determines the new state. Schulzrinne, et al. Expires October 6, 2013 [Page 252] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 +----------------+-----------------------+--------+-----------------+ | Action | Requisite | New | Response | | | | State | | +----------------+-----------------------+--------+-----------------+ | PAUSE | Prs URI | Ready | Set RP to | | | | | present point | | | | | | | End of media | All media | Play | Set RP = End of | | | | | media | | | | | | | End of range | | Play | Set RP = End of | | | | | range | | | | | | | PLAY | Prs URI, No range | Play | Play from | | | | | present point | | | | | | | PLAY | Prs URI, Range | Play | According to | | | | | range | | | | | | | SC:PLAY_NOTIFY | | Play | 200 | | | | | | | SETUP | New URI | Play | 455 | | | | | | | SETUP | Setuped URI | Play | 455 | | | | | | | SETUP | Setuped URI, IFI | Play | Change | | | | | transport | | | | | param. | | | | | | | TEARDOWN | Prs URI | Init | No session hdr | | | | | | | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | | | | | NRM=0 | | | | | | | TEARDOWN | md URI | Play | 455 | | | | | | | SC:REDIRECT | Terminate Reason with | Play | Set RedP | | | Time parameter | | | | | | | | | SC:REDIRECT | | Init | Session is | | | | | removed | | | | | | | RedP reached | | Init | TEARDOWN of | | | | | session | | | | | | | Timeout | | Init | Stop Media | | | | | playout | +----------------+-----------------------+--------+-----------------+ Schulzrinne, et al. Expires October 6, 2013 [Page 253] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Table 16: State: Play The Play state table, see Table 16, contains a number of requests that need a presentation URI (labeled as Prs URI) to work on (i.e., the presentation URI has to be used as the Request-URI). This is due to the exclusion of non-aggregated stream control in sessions with more than one media stream. To avoid inconsistencies between the client and server, automatic state transitions are avoided. This can be seen at for example "End of media" event when all media has finished playing, the session still remains in Play state. An explicit PAUSE request needs to be sent to change the state to Ready. It may appear that there exist automatic transitions in "RedP reached" and "PP reached". However, they are requested and acknowledged before they take place. The time at which the transition will happen is known by looking at the range header. If the client sends a request close in time to these transitions it needs to be prepared for receiving error messages, as the state may or may not have changed. Schulzrinne, et al. Expires October 6, 2013 [Page 254] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix C. Media Transport Alternatives This section defines how certain combinations of protocols, profiles and lower transports are used. This includes the usage of the Transport header's source and destination address parameters "src_addr" and "dest_addr". C.1. RTP This section defines the interaction of RTSP with respect to the RTP protocol [RFC3550]. It also defines any necessary media transport signaling with regards to RTP. The available RTP profiles and lower layer transports are described below along with rules on signaling the available combinations. C.1.1. AVP The usage of the "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] when using RTP for media transport over different lower layer transport protocols is defined below in regards to RTSP. One such case is defined within this document: the use of embedded (interleaved) binary data as defined in Section 14. The usage of this method is indicated by including the "interleaved" parameter. When using embedded binary data the "src_addr" and "dest_addr" MUST NOT be used. This addressing and multiplexing is used as defined with use of channel numbers and the interleaved parameter. C.1.2. AVP/UDP This part describes sending of RTP [RFC3550] over lower transport layer UDP [RFC0768] according to the profile "RTP Profile for Audio and Video Conferences with Minimal Control" defined in RFC 3551 [RFC3551]. This profile requires one or two uni- or bi-directional UDP flows per media stream. The first UDP flow is for RTP and the second is for RTCP. Multiplexing of RTP and RTCP (Appendix C.1.6.4) MAY be used, in which case a single UDP flow is used for both parts. Embedding of RTP data with the RTSP messages, in accordance with Section 14, SHOULD NOT be performed when RTSP messages are transported over unreliable transport protocols, like UDP [RFC0768]. The RTP/UDP and RTCP/UDP flows can be established using the Transport header's "src_addr", and "dest_addr" parameters. In RTSP PLAY mode, the transmission of RTP packets from client to Schulzrinne, et al. Expires October 6, 2013 [Page 255] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 server is unspecified. The behavior in regards to such RTP packets MAY be defined in future. The "src_addr" and "dest_addr" parameters are used in the following way for media delivery and playback mode, i.e. Mode=PLAY: o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 2 address specifications. Note that two address specifications MAY be provided even if RTP and RTCP multiplexing is negotiated. o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST contain either: * both an address and a port number, or * a port number without an address. o The first address specification given in either of the parameters applies to the RTP stream. The second specification if present applies to the RTCP stream, unless in case RTP and RTCP multiplexing is negotiated where both RTP and RTCP will use the first specification. o The RTP/UDP packets from the server to the client MUST be sent to the address and port given by the first address specification of the "dest_addr" parameter. o The RTCP/UDP packets from the server to the client MUST be sent to the address and port given by the second address specification of the "dest_addr" parameter, unless RTP and RTCP multiplexing has been negotiated, in which case RTCP MUST be sent to the first address specification. If no second pair is specified and RTP and RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. o The RTCP/UDP packets from the client to the server MUST be sent to the address and port given by the second address specification of the "src_addr" parameter, unless RTP and RTCP multiplexing has been negotiated, in which case RTCP MUST be sent to the first address specification. If no second pair is specified and RTP and RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. o The RTP/UDP packets from the client to the server MUST be sent to the address and port given by the first address specification of the "src_addr" parameter. o RTP and RTCP Packets SHOULD be sent from the corresponding receiver port, i.e. RTCP packets from the server should be sent from the "src_addr" parameters second address port pair, unless Schulzrinne, et al. Expires October 6, 2013 [Page 256] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 RTP and RTCP multiplexing has been negotiated in which case the first address port pair is used. C.1.3. AVPF/UDP The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. All that is defined for AVP MUST also apply for AVPF. The usage of AVPF is indicated by the media initialization protocol used. In the case of SDP it is indicated by media lines (m=) containing the profile RTP/AVPF. That SDP MAY also contain further AVPF related SDP attributes configuring the AVPF session regarding reporting interval and feedback messages to be used [RFC4585]. This configuration MUST be followed. C.1.4. SAVP/UDP The RTP profile "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions using RTP. All that is defined for AVP MUST also apply for SAVP. The usage of SRTP requires that a security context is established. The default key-management unless otherwise signalled SHALL be MIKEY in RSA-R mode as defined in Appendix C.1.4.1, and not according to the procedure defined in "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY message in SDP, thus both requiring the usage of the DESCRIBE method and forcing the server to keep state for clients performing DESCRIBE in anticipation that they might require key management. MIKEY is selected as default method for establishing SRTP cryptographic context within an RTSP session as it can be embedded in the RTSP messages, while still ensuring confidentiality of content of the keying material, even when using hop-by-hop TLS security for the RTSP messages. This method does also support pipelining of the RTSP messages. C.1.4.1. MIKEY Key Establishment This method for using MIKEY [RFC3830] to establish the SRTP cryptographic context is initiated in the client's SETUP request, and the server's response to the SETUP carries the MIKEY response. This ensures that the crypto context establishment happens simultaneously with the establishment of the media stream being protected. By using MIKEY's RSA-R mode [RFC4738] the client can be the initiator and still allow the server to set the parameters in accordance with the Schulzrinne, et al. Expires October 6, 2013 [Page 257] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 actual media stream. The SRTP cryptographic context establishment is done according to the following process: 1. The client determines that SAVP or SAVPF shall be used from media description format, e.g. SDP. If no other key management method is explicitly signalled, then MIKEY SHALL be used as defined herein. This specification does not specify an explicit method for indicating this SRTP cryptographic context establishment method, but future specifications may. 2. The client SHALL establish a TLS connection for RTSP messages, directly or hop by hop with the server. If hop-by-hop TLS security is used, the User method SHALL be indicated in the Accept-Credentials header. We do note that using hop-by-hop does allow the proxy to insert itself as a man in the middle also in the MIKEY exchange by providing one of its certificates, rather than the server's in the Connection-Credentials header. The client SHALL therefore validate the server certificate. 3. The client retrieves the server's certificate from a direct TLS connection, or if hop by hop from Connection-Credentials header. The client then checks that the server certificate is valid and belongs to the server. 4. The client forms the MIKEY Initiator message using RSA-R mode in unicast mode as specified in [RFC4738]. The client SHOULD use the same certificate for TLS and in MIKEY to enable the server to bind the two together. The client's certificate SHALL be included in the MIKEY message. The client SHALL indicate its SRTP capabilities in the message. 5. The MIKEY message from the previous step is base64 [RFC4648] encoded and becomes the value of the MIKEY parameter that is included in the transport specification(s) that specifies a SRTP based profile (SAVP, SAVPF) in the SETUP request. 6. Any proxy encountering the MIKEY parameter SHALL forward it without modification. A proxy requiring to understand transport specification which doesn't support SAVP/SAVPF with MIKEY will discard the whole transport specification. Most types of proxies can easily support SAVP and SAVPF with MIKEY. If possible bypassing the proxy should be tried. 7. The server upon receiving the SETUP request, will need to decide upon the transport specification to use, if multiple are included by the client. In the determination of which transport Schulzrinne, et al. Expires October 6, 2013 [Page 258] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 specifications that are supported and preferred, the server SHOULD decode the MIKEY message to take the embedded SRTP parameters into account. If all transport specs require SRTP but no MIKEY parameter or other supported keying method is included, the server SHALL respond with 403. 8. Upon generating a response the following outcomes can occur: * A transport spec not using SRTP and MIKEY is selected. Thus the response will not contain any MIKEY parameter. * A transport spec using SRTP and MIKEY is selected but an error is encountered in the MIKEY processing. In that case an RTSP error response code of 466 "Key Management Error" SHALL be used. A MIKEY message describing the error MAY be included. * A transport spec using SRTP and MIKEY is selected and a MIKEY response message can be created. The server SHOULD use the same certificate for TLS and in MIKEY to enable client to bind the two together. If a different certificate is used it SHALL be included in the MIKEY message. It is RECOMMENDED that the envelope key cache type is set to 'Cache' and that a single envelope key is reused for all MIKEY messages to the client. That message is included in the MIKEY parameter part of the single selected transport specification in the SETUP response. The server will set the SRTP parameters as preferred for this media stream within the supported range by the client. 9. The server transmits the SETUP response back to the client. 10. The client receives the SETUP response and if the response code indicates a successful request it decodes the MIKEY message and establishes the SRTP cryptographic context from the parameters in the MIKEY response. In the above method the client's certificate may be self-signed in cases where the client's identity is not necessary to authenticate and the security goal is only to ensure that the RTSP signaling client is the same as the one receiving the SRTP security context. C.1.5. SAVPF/UDP The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in RTSP sessions using RTP. All that is defined for AVPF MUST also apply for SAVPF. Schulzrinne, et al. Expires October 6, 2013 [Page 259] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 The usage of SRTP requires that a cryptographic context is established. The default mechanism for establishing that security association is to use MIKEY[RFC3830] with RTSP as defined in Appendix C.1.4.1. C.1.6. RTCP usage with RTSP RTCP has several usages when RTP is used for media transport as explained below. Due to that RTCP MUST be supported if an RTSP agent handles RTP. C.1.6.1. Media synchronization RTCP provides media synchronization and clock drift compensation. The initial media synchronization is available from RTP-Info header. However, to be able to handle any clock drift between the media streams, RTCP is needed. C.1.6.2. RTSP Session keep-alive RTCP traffic from the RTSP client to the RTSP server MUST function as keep-alive. This requires an RTSP server supporting RTP to use the received RTCP packets as indications that the client desires the related RTSP session to be kept alive. C.1.6.3. Bit-rate adaption RTCP Receiver reports and any additional feedback from the client MUST be used to adapt the bit-rate used over the transport for all cases when RTP is sent over UDP. An RTP sender without reserved resources MUST NOT use more than its fair share of the available resources. This can be determined by comparing on short to medium term (some seconds) the used bit-rate and adapt it so that the RTP sender sends at a bit-rate comparable to what a TCP sender would achieve on average over the same path. C.1.6.4. RTP and RTCP Multiplexing RTSP can be used to negotiate the usage of RTP and RTCP multiplexing as described in [RFC5761]. This allows servers and client to reduce the amount of resources required for the session by only requiring one underlying transport stream per media stream instead of two when using RTP and RTCP. This lessens the server port consumption and also the necessary state and keep-alive work when operating across Network and Address Translators [RFC2663]. Content must be prepared with some consideration for RTP and RTCP multiplexing, mainly ensuring that the RTP payload types used do not Schulzrinne, et al. Expires October 6, 2013 [Page 260] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 collide with the ones used for RTCP packet types. This option likely needs explicit support from the content unless the RTP payload types can be remapped by the server and that is correctly reflected in the session description. Beyond that support of this feature should come at little cost and much gain. It is recommended that if the content and server support RTP and RTCP multiplexing that this is indicated in the session description, for example using the SDP attribute "a=rtcp-mux". If the SDP message contains the a=rtcp-mux attribute for a media stream, the server MUST support RTP and RTCP multiplexing. If indicated or otherwise desired by the client it can include the Transport parameter "RTCP-mux" in any transport specification where it desires to use RTCP-mux. The server will indicate if it supports RTCP-mux. Servers and Clients SHOULD support RTP and RTCP multiplexing. For capability exchange, an RTSP feature tag for RTP and RTCP multiplexing is defined: "setup.rtp.rtcp.mux". To minimize the risk of negotiation failure while using RTP and RTCP multiplexing some recommendations are here provided. If the session description includes explicit indication of support (a=rtcp-mux in SDP), then a RTSP agent can safely create a SETUP request with a transport specification with only a single dest_addr parameter address specification. If no such explicit indication is provided, then even if the feature tag "setup.rtp.rtcp.mux" is provided in a Supported header by the RTSP server or the feature tag included in the Required header in the SETUP request, the media resource may not support RTP and RTCP multiplexing. Thus, to maximize the probability of successful negotiation the RTSP agent is recommended to include two dest_addr parameter address specifications in the first or first set (if pipelining is used) of SETUP request(s) for any media resource aggregate. That way the RTSP server can either accept RTP and RTCP multiplexing and only use the first address specification, and if not use both specifications. The RTSP agent after having received the response for a successful negotiation of the usage of RTP and RTCP multiplexing, can then release the resources associated with the second address specification. C.2. RTP over TCP Transport of RTP over TCP can be done in two ways: over independent TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP control connection. In both cases the protocol MUST be "rtp" and the lower layer MUST be TCP. The profile may be any of the above specified ones; AVP, AVPF, SAVP or SAVPF. Schulzrinne, et al. Expires October 6, 2013 [Page 261] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C.2.1. Interleaved RTP over TCP The use of embedded (interleaved) binary data transported on the RTSP connection is possible as specified in Section 14. When using this declared combination of interleaved binary data the RTSP messages MUST be transported over TCP. TLS may or may not be used. If TLS is used both RTSP messages and the binary data will be protected by TLS. One should, however, consider that this will result in all media streams go through any proxy. Using independent TCP connections can avoid that issue. C.2.2. RTP over independent TCP In this Appendix, we describe the sending of RTP [RFC3550] over lower transport layer TCP [RFC0793] according to "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport" [RFC4571]. This Appendix adapts the guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work with RTSP. A client codes the support of RTP over independent TCP by specifying an RTP/AVP/TCP transport option without an interleaved parameter in the Transport line of a SETUP request. This transport option MUST include the "unicast" parameter. If the client wishes to use RTP with RTCP, two address specifications needs to be included in the dest_addr parameter. If the client wishes to use RTP without RTCP, one address specification is included in the dest_addr parameter. If the client wishes to multiplex RTP and RTCP on a single transport flow (see Appendix C.1.6.4), one or two address specifications are included in the dest_addr parameter in addition to the RTCP-mux transport parameter. Two address specifications are allowed to allow successful negotiation when server or content can't support RTP and RTCP multiplexing. Ordering rules of dest_addr ports follow the rules for RTP/AVP/UDP. If the client wishes to play the active role in initiating the TCP connection, it MAY set the "setup" parameter (See Section 18.52) on the Transport line to be "active", or it MAY omit the setup parameter, as active is the default. If the client signals the active role, the ports in the address specifications in the dest_addr parameter MUST be set to 9 (the discard port). If the client wishes to play the passive role in TCP connection initiation, it MUST set the "setup" parameter on the Transport line to be "passive". If the client is able to assume the active or the passive role, it MUST set the "setup" parameter on the Transport line Schulzrinne, et al. Expires October 6, 2013 [Page 262] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 to be "actpass". In either case, the dest_addr parameter's address specification port value for RTP MUST be set to the TCP port number on which the client is expecting to receive the TCP connection for RTP, and the dest_addr's address specification port value for RTCP MUST be set to the TCP port number on which the client is expecting to receive the TCP connection for RTCP. In the case that the client wishes to multiplex RTP and RTCP on a single transport flow, the RTCP-mux parameter is included and one or two dest_addr parameter address specifications are included, as mentioned earlier in this section. If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a server decides to accept this requested option, the 2xx reply MUST contain a Transport option that specifies RTP/AVP/TCP (without using the interleaved parameter, and with using the unicast parameter). The dest_addr parameter value MUST be echoed from the parameter value in the client request unless the destination address (only port) was not provided in which case the server MAY include the source address of the RTSP TCP connection with the port number unchanged. In addition, the server reply MUST set the setup parameter on the Transport line, to indicate the role the server will play in the connection setup. Permissible values are "active" (if a client set "setup" to "passive" or "actpass") and "passive" (if a client set "setup" to "active" or "actpass"). If a server sets "setup" to "passive", the "src_addr" in the reply MUST indicate the ports the server is willing to receive an TCP connection for RTP and (if the client requested an TCP connection for RTCP by specifying two dest_addr address specifications) an TCP/RTCP connection. If a server sets "setup" to "active", the ports specified in "src_addr" address specifications MUST be set to 9. The server MAY use the "ssrc" parameter, following the guidance in Section 18.52. The server sets only one address specification in the case that the client has indicated only a single address specification or in case RTP and RTCP multiplexing was requested and accepted by server. Port ordering for src_addr follows the rules for RTP/AVP/UDP. Servers MUST support taking the passive role and MAY support taking the active role. Servers with a public IP address take the passive role, thus enabling clients behind NATs and Firewalls a better chance of successful connect to the server by actively connecting outwards. Therefore the clients are RECOMMENDED to take the active role. After sending (receiving) a 2xx reply for a SETUP method for a non- interleaved RTP/AVP/TCP media stream, the active party SHOULD initiate the TCP connection as soon as possible. The client MUST NOT Schulzrinne, et al. Expires October 6, 2013 [Page 263] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 send a PLAY request prior to the establishment of all the TCP connections negotiated using SETUP for the session. In case the server receives a PLAY request in a session that has not yet established all the TCP connections, it MUST respond using the 464 "Data Transport Not Ready Yet" (Section 17.4.29) error code. Once the PLAY request for a media resource transported over non- interleaved RTP/AVP/TCP occurs, media begins to flow from server to client over the RTP TCP connection, and RTCP packets flow bidirectionally over the RTCP TCP connection. Unless RTP and RTCP multiplexing has been negotiated in which case RTP and RTCP will flow over a common TCP connection. As in the RTP/UDP case, client to server traffic on a RTP only TCP session is unspecified by this memo. The packets that travel on these connections MUST be framed using the protocol defined in [RFC4571], not by the framing defined for interleaving RTP over the RTSP control connection defined in Section 14. A successful PAUSE request for a media being transported over RTP/ AVP/TCP pauses the flow of packets over the connections, without closing the connections. A successful TEARDOWN request signals that the TCP connections for RTP and RTCP are to be closed by the RTSP client as soon as possible. Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be ambiguous in the following way: does the client wish to open up new TCP connection for RTP or RTCP for the URI, or does the client wish to continue using the existing TCP connections? The client SHOULD use the "connection" parameter (defined in Section 18.52) on the Transport line to make its intention clear (by setting "connection" to "new" if new connections are needed, and by setting "connection" to "existing" if the existing connections are to be used). After a 2xx reply for a SETUP request for a new connection, parties should close the pre-existing connections, after waiting a suitable period for any stray RTP or RTCP packets to arrive. The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that a security association is established. The default mechanism for establishing that security association is to use MIKEY[RFC3830] with RTSP as defined Appendix C.1.4.1. Below, we rewrite part of the example media on demand example shown in Appendix A.1 to use RTP/AVP/TCP non-interleaved: Schulzrinne, et al. Expires October 6, 2013 [Page 264] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 M->C: 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: 227 Content-Base: rtsp://example.com/twister.3gp/ Expires: 24 Jan 1997 15:35:06 GMT v=0 o=- 2890844256 2890842807 IN IP4 198.51.100.34 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 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; setup=active;connection=new Accept-Ranges: NPT, SMPTE, UTC Schulzrinne, et al. Expires October 6, 2013 [Page 265] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Transport: RTP/AVP/TCP;unicast; dest_addr=":9"/":9"; src_addr="198.51.100.5:53478"/"198.51.100:54091"; setup=passive;connection=new;ssrc=93CB001E Session: 12345678 Expires: 24 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT Accept-Ranges: NPT Media-Properties: Random-Access=0.8, Immutable, Unlimited C->M: TCP Connection Establishment x2 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Range: npt=30- Session: 12345678 M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:14 GMT Session: 12345678 Range: npt=30-623.10 Seek-Style: First-Prior RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889 C.3. Handling Media Clock Time Jumps in the RTP Media Layer RTSP allows media clients to control selected, non-contiguous sections of media presentations, rendering those streams with an RTP media layer [RFC3550]. Two cases occur, the first is when a new PLAY request replaces an old ongoing request and the new request results in a jump in the media. This should produce in the RTP layer a continuous media stream. A client may also directly following a completed PLAY request perform a new PLAY request. This will result in some gap in the media layer. The below text will look into both cases. A PLAY request that replaces an ongoing request allows the media layer rendering the RTP stream without being affected by jumps in media clock time. The RTP timestamps for the new media range is set so that they become continuous with the previous media range in the previous request. The RTP sequence number for the first packet in Schulzrinne, et al. Expires October 6, 2013 [Page 266] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 the new range will be the next following the last packet in the previous range, i.e. monotonically increasing. The goal is to allow the media rendering layer to work without interruption or reconfiguration across the jumps in media clock. This should be possible in all cases of replaced PLAY requests for media that has random-access properties. In this case care is needed to align frames or similar media dependent structures. In cases where jumps in media clock time are a result of RTSP signaling operations arriving after a completed PLAY operation, the request timing will result in that media becomes non-continuous. The server becomes unable to send the media so that it arrives timely and still carry timestamps to make the media stream continuous. In these cases the server will produce RTP streams where there are gaps in the RTP timeline for the media. In such cases, if the media has frame structure, aligning the timestamp for the next frame with the previous structure reduces the burden to render this media. The gap should represent the time the server hasn't been serving media, e.g. the time between the end of the media stream or a PAUSE request and the new PLAY request. In these cases the RTP sequence number would normally be monotonically increasing across the gap. For RTSP sessions with media that lacks random access properties, such as live streams, any media clock jump is commonly the result of a correspondingly long pause of delivery. The RTP timestamp will have increased in direct proportion to the duration of the paused delivery. Note also that in this case the RTP sequence number should be the next packet number. If not, the RTCP packet loss reporting will indicate as loss all packets not received between the point of pausing and later resuming. This may trigger congestion avoidance mechanisms. An allowed exception from the above recommendation on monotonically increasing RTP sequence number is live media streams, likely being relayed. In this case, when the client resumes delivery, it will get the media that is currently being delivered to the server itself. For this type of basic delivery of live streams to multiple users over unicast, individual rewriting of RTP sequence numbers becomes quite a burden. For solutions that anyway caches media, timeshifts, etc, the rewriting should be a minor issue. The goal when handling jumps in media clock time is that the provided stream is continuous without gaps in RTP timestamp or sequence number. However, when delivery has been halted for some reason the RTP timestamp when resuming MUST represent the duration the delivery was halted. RTP sequence number MUST generally be the next number, i.e. monotonically increasing modulo 65536. For media resources with the properties Time-Progressing and Time-Duration=0.0 the server MAY create RTP media streams with RTP sequence number jumps in them due to the client first halting delivery and later resuming it (PAUSE and Schulzrinne, et al. Expires October 6, 2013 [Page 267] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 then later PLAY). However, servers utilizing this exception must take into consideration the resulting RTCP receiver reports that likely contain loss reports for all the packets part of the discontinuity. A client cannot rely on that a server will align when resuming playing even if it is RECOMMENDED. The RTP-Info header will provide information on how the server acts in each case. We cannot assume that the RTSP client can communicate with the RTP media agent, as the two may be independent processes. If the RTP timestamp shows the same gap as the NPT, the media agent will assume that there is a pause in the presentation. If the jump in NPT is large enough, the RTP timestamp may roll over and the media agent may believe later packets to be duplicates of packets just played out. Having the RTP timestamp jump will also affect the RTCP measurements based on this. As an example, assume an RTP timestamp frequency of 8000 Hz, a packetization interval of 100 ms and an initial sequence number and timestamp of zero. C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 4 Session: abcdefgh Range: npt=10-15 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 4 Session: abcdefgh Range: npt=10-15 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=0;rtptime=0 The ensuing RTP data stream is depicted below: S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s . . . S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s Upon the completion of the requested delivery the server sends a PLAY_NOTIFY Schulzrinne, et al. Expires October 6, 2013 [Page 268] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 CSeq: 5 Notify-Reason: end-of-stream Request-Status: cseq=4 status=200 reason="OK" Range: npt=-15 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=49;rtptime=39200 Session: abcdefgh C->S: RTSP/2.0 200 OK CSeq: 5 User-Agent: PhonyClient/1.2 Upon the completion of the play range, the client follows up with a request to PLAY from a new NPT. C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 6 Session: abcdefg Range: npt=18-20 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 6 Session: abcdefg Range: npt=18-20 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=50;rtptime=40100 The ensuing RTP data stream is depicted below: S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s . . . S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s In this example, first, NPT 10 through 15 is played, then the client requests the server to skip ahead and play NPT 18 through 20. The first segment is presented as RTP packets with sequence numbers 0 through 49 and timestamp 0 through 39,200. The second segment consists of RTP packets with sequence number 50 through 69, with timestamps 40,100 through 55,200. While there is a gap in the NPT, there is no gap in the sequence number space of the RTP data stream. The RTP timestamp gap is present in the above example due to the time it takes to perform the second play request, in this case 12.5 ms (100/8000). Schulzrinne, et al. Expires October 6, 2013 [Page 269] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C.4. Handling RTP Timestamps after PAUSE During a PAUSE / PLAY interaction in an RTSP session, the duration of time for which the RTP transmission was halted MUST be reflected in the RTP timestamp of each RTP stream. The duration can be calculated for each RTP stream as the time elapsed from when the last RTP packet was sent before the PAUSE request was received and when the first RTP packet was sent after the subsequent PLAY request was received. The duration includes all latency incurred and processing time required to complete the request. The RTP RFC [RFC3550] states that: The RTP timestamp for each unit [packet] would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline. In order to satisfy the requirements of [RFC3550], the RTP timestamp space needs to increase continuously with real time. While this is not optimal for stored media, it is required for RTP and RTCP to function as intended. Using a continuous RTP timestamp space allows the same timestamp model for both stored and live media and allows better opportunity to integrate both types of media under a single control. As an example, assume a clock frequency of 8000 Hz, a packetization interval of 100 ms and an initial sequence number and timestamp of zero. C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 4 Session: abcdefg Range: npt=10-15 User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 4 Session: abcdefg Range: npt=10-15 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=0;rtptime=0 The ensuing RTP data stream is depicted below: S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s The client then sends a PAUSE request: Schulzrinne, et al. Expires October 6, 2013 [Page 270] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 CSeq: 5 Session: abcdefg User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 5 Session: abcdefg Range: npt=10.4-15 20 seconds elapse and then the client sends a PLAY request. In addition the server requires 15 ms to process the request: C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 6 Session: abcdefg User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 6 Session: abcdefg Range: npt=10.4-15 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=4;rtptime=164400 The ensuing RTP data stream is depicted below: S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s First, NPT 10 through 10.3 is played, then a PAUSE is received by the server. After 20 seconds a PLAY is received by the server which takes 15 ms to process. The duration of time for which the session was paused is reflected in the RTP timestamp of the RTP packets sent after this PLAY request. A client can use the RTSP range header and RTP-Info header to map NPT time of a presentation with the RTP timestamp. Note: In RFC 2326 [RFC2326], this matter was not clearly defined and was misunderstood commonly. However, for RTSP 2.0 it is expected that this will be handled correctly and no exception handling will be required. Note further: It may be required to reset some of the state to ensure the correct media decoding and the usual jitter-buffer handling when issuing a PLAY request. Schulzrinne, et al. Expires October 6, 2013 [Page 271] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 C.5. RTSP / RTP Integration For certain datatypes, tight integration between the RTSP layer and the RTP layer will be necessary. This by no means precludes the above restrictions. Combined RTSP/RTP media clients should use the RTP-Info field to determine whether incoming RTP packets were sent before or after a seek or before or after a PAUSE. C.6. Scaling with RTP For scaling (see Section 18.44), RTP timestamps should correspond to the rendering timing. For example, when playing video recorded at 30 frames/second at a scale of two and speed (Section 18.48) of one, the server would drop every second frame to maintain and deliver video packets with the normal timestamp spacing of 3,000 per frame, but NPT would increase by 1/15 second for each video frame. Note: The above scaling puts requirements on the media codec or a media stream to support it. For example motion JPEG or other non- predictive video coding can easier handle the above example. C.7. Maintaining NPT synchronization with RTP timestamps The client can maintain a correct display of NPT (Normal Play Time) by noting the RTP timestamp value of the first packet arriving after repositioning. The sequence parameter of the RTP-Info (Section 18.43) header provides the first sequence number of the next segment. C.8. Continuous Audio For continuous audio, the server SHOULD set the RTP marker bit at the beginning of serving a new PLAY request or at jumps in timeline. This allows the client to perform playout delay adaptation. C.9. Multiple Sources in an RTP Session Note that more than one SSRC MAY be sent in the media stream. If it happens all sources are expected to be rendered simultaneously. C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session The RTCP BYE message indicates the end of use of a given SSRC. If all sources leave an RTP session, it can, in most cases, be assumed to have ended. Therefore, a client or server MUST NOT send an RTCP BYE message until it has finished using a SSRC. A server SHOULD keep using a SSRC until the RTP session is terminated. Prolonging the use of a SSRC allows the established synchronization context associated Schulzrinne, et al. Expires October 6, 2013 [Page 272] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 with that SSRC to be used to synchronize subsequent PLAY requests even if the PLAY response is late. An SSRC collision with the SSRC that transmits media does also have consequences, as it will normally force the media sender to change its SSRC in accordance with the RTP specification [RFC3550]. However, an RTSP server may wait and see if the client changes and thus resolve the conflict to minimize the impact. As media sender SSRC change will result in a loss of synchronization context, and require any receiver to wait for RTCP sender reports for all media requiring synchronization before being able to play out synchronized. Due to these reasons a client joining a session should take care to not select the same SSRC(s) as the server indicates in the ssrc Transport header parameter. Any SSRC signalled in the Transport header MUST be avoided. A client detecting a collision prior to sending any RTP or RTCP messages SHALL also select a new SSRC. C.11. Future Additions It is the intention that any future protocol or profile regarding media delivery and lower transport should be easy to add to RTSP. This section provides the necessary steps that needs to be meet. The following things needs to be considered when adding a new protocol or profile for use with RTSP: o The protocol or profile needs to define a name tag representing it. This tag is required to be an ABNF "token" to be possible to use in the Transport header specification. o The useful combinations of protocol, profiles and lower layer transport for this extension needs to be defined. For each combination declare the necessary parameters to use in the Transport header. o For new media protocols the interaction with RTSP needs to be addressed. One important factor will be the media synchronization. It may be necessary to have new headers similar to RTP info to carry this information. o Discuss congestion control for media, especially if transport without built in congestion control is used. See the IANA section (Section 22) for information how to register new attributes. Schulzrinne, et al. Expires October 6, 2013 [Page 273] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix D. Use of SDP for RTSP Session Descriptions The Session Description Protocol (SDP, [RFC4566]) may be used to describe streams or presentations in RTSP. This description is typically returned in reply to a DESCRIBE request on an URI from a server to a client, or received via HTTP from a server to a client. This appendix describes how an SDP file determines the operation of an RTSP session. Thus, it is worth pointing out that the interpretation of the SDP is done in the context of the SDP receiver, which is the one being configured. This is the same as in SAP [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each SDP is interpreted in the context of the agent providing it. SDP as is provides no mechanism by which a client can distinguish, without human guidance, between several media streams to be rendered simultaneously and a set of alternatives (e.g., two audio streams spoken in different languages). The SDP extension "Grouping of Media Lines in the Session Description Protocol (SDP)" [RFC5888] provides such functionality to some degree. Appendix D.4 describes the usage of SDP media line grouping for RTSP. D.1. Definitions The terms "session-level", "media-level" and other key/attribute names and values used in this appendix are to be used as defined in SDP[RFC4566]: D.1.1. Control URI The "a=control:" attribute is used to convey the control URI. This attribute is used both for the session and media descriptions. If used for individual media, it indicates the URI to be used for controlling that particular media stream. If found at the session level, the attribute indicates the URI for aggregate control (presentation URI). The session level URI MUST be different from any media level URI. The presence of a session level control attribute MUST be interpreted as support for aggregated control. The control attribute MUST be present on media level unless the presentation only contains a single media stream, in which case the attribute MAY be present on the session level only and then also apply to that single media stream. ABNF for the attribute is defined in Section 20.3. Example: a=control:rtsp://example.com/foo Schulzrinne, et al. Expires October 6, 2013 [Page 274] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 This attribute MAY contain either relative or absolute URIs, following the rules and conventions set out in RFC 3986 [RFC3986]. Implementations MUST look for a base URI in the following order: 1. the RTSP Content-Base field; 2. the RTSP Content-Location field; 3. the RTSP Request-URI. If this attribute contains only an asterisk (*), then the URI MUST be treated as if it were an empty embedded URI, and thus inherit the entire base URI. Note, RFC 2326 was very unclear on the processing of relative URI and several RTSP 1.0 implementations at the point of publishing this document did not perform RFC 3986 processing to determine the resulting URI, instead simple concatenation is common. To avoid this issue completely it is recommended to use absolute URI in the SDP. The URI handling for SDPs from container files need special consideration. For example let's assume that a container file has the URI: "rtsp://example.com/container.mp4". Let's further assume this URI is the base URI, and that there is an absolute media level URI: "rtsp://example.com/container.mp4/trackID=2". A relative media level URI that resolves in accordance with RFC 3986 [RFC3986] to the above given media URI is: "container.mp4/trackID=2". It is usually not desirable to need to include in or modify the SDP stored within the container file with the server local name of the container file. To avoid this, one can modify the base URI used to include a trailing slash, e.g. "rtsp://example.com/container.mp4/". In this case the relative URI for the media will only need to be: "trackID=2". However, this will also mean that using "*" in the SDP will result in control URI including the trailing slash, i.e. "rtsp://example.com/container.mp4/". Note: The usage of TrackID in the above is not a standardized form, but one example out of several similar strings such as TrackID, Track_ID, StreamID that is used by different server vendors to indicate a particular piece of media inside a container file. D.1.2. Media Streams The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is over multicast, the port number Schulzrinne, et al. Expires October 6, 2013 [Page 275] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 indicated SHOULD be used for reception. The client MAY try to override the destination port, through the Transport header. The servers MAY allow this, the response will indicate if allowed or not. If the session is unicast, the port numbers are the ones RECOMMENDED by the server to the client, about which receiver ports to use; the client MUST still include its receiver ports in its SETUP request. The client MAY ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero. The "m=" lines contain information about which transport protocol, profile, and possibly lower-layer is to be used for the media stream. The combination of transport, profile and lower layer, like RTP/AVP/ UDP needs to be defined for how to be used with RTSP. The currently defined combinations are defined in Appendix C, further combinations MAY be specified. Example: m=audio 0 RTP/AVP 31 D.1.3. Payload Type(s) The payload type(s) are specified in the "m=" line. In case the payload type is a static payload type from RFC 3551 [RFC3551], no other information may be required. In case it is a dynamic payload type, the media attribute "rtpmap" is used to specify what the media is. The "encoding name" within the "rtpmap" attribute may be one of those specified in [RFC4856], or a media type registered with IANA according to [RFC4855], or an experimental encoding as specified in SDP [RFC4566]). Codec-specific parameters are not specified in this field, but rather in the "fmtp" attribute described below. The selection of the RTP payload type numbers used may be required to consider RTP and RTCP Multiplexing [RFC5761] if that is to be supported by the server. D.1.4. Format-Specific Parameters Format-specific parameters are conveyed using the "fmtp" media attribute. The syntax of the "fmtp" attribute is specific to the encoding(s) that the attribute refers to. Note that some of the format specific parameters may be specified outside of the fmtp parameters, like for example the "ptime" attribute for most audio encodings. D.1.5. Directionality of media stream The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" provide instructions about the direction the media streams flow Schulzrinne, et al. Expires October 6, 2013 [Page 276] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 within a session. When using RTSP the SDP can be delivered to a client using either RTSP DESCRIBE or a number of RTSP external methods, like HTTP, FTP, and email. Based on this the SDP applies to how the RTSP client will see the complete session. Thus media streams delivered from the RTSP server to the client, would be given the "a=recvonly" attribute. "a=recvonly" in a SDP provided to the RTSP client indicates that media delivery will only occur in the direction from the RTSP server to the client. SDP provided to the RTSP client that lacks any of the directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would be interpreated as having a=sendrecv. At the time of writing there exist no RTSP mode suitable for media traffic in the direction from the RTSP client to the server. Thus all RTSP SDP SHOULD have a=recvonly attribute when using the PLAY mode defined in this document. If future modes are defined for media in client to server direction, then usage of a=sendonly, or a=sendrecv may become suitable to indicate intended media directions. D.1.6. Range of Presentation The "a=range" attribute defines the total time range of the stored session or an individual media. Non-seekable live sessions can be indicated as specified below, while the length of live sessions can be deduced from the "t=" and "r=" SDP parameters. The attribute is both a session and a media level attribute. For presentations that contain media streams of the same duration, the range attribute SHOULD only be used at session-level. In case of different lengths the range attribute MUST be given at media level for all media, and SHOULD NOT be given at session level. If the attribute is present at both media level and session level the media level values MUST be used. Note: Usually one will specify the same length for all media, even if there isn't media available for the full duration on all media. However, that requires that the server accepts PLAY requests within that range. Servers MUST take care to provide RTSP Range (see Section 18.38) values that are consistent with what is presented in the SDP for the content. There is no reason for non dynamic content, like media clips provided on demand to have inconsistent values. Inconsistent values between the SDP and the actual values for the content handled by the server is likely to generate some failure, like 457 "Invalid Range", in case the client uses PLAY requests with a Range header. In case the content is dynamic in length and it is infeasible to provide a correct value in the SDP the server is recommended to Schulzrinne, et al. Expires October 6, 2013 [Page 277] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 describe this as non-seekable content (see below). The server MAY override that property in the response to a PLAY request using the correct values in the Range header. The unit is specified first, followed by the value range. The units and their values are as defined in Section 4.4, Section 4.5 and Section 4.6 and MAY be extended with further formats. Any open ended range (start-), i.e. without stop range, is of unspecified duration and MUST be considered as non-seekable content unless this property is overridden. Multiple instances carrying different clock formats MAY be included at either session or media level. ABNF for the attribute is defined in Section 20.3. Examples: a=range:npt=0-34.4368 a=range:clock=19971113T211503Z-19971113T220300Z Non seekable stream of unknown duration: a=range:npt=0- D.1.7. Time of Availability The "t=" field defines when the SDP is valid. For on-demand content the server SHOULD indicate a stop time value for which it guarantees the description to be valid, and a start time that is equal to or before the time at which the DESCRIBE request was received. It MAY also indicate start and stop times of 0, meaning that the session is always available. For sessions that are of live type, i.e. specific start time, unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD be used to indicate the start time of the event. The stop time SHOULD be given so that the live event will have ended at that time, while still not be unnecessary long into the future. D.1.8. Connection Information In SDP used with RTSP, the "c=" field contains the destination address for the media stream. If a multicast address is specified the client SHOULD use this address in any SETUP request as destination address, including any additional parameters, such as TTL. For on-demand unicast streams and some multicast streams, the destination address MAY be specified by the client via the SETUP request, thus overriding any specified address. To identify streams without a fixed destination address, where the client is required to specify a destination address, the "c=" field SHOULD be set to a null value. For addresses of type "IP4", this value MUST be "0.0.0.0", and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be Schulzrinne, et al. Expires October 6, 2013 [Page 278] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 written as "::"), i.e. the unspecified address according to RFC 4291 [RFC4291]. D.1.9. Message Body Tag The optional "a=mtag" attribute identifies a version of the session description. It is opaque to the client. SETUP requests may include this identifier in the If-Match field (see Section 18.23) to only allow session establishment if this attribute value still corresponds to that of the current description. The attribute value is opaque and may contain any character allowed within SDP attribute values. ABNF for the attribute is defined in Section 20.3. Example: a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" One could argue that the "o=" field provides identical functionality. However, it does so in a manner that would put constraints on servers that need to support multiple session description types other than SDP for the same piece of media content. D.2. Aggregate Control Not Available If a presentation does not support aggregate control no session level "a=control:" attribute is specified. For a SDP with multiple media sections specified, each section will have its own control URI specified via the "a=control:" attribute. Example: v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.56 s=I came from a web page e=adm@example.com c=IN IP4 0.0.0.0 t=0 0 m=video 8002 RTP/AVP 31 a=control:rtsp://audio.example.com/movie.aud m=audio 8004 RTP/AVP 3 a=control:rtsp://video.example.com/movie.vid Note that the position of the control URI in the description implies that the client establishes separate RTSP control sessions to the servers audio.example.com and video.example.com. It is recommended that an SDP file contains the complete media initialization information even if it is delivered to the media Schulzrinne, et al. Expires October 6, 2013 [Page 279] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 client through non-RTSP means. This is necessary as there is no mechanism to indicate that the client should request more detailed media stream information via DESCRIBE. D.3. Aggregate Control Available In this scenario, the server has multiple streams that can be controlled as a whole. In this case, there are both a media-level "a=control:" attributes, which are used to specify the stream URIs, and a session-level "a=control:" attribute which is used as the Request-URI for aggregate control. If the media-level URI is relative, it is resolved to absolute URIs according to Appendix D.1.1 above. Example: C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 M->C: RTSP/2.0 200 OK CSeq: 1 Date: Thu, 23 Jan 1997 15:35:06 GMT Expires: Thu, 23 Jan 1997 16:35:06 GMT Content-Type: application/sdp Content-Base: rtsp://example.com/movie/ Content-Length: 227 v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.211 s=I contain i=<more info> e=adm@example.com c=IN IP4 0.0.0.0 a=control:* t=0 0 m=video 8002 RTP/AVP 31 a=control:trackID=1 m=audio 8004 RTP/AVP 3 a=control:trackID=2 In this example, the client is recommended to establish a single RTSP session to the server, and uses the URIs rtsp://example.com/movie/trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video and audio streams, respectively. The URI rtsp://example.com/movie/, which is resolved from the "*", controls the whole presentation (movie). A client is not required to issue SETUP requests for all streams Schulzrinne, et al. Expires October 6, 2013 [Page 280] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 within an aggregate object. Servers should allow the client to ask for only a subset of the streams. D.4. Grouping of Media Lines in SDP For some types of media it is desirable to express a relationship between various media components, for instance, for lip synchronization or Scalable Video Codec (SVC) [RFC5583]. This relationship is expressed on the SDP level by grouping of media lines, as described in [RFC5888] and can be exposed to RTSP. For RTSP it is mainly important to know how to handle grouped medias received by means of SDP, i.e., if the media are under aggregate control (see Appendix D.3) or if aggregate control is not available (see Appendix D.2). It is RECOMMENDED that grouped medias are handled by aggregate control, to give the client the ability to control either the whole presentation or single medias. D.5. RTSP external SDP delivery There are some considerations that need to be made when the session description is delivered to the client outside of RTSP, for example via HTTP or email. First of all, the SDP needs to contain absolute URIs, since relative will in most cases not work as the delivery will not correctly forward the base URI. The writing of the SDP session availability information, i.e. "t=" and "r=", needs to be carefully considered. When the SDP is fetched by the DESCRIBE method, the probability that it is valid is very high. However, the same is much less certain for SDPs distributed using other methods. Therefore the publisher of the SDP should take care to follow the recommendations about availability in the SDP specification [RFC4566] in Section 4.2. Schulzrinne, et al. Expires October 6, 2013 [Page 281] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix E. RTSP Use Cases This Appendix describes the most important and considered use cases for RTSP. They are listed in descending order of importance in regards to ensuring that all necessary functionality is present. This specification only fully supports usage of the two first. Also in these first two cases, there are special cases or exceptions that are not supported without extensions, e.g. the redirection of media delivery to another address than the controlling agent's (client's). E.1. On-demand Playback of Stored Content An RTSP capable server stores content suitable for being streamed to a client. A client desiring playback of any of the stored content uses RTSP to set up the media transport required to deliver the desired content. RTSP is then used to initiate, halt and manipulate the actual transmission (playout) of the content. RTSP is also required to provide necessary description and synchronization information for the content. The above high level description can be broken down into a number of functions that RTSP needs to be capable of. Presentation Description: Provide initialization information about the presentation (content); for example, which media codecs are needed for the content. Other information that is important includes the number of media streams the presentation contains, the transport protocols used for the media streams, and identifiers for these media streams. This information is required before setup of the content is possible and to determine if the client is even capable of using the content. This information need not be sent using RTSP; other external protocols can be used to transmit the transport presentation descriptions. Two good examples are the use of HTTP [RFC2616] or email to fetch or receive presentation descriptions like SDP [RFC4566] Setup: Set up some or all of the media streams in a presentation. The setup itself consists of selecting the protocol for media transport and the necessary parameters for the protocol, like addresses and ports. Control of Transmission: After the necessary media streams have been established the client can request the server to start transmitting the content. The client must be allowed to start or stop the transmission of the content at arbitrary times. The client must also be able to start the transmission at any Schulzrinne, et al. Expires October 6, 2013 [Page 282] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 point in the timeline of the presentation. Synchronization: For media transport protocols like RTP [RFC3550] it might be beneficial to carry synchronization information within RTSP. This may be due to either the lack of inter-media synchronization within the protocol itself, or the potential delay before the synchronization is established (which is the case for RTP when using RTCP). Termination: Terminate the established contexts. For this use case there are a number of assumptions about how it works. These are: On-Demand content: The content is stored at the server and can be accessed at any time during a time period when it is intended to be available. Independent sessions: A server is capable of serving a number of clients simultaneously, including from the same piece of content at different points in that presentations time-line. Unicast Transport: Content for each individual client is transmitted to them using unicast traffic. It is also possible to redirect the media traffic to a different destination than that of the agent controlling the traffic. However, allowing this without appropriate mechanisms for checking that the destination approves of this allows for distributed denial of service attacks (DDoS). E.2. Unicast Distribution of Live Content This use case is similar to the above on-demand content case (see Appendix E.1) the difference is the nature of the content itself. Live content is continuously distributed as it becomes available from a source; i.e., the main difference from on-demand is that one starts distributing content before the end of it has become available to the server. In many cases the consumer of live content is only interested in consuming what actually happens "now"; i.e., very similar to broadcast TV. However, in this case it is assumed that there exists no broadcast or multicast channel to the users, and instead the server functions as a distribution node, sending the same content to multiple receivers, using unicast traffic between server and client. This unicast traffic and the transport parameters are individually negotiated for each receiving client. Schulzrinne, et al. Expires October 6, 2013 [Page 283] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Another aspect of live content is that it often has a very limited time of availability, as it is only available for the duration of the event the content covers. An example of such a live content could be a music concert which lasts 2 hour and starts at a predetermined time. Thus there is a need to announce when and for how long the live content is available. In some cases, the server providing live content may be saving some or all of the content to allow clients to pause the stream and resume it from the paused point, or to "rewind" and play continuously from a point earlier than the live point. Hence, this use case does not necessarily exclude playing from other than the live point of the stream, playing with scales other than 1.0, etc. E.3. On-demand Playback using Multicast It is possible to use RTSP to request that media be delivered to a multicast group. The entity setting up the session (the controller) will then control when and what media is delivered to the group. This use case has some potential for denial of service attacks by flooding a multicast group. Therefore, a mechanism is needed to indicate that the group actually accepts the traffic from the RTSP server. An open issue in this use case is how one ensures that all receivers listening to the multicast or broadcast receives the session presentation configuring the receivers. This specification has to rely on an external solution to solve this issue. E.4. Inviting an RTSP server into a conference If one has an established conference or group session, it is possible to have an RTSP server distribute media to the whole group. Transmission to the group is simplest when controlled by a single participant or leader of the conference. Shared control might be possible, but would require further investigation and possibly extensions. This use case assumes that there exists either multicast or a conference focus that redistribute media to all participants. This use case is intended to be able to handle the following scenario: A conference leader or participant (hereafter called the controller) has some pre-stored content on an RTSP server that he wants to share with the group. The controller sets up an RTSP session at the streaming server for this content and retrieves the session description for the content. The destination for the media content is set to the shared multicast group or conference focus. Schulzrinne, et al. Expires October 6, 2013 [Page 284] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 When desired by the controller, he/she can start and stop the transmission of the media to the conference group. There are several issues with this use case that are not solved by this core specification for RTSP: Denial of service: To avoid an RTSP server from being an unknowing participant in a denial of service attack the server needs to be able to verify the destination's acceptance of the media. Such a mechanism to verify the approval of received media does not yet exist; instead, only policies can be used, which can be made to work in controlled environments. Distributing the presentation description to all participants in the group: To enable a media receiver to correctly decode the content the media configuration information needs to be distributed reliably to all participants. This will most likely require support from an external protocol. Passing control of the session: If it is desired to pass control of the RTSP session between the participants, some support will be required by an external protocol to exchange state information and possibly floor control of who is controlling the RTSP session. E.5. Live Content using Multicast This use case in its simplest form does not require any use of RTSP at all; this is what multicast conferences being announced with SAP [RFC2974] and SDP are intended to handle. However, in use cases where more advanced features like access control to the multicast session are desired, RTSP could be used for session establishment. A client desiring to join a live multicasted media session with cryptographic (encryption) access control could use RTSP in the following way. The source of the session announces the session and gives all interested an RTSP URI. The client connects to the server and requests the presentation description, allowing configuration for reception of the media. In this step it is possible for the client to use secured transport and any desired level of authentication; for example, for billing or access control. An RTSP link also allows for load balancing between multiple servers. If these were the only goals, they could be achieved by simply using HTTP. However, for cases where the sender likes to keep track of each individual receiver of a session, and possibly use the session as a side channel for distributing key-updates or other information on a per-receiver basis, and the full set of receivers is not known Schulzrinne, et al. Expires October 6, 2013 [Page 285] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 prior to the session start, the state establishment that RTSP provides can be beneficial. In this case a client would establish an RTSP session for this multicast group with the RTSP server. The RTSP server will not transmit any media, but instead will point to the multicast group. The client and server will be able to keep the session alive for as long as the receiver participates in the session thus enabling, for example, the server to push updates to the client. This use case will most likely not be able to be implemented without some extensions to the server-to-client push mechanism. Here the PLAY_NOTIFY method (see Section 13.5) with a suitable extension could provide clear benefits. Schulzrinne, et al. Expires October 6, 2013 [Page 286] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix F. Text format for Parameters A resource of type "text/parameters" consists of either 1) a list of parameters (for a query) or 2) a list of parameters and associated values (for an response or setting of the parameter). Each entry of the list is a single line of text. Parameters are separated from values by a colon. The parameter name MUST only use US-ASCII visible characters while the values are UTF-8 text strings. The media type registration form is in Section 22.16. There is a potential interoperability issue for this format. It was named in RFC 2326 but never defined, even if used in examples that hint at the syntax. This format matches the purpose and its syntax supports the examples provided. However, it goes further by allowing UTF-8 in the value part, thus usage of UTF-8 strings may not be supported. However, as individual parameters are not defined, the using application anyway needs to have out-of-band agreement or using feature-tag to determine if the end-point supports the parameters. The ABNF [RFC5234] grammar for "text/parameters" content is: file = *((parameter / parameter-value) CRLF) parameter = 1*visible-except-colon parameter-value = parameter *WSP ":" value visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" value = *(TEXT-UTF8char / WSP) TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-FB 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF WSP = <See RFC 5234> ; Space or HTAB VCHAR = <See RFC 5234> CRLF = <See RFC 5234> Schulzrinne, et al. Expires October 6, 2013 [Page 287] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix G. Requirements for Unreliable Transport of RTSP This section provides anyone intending to define how to transport of RTSP messages over a unreliable transport protocol with some information learned by the attempt in RFC 2326 [RFC2326]. RFC 2326 defined both an URI scheme and some basic functionality for transport of RTSP messages over UDP, however, it was not sufficient for reliable usage and successful interoperability. The RTSP scheme defined for unreliable transport of RTSP messages was "rtspu". It has been reserved by this specification as at least one commercial implementation exists, thus avoiding any collisions in the name space. The following considerations should exist for operation of RTSP over an unreliable transport protocol: o Request shall be acknowledged by the receiver. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time (RTT). Any retransmissions due to lack of acknowledgement must carry the same sequence number as the original request. o The round-trip time can be estimated as in TCP (RFC 6298) [RFC6298], with an initial round-trip value of 500 ms. An implementation may cache the last RTT measurement as the initial value for future connections. o The Timestamp header (Section 18.51) is used to avoid the retransmission ambiguity problem [Stevens98]. o The registered default port for RTSP over UDP for the server is 554. o RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean. o RTSP messages are vulnerable to bit errors and should not be subjected to them. o Source authentication, or at least validation that RTSP messages comes from the same entity becomes extremely important, as session hijacking may be substantially easier for RTSP message transport using an unreliable protocol like UDP than for TCP. There are two RTSP headers that are primarily intended for being used by the unreliable handling of RTSP messages and which will be maintained: Schulzrinne, et al. Expires October 6, 2013 [Page 288] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o CSeq: See Section 18.19 o Timestamp: See Section 18.51 Schulzrinne, et al. Expires October 6, 2013 [Page 289] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix H. Backwards Compatibility Considerations This section contains notes on issues about backwards compatibility with clients or servers being implemented according to RFC 2326 [RFC2326]. Note that there exists no requirement to implement RTSP 1.0; in fact we recommend against it as it is difficult to do in an interoperable way. A server implementing RTSP/2.0 MUST include an RTSP-Version of RTSP/2.0 in all responses to requests containing RTSP-Version RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond with an RTSP/1.0 response if it chooses to support RFC 2326. If the server chooses not to support RFC 2326, it MUST respond with a 505 (RTSP Version not supported) status code. A server MUST NOT respond to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 response. Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- Version of 2.0 to determine whether a server supports RTSP/2.0. If the server responds with either an RTSP-Version of 1.0 or a status code of 505 (RTSP Version not supported), the client will have to use RTSP/1.0 requests if it chooses to support RFC 2326. H.1. Play Request in Play State The behavior in the server when a Play is received in Play state has changed (Section 13.4). In RFC 2326, the new PLAY request would be queued until the current Play completed. Any new PLAY request now takes effect immediately replacing the previous request. H.2. Using Persistent Connections Some server implementations of RFC 2326 maintain a one-to-one relationship between a connection and an RTSP session. Such implementations require clients to use a persistent connection to communicate with the server and when a client closes its connection, the server may remove the RTSP session. This is worth noting if a RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. Schulzrinne, et al. Expires October 6, 2013 [Page 290] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix I. Changes This appendix briefly lists the differences between RTSP 1.0 [RFC2326] and RTSP 2.0 for an informational purpose. For implementers of RTSP 2.0 it is recommended to read carefully through this memo and not to rely on the list of changes below to adapt from RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards compatible with RTSP 1.0 [RFC2326] other than the version negotiation mechanism. I.1. Brief Overview The following protocol elements were removed in RTSP 2.0 compared to RTSP 1.0: o there is no section on minimal implementation anymore, but more the definition of RTSP 2.0 core; o the RECORD and ANNOUNCE methods and all related functionality (including 201 (Created) and 250 (Low On Storage Space) status codes); o the use of UDP for RTSP message transport was removed due to missing interest and to broken specification; o the use of PLAY method for keep-alive in Play state. The following protocol elements were added or changed in RTSP 2.0 compared to RTSP 1.0: o RTSP session TEARDOWN from the server to the client; o IPv6 support; o extended IANA registries (e.g., transport headers parameters, transport-protocol, profile, lower-transport, and mode); o request pipelining for quick session start-up; o fully reworked state-machine; o RTSP messages now use URIs rather then URLs; o incorporated much of related HTTP text ([RFC2616]) in this memo, compared to just referencing the sections in HTTP, to avoid ambiguities; Schulzrinne, et al. Expires October 6, 2013 [Page 291] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o the REDIRECT method was expanded and diversified for different situations; o Includes a new section about how to setup different media transport alternatives and their profiles, and lower layer protocols. This caused the appendix on RTP interaction to be moved there instead of being in the part which describes RTP. The section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles; o Added an asynchronous notification method PLAY_NOTIFY. This method is used by the RTSP server to asynchronously notify clients about session changes while in Play state. To a limited extent this is comparable with some implementations of ANNOUNCE in RTSP 1.0 not intended for Recording. I.2. Detailed List of Changes Compared to RTSP 1.0 (RFC 2326), the below changes has been made when defining RTSP 2.0. Note that this list does not reflect minor changes in wording or correction of typographical errors. o The section on minimal implementation was deleted without substitution. o The Transport header has been changed in the following way: * The ABNF has been changed to define that extensions are possible, and that unknown parameters result in that servers ignore the transport specification. * To prevent backwards compatibility issues, any extension or new parameter requires the usage of a feature-tag combined with the Require header. * Syntax unclarities with the Mode parameter have been resolved. * Syntax error with ";" for multicast and unicast has been resolved. * Two new addressing parameters have been defined, src_addr and dest_addr. These replace the parameters "port", "client_port", "server_port", "destination", "source". * Support for IPv6 explicit addresses in all address fields has been included. Schulzrinne, et al. Expires October 6, 2013 [Page 292] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 * To handle URI definitions that contain ";" or "," a quoted URI format has been introduced and is required. * Defined IANA registries for the transport headers parameters, transport-protocol, profile, lower-transport, and mode. * The transport headers interleaved parameter's text was made more strict and uses formal requirements levels. It was also clarified that the interleaved channels are symmetric and that it is the server that sets the channel numbers. * It has been clarified that the client can't request of the server to use a certain RTP SSRC, using a request with the transport parameter SSRC. * Syntax definition for SSRC has been clarified to require 8HEX. It has also been extended to allow multiple values for clients supporting this version. * Clarified the text on the transport headers "dest_addr" parameters regarding what security precautions the server is required to perform. o The Range formats has been changed in the following way: * The NPT format has been given an initial NPT identifier that must now be used. * All formats now support initial open ended formats of type "npt=-10" and also format only "Range: smpte" ranges for usage with GET_PARAMETER requests. o RTSP message handling has been changed in the following way: * RTSP messages now use URIs rather then URLs. * It has been clarified that a 4xx message due to missing CSeq header shall be returned without a CSeq header. * The 300 (Multiple Choices) response code has been removed. * Rules for how to handle timing out RTSP messages has been added. * Extended Pipelining rules allowing for quick session startup. Schulzrinne, et al. Expires October 6, 2013 [Page 293] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o The HTTP references have been updated to RFC 2616 and RFC 2617. Most of the text has been copied and then altered to fit RTSP into this specification. Public, and the Content-Base header has also been imported from RFC 2068 so that they are defined in the RTSP specification. Known effects on RTSP due to HTTP clarifications: * Content-Encoding header can include encoding of type "identity". o The state machine section has been completely rewritten. It now includes more details and is also more clear about the model used. o An IANA section has been included which contains a number of registries and their rules. This will allow us to use IANA to keep track of RTSP extensions. o The transport of RTSP messages has seen the following changes: * The use of UDP for RTSP message transport has been deprecated due to missing interest and to broken specification. * The rules for how TCP connections are to be handled has been clarified. Now it is made clear that servers should not close the TCP connection unless they have been unused for significant time. * Strong recommendations why server and clients should use persistent connections have also been added. * There is now a requirement on the servers to handle non- persistent connections as this provides fault tolerance. * Added wording on the usage of Connection:Close for RTSP. * Specified usage of TLS for RTSP messages, including a scheme to approve a proxy's TLS connection to the next hop. o The following header related changes have been made: * Accept-Ranges response header is added. This header clarifies which range formats that can be used for a resource. * Fixed the missing definitions for the Cache-Control header. Also added to the syntax definition the missing delta-seconds for max-stale and min-fresh parameters. * Put requirement on CSeq header that the value is increased by one for each new RTSP request. A Recommendation to start at 0 Schulzrinne, et al. Expires October 6, 2013 [Page 294] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 has also been added. * Added requirement that the Date header must be used for all messages with message body and the Server should always include it. * Removed possibility of using Range header with Scale header to indicate when it is to be activated, since it can't work as defined. Also added rule that lack of Scale header in response indicates lack of support for the header. Feature-tags for scaled playback has been defined. * The Speed header must now be responded to indicate support and the actual speed going to be used. A feature-tag is defined. Notes on congestion control were also added. * The Supported header was borrowed from SIP [RFC3261] to help with the feature negotiation in RTSP. * Clarified that the Timestamp header can be used to resolve retransmission ambiguities. * The Session header text has been expanded with an explanation on keep alive and which methods to use. SET_PARAMETER is now recommended to use if only keep-alive within RTSP is desired. * It has been clarified how the Range header formats are used to indicate pause points in the PAUSE response. * Clarified that RTP-Info URIs that are relative, use the Request-URI as base URI. Also clarified that the used URI must be the one that was used in the SETUP request. The URIs are now also required to be quoted. The header also expresses the SSRC for the provided RTP timestamp and sequence number values. * Added text that requires the Range to always be present in PLAY responses. Clarified what should be sent in case of live streams. * The headers table has been updated using a structure borrowed from SIP. Those tables convey much more information and should provide a good overview of the available headers. * It has been clarified that any message with a message body is required to have a Content-Length header. This was the case in RFC 2326, but could be misinterpreted. Schulzrinne, et al. Expires October 6, 2013 [Page 295] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 * ETag has changed name to MTag. * To resolve functionality around MTag. The MTag and If-None- Match header have been added from HTTP with necessary clarification in regards to RTSP operation. * Imported the Public header from HTTP RFC 2068 [RFC2068] since it has been removed from HTTP due to lack of use. Public is used quite frequently in RTSP. * Clarified rules for populating the Public header so that it is an intersection of the capabilities of all the RTSP agents in a chain. * Added the Media-Range header for listing the current availability of the media range. * Added the Notify-Reason header for giving the reason when sending PLAY_NOTIFY requests. * A new header Seek-Style has been defined to direct and inform how any seek operation should/have been performed. o The Protocol Syntax has been changed in the following way: * All ABNF definitions are updated according to the rules defined in RFC 5234 [RFC5234] and have been gathered in a separate Section 20. * The ABNF for the User-Agent and Server headers have been corrected. * Some definitions in the introduction regarding the RTSP session have been changed. * The protocol has been made fully IPv6 capable. * The CHAR rule has been changed to exclude NULL. o The Status codes have been changed in the following way: * The use of status code 303 "See Other" has been deprecated as it does not make sense to use in RTSP. * When sending response 451 and 458 the response body should contain the offending parameters. Schulzrinne, et al. Expires October 6, 2013 [Page 296] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 * Clarification on when a 3rr redirect status code can be received has been added. This includes receiving 3rr as a result of a request within a established session. This provides clarification to a previous unspecified behavior. * Removed the 201 (Created) and 250 (Low On Storage Space) status codes as they are only relevant to recording, which is deprecated. * Several new Status codes have been defined: 464 "Data Transport Not Ready Yet", 465 "Notification Reason Unknown", 470 "Connection Authorization Required", 471 "Connection Credentials not accepted", 472 "Failure to establish secure connection". o The following functionality has been deprecated from the protocol: * The use of Queued Play. * The use of PLAY method for keep-alive in Play state. * The RECORD and ANNOUNCE methods and all related functionality. Some of the syntax has been removed. * The possibility to use timed execution of methods with the time parameter in the Range header. * The description on how rtspu works is not part of the core specification and will require external description. Only that it exists is defined here and some requirements for the transport is provided. o The following changes have been made in relation to methods: * The OPTIONS method has been clarified with regards to the use of the Public and Allow headers. * Added text clarifying the usage of SET_PARAMETER for keep-alive and usage without any body. * PLAY method is now allowed to be pipelined with the pipelining of one or more SETUP requests following the initial that generates the session for aggregated control. * REDIRECT has been expanded and diversified for different situations. Schulzrinne, et al. Expires October 6, 2013 [Page 297] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 * Added a new method PLAY_NOTIFY. This method is used by the RTSP server to asynchronously notify clients about session changes. o Wrote a new section about how to setup different media transport alternatives and their profiles, and lower layer protocols. This caused the appendix on RTP interaction to be moved there instead of being in the part which describes RTP. The section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles. o Setup and usage of independent TCP connections for transport of RTP has been specified. o Added a new section describing the available mechanisms to determine if functionality is supported, called "Capability Handling". Renamed option-tags to feature-tags. o Added a contributors section with people who have contributed actual text to the specification. o Added a section Use Cases that describes the major use cases for RTSP. o Clarified the usage of a=range and how to indicate live content that are not seekable with this header. o Text specifying the special behavior of PLAY for live content. Schulzrinne, et al. Expires October 6, 2013 [Page 298] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix J. Acknowledgements This memorandum defines RTSP version 2.0 which is a revision of the Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert Lanphier. Both RTSP version 1.0 and RTSP version 2.0 borrow format and descriptions from HTTP/1.1. This document has benefited greatly from the comments of all those participating in the MMUSIC-WG. In addition to those already mentioned, the following individuals have contributed to this specification: Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick Hoffman, Jinhang Choi, Ross Finlayson, Dale R. Worley, and especially to Flemming Andreasen. J.1. Contributors The following people have made written contributions that were included in the specification: o Tom Marshall contributed text on the usage of 3rr status codes. o Thomas Zheng contributed text on the usage of the Range in PLAY responses and proposed an earlier version of the PLAY_NOTIFY method. o Sean Sheedy contributed text on the timeout behavior of RTSP messages and connections, the 463 status code, and proposed an earlier version of the PLAY_NOTIFY method. o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY method. Schulzrinne, et al. Expires October 6, 2013 [Page 299] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 o Fredrik Lindholm contributed text about the RTSP security framework. o John Lazzaro contributed the text for RTP over Independent TCP. o Aravind Narasimhan contributed by rewriting Media Transport Alternatives (Appendix C) and editorial improvements on a number of places in the specification. o Torbjorn Einarsson has done some editorial improvements of the text. Schulzrinne, et al. Expires October 6, 2013 [Page 300] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Appendix K. RFC Editor Consideration Please replace RFC XXXX with the RFC number this specification receives. Schulzrinne, et al. Expires October 6, 2013 [Page 301] Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) April 2013 Authors' Addresses Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Anup Rao Cisco USA Email: anrao@cisco.com Rob Lanphier Seattle, WA USA Email: robla@robla.net Magnus Westerlund Ericsson AB Faeroegatan 6 STOCKHOLM, SE-164 80 SWEDEN Email: magnus.westerlund@ericsson.com Martin Stiemerling NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 113 Email: martin.stiemerling@neclab.eu URI: http://ietf.stiemerling.org Schulzrinne, et al. Expires October 6, 2013 [Page 302]