RTP：实时应用传输协议详解

需积分: 1 143 浏览量更新于2024-06-22 收藏 505KB PDF 举报

"RFC-3550是一个关于实时应用传输协议(RTP)的技术文档，由互联网工程任务组(IETF)发布，旨在定义一个适用于互联网社区的标准协议，并鼓励讨论和改进建议。该文档由H.Schulzrinne、S.Casner、R.Frederick和V.Jacobson等人撰写，取代了旧版RFC-1889。RTP主要用于在多播或单播网络服务中传输实时数据，如音频、视频或模拟数据，但不处理资源预留和质量保证问题。" RTP（Real-Time Transport Protocol）是互联网上广泛使用的协议，它为实时数据传输提供了一种端到端的网络传输服务。RTP的设计目标是为了支持实时应用，这些应用通常需要低延迟和高可靠性，例如VoIP（Voice over IP）、在线视频会议和流媒体服务。RTP本身并不负责确保服务质量(QoS)，这意味着它不会保证特定的数据传输速率或优先级，而是依赖于下层网络协议来处理这些问题。 RTP协议的核心组成部分包括两部分：数据包传输和控制协议。数据包传输部分处理实际的数据流，而控制协议（通常是指RTP控制协议RTCP，Real-Time Control Protocol）用于监测和控制数据传输的质量，包括同步、错误检测和报告、以及参与者统计信息的交换。 RTP数据包结构包含了一个固定头部和可选的扩展头部，以及负载数据。头部包含了时间戳、序列号、源标识符等信息，这些信息对于接收端正确排序和同步数据流至关重要。时间戳尤其关键，因为它允许接收端根据发送时的时间戳恢复原始数据的时序，这对于音频和视频的播放非常重要。 RTCP则与RTP协同工作，定期发送控制包，以收集关于会话质量的反馈，例如丢包率、网络延迟和Jitter（抖动）。这些信息可以帮助网络管理员或应用程序动态调整传输参数，以适应网络条件的变化。 RTP的灵活性使其能够适应各种网络环境，无论是IP多播，还是单播模式。多播模式下，RTP能够有效地将同一数据流广播给多个接收者，而在单播模式下，RTP可以实现一对一的数据传输。总结来说，RFC-3550定义的RTP是一个基础且关键的协议，它是许多实时通信服务背后的支柱。通过与RTCP的配合，RTP提供了必要的工具，使得实时数据能够在不可预测的网络环境中尽可能顺畅地传输。然而，它并不处理网络拥塞控制和QoS保证，这些通常是通过其他网络协议（如DiffServ或Integrated Services）来实现的。

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]

周期性发送

SR 和 RR

canonical name

规范名

CNAME

为RTP提供一个固定CNAME,不随SSRC改变

必须控制速率，以便可以有序扩充大量的RTP参与

者

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页未读，继续阅读

毕加索解锁

粉丝: 2503
资源: 24

RTP：实时应用传输协议详解

RFC3550_RTP协议中文版.pdf

RTP: A Transport Protocol for Real-Time Applications

RFC3550_RTP：实时应用程序传输协议

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

rfc 3550 中文版

rfc viewer

netty websocket

上述中，info与rfc2833的包差异在哪儿

rfc3550中文版

H265初始化RTP头

最新资源