RTP协议详解：实时应用的网络传输标准RFC3550

需积分: 9 37 浏览量更新于2024-07-27 收藏 492KB PDF 举报

RTP (Real-time Transport Protocol) 是RFC 3550定义的一个标准网络传输协议，它专注于为实时应用提供端到端的数据传输服务。这份文档由H. Schulzrinne等人于2003年发布，旨在规范在互联网上进行音频、视频、模拟数据等实时数据传输的方式。作为一项"标准跟踪"文档，它取代了先前的RFC 1889，表明RTP协议已经经过了标准化并处于活跃的讨论和改进阶段。 RTP设计的核心目标是确保实时数据的高效传输，特别适合那些对延迟敏感的应用，如在线会议、语音通话、视频会议和在线游戏等。它不涉及资源预留或服务质量(QoS)保证，这意味着尽管它能够处理多播或单播网络服务，但并不保证数据的传输速率或丢包率。因此，对于需要严格服务质量保障的应用，可能需要结合其他QoS机制来优化性能。 RTP协议包含两个主要部分：数据传输和控制功能。数据传输部分负责实际的数据包发送，每个RTP数据包都包含时间戳、序列号以及与会话相关的标识符，使得接收端可以正确地同步和解析数据流。控制功能则通过控制字段来传递元数据，如丢包指示、编码参数变化等，帮助接收方调整解码策略。此外，RTP被设计为轻量级协议，以适应实时应用对带宽和处理能力的需求。它支持加密，以保护数据安全，同时允许扩展，以适应未来可能的扩展需求。然而，由于其基础性质，RTP并不适用于需要持久连接或复杂流量管理的非实时应用。这份RFC文档还强调，RTP是互联网标准的一部分，其标准化状态和更新可以在互联网官方协议标准（STD 1）的最新版本中查阅。版权方面，该文档由互联网协会持有，所有权利受到保留。 RTP协议是实时通信网络架构中的基石，对于许多依赖于即时交互的应用至关重要，但同时也需要与其它技术配合以满足不同场景下的具体需求。随着技术的发展，对RTP的优化和扩展仍将持续进行，以适应不断演变的网络环境。

RFC 3550 RTP July 2003

5.2 Multiplexing RTP Sessions

For eﬃcient protocol processing, the number of multiplexing points should be minimized, as de-

scribed in the integrated layer processing design principle [10]. In RTP, multiplexing is provided

by the destination transport address (network address and port number) which is diﬀerent for

each RTP session. For example, in a teleconference composed of audio and video media encoded

separately, each medium should be carried in a separate RTP session with its own destination

transport address.

Separate audio and video streams should not be carried in a single RTP session and demultiplexed

based on the payload type or SSRC ﬁelds. Interleaving packets with diﬀerent RTP media types

but using the same SSRC would introduce several problems:

1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one

were to change encodings and thus acquire a diﬀerent RTP payload type, there would be no

general way of identifying which stream had changed encodings.

2. An SSRC is deﬁned to identify a single timing and sequence number space. Interleaving

multiple payload types would require diﬀerent timing spaces if the media clock rates diﬀer

and would require diﬀerent sequence number spaces to tell which payload type suﬀered packet

loss.

3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and

sequence number space per SSRC and do not carry a payload type ﬁeld.

4. An RTP mixer would not be able to combine interleaved streams of incompatible media into

one stream.

5. Carrying multiple media in one RTP session precludes: the use of diﬀerent network paths or

network resource allocations if appropriate; reception of a subset of the media if desired, for

example just audio if video would exceed the available bandwidth; and receiver implementa-

tions that use separate processes for the diﬀerent media, whereas using separate RTP sessions

permits either single- or multiple-process implementations.

Using a diﬀerent SSRC for each medium but sending them in the same RTP session would avoid

the ﬁrst three problems but not the last two.

On the other hand, multiplexing multiple related sources of the same medium in one RTP session

using diﬀerent SSRC values is the norm for multicast sessions. The problems listed above don’t

apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is

applicable for all of them. It may also be appropriate to multiplex streams of the same medium

using diﬀerent SSRC values in other scenarios where the last two problems do not apply.

5.3 Proﬁle-Speciﬁc Modiﬁcations to the RTP Header

The existing RTP data packet header is believed to be complete for the set of functions required

in common across all the application classes that RTP might support. However, in keeping with

the ALF design principle, the header may be tailored through modiﬁcations or additions deﬁned

Schulzrinne, et al. Standards Track [Page 15]

RFC 3550 RTP July 2003

in a proﬁle speciﬁcation while still allowing proﬁle-independent monitoring and recording tools to

function.

• The marker bit and payload type ﬁeld carry proﬁle-speciﬁc information, but they are allocated

in the ﬁxed header since many applications are expected to need them and might otherwise

have to add another 32-bit word just to hold them. The octet containing these ﬁelds may be

redeﬁned by a proﬁle to suit diﬀerent requirements, for example with more or fewer marker

bits. If there are any marker bits, one should be located in the most signiﬁcant bit of the

octet since proﬁle-independent monitors may be able to observe a correlation between packet

loss patterns and the marker bit.

• Additional information that is required for a particular payload format, such as a video

encoding, should be carried in the payload section of the packet. This might be in a header

that is always present at the start of the payload section, or might be indicated by a reserved

value in the data pattern.

• If a particular class of applications needs additional functionality independent of payload for-

mat, the proﬁle under which those applications operate should deﬁne additional ﬁxed ﬁelds

to follow immediately after the SSRC ﬁeld of the existing ﬁxed header. Those applications will

be able to quickly and directly access the additional ﬁelds while proﬁle-independent monitors

or recorders can still process the RTP packets by interpreting only the ﬁrst twelve octets.

If it turns out that additional functionality is needed in common across all proﬁles, then a new

version of RTP should be deﬁned to make a permanent change to the ﬁxed header.

5.3.1 RTP Header Extension

An extension mechanism is provided to allow individual implementations to experiment with new

payload-format-independent functions that require additional information to be carried in the RTP

data packet header. This mechanism is designed so that the header extension may be ignored by

other interoperating implementations that have not been extended.

Note that this header extension is intended only for limited use. Most potential uses of this

mechanism would be better done another way, using the methods described in the previous section.

For example, a proﬁle-speciﬁc extension to the ﬁxed header is less expensive to process because it is

not conditional nor in a variable location. Additional information required for a particular payload

format should not use this header extension, but should be carried in the payload section of

the packet.

0123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| defined by profile | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| header extension |

| .... |

Schulzrinne, et al. Standards Track [Page 16]

RFC 3550 RTP July 2003

If the X bit in the RTP header is one, a variable-length header extension must be appended to

the RTP header, following the CSRC list if present. The header extension contains a 16-bit length

ﬁeld that counts the number of 32-bit words in the extension, excluding the four-octet extension

header (therefore zero is a valid length). Only a single extension can be appended to the RTP data

header. To allow multiple interoperating implementations to each experiment independently with

diﬀerent header extensions, or to allow a particular implementation to experiment with more than

one type of header extension, the ﬁrst 16 bits of the header extension are left open for distinguishing

identiﬁers or parameters. The format of these 16 bits is to be deﬁned by the proﬁle speciﬁcation

under which the implementations are operating. This RTP speciﬁcation does not deﬁne any header

extensions itself.

6. RTP Control Protocol — RTCP

The RTP control protocol (RTCP) is based on the periodic transmission of control packets to

all participants in the session, using the same distribution mechanism as the data packets. The

underlying protocol must provide multiplexing of the data and control packets, for example using

separate port numbers with UDP. RTCP performs four functions:

1. The primary function is to provide feedback on the quality of the data distribution. This

is an integral part of the RTP’s role as a transport protocol and is related to the ﬂow and

congestion control functions of other transport protocols (see Section 10 on the requirement

for congestion control). The feedback may be directly useful for control of adaptive encodings

[18, 19], but experiments with IP multicasting have shown that it is also critical to get feedback

from the receivers to diagnose faults in the distribution. Sending reception feedback reports

to all participants allows one who is observing problems to evaluate whether those problems

are local or global. With a distribution mechanism like IP multicast, it is also possible for

an entity such as a network service provider who is not otherwise involved in the session

to receive the feedback information and act as a third-party monitor to diagnose network

problems. This feedback function is performed by the RTCP sender and receiver reports,

described below in Section 6.4.

2. RTCP carries a persistent transport-level identiﬁer for an RTP source called the canoni-

cal name or CNAME, Section 6.5.1. Since the SSRC identiﬁer may change if a conﬂict is

discovered or a program is restarted, receivers require the CNAME to keep track of each

participant. Receivers may also require the CNAME to associate multiple data streams from

a given participant in a set of related RTP sessions, for example to synchronize audio and

video. Inter-media synchronization also requires the NTP and RTP timestamps included in

RTCP packets by data senders.

3. The ﬁrst two functions require that all participants send RTCP packets, therefore the rate

must be controlled in order for RTP to scale up to a large number of participants. By having

each participant send its control packets to all the others, each can independently observe the

Schulzrinne, et al. Standards Track [Page 17]

RFC 3550 RTP July 2003

number of participants. This number is used to calculate the rate at which the packets are

sent, as explained in Section 6.2.

4. A fourth, optional function is to convey minimal session control information, for example

participant identiﬁcation to be displayed in the user interface. This is most likely to be useful

in “loosely controlled” sessions where participants enter and leave without membership control

or parameter negotiation. RTCP serves as a convenient channel to reach all the participants,

but it is not necessarily expected to support all the control communication requirements of

an application. A higher-level session control protocol, which is beyond the scope of this

document, may be needed.

Functions 1-3 should be used in all environments, but particularly in the IP multicast environment.

RTP application designers should avoid mechanisms that can only work in unicast mode and will

not scale to larger numbers. Transmission of RTCP may be controlled separately for senders and

receivers, as described in Section 6.2, for cases such as unidirectional links where feedback from

receivers is not possible.

Non-normative note: In the multicast routing approach called Source-Speciﬁc Mul-

ticast (SSM), there is only one sender per “channel” (a source address, group address

pair), and receivers (except for the channel source) cannot use multicast to communi-

cate directly with other channel members. The recommendations here accommodate

SSM only through Section 6.2’s option of turning oﬀ receivers’ RTCP entirely. Future

work will specify adaptation of RTCP for SSM so that feedback from receivers can be

maintained.

6.1 RTCP Packet Format

This speciﬁcation deﬁnes several RTCP packet types to carry a variety of control information:

SR: Sender report, for transmission and reception statistics from participants that are active

senders

RR: Receiver report, for reception statistics from participants that are not active senders and in

combination with SR for active senders reporting on more than 31 sources

SDES: Source description items, including CNAME

BYE: Indicates end of participation

APP: Application-speciﬁc functions

Each RTCP packet begins with a ﬁxed part similar to that of RTP data packets, followed by

structured elements that may be of variable length according to the packet type but must end on

a 32-bit boundary. The alignment requirement and a length ﬁeld in the ﬁxed part of each packet are

included to make RTCP packets “stackable”. Multiple RTCP packets can be concatenated without

any intervening separators to form a compound RTCP packet that is sent in a single packet of the

Schulzrinne, et al. Standards Track [Page 18]

剩余88页未读，继续阅读

wonder_dream

粉丝: 2
资源: 4

RTP协议详解：实时应用的网络传输标准RFC3550

RFC-3550-RTP协议-中文版.pdf

RTP协议文档-RFC3550.pdf中文版

RTP协议-RFC3551

RTP-RTCP协议-RFC3550.pdf

3-RFC3550(中文)-RTP协议中文版1

rfc3984_H.264中文版和RTP-RFC_3550中文版

rtp-rfc3551

rtp.zip_RFC3550 SOURCE CODE_RTP RFC_rtp_rtp 源代码_rtp-tcp

rfc3550-RTP-RTSP协议（英文原版）

rtp -rf3550中文文档

最新资源