RTSP协议版本2.0详解

需积分: 14 84 浏览量更新于2024-07-06 收藏 466KB PDF 举报

"rfc7826_rtsp.pdf - RTSP实时传输流协议V2.0，涵盖了register、setup、play、pause、teardown等控制操作，由IETF发布，取代了RTSP V1.0 (RFC2326)，旨在定义实时数据的可控、按需传输框架，适用于音频、视频等实时数据的流传输。" RTSP（实时传输流协议）是互联网工程任务组（IETF）制定的一种应用层协议，主要目的是管理和控制具有实时特性的数据传输。RTSP V2.0对1.0版本进行了更新和优化，旨在提供一个可扩展的框架，允许对实时数据（如音频和视频流）进行受控的、按需的交付。这些数据源可以包括现场数据馈送和存储的剪辑。协议的核心功能包括： 1. **控制操作**：RTSP提供了多种控制命令，如： - **Register**：注册请求用于将客户端的URI与特定的服务器端点关联起来，以便于后续的交互。 - **Setup**：设置命令用于建立和配置传输会话，包括选择合适的传输通道（如UDP、多播UDP或TCP）以及RTP（实时传输协议）参数。 - **Play**：播放命令启动数据流的传输，通常是从指定的时间点开始。 - **Pause**：暂停命令可以临时停止数据流的传输，而不会完全关闭会话。 - **Teardown**：拆卸命令用于终止传输会话，释放所有相关的资源。 2. **多通道支持**：RTSP允许选择不同的传输通道，如单播UDP、多播UDP和TCP，以适应不同网络环境和负载需求。 3. **基于RTP的传输机制**：RTSP常与RTP结合使用，RTP是一种标准的传输协议，用于在不可靠的网络上高效地传输实时数据。RTSP通过RTP实现数据的可靠传输和同步。 4. **扩展性**：RTSP的设计允许通过添加新的控制命令和头字段来扩展其功能，以适应未来的新需求和技术发展。 5. **标准文档地位**：此文档被定义为Internet Standards Track文档，表明它已成为互联网标准的一部分，是经过广泛讨论和共识形成的规范。 RTSP V2.0的发布，意味着对原有协议的改进和增强，可能包括性能提升、安全增强、更灵活的交互模式等。对于开发实时流媒体应用和服务的开发者来说，理解和掌握RTSP协议至关重要，因为它提供了对实时内容传输的强大控制能力。

RFC 7826 RTSP 2.0 December 2016

example, clients needing to know the current media range for a time-

progressing session can use the GET_PARAMETER method and include the

media range. Furthermore, synchronization information can be

requested by using a combination of RTP-Info (Section 18.45) and

Range (Section 18.40).

RTSP 2.0 does not have a strong mechanism for negotiating the headers

or parameters and their formats. However, responses will indicate

request-headers or parameters that are not supported. A priori

determination of what features are available needs to be done through

out-of-band mechanisms, like the session description, or through the

usage of feature tags (Section 4.5).

2.5. Media Delivery

This document specifies how media is delivered with RTP [RFC3550]

over UDP [RFC768], TCP [RFC793], or the RTSP connection. Additional

protocols may be specified in the future as needed.

The usage of RTP as a media delivery protocol requires some

additional information to function well. The PLAY response contains

information to enable reliable and timely delivery of how a client

should synchronize different sources in the different RTP sessions.

It also provides a mapping between RTP timestamps and the content-

time scale. When the server wants to notify the client about the

completion of the media delivery, it sends a PLAY_NOTIFY request to

the client. The PLAY_NOTIFY request includes information about the

stream end, including the last RTP sequence number for each stream,

thus enabling the client to empty the buffer smoothly.

2.5.1. Media Delivery Manipulations

The basic playback functionality of RTSP enables delivery of a range

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.

Scale: The ratio of media-content time delivered per unit of

playback time.

Speed: The ratio of playback time delivered per unit of wallclock

time.

Both affect the media delivery per time unit. However, they

manipulate two independent timescales and the effects are possible to

combine.

Schulzrinne, et al. Standards Track [Page 16]

RFC 7826 RTSP 2.0 December 2016

Scale (Section 18.46) is used for fast-forward or slow-motion control

as it changes the amount of content timescale that should be played

back per time unit. 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 = 1.0 is the default value that is used if

no scale is specified, i.e., playback at the content’s original rate.

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. Let’s consider two common

media types, audio and video.

It is very difficult to modify the playback rate of audio.

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, although the

rendering capabilities are often limited to certain frame rates.

Also, the allowed bitrates in decoding, the structure used in the

encoding, and the dependency between frames and other capabilities of

the rendering device limits the possible manipulations. Therefore,

the basic fast-forward capabilities often are implemented by

selecting certain subsets of frames.

Due to the media restrictions, the possible scale values are commonly

restricted to the set of realizable scale ratios. To enable the

clients to select from the possible scale values, RTSP can signal the

supported scale ratios for the content. To support aggregated or

dynamic content, where this may change during the ongoing session and

dependent on the location within the content, a mechanism for

updating the media properties and the scale factor currently in use,

exists.

Speed (Section 18.50) affects how much of the playback timeline is

delivered in a given wallclock period. The default is Speed = 1

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

Schulzrinne, et al. Standards Track [Page 17]

RFC 7826 RTSP 2.0 December 2016

than the regular media rate. Speed values of 0 or lower have no

meaning and are not allowed. This mechanism enables two general

functionalities. One is client-side scale operations, i.e., the

client receives all the frames and makes the adjustment to the

playback locally. The second is delivery control for the buffering

of media. By specifying a speed over 1.0, the client can build up

the amount of playback time it has present in its buffers to a level

that is sufficient for its needs.

A naive implementation of Speed would only affect the transmission

schedule of the media and has a clear impact on the needed bandwidth.

This would result in the data rate being proportional to the speed

factor. Speed = 1.5, i.e., 50% faster than normal delivery, would

result in a 50% increase in the data-transport rate. Whether or not

that can be supported depends solely on the underlying network path.

Scale may also have some impact on the required bandwidth due to the

manipulation of the content in the new playback schedule. An example

is fast forward where only the independently decodable intra-frames

are included in the media stream. This usage of solely intra-frames

increases the data rate significantly compared to a normal sequence

with the same number of frames, where most frames are encoded using

prediction.

This potential increase of the data rate needs to be handled by the

media sender. The client has requested that the media be delivered

in a specific way, which should be honored. However, the media

sender cannot ignore if the network path between the sender and the

receiver can’t handle the resulting media stream. In that case, the

media stream needs to be adapted to fit the available resources of

the path. This can result in a reduced media quality.

The need for bitrate adaptation becomes especially problematic in

connection with the Speed semantics. If the goal is to fill up the

buffer, the client may not want to do that at the cost of reduced

quality. If the client wants to make local playout changes, then it

may actually require that the requested speed be honored. To resolve

this issue, Speed uses a range so that both cases can be supported.

The server is requested to use the highest possible speed value

within the range, which is compatible with the available bandwidth.

As long as the server can maintain a speed value within the range, it

shall not change the media quality, but instead modify the actual

delivery rate in response to available bandwidth and reflect this in

the Speed value in the response. However, if this is not possible,

the server should instead modify the media quality to respect the

lowest speed value and the available bandwidth.

Schulzrinne, et al. Standards Track [Page 18]

RFC 7826 RTSP 2.0 December 2016

This functionality enables the local scaling implementation to use a

tight range, or even a range where the lower bound equals the upper

bound, to identify that it requires the server to deliver the

requested amount of media time per delivery time, independent of how

much it needs to adapt the media quality to fit within the available

path bandwidth. For buffer filling, it is suitable to use a range

with a reasonable span and with a lower bound at the nominal media

rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the

buffer, it can specify an upper bound that is below 1.0 to force the

server to deliver slower than the nominal media rate.

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:

o Media-transport protocol keep-alive. RTP Control Protocol (RTCP)

may be used when using RTP.

o Any RTSP request referencing the session context.

Section 10.5 discusses the methods for showing liveness in more

depth. If the client fails to show liveness for more than the

established session timeout value (normally 60 seconds), the server

may terminate the context. Other values may be selected by the

server through the inclusion of the timeout parameter in the session

header.

The session context is normally terminated by the client sending a

TEARDOWN request (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.

A client may keep the session alive indefinitely if allowed by the

server; however, a client is advised to release the session context

when an extended period of time without media delivery activity has

passed. The client can re-establish the session context if required

later. What constitutes an extended period of time is dependent on

the client, server, and their usage. 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.

When a server terminates the session context, it does so by sending a

TEARDOWN request indicating the reason.

Schulzrinne, et al. Standards Track [Page 19]

RFC 7826 RTSP 2.0 December 2016

A server can also request that the client tear down the session and

re-establish it at an alternative server, as may be needed for

maintenance. This is done by using the REDIRECT method

(Section 13.10). The Terminate-Reason header (Section 18.52) is used

to indicate when and why. The Location header indicates where it

should connect if there is an alternative server available. When the

deadline expires, the server simply stops providing the service. To

achieve a clean closure, the client needs to initiate session

termination prior to the deadline. In case the server has no other

server to redirect to, and it wants to close the session for

maintenance, it shall use the TEARDOWN method with a Terminate-Reason

header.

2.7. Extending RTSP

RTSP is quite a versatile protocol that supports extensions in many

different directions. Even this core specification contains several

blocks of functionality that are optional to implement. The use case

and need for the protocol deployment should determine what parts are

implemented. Allowing for extensions makes it possible for RTSP to

address additional use cases. However, extensions will affect the

interoperability of the protocol; therefore, it is important that

they can be added in a structured way.

The client can learn the capability of a server by using the OPTIONS

method (Section 13.1) and the Supported header (Section 18.51). It

can also try and possibly fail using new methods or require that

particular features be supported using the Require (Section 18.43) or

Proxy-Require (Section 18.37) header.

The RTSP, in itself, can be extended in three ways, listed here in

increasing order of the magnitude of changes supported:

o Existing methods can be extended with new parameters, for example,

headers, as long as these parameters can be safely ignored by the

recipient. If the client needs negative acknowledgment when a

method extension is not supported, a tag corresponding to the

extension may be added in the field of the Require or Proxy-

Require headers.

o New methods can be added. If the recipient of the message does

not understand the request, it must respond with error code 501

(Not Implemented) so that the sender can avoid using this method

again. A client may also use the OPTIONS method to inquire about

methods supported by the server. The server must list the methods

it supports using the Public response-header.

Schulzrinne, et al. Standards Track [Page 20]

剩余317页未读，继续阅读

徐福记456

粉丝: 1104
资源: 47

RTSP协议版本2.0详解

rfc2326-RTSP.pdf

RTSP 2.0 协议 PDF 带书签

rfc7826.doc

RFC2326 - RTSP.pdf

RTSP_RFC2326(CN).zip_rfc2326_rtsp_rtsp rfc

rfc2326_Real_Time_Streaming_Protocol(RTSP).pdf

rtsp_rfc.rar

rfc3261-cn.pdf

RFC-SIP 326.pdf

RTSP_RFC2326(CN).pdf

最新资源