RFC7826: Real-Time Streaming Protocol¶
Obsoletes:
rfc2326Category: Standards Track
December 2016
RTSP协议提供了一种可靠、高效的控制协议，可以控制实时媒体流的传输，并且具有良好的可扩展性，可以适应不同的应用场景。
其核心要点如下:
客户端/服务器架构：RTSP协议采用客户端/服务器架构，客户端可以控制服务器上的媒体流，并向服务器请求媒体流的传输。
媒体流的描述：RTSP协议允许客户端获取媒体流的描述信息，例如媒体类型、编码格式、码率等。
支持会话：RTSP协议支持会话管理，可以通过建立、修改和终止会话来控制媒体流的传输。
控制命令和状态码：RTSP协议定义了一组控制命令和状态码，用于控制媒体流的传输，例如PLAY、PAUSE、STOP等命令。
可扩展性：RTSP协议具有良好的可扩展性，可以通过定义新的控制命令和状态码来满足不同应用场景下的需求。
总的来说，RTSP协议提供了一种可靠、高效的控制协议，可以控制实时媒体流的传输，并且具有良好的可扩展性，可以适应不同的应用场景。
It defines the RTSP 2.0 protocol, which is an application-layer protocol used for controlling the delivery of media data over the Internet.
It supports a wide range of media formats and delivery methods, including live streaming and video-on-demand.
It provides a flexible and extensible framework for controlling the delivery of media data, including support for advanced features such as server push and client pull.
It includes support for authentication and encryption to ensure secure and private communication between clients and servers.
It defines a number of new RTSP methods, headers, and response codes to support the new features and capabilities of the RTSP 2.0 protocol.
Abstract¶
RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties.
RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video.
Sources of data can include both live data feeds and stored clips.
This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP
1. Introduction¶
RTSP acts as a “network remote control” for multimedia servers.
The protocol operates between RTSP 2.0 clients and servers, but it also supports the use of proxies placed between clients and servers.
Clients can request information about streaming media from servers by asking for a description of the media or use media description provided externally.
The media delivery protocol is used to establish the media streams described by the media description.
Clients can then request to play out the media, pause it, or stop it completely.
The requested media can consist of multiple audio and video streams that are delivered as time-synchronized streams from servers to clients.
This protocol is based on RTSP 1.0 but is not backwards compatible other than in the basic version negotiation mechanism.
2. Protocol Overview¶
RTSP 2.0 is a bidirectional request and response protocol that first establishes a context including content resources (the media) and then controls the delivery of these content resources from the provider to the consumer.
RTSP has three fundamental parts:
Session Establishment, Media Delivery Control, an extensibility model described below.
The protocol is based on some assumptions about existing functionality to provide a complete solution for client-controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may contain a binary message body.
RTSP 2.0 requires clients and servers to implement TCP and TLS over TCP as mandatory transports for RTSP messages.
2.1. Presentation Description¶
RTSP exists to provide access to multimedia presentations and content but tries to be agnostic about the media type or the actual media delivery protocol that is used.
To enable a client to implement a complete system, an RTSP-external mechanism for describing the presentation and the delivery protocol(s) is used.
RTSP assumes that this description is either delivered completely out of band or as a data object in the response to a client’s request using the DESCRIBE method (Section 13.2).
Parameters that commonly have to be included in the presentation description are the following:
1. The number of media streams
2. the resource identifier for each media stream/resource that is to be controlled by RTSP
3. the protocol that will be used to deliver each media stream
4. the transport protocol parameters that are not negotiated or vary with each client
5. the media-encoding information enabling a client to correctly decode the media upon reception
6. an aggregate control resource identifier
2.2. Session Establishment¶
The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of the media streams.
The RTSP session is a common context between the client and the server that consists of one or more media resources that are to be under common media delivery control.
The client creates an RTSP session by sending a request using the SETUP method (Section 13.3) to the server.
2.3. Media Delivery Control¶
The basic operations are “begin playback”, using the PLAY method (Section 13.4) and “suspend (pause) playback” by using the PAUSE method (Section 13.6).
several different time formats:
1. Normal Play Time (NPT) (Section 4.4.2),
2. Society of Motion Picture and Television Engineers (SMPTE) Timestamps (Section 4.4.1),
3. absolute time (Section 4.4.3)
The support for positioning/searching within media content depends on the content’s media properties.
The properties applicable for the RTSP session are provided by the server in the SETUP response using the Media-Properties header (Section 18.29).
Content exists in a number of different types, such as:
on-demand,
live,
live with simultaneous recording
2.4. Session Parameter Manipulations¶
A session may have additional state or functionality that affects how the server or client treats the session or content, how it functions, or feedback on how well the session works.
Such extensions are not defined in this specification, but they may be covered in various extensions.
RTSP has two methods for retrieving and setting parameter values on either the client or the server: GET_PARAMETER (Section 13.8) and SET_PARAMETER (Section 13.9).
2.5. Media Delivery¶
This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC768], TCP [RFC793], or the RTSP connection.
2.5.1. Media Delivery Manipulations¶
RTSP is a protocol that enables the delivery of requested content to the client at the pace intended by the content’s creator.
However, RTSP can also manipulate the delivery to the client in two ways:
1. Scale: The ratio of media-content time delivered per unit of playback time. => media-content time / playback time 2. Speed: The ratio of playback time delivered per unit of wallclock time. => playback time / wallclock time
备注
Both affect the media delivery per time unit. However, they manipulate two independent timescales and the effects are possible to combine.
Scale¶
Scale (Section 18.46)
Scale = 1.0 is the default value that is used if no scale is specified, i.e., playback at the content’s original rate.
Scale > 1.0, means fast forward, e.g., scale = 2.0 results in that 2 seconds of content being played back every second of playback.
Scale values between 0 and 1.0 provide for slow motion.
Scale can be negative to allow for reverse playback in either regular pace (scale = -1.0), fast backwards (scale < -1.0), or slow-motion backwards (-1.0 < scale < 0).
Scale = 0 would be equal to pause and is not allowed.
备注
In most cases, the realization of scale means server-side manipulation of the media to ensure that the client can actually play it back. The nature of these media manipulations and when they are needed is highly media-type dependent.
For audio, it is very difficult to modify the playback rate.
Typically, no more than a factor of two is possible while maintaining intelligibility by changing the pitch and rate of speech.
Music goes out of tune if one tries to manipulate the playback rate by resampling it.
This is a well-known problem, and audio is commonly muted or played back in short segments with skips to keep up with the current playback point.
For video, it is possible to manipulate the frame rate
Speed¶
Speed (Section 18.50)
Speed = 1(default) which means to deliver at the same rate the media is consumed.
Speed > 1 means that the receiver will get content faster than it regularly would consume it.
Speed < 1 means that delivery is slower than the regular media rate.
Speed values of 0 or lower have no meaning and are not allowed.
2.6. Session Maintenance and Termination¶
The session context that has been established is kept alive by having the client show liveness. This is done in two main ways:
1. Media-transport protocol keep-alive.
RTP Control Protocol (RTCP) may be used when using RTP.
2. Any RTSP request referencing the session context.
If the client fails to show liveness for more than the established session timeout value (normally 60 seconds), the server may terminate the context.
The session context is normally terminated by the client sending a
TEARDOWNrequest (Section 13.7) to the server referencing the aggregated control URI.An individual media resource can be removed from a session context by a TEARDOWN request referencing that particular media resource.
If all media resources are removed from a session context, the session context is terminated
It is recommended that the client terminate the session before ten times the session timeout value has passed.
A server may terminate the session after one session timeout period without any client activity beyond keep-alive.
2.7. Extending RTSP¶
RTSP is quite a versatile protocol that supports extensions in many different directions.
The RTSP, in itself, can be extended in three ways:
1. Existing methods can be extended with new parameters
2. New methods can be added
3. A new version of the protocol can be defined
3. Document Conventions¶
3.2. Terminology¶
Aggregate control: The concept of controlling multiple streams using a single timeline, generally one maintained by the server.【示例】A client uses aggregate control when it issues a single play or pause message to simultaneously control both the audio and video in a movie.
Aggregated session: A session that is under aggregate control is referred to as an “aggregated session”.
Aggregate control URI: The URI used in an RTSP request to refer to and control an aggregated session.
Non-aggregated control: Control of a single media stream.
IRI: An Internationalized Resource Identifier is similar to a URI but allows characters from the whole Universal Character Set (Unicode/ISO 10646), rather than the US-ASCII only.
4. Protocol Parameters¶
4.1. RTSP Version¶
<major>.<minor>
例:
RTSP/2.13
4.2. RTSP IRI and URI¶
three URI schemes:
1. rtsp
port: 554
2. rtsps
port: 322
3. rtspu
indicates unspecified transport of the RTSP messages over unreliable transport means (UDP in RTSP 1.0)
RTSP URI:
rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister"
rtsp://media.example.com:554/twister
may be composed of audio and video streams,
but could also be something else, such as a random media redirector.
4.3. Session Identifiers¶
Session identifiers are strings of a length between 8-128 characters.
4.4. Media-Time Formats¶
RTSP currently supports three different media-time formats defined below.
4.4.1. SMPTE-Relative Timestamps¶
A timestamp may use a format derived from a Society of Motion Picture and Television Engineers (SMPTE) specification and expresses time offsets anchored at the start of the media clip.
Relative timestamps are expressed as SMPTE time codes [SMPTE-TC] for frame-level access accuracy.
The time code has the format:
hours:minutes:seconds:frames.subframes
The default SMPTE format is “SMPTE 30 drop” format, with a frame rate of 29.97 frames per second.
For SMPTE 30, the “frames” field in the time value can assume the values 0 through 29.
The difference between 30 and 29.97 frames per second is handled by dropping the first two frame indices (values 00 and 01) of every minute, except every tenth minute.
If the frame and the subframe values are zero, they may be omitted.
Subframes are measured in hundredths of a frame.
Examples:
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
Other SMPTE codes MAY be supported (such as “SMPTE 25”) through the use of “smpte-type”
smpte-25=10:07:00-10:07:33:05.01
4.4.2. Normal Play Time¶
Normal Play Time (NPT) indicates the stream-absolute position relative to the beginning of the presentation.
The timestamp consists of two parts:
The mandatory first part may be expressed in either seconds only or in hours, minutes, and seconds.
The optional second part consists of a decimal point and decimal figures and indicates fractions of a second.
The special constant “now” is defined as the current instant of a live event. It MAY only be used for live events and MUST NOT be used for on-demand (i.e., non-live) content.
Examples:
npt=123.45-125 npt=12:05:35.3- npt=now-
In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds MUST all be present, with two digits used for minutes and for seconds and with at least two digits for hours.
An NPT of 7 minutes and 0 seconds is represented as “00:07:00”, and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as “392:00:06”.
4.4.3. Absolute Time¶
Absolute time is expressed using a timestamp based on ISO 8601 [ISO.8601.2000].
Below are three examples of media time formats:
clock=19961108T143720.25Z-19961108T144725.25Z: a request for a clock format range request for a starting time of November 8, 1996 at 14 h 37 min and 20 1/4 seconds UTC playing for 10 min and 5 secondsTime-Limited=20141224T1500Z: a Media-Properties header’s “Time-Limited” UTC property for the 24th of December 2014 at 15 hours and 00 minutestime=20130618T161256Z: a Terminate-Reason header “time” property for the 18th of June 2013 at 16 hours, 12 minutes, and 56 seconds
4.7. Media Properties¶
When an RTSP server handles media, it is important to consider the different properties a media instance for delivery and playback can have.
They are derived from the differences between a number of supported usages:
1. On-demand: 2. Dynamic On-demand: 3. Live: 4. Live with Recording:
4.7.1. Random Access and Seeking¶
Random access is the ability to specify and get media delivered starting from any time (instant) within the content, an operation called “seeking”.
The Media-Properties header will indicate the general capability for a media resource to perform random access:
1. Random-Access 2. Beginning-Only 3. No-Seeking
4.7.2. Retention¶
The following retention policies are used by media to limit possible protocol operations:
1. Unlimited: The media will not be removed as long as the RTSP session is in existence
2. Time-Limited: The media will not be removed before the given wallclock time.
3. Time-Duration: The media (on fragment or unit basis) will be retained for the specified duration.
4.7.3. Content Modifications¶
media property for content modifications is needed and the following initial values are defined:
1. Immutable
2. Dynamic
3. Time-Progressing
4.7.4. Supported Scale Factors¶
The attribute is named “Scales”.
4.7.5. Mapping to the Attributes¶
This section shows examples of how one would map the above usages to the properties and their values.
Example of On-Demand:
Random Access: Random-Access=5.0,
Content Modifications: Immutable,
Retention: Unlimited or Time-Limited.
Example of Dynamic On-Demand:
Random Access: Random-Access=3.0,
Content Modifications: Dynamic,
Retention: Unlimited or Time-Limited.
Example of Live:
Random Access: No-Seeking,
Content Modifications: Time-Progressing,
Retention: Time-Duration=0.0
Example of Live with Recording:
Random Access: Random-Access=3.0,
Content Modifications: Time-Progressing,
Retention: Time-Duration=7200.0
5. RTSP Message¶
RTSP is a text-based protocol that uses the ISO 10646 character set in UTF-8 encoding
5.1. Message Types¶
RTSP messages are either requests from client to server or from server to client, and responses in the reverse direction.
Both types of messages consist of:
1. a start-line,
2. zero or more header fields (also known as "headers"),
3. an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the headers,
4. possibly the data of the message body.
ABNF:
generic-message = start-line
*(rtsp-header CRLF)
CRLF
[ message-body-data ]
start-line = Request-Line / Status-Line
5.2. Message Headers¶
RTSP header fields (see Section 18) include:
1. general-header, 2. request-header, 3. response-header, 4. message body header fields.
5.3. Message Body¶
The message body (if any) of an RTSP message is used to carry further information for a particular resource associated with the request or response.
An example of a message body is an SDP message.
5.4. Message Length¶
An RTSP message that does not contain any message body is terminated by the first empty line after the header fields
The length of that body is determined by the value of the
Content-Lengthheader
6. General-Header Fields¶
The general-headers are listed in Table 1:
+--------------------+----------------+
| Header Name | Defined in |
+--------------------+----------------+
| Accept-Ranges | Section 18.5 |
| | |
| Cache-Control | Section 18.11 |
| | |
| Connection | Section 18.12 |
| | |
| CSeq | Section 18.20 |
| | |
| Date | Section 18.21 |
| | |
| Media-Properties | Section 18.29 |
| | |
| Media-Range | Section 18.30 |
| | |
| Pipelined-Requests | Section 18.33 |
| | |
| Proxy-Supported | Section 18.38 |
| | |
| Range | Section 18.40 |
| | |
| RTP-Info | Section 18.45 |
| | |
| Scale | Section 18.46 |
| | |
| Seek-Style | Section 18.47 |
| | |
| Server | Section 18.48 |
| | |
| Session | Section 18.49 |
| | |
| Speed | Section 18.50 |
| | |
| Supported | Section 18.51 |
| | |
| Timestamp | Section 18.53 |
| | |
| Transport | Section 18.54 |
| | |
| User-Agent | Section 18.56 |
| | |
| Via | Section 18.57 |
+--------------------+----------------+
7. Request¶
A request message uses the format outlined below regardless of the direction of a request, whether client to server or server to client:
1. Request line,
containing:
the method to be applied to the resource,
the identifier of the resource,
the protocol version in use;
2. Zero or more Header lines,
which can be of the following types:
general-headers (Section 6),
request-headers (Section 7.2),
message body headers (Section 9.1);
3. One empty line (CRLF)
to indicate the end of the header section;
4. Optionally, a message body,
consisting of one or more lines.
The length of the message body in octets is indicated by the Content- Length message header.
7.1. Request Line¶
The syntax of the RTSP request line has the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
The methods that are defined by this specification are listed in Table 2:
+---------------+----------------+
| Method | Defined in |
+---------------+----------------+
| DESCRIBE | Section 13.2 |
| | |
| GET_PARAMETER | Section 13.8 |
| | |
| OPTIONS | Section 13.1 |
| | |
| PAUSE | Section 13.6 |
| | |
| PLAY | Section 13.4 |
| | |
| PLAY_NOTIFY | Section 13.5 |
| | |
| REDIRECT | Section 13.10 |
| | |
| SETUP | Section 13.3 |
| | |
| SET_PARAMETER | Section 13.9 |
| | |
| TEARDOWN | Section 13.7 |
+---------------+----------------+
An asterisk “*” can be used instead of an absolute URI in the Request-URI part to indicate that the request does not apply to a particular resource but to the server or proxy itself, and is only allowed when the request method does not necessarily apply to a resource:
For example: OPTIONS * RTSP/2.0
7.2. Request-Header Fields¶
+---------------------+----------------+
| Header | Defined in |
+---------------------+----------------+
| Accept | Section 18.1 |
| | |
| Accept-Credentials | Section 18.2 |
| | |
| Accept-Encoding | Section 18.3 |
| | |
| Accept-Language | Section 18.4 |
| | |
| Authorization | Section 18.8 |
| | |
| Bandwidth | Section 18.9 |
| | |
| Blocksize | Section 18.10 |
| | |
| From | Section 18.23 |
| | |
| If-Match | Section 18.24 |
| | |
| If-Modified-Since | Section 18.25 |
| | |
| If-None-Match | Section 18.26 |
| | |
| Notify-Reason | Section 18.32 |
| | |
| Proxy-Authorization | Section 18.36 |
| | |
| Proxy-Require | Section 18.37 |
| | |
| Referrer | Section 18.41 |
| | |
| Request-Status | Section 18.42 |
| | |
| Require | Section 18.43 |
| | |
| Terminate-Reason | Section 18.52 |
+---------------------+----------------+
8. Response¶
8.1. Status-Line¶
<RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
Status Code and Reason Phrase(Table 4: Status Codes and Their Usage with RTSP Methods):
+------+---------------------------------+--------------------------+
| Code | Reason | Method |
+------+---------------------------------+--------------------------+
| 100 | Continue | all |
| | | |
| 200 | OK | all |
| | | |
| 301 | Moved Permanently | all |
| 302 | Found | all |
| 303 | See Other | n/a |
| 304 | Not Modified | all |
| 305 | Use Proxy | all |
| | | |
| 400 | Bad Request | all |
| 401 | Unauthorized | all |
| 402 | Payment Required | all |
| 403 | Forbidden | all |
| 404 | Not Found | all |
| 405 | Method Not Allowed | all |
| 406 | Not Acceptable | all |
| 407 | Proxy Authentication Required | all |
| 408 | Request Timeout | all |
| 410 | Gone | all |
| 412 | Precondition Failed | DESCRIBE, SETUP |
| 413 | Request Message Body Too Large | all |
| 414 | Request-URI Too Long | all |
| 415 | Unsupported Media Type | all |
| 451 | Parameter Not Understood | SET_PARAMETER, GET_PARAMETER |
| 452 | reserved | n/a |
| 453 | Not Enough Bandwidth | SETUP |
| 454 | Session Not Found | all |
| 455 | Method Not Valid in This State | all |
| 456 | Header Field Not Valid | all |
| 457 | Invalid Range | PLAY, PAUSE |
| 458 | Parameter Is Read-Only | SET_PARAMETER |
| 459 | Aggregate Operation Not Allowed | all |
| 460 | Only Aggregate Operation Allowed| all |
| 461 | Unsupported Transport | all |
| 462 | Destination Unreachable | all |
| 463 | Destination Prohibited | SETUP |
| 464 | Data Transport Not Ready Yet | PLAY |
| 465 | Notification Reason Unknown | PLAY_NOTIFY |
| 466 | Key Management Error | all |
| 470 |Connection Authorization Required| all |
| 471 |Connection Credentials Not Accept| all |
| 472 | Failure to Establish Secure Conn| all |
| | | |
| 500 | Internal Server Error | all |
| 501 | Not Implemented | all |
| 502 | Bad Gateway | all |
| 503 | Service Unavailable | all |
| 504 | Gateway Timeout | all |
| 505 | RTSP Version Not Supported | all |
| 551 | Option Not Supported | all |
| 553 | Proxy Unavailable | all |
+------+---------------------------------+--------------------------+
8.2. Response Headers¶
The RTSP Response Headers(Table 5: The RTSP Response Headers):
+------------------------+----------------+
| Header | Defined in |
+------------------------+----------------+
| Authentication-Info | Section 18.7 |
| | |
| Connection-Credentials | Section 18.13 |
| | |
| Location | Section 18.28 |
| | |
| MTag | Section 18.31 |
| | |
| Proxy-Authenticate | Section 18.34 |
| | |
| Public | Section 18.39 |
| | |
| Retry-After | Section 18.44 |
| | |
| Unsupported | Section 18.55 |
| | |
| WWW-Authenticate | Section 18.58 |
+------------------------+----------------+
9. Message Body¶
9.1. Message Body Header Fields¶
The RTSP Message Body Headers:
+------------------+----------------+
| Header | Defined in |
+------------------+----------------+
| Allow | Section 18.6 |
| | |
| Content-Base | Section 18.14 |
| | |
| Content-Encoding | Section 18.15 |
| | |
| Content-Language | Section 18.16 |
| | |
| Content-Length | Section 18.17 |
| | |
| Content-Location | Section 18.18 |
| | |
| Content-Type | Section 18.19 |
| | |
| Expires | Section 18.22 |
| | |
| Last-Modified | Section 18.27 |
+------------------+----------------+
9.2. Message Body¶
An RTSP message with a message body MUST include the Content-Type and Content-Length headers.
9.3. Message Body Format Negotiation¶
The content format of the message body is provided using the Content-Type header
10. Connections¶
RTSP requests can be transmitted using the two different connection scenarios listed below:
1. persistent - a transport connection is used for several request/response transactions;
2. transient - a transport connection is used for each single request/response transaction.
10.1. Reliability and Acknowledgements¶
Since RTSP messages are transmitted using reliable transport protocols, they MUST NOT be retransmitted at the RTSP level.
Instead, the implementation must rely on the underlying transport to provide reliability.
10.2. Using Connections¶
A TCP transport can be used for both persistent connections (for several message exchanges) and transient connections (for a single message exchange).
Implementations of this specification MUST support RTSP over TCP.
The registered default ports: 554(rtsp), 322(rtsps), 8554(alternative)
A server MUST handle both persistent and transient connections.
10.3. Closing Connections¶
The client MAY close a connection at any point when no outstanding request/response transactions exist for any RTSP session being managed through the connection.
The server, however, SHOULD NOT close a connection until all RTSP sessions being managed through the connection have been timed out (Section 18.49).
A server SHOULD NOT close a connection immediately after responding to a session-level TEARDOWN request for the last RTSP session being controlled through the connection.
10.4. Timing Out Connections and RTSP Messages¶
A responder SHOULD respond to all requests within 5 seconds.
A requester SHOULD wait at least 10 seconds for a response before concluding that the responder will not be responding to its request.
10.5. Showing Liveness¶
RTSP requires the client to periodically show its liveness to the server or the server may terminate any session state.
10.6. Use of IPv6¶
RTSP 2.0 has been updated for explicit IPv6 support.
10.7. Overload Control¶
Overload in RTSP can occur when servers and proxies have insufficient resources to complete the processing of a request.
11. Capability Handling¶
This section describes the available capability-handling mechanism that allows RTSP to be extended.
Extensions to this version of the protocol are basically done in two ways.
Firstly, new headers can be added.
Secondly, new methods can be added.
12. Pipelining Support¶
Pipelining is a general method to improve performance of request/response protocols by allowing the requesting agent to have more than one request outstanding and to send them over the same persistent connection.
13. Method Definitions¶
The method indicates what is to be performed on the resource identified by the Request-URI.
13.1. OPTIONS¶
The semantics of the RTSP OPTIONS method is similar to that of the HTTP OPTIONS method
Example:
C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages
Supported: play.basic
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1
13.2. DESCRIBE¶
The DESCRIBE method is used to retrieve the description of a presentation or media object from a server.
Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient/1.2
Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp
Content-Length: 358
v=0
o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
c=IN IP4 0.0.0.0
a=control:*
t=2873397496 2873404696
m=audio 3456 RTP/AVP 0
a=control:audio
m=video 2232 RTP/AVP 31
a=control:video
There are three ways that an RTSP client may receive initialization information:
- via an RTSP DESCRIBE request
- via some other protocol (HTTP, email attachment, etc.)
- via some form of user interface
13.3. SETUP¶
The description below uses the following states in a protocol state machine that is related to a specific session when that session has been created.
The state transitions are driven by protocol interactions.
For additional information about the state machine:
1. Init: Initial state. No session exists.
2. Ready: Session is ready to start playing.
3. Play: Session is playing, i.e., sending media-stream data in the direction S->C.
A basic example for SETUP:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: npt
Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0
Media-Range: npt=0-2893.23
13.4. PLAY¶
13.4.1. General Usage¶
The PLAY method tells the server to start sending data via the mechanism specified in SETUP and which part of the media should be played out.
PLAY requests are valid when the session is in Ready or Play state.
A PLAY request MUST include a Session header to indicate to which session the request applies.
The example below will play seconds 10 through 25:
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835
Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=10-25
Seek-Style: RAP
User-Agent: PhonyClient/1.2
Example for a single audio stream where the client requests the media starting from 3.52 seconds and to the end. The server sends a 200 OK response with the actual play time, which is 10 ms prior (3.51), and the RTP-Info header that contains the necessary parameters for the RTP stack.:
C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=3.52-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Range: npt=3.51-324.39
Seek-Style: First-Prior
Session: ULExwZCXh2pd0xuFgkgZJW
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.51
Media duration=0.16 seconds
In most cases, it is probably most suitable not to render that time period:
C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=7.05-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=3.52-
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds
13.4.2. Aggregated Sessions¶
PLAY requests can operate on sessions controlling a single media stream and on aggregated sessions controlling multiple media streams.
In an aggregated session, the PLAY request MUST contain an aggregated control URI.
13.4.3. Updating Current PLAY Requests¶
Clients can issue PLAY requests while the stream is in Play state and thus updating their request.
【Example】The server has received requests to play ranges 10 to 15. If the new PLAY request arrives at the server 4 seconds after the previous one, it will take effect while the server still plays the first range (10-15). The server changes the current play to continue to 25 seconds, i.e., the equivalent single request would be PLAY with “range: npt=10-25”:
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=10-15
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=-25
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=14-25
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
13.4.4. Playing On-Demand Media¶
On-demand media is indicated by the content of the Media-Properties(Section 18.29) header in the SETUP response when:
the Random Access property is set to Random-Access;
the Content Modifications property is set to Immutable;
the Retention property is set to Unlimited or Time-Limited.
13.4.5. Playing Dynamic On-Demand Media¶
Dynamic on-demand media is indicated by the content of the Media-Properties(Section 18.29) header in the SETUP response when:
the Random Access property is set to Random-Access;
the Content Modifications property is set to Dynamic;
the Retention property is set to Unlimited or Time-Limited.
13.4.6. Playing Live Media¶
Live media is indicated by the content of the Media-Properties header in the SETUP response when:
- the `Random Access` property is set to `No-Seeking`;
- the `Content Modifications` property is set to `Time-Progressing`;
- the `Retention` property's Time-Duration is set to 0.0.
13.4.7. Playing Live with Recording¶
This live media is indicated by the content of the Media-Properties header in the SETUP response when:
- the `Random Access` property is set to `Random-Access`;
- the `Content Modifications` property is set to `Time-Progressing`;
- the `Retention` property is set to `Time-Limited` or `Unlimited`
13.4.8. Playing Live with Time-Shift¶
This live media is indicated by the content of the Media-Properties header in the SETUP response when:
- the `Random Access` property is set to `Random-Access`;
- the `Content Modifications` property is set to `Time-Progressing`;
- the `Retention` property is set to Time-Duration and a value indicating the recording interval (>0).
13.5. PLAY_NOTIFY¶
The PLAY_NOTIFY method is issued by a server to inform a client about an asynchronous event for a session in Play state.
This document defines how servers can send PLAY_NOTIFY with Notify-Reason values of these types:
- end-of-stream (see Section 13.5.1);
- media-properties-update (see Section 13.5.2);
- scale-change (see Section 13.5.3).
13.5.1. End-of-Stream¶
Indicates the completion or near completion of the PLAY request and the ending delivery of the media stream(s).
This example request notifies the client about a future end-of-stream event:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145
RTP-Info:url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545,
url="rtsp://example.com/fizzle/video"
ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: CDtUJfDQXJWtJ7Iqua2xOi
Date: Mon, 08 Mar 2010 13:37:16 GMT
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
13.5.2. Media-Properties-Update¶
Indicates an update of the
media properties(Section 18.29)for the given session or the available media range that can be played as indicated by the Media-Range header(Section 18.30).A PLAY_NOTIFY request with Notify-Reason header set to media-properties-update MUST NOT carry a message body:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 Date: Tue, 14 Apr 2008 15:48:06 GMT CSeq: 854 Notify-Reason: media-properties-update Session: CDtUJfDQXJWtJ7Iqua2xOi Media-Properties: Time-Progressing, Time-Limited=20080415T153919.36Z, Random-Access=5.0 Media-Range: npt=00:00:00-01:37:21.394 Range: npt=01:15:49.873- C->S: RTSP/2.0 200 OK CSeq: 854 User-Agent: PhonyClient/1.2 Session: CDtUJfDQXJWtJ7Iqua2xOi
13.5.3. Scale-Change¶
A PLAY_NOTIFY request with Notify-Reason header set to “Scale-Change” MUST NOT carry a message body:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 Date: Tue, 14 Apr 2008 15:48:06 GMT CSeq: 854 Notify-Reason: scale-change Session: CDtUJfDQXJWtJ7Iqua2xOi Media-Properties: Time-Progressing, Time-Limited=20080415T153919.36Z, Random-Access=5.0 Media-Range: npt=00:00:00-01:37:21.394 Range: npt=01:37:21.394- Scale: 1 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" ssrc=0D12F123:rtptime=2345962545, url="rtsp://example.com/fizzle/foo/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193 C->S: RTSP/2.0 200 OK CSeq: 854 User-Agent: PhonyClient/1.2 Session: CDtUJfDQXJWtJ7Iqua2xOi
13.6. PAUSE¶
The PAUSE request causes the stream delivery to immediately be interrupted (halted).
Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OoOUPyUwt0VeY9fFRHuZ6L
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: OoOUPyUwt0VeY9fFRHuZ6L
Range: npt=45.76-75.00
13.7. TEARDOWN¶
13.7.1. Client to Server¶
The TEARDOWN client-to-server request stops the stream delivery for the given URI, freeing the resources associated with it.
Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 892
Server: PhonyServer/1.0
13.7.2. Server to Client¶
The server can send TEARDOWN requests in the server-to-client direction to indicate that the server has been forced to terminate the ongoing session.
13.8. GET_PARAMETER¶
The GET_PARAMETER request retrieves the value of any specified parameter or parameters for a presentation or stream specified in the URI.
The headers in this specification that MAY be used for retrieving their current value using GET_PARAMETER are listed below:
- Accept-Ranges - Media-Range - Media-Properties - Range - RTP-Info
Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Content-Length: 26
Content-Type: text/parameters
packets_received
jitter
C->S: RTSP/2.0 200 OK
CSeq: 431
Session: OccldOFFq23KwjYpAnBbUr
Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT
Content-Length: 38
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
13.9. SET_PARAMETER¶
This method requests the setting of the value of a parameter or a set of parameters for a presentation or stream specified by the URI.
Example: If the receiver of the request does not understand or cannot locate a parameter, error 451 (Parameter Not Understood) MUST be used:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421
User-Agent: PhonyClient/1.2
Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421
Session: iixT43KLc
Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 20
Content-type: text/parameters
barparam: barstuff
13.10. REDIRECT¶
The REDIRECT method is issued by a server to inform a client that the service provided will be terminated and where a corresponding service can be provided instead.
This example request redirects traffic for this session to the new server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732
Location: rtsp://s2.example.com:8001/fizzle/foo
Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK
CSeq: 732
User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M
14. Embedded (Interleaved) Binary Data¶
In order to fulfill certain requirements on the network side, e.g., in conjunction with network address translators that block RTP traffic over UDP, it may be necessary to interleave RTSP messages and media-stream data.
This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead.
Stream data, such as RTP packets, is encapsulated by an ASCII dollar sign (36 decimal) followed by a one-octet channel identifier and the length of the encapsulated binary data as a binary, two-octet unsigned integer in network octet order (Appendix B of [RFC791])
Figure 1: Embedded Interleaved Binary Data Format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 36 | Channel ID | Length in octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Binary data (Length according to Length field) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If RTCP is used, packets MUST be sent on the first available channel that is higher than the RTP channel. The channels are bidirectional, using the same Channel ID in both directions; therefore, RTCP traffic is sent on the second channel in both directions:
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 CSeq: 112 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: npt, smpte, clock User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 112 Date: Thu, 05 Jun 1997 18:57:18 GMT Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Session: OccldOFFq23KwjYpAnBbUr Accept-Ranges: npt Media-Properties: Random-Access=0.2, Immutable, Unlimited C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 CSeq: 113 Session: OccldOFFq23KwjYpAnBbUr User-Agent: PhonyClient/1.2 S->C: RTSP/2.0 200 OK CSeq: 113 Session: OccldOFFq23KwjYpAnBbUr Date: Thu, 05 Jun 1997 18:57:19 GMT RTP-Info: url="rtsp://example.com/bar.file" ssrc=0D12F123:seq=232433;rtptime=972948234 Range: npt=0-56.8 Seek-Style: RAP S->C: $005{2 octet length}{"length" octets data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header} S->C: $006{2 octet length}{"length" octets RTCP packet}
15. Proxies¶
Proxies are introduced for several different reasons; those listed below are often combined:
1. Caching Proxy
2. Translator Proxy
3. Access Proxy
4. Security Proxy
5. Auditing Proxy
15.1. Proxies and Protocol Extensions¶
The existence of proxies must always be considered when developing new RTSP extensions.
15.2. Multiplexing and Demultiplexing of Messages¶
RTSP proxies may have to multiplex several RTSP sessions from their clients towards RTSP servers.
16. Caching¶
In HTTP, request/response pairs are cached.
16.1. Validation Model¶
When a cache has a stale entry that it would like to use as a response to a client’s request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. This is called “validating” the cache entry.
16.2. Invalidation after Updates or Deletions¶
The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non- transparently invalid.
17. Status Code Definitions¶
Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are reused.
18. Header Field Definitions¶
Table 8: Overview of RTSP Methods:
+---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| OPTIONS | C -> S, S -> C | P,S | OPT | |
| PAUSE | C -> S | P,S | PSE | |
| PLAY | C -> S | P,S | PLY | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R |
| REDIRECT | S -> C | P,S | RDR | |
| SETUP | C -> S | S | STP | |
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| TEARDOWN | C -> S | P,S | TRD | |
| | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+
注:
P: presentation, S: stream
R=request, r=response
The “where” column(describes the request and response types in which the header field can be used):
R: header field may only appear in requests
r: header field may only appear in responses
2xx, 4xx, etc.: numerical value or range indicates response codes with which the header field can be used
c: header field is copied from the request to the esponse
G: header field is a general-header and may be present in both requests and responses
The “proxy” column:
a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value.
d: A proxy can delete a header field-value.
r: A proxy needs to be able to read the header field;
thus, this header field cannot be encrypted.
An empty proxy column indicates that the proxy MUST NOT make any changes to that header
abbreviated:
c: Conditional; requirements on the header field depend on the context of the message.
m: The header field is mandatory.
m*: The header field SHOULD be sent, but agents need to be prepared to receive messages without that header field.
o: The header field is optional.
*: The header field MUST be present if the message body is not empty.
-: The header field is not applicable.
Figure 2: Overview of RTSP Header Fields (A-L) Related to Methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN:
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - |
| Accept- | R | rm | o | o | o | o | o | o |
| Credentials | | | | | | | | |
| Accept-Encoding | R | r | o | - | - | - | - | - |
| Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Ranges | G | r | - | - | m | - | - | - |
| Accept-Ranges | 456 | r | - | - | - | m | - | - |
| Allow | r | am | c | c | c | - | - | - |
| Allow | 405 | am | m | m | m | m | m | m |
| Authentication- | r | | o | o | o | o | o | o/- |
| Info | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o/- |
| Bandwidth | R | | o | o | o | o | - | - |
| Blocksize | R | | o | - | o | o | - | - |
| Cache-Control | G | r | o | - | o | - | - | - |
| Connection | G | ad | o | o | o | o | o | o |
| Connection- | 470, | ar | o | o | o | o | o | o |
| Credentials | 407 | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - |
| Content-Base | 4xx, | | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - |
| Content-Encoding | r | r | o | - | - | - | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Language | R | r | - | - | - | - | - | - |
| Content-Language | r | r | o | - | - | - | - | - |
| Content-Language | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | 4xx, | r | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Type | r | r | * | - | - | - | - | - |
| Content-Type | 4xx, | ar | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| CSeq | Gc | rm | m | m | m | m | m | m |
| Date | G | am | o/*| o/*| o/* | o/* | o/* | o/* |
| Expires | r | r | o | - | o | - | - | - |
| From | R | r | o | o | o | o | o | o |
| If-Match | R | r | - | - | o | - | - | - |
| If-Modified-Since | R | r | o | - | o | - | - | - |
| If-None-Match | R | r | o | - | o | - | - | - |
| Last-Modified | r | r | o | - | o | - | - | - |
| Location | 3rr | | m | m | m | m | m | m |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
Figure 3: Overview of RTSP Header Fields (M-W) Related to Methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN:
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Media-Properties | r | | - | - | m | o | o | - |
| Media-Range | r | | - | - | c | c | c | - |
| MTag | r | r | o | - | o | - | - | - |
| Pipelined- | G | amd | - | o | o | o | o | o |
| Requests | | r | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | |
| Proxy- | r | amd | o | o | o | o | o | o/- |
| Authentication- | | r | | | | | | |
| Info | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o |
| Authorization | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | o | o | o |
| Proxy-Require | r | r | c | c | c | c | c | c |
| Proxy-Supported | R | amr | c | c | c | c | c | c |
| Proxy-Supported | r | | c | c | c | c | c | c |
| Public | r | amr | - | m | - | - | - | - |
| Public | 501 | amr | m | m | m | m | m | m |
| Range | R | | - | - | - | o | - | - |
| Range | r | | - | - | c | m | m | - |
| Referrer | R | | o | o | o | o | o | o |
| Request-Status | R | | - | - | - | - | - | - |
| Require | R | | o | o | o | o | o | o |
| Retry-After | 3rr,503 | | o | o | o | o | o | - |
| | ,553 | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - |
| RTP-Info | r | | - | - | c | c | - | - |
| Scale | R | r | - | - | - | o | - | - |
| Scale | r | amr | - | - | c | c | c | - |
| Seek-Style | R | | - | - | - | o | - | - |
| Seek-Style | r | | - | - | - | m | - | - |
| Server | R | r | - | o | - | - | - | o |
| Server | r | r | o | o | o | o | o | o |
| Session | R | r | - | o | o | m | m | m |
| Session | r | r | - | c | m | m | m | o |
| Speed | R | admr| - | - | - | o | - | - |
| Speed | r | admr| - | - | - | c | - | - |
| Supported | R | r | o | o | o | o | o | o |
| Supported | r | r | c | c | c | c | c | c |
| Terminate-Reason | R | r | - | - | - | - | - | -/o |
| Timestamp | R | admr| o | o | o | o | o | o |
| Timestamp | c | admr| m | m | m | m | m | m |
| Transport | G | mr | - | - | m | - | - | - |
| Unsupported | r | | c | c | c | c | c | c |
| User-Agent | R | | m* | m* | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c | c | c |
| Via | r | amr | c | c | c | c | c | c |
| WWW-Authenticate | 401 | | m | m | m | m | m | m |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
Figure 4: Overview of RTSP Header Fields (A-L) Related to Methods GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY:
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Accept-Credentials | R | rm | o | o | o | - |
| Accept-Encoding | R | r | o | o | o | - |
| Accept-Language | R | r | o | o | o | - |
| Accept-Ranges | G | rm | o | - | - | - |
| Allow | 405 | amr | m | m | m | m |
| Authentication-Info | r | | o/- | o/- | - | - |
| Authorization | R | | o | o | o | - |
| Bandwidth | R | | - | o | - | - |
| Blocksize | R | | - | o | - | - |
| Cache-Control | G | r | o | o | - | - |
| Connection | G | | o | o | o | o |
| Connection-Credentials | 470, | ar | o | o | o | - |
| | 407 | | | | | |
| Content-Base | R | | o | o | - | o |
| Content-Base | r | | o | o | - | - |
| Content-Base | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Encoding | R | r | o | o | - | o |
| Content-Encoding | r | r | o | o | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Language | R | r | o | o | - | o |
| Content-Language | r | r | o | o | - | - |
| Content-Language | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Length | R | r | * | * | - | * |
| Content-Length | r | r | * | * | - | - |
| Content-Length | 4xx, | r | * | * | * | * |
| | 5xx | | | | | |
| Content-Location | R | | o | o | - | o |
| Content-Location | r | | o | o | - | - |
| Content-Location | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Type | R | | * | * | - | * |
| Content-Type | r | | * | * | - | - |
| Content-Type | 4xx, | | * | * | * | * |
| | 5xx | | | | | |
| CSeq | R,c | mr | m | m | m | m |
| Date | R | a | o/* | o/* | m | o/* |
| Date | r | am | o/* | o/* | o/* | o/* |
| Expires | r | r | - | - | - | - |
| From | R | r | o | o | o | - |
| If-Match | R | r | - | - | - | - |
| If-Modified-Since | R | am | o | - | - | - |
| If-None-Match | R | am | o | - | - | - |
| Last-Modified | R | r | - | - | - | - |
| Last-Modified | r | r | o | - | - | - |
| Location | 3rr | | m | m | m | - |
| Location | R | | - | - | m | - |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
Figure 5: Overview of RTSP Header Fields (M-W) Related to Methods GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY:
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Media-Properties | R | amr | o | - | - | c |
| Media-Properties | r | mr | c | - | - | - |
| Media-Range | R | | o | - | - | c |
| Media-Range | r | | c | - | - | - |
| MTag | r | r | o | - | - | - |
| Notify-Reason | R | | - | - | - | m |
| Pipelined-Requests | R | amdr | o | o | - | - |
| Proxy-Authenticate | 407 | amdr | m | m | m | - |
| Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - |
| Proxy-Authorization | R | amdr | o | o | o | - |
| Proxy-Require | R | ar | o | o | o | - |
| Proxy-Supported | R | amr | c | c | c | - |
| Proxy-Supported | r | | c | c | c | - |
| Public | 501 | admr | m | m | m | - |
| Range | R | | o | - | - | m |
| Range | r | | c | - | - | - |
| Referrer | R | | o | o | o | - |
| Request-Status | R | mr | - | - | - | c |
| Require | R | r | o | o | o | o |
| Retry-After | 3rr,503,| | o | o | - | - |
| | 553 | | | | | |
| Retry-After | 413 | | o | o | - | - |
| RTP-Info | R | r | o | - | - | C |
| RTP-Info | r | r | c | - | - | - |
| Scale | G | | c | - | c | c |
| Seek-Style | G | | - | - | - | - |
| Server | R | r | o | o | o | o |
| Server | r | r | o | o | - | - |
| Session | R | r | o | o | o | m |
| Session | r | r | c | c | o | m |
| Speed | G | | - | - | - | - |
| Supported | R | r | o | o | o | - |
| Supported | r | r | c | c | c | - |
| Terminate-Reason | R | r | - | - | m | - |
| Timestamp | R | adrm | o | o | o | o |
| Timestamp | c | adrm | m | m | m | m |
| Transport | G | mr | - | - | - | - |
| Unsupported | r | arm | c | c | c | c |
| User-Agent | R | r | m* | m* | - | - |
| User-Agent | r | r | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c |
| Via | r | amr | c | c | c | c |
| WWW-Authenticate | 401 | | m | m | m | - |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
18.33. Pipelined-Requests¶
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.
Pipelined-Requests头允许客户端发送多个请求，而无需等待服务器对上一次请求的响应。这种技术可以减少客户端向服务器发出请求所需的时间，并在一定程度上提高数据传输的效率。
当客户端向服务器发送多个请求时，服务器会将这些请求按顺序处理，并将响应数据发送回客户端。
通过使用Pipelined-Requests头，客户端可以在等待服务器响应时发回更多的请求，并在不增加服务器压力的情况下提高数据传输速度。
19. Security Framework¶
The RTSP security framework consists of two high-level components:
1. the pure authentication mechanisms based on HTTP authentication
2. the message transport protection based on TLS, which is independent of RTSP.
19.1. RTSP and HTTP Authentication¶
RTSP and HTTP share common authentication schemes; thus, they follow the same framework as specified in [RFC7235].
Servers SHOULD implement both the Basic [RFC7617] and the Digest [RFC7616] authentication schemes.
Clients MUST implement both the Basic and the Digest authentication schemes so that a server that requires the client to authenticate can trust that the capability is present.
备注
This authentication mechanism works only for client-to-server requests as currently defined. This leaves server-to-client request outside of the context of TLS-based communication more vulnerable to message-injection attacks on the client. Based on the server-to-client methods that exist, the potential risks are various: hijacking (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY), or attacks with uncertain results (SET_PARAMETER).
Digest authentication uses two additional headers,
Authentication-InfoandProxy-Authentication-Info, that are defined as in [RFC7615].
19.2. RTSP over TLS¶
RTSP agents MUST implement RTSP over TLS as defined in this section and the next Section 19.3.
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 one.
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:
1. Any: the proxy (or proxies) MUST accept whatever certificate is presented. 2. Proxy: the proxy (or proxies) MUST use its own policies 3. User: the proxy (or proxies) MUST send credential information about the next hop to the client for authorization.
19.3.2. User-Approved TLS Procedure¶
For the “User” method, each proxy MUST perform the following procedure for each RTSP request:…
Example:
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, clock
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, clock
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, clock
20. Syntax¶
20.1. Base Syntax¶
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
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking whitespace
SWS = [LWS] ; Separating whitespace
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 / "+" / "/"
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-2 / UTF8-3 / UTF8-4
UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629>
UTF8-tail = <As defined in RFC 3629>
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT
20.2. RTSP Protocol Definition¶
20.2.1. Generic Protocol Elements¶
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 ":"
; No parameter (; delimited) inside path.
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
; sub-delims is different from RFC 3987
; not including ";"
iquery = < As defined in RFC 3987>
iunreserved = < As defined in RFC 3987>
pct-encoded = < As defined in RFC 3987>
smpte-range = smpte-type [EQUAL smpte-range-spec]
; See section 4.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" [EQUAL npt-range-spec]
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp
npt-sec = 1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh = 2*19DIGIT ; any positive number
npt-mm = 2*2DIGIT ; 0-59
npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp
[ "." 1*9DIGIT ] ; Compatibility format
npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59
utc-range = "clock" [EQUAL 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 / LWS)
20.2.2. Message Syntax¶
RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line
*((general-header
/ request-header
/ message-body-header) CRLF)
CRLF
[ message-body-data ]
Response = Status-Line
*((general-header
/ response-header
/ message-body-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
...
extension-code = 3DIGIT
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP)
rtsp-header = general-header
/ request-header
/ response-header
/ message-body-header
general-header = Accept-Ranges
/ Cache-Control
/ Connection
...
request-header = Accept
/ Accept-Credentials
/ Accept-Encoding
/ Accept-Language
...
response-header = Authentication-Info
/ Connection-Credentials
/ Location
/ MTag
/ Proxy-Authenticate
...
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
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 = "identity" / 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" / "smpte-30-drop" / "smpte-25"
/ "clock" / extension-format
extension-format = token
Allow = "Allow" HCOLON Method *(COMMA Method)
Authentication-Info = "Authentication-Info" HCOLON auth-param-list
auth-param-list = <As the Authentication-Info element in RFC 7615>
Authorization = "Authorization" HCOLON credentials
credentials = <As defined by RFC 7235>
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
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 = date-time ;
date-time = <As defined in RFC 5322>
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])
/ "Beginning-Only"
/ "No-Seeking"
/ "Immutable"
/ "Dynamic"
/ "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
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = <As defined by the WWW-Authenticate in RFC 7235>
Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON
auth-param-list
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
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 [EQUAL 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
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]
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)
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>
Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment )
*(LWS (product / comment))
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¶
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
21. Security Considerations¶
21.1. Signaling Protocol Threats¶
This section focuses on issues related to the signaling protocol.
The following are considerations same with http protocol:
1. Abuse of Server Log Information
2. Transfer of Sensitive Information
3. Attacks Based On File and Path Names
4. Personal Information
5. Privacy Issues Connected to Accept Headers
6. Establishing Authority
7. Location Headers and Spoofing
The following are added considerations for RTSP implementations:
1. Session Hijacking
2. Authentication
3. Suspicious Behavior
4. TLS through Proxies
5. Resource Exhaustion
21.2. Media Stream Delivery Threats¶
The set of general threats from or by the media-stream delivery itself are:
1. Concentrated Denial-of-Service Attack
2. Media Confidentiality
3. Media Integrity and Authentication
4. Scope of Multicast
21.2.1. Remote DoS Attack¶
The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests.
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.
In perspective of the usage of RTP in the context of RTSP, the following properties should be noted:
Stream Additions
Forged Feedback
RTP/RTCP Extensions
Appendix A. Examples¶
A.1. Media on Demand (Unicast)¶
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: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
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=00:00:00-00: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
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, clock
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: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
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: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt, smpte, clock
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: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
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: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
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: OccldOFFq23KwjYpAnBbUr
# Pause happens 0.87 seconds after starting to play
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:35 +0000
Session: OccldOFFq23KwjYpAnBbUr
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: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:22:13 +0000
Session: OccldOFFq23KwjYpAnBbUr
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
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 7
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:31:53 +0000
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.
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: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
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=00:00:00-00: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
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, clock
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, clock
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: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
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: OccldOFFq23KwjYpAnBbUr
Expires: Sat, 21 Dec 2013 10:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Range: NPT
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: Fri, 20 Dec 2013 10:20:32 +0000
Session: OccldOFFq23KwjYpAnBbUr
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. Secured Media Session for On-Demand Content¶
This example is basically the above example (Appendix A.2), but now including establishment of SRTP crypto contexts to get a secured media delivery.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 301 Moved Permanently
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:32 +0000
Location: rtsps://example.com/twister.3gp
C->M: Establish TCP/TLS connection and verify server's
certificate that represents example.com.
Used for all below RTSP messages.
C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:33 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsps://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:25:33 +0000
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=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/SAVP 0
a=control: trackID=1
m=video 0 RTP/SAVP 26
a=control: trackID=4
C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001";
MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003";
MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ=
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/SAVP;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;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Transport: RTP/SAVP;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;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsps://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889;
Pipelined-Requests: 7654
A.4. Media on Demand (Unicast)¶
An alternative example of media on demand with a few 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:
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.1 200 OK
Date: Wed, 23 Jan 2013 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 278
Expires: Thu, 24 Jan 2013 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=00:00:00-01: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, clock
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: OccldOFFq23KwjYpAnBbUr
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: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Cache-Control: public
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.02, Immutable, Unlimited
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, clock
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: P5it3pMo6xHkjUcDrNkBjf
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: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Cache-Control: public
Expires: Thu, 24 Jan 2013 15:35:12 +0000
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: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: P5it3pMo6xHkjUcDrNkBjf
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: Wed, 23 Jan 2013 15:35:13 +0000
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: OccldOFFq23KwjYpAnBbUr
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: Wed, 23 Jan 2013 15:35:13 +0000
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
A.5. 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.:
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: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Thu, 24 Jan 2013 15:36:52 +0000
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
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, clock
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: NYkqQYKk0bb12BY3goyoyO
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.5, Immutable, Unlimited
C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: NYkqQYKk0bb12BY3goyoyO
Range: npt=0-600
Seek-Style: RAP
RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123
A.6. Live Media Presentation Using Multicast¶
The media server M chooses the multicast address and port:
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: Wed, 23 Jan 2013 15:36:52 +0000
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-
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, clock
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
;ssrc=4D12AB92/0DF876A3
Session: qHj4jidpmF6zy9v9tNbtxr
Accept-Ranges: npt, clock
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: qHj4jidpmF6zy9v9tNbtxr
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: qHj4jidpmF6zy9v9tNbtxr
Seek-Style: Next
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
A.7. Capability Negotiation¶
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
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, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
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
Appendix B. RTSP Protocol State Machine¶
B.1. States¶
The state machine contains three states:
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:
NRM: The number of media streams that are 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¶
IFI: IF Implemented.
md: Media
PP: Pause Point, the point in the presentation timeline at which the presentation was paused.
Prs: Presentation, the complete multimedia presentation.
RedP: Redirect Point, the point in the presentation timeline at which a REDIRECT was specified to occur.
SES: Session.
B.4. State Tables¶
Table 10: State: Init:
+------------------+----------------+-----------+-------------------+
| 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 11: State: Ready:
+-------------+------------------------+---------+------------------+
| 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 12: State: Play:
+----------------+--------------------------------------+-----------+-------------------------+
| Action | Requisite | New State | Response |
+================+======================================+===========+=========================+
| PAUSE | Prs URI | Ready | Set RP to present point |
| End of media | All media | Play | Set RP = End of media |
| End of range | nil | 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 | nil | Play | 200 |
| SETUP | New URI | Play | 455 |
| SETUP | md URI | Play | 455 |
| SETUP | md 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 Time parameter | Play | Set RedP |
| SC:REDIRECT | nil | Init | Session is removed |
| RedP reached | nil | Init | TEARDOWN of session |
| Timeout | nil | Init | Stop Media playout |
+----------------+--------------------------------------+-----------+-------------------------+
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].
C.1.1. AVP¶
AVP是最基本的视频传输协议，也是RTP协议的默认模式。它使用动态端口传输视频数据，没有丢包反馈机制。如果出现网络抖动或者丢包，将会对视频的质量产生较大的影响。因此，使用AVP协议传输视频需要保证网络的稳定性和带宽的充足性。
C.1.2. AVP/UDP¶
AVP/UDP是基于UDP协议的视频传输协议，它继承了AVP协议的特点，并且具有更长的包头（12字节）。这些包头可以用来支持更多的控制消息和补偿机制。AVP/UDP协议可以通过改变包的丢失策略和传输速率来适应不同的网络状况。
C.1.3. AVPF/UDP¶
AVPF/UDP是基于AVP协议的增强版，它支持丢包反馈（FEC）和往返时延（RTCP）反馈机制。通过这些机制，AVPF/UDP可以在丢包或者网络延迟较高的情况下提高视频的传输质量。AVPF/UDP协议还支持自适应码率，可以在带宽不足的情况下自动降低视频的分辨率。
C.1.4. SAVP/UDP¶
SAVP/UDP是Secure RTP（SRTP）的AVP协议版本。SRTP是一个加密的视频传输协议，它可以保护视频数据不被恶意攻击者窃取和篡改。
SAVP/UDP协议需要在双方之间进行协商，才能进行加密和解密操作。
C.1.5. SAVPF/UDP¶
SAVPF/UDP是Secure RTP（SRTP）的AVPF协议版本。它继承了SAVP/UDP协议的特点，并且加入了丢包反馈和往返时延反馈机制。
SAVPF/UDP协议是一种更加安全和稳定的视频传输协议，适用于对数据安全性要求较高的场景。
C.2. RTP over TCP¶
Transport of RTP over TCP can be done in two ways: over independent TCP connections using [RFC4571] or interleaved in the RTSP connection.
In both cases, the protocol MUST be “rtp” and the lower-layer MUST be TCP.
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.
C.2.2. RTP over Independent TCP¶
In this section, the sending of RTP [
RFC3550] over lower-layer transport TCP [RFC793] according to RTP and RTCP Packets over Connection-Oriented Transport” [RFC4571] is described.This section adapts the guidelines for using RTP over TCP within SIP/SDP [
RFC4145] to work with RTSP.
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: Wed, 23 Jan 2013 15:36:52 +0000
Content-Type: application/sdp
Content-Length: 227
Content-Base: rtsp://example.com/twister.3gp/
Expires: Thu, 24 Jan 2013 15:36:52 +0000
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=00:00:00-00: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, clock
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: OccldOFFq23KwjYpAnBbUr
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Date: Wed, 23 Jan 2013 15:36:52 +0000
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: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:54 +0000
Session: OccldOFFq23KwjYpAnBbUr
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; a client may also immediately follow a completed PLAY request with a new PLAY request.
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: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
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:
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: ymIqLXufHkMHGdtENdblWK
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: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
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 are 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 timestamps 0 through 39,200.
The second segment consists of RTP packets with sequence numbers 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).
8000是指每秒发送的RTP timestamp数
100是指播放范围的时间间隔(第一个请求的最后一帧是39200，如果没有gap第二个请求的第一帧是40000，但实际第一帧是40100，所以gap是100)
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.
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: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
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:
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
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: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
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 that 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.
注:
164400 = 2400 + 800 + 20*10*800 + 0.015*10*800
= 3200 + 160000 + 1200(?? 这儿感觉应该是150ms=0.15s才对)
C.5. RTSP/RTP Integration¶
For certain data types, 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.46), RTP timestamps should correspond to the rendering timing.
For example, when playing video recorded at 30 frames per second at a scale of two and speed (Section 18.50) 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.
C.7. Maintaining NPT Synchronization with RTP Timestamps¶
The client can maintain a correct display of NPT by noting the RTP timestamp value of the first packet arriving after repositioning.
The sequence parameter of the RTP-Info (Section 18.45) 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.
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.
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 a URI from a server to a client or received via HTTP from a server to a client.
D.1. Definitions¶
D.1.1. Control URI¶
The “a=control” attribute is used to convey the control URI.
This attribute is used both for the
sessionandmediadescriptions.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.
Example:
a=control:rtsp://example.com/foo
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.
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 indicated SHOULD be used for reception.
Example:
m=audio 0 RTP/AVP 31
The “m=” lines contain information about which transport protocol, profile, and possibly lower-layer are 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.
D.1.3. Payload Type(s)¶
The payload type or types 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.
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) to which the attribute refers.
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 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.
For now, all RTSP SDP SHOULD have an “a=recvonly” attribute when using the PLAY mode defined in this document.
If future modes are defined for media in the 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.
The attribute is both a
session-and amedia-levelattribute.
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.
D.1.8. Connection Information¶
In SDP used with RTSP, the “c=” field contains the destination address for the media stream.
D.1.9. Message Body Tag¶
The optional “a=mtag” attribute identifies a version of the session description.
Example:
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
D.2. Aggregate Control Not Available¶
If a presentation does not support aggregate control, no session-level “a=control” attribute is specified.
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
D.3. Aggregate Control Available¶
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: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Wed, 23 Jan 2013 16:36:52 +0000
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
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].
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.
Appendix E. RTSP Use Cases¶
This appendix describes the most important and considered use cases for RTSP.
E.1. On-Demand Playback of Stored Content¶
An RTSP-capable server stores content suitable for being streamed to a client.
The above high-level description can be broken down into a number of functions of which RTSP needs to be capable:
Presentation Description:
Setup:
Control of Transmission:
Synchronization:
Termination:
For this use case, there are a number of assumptions about how it works:
On-Demand content:
Independent sessions:
Unicast Transport:
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
E.3. On-Demand Playback Using Multicast¶
It is possible to use RTSP to request that media be delivered to a multicast group.
E.4. Inviting an RTSP Server into a Conference¶
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.
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.
Appendix F. Text Format for Parameters¶
The ABNF 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 = <as defined in Section 20.1>
WSP = <See RFC 5234> ; Space or HTAB
VCHAR = <See RFC 5234>
CRLF = <See RFC 5234>
Appendix G. Requirements for Unreliable Transport of RTSP¶
This appendix provides guidance for those who want to implement RTSP messages over unreliable transports as has been defined in RTSP 1.0 [RFC2326].
Appendix H. Backwards-Compatibility Considerations¶
A server implementing RTSP 2.0 MUST include an RTSP-Version of “RTSP/2.0” in all responses to requests containing RTSP-Version value of “RTSP/2.0”.
H.1. Play Request in Play State¶
The behavior in the server when a Play is received in Play state has changed
H.2. Using Persistent Connections¶
Some server implementations of RFC 2326 maintain a one-to-one relationship between a connection and an RTSP session.
Appendix I. Changes¶
This appendix briefly lists the differences between RTSP 1.0 [RFC2326] and RTSP 2.0 for an informational purpose.
I.1. Brief Overview¶
The following protocol elements were removed in RTSP 2.0 compared to RTSP 1.0:
- the `RECORD` and `ANNOUNCE` methods and all related functionality
(including 201 (Created) and 250 (Low On Storage Space) status codes);
- the use of UDP for RTSP message transport (due to missing interest and to broken specification);
- 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:
1. RTSP session TEARDOWN from the server to the client;
2. IPv6 support;
3. extended IANA registries (e.g., transport headers parameters, transport-protocol, profile, lower-transport, and mode);
4. request pipelining for quick session start-up;
5. fully reworked state machine;
6. RTSP messages now use URIs rather than URLs;
7. incorporated much of related HTTP text ([RFC2616]) in this memo, compared to just referencing the sections in HTTP, to avoid ambiguities;
8. the REDIRECT method was expanded and diversified for different situations;
9. Includes a new section about how to set up different media-transport alternatives and their profiles in addition to lower-layer protocols.
This caused the appendix on RTP interaction to be moved to the new section instead of being in the part that describes RTP.
The section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles;
10. 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¶
The below changes have been made to RTSP 1.0 (RFC 2326) when defining RTSP 2.0.
The Transport header has been changed in the following ways:
The ABNF has been changed to define that extensions are possible
and that unknown parameters result in servers ignoring 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 ambiguities 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", and "source".
Support for IPv6 explicit addresses in all address fields has been included.
To handle URI definitions that contain ";" or ",", a quoted-URI format has been introduced and is required.
IANA registries for the transport header parameters, transport-protocol, profile, lower-transport, and mode have been defined.
The Transport header's 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 header's "dest_addr" parameters regarding what security precautions the server is required to perform.
The Range formats have 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.
The npt-hhmmss notation now follows ISO 8601 more strictly.
RTSP message handling has been changed in the following ways:
* RTSP messages now use URIs rather than URLs.
* It has been clarified that a 4xx message due to a missing CSeq
header shall be returned without a CSeq header.
* The 300 (Multiple Choices) response code has been removed.
* Rules for how to handle the timing out RTSP messages have been added.
* Extended Pipelining rules allowing for quick session startup.
* Sequence numbering and proxy handling of sequence numbers have
been defined, including cases when responses arrive out of
order.
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 have 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 servers 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.
The following header-related changes have been made:
Accept-Ranges response-header has been added. This header clarifies which range formats 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 has also been added.
Added a requirement that the Date header must be used for all messages with a message body and the Server should always include it.
Removed the 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 a rule that lack of Scale header in a response indicates lack of support for the header. feature tags for scaled playback have been defined.
The Speed header must now be responded to in order 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.
ETag has changed its name to MTag.
To resolve functionality around MTag, the MTag and If-None- Match header have been added from HTTP with necessary clarification in regard 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.
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 (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.
The Status codes have been changed in the following ways:
* The use of status code 303 (See Other) has been deprecated as
it does not make sense to use in RTSP.
* The never-defined status code 411 "Length Required" has been
completely removed.
* When sending response 451 (Parameter Not Understood) and 458
(Parameter Is Read-Only), the response body should contain the
offending parameters.
* 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 an 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), and 472 (Failure to Establish Secure
Connection).
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 mentioned here and some requirements for the
transport are provided.
The following changes have been made in relation to methods:
* The OPTIONS method has been clarified with regard to the use of
the Public and Allow headers.
* Added text clarifying the usage of SET_PARAMETER for keep-alive
and usage without a 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.
* Added a new method PLAY_NOTIFY. This method is used by the
RTSP server to asynchronously notify clients about session
changes.
Security features of RTSP have been clarified:
* HTTP-based authorization has been clarified requiring both
Basic and Digest support
* TLS support has been mandated
* If one implements RTP, then SRTP and defined MIKEY-based key-exchange must be supported
* Various minor mitigations discussed or resulted in protocol
changes.