RTP协议中文版
RTP协议的中文版
RTP协议的中文版协议名称：RTP协议的中文版一、引言RTP（Real-time Transport Protocol）是一种用于实时传输音频和视频数据的协议。
本协议旨在提供一套标准化的通信机制，以确保实时数据的传输和接收的准确性和可靠性。
本文档旨在描述RTP协议的中文版，以便在中文语境下更好地理解和应用该协议。
二、范围本协议适用于所有需要实时传输音频和视频数据的应用场景，包括但不限于实时音视频通话、实时音视频会议、实时音视频直播等。
三、定义3.1 RTP数据包RTP数据包是RTP协议中的基本单位，用于传输音频和视频数据。
每个RTP 数据包由RTP头和有效载荷组成。
RTP头包含序列号、时间戳、同步信源标识符等字段，用于标识和同步数据包。
有效载荷部分包含音频和视频数据。
3.2 RTP会话RTP会话是指在特定时间段内，通过RTP协议传输的一组相关音频和视频数据。
RTP会话由一个或多个RTP参与者组成，可以包含多个RTP流。
3.3 RTP参与者RTP参与者是指通过RTP协议发送和接收音频和视频数据的实体。
每个RTP 参与者都有唯一的同步信源标识符（SSRC），用于标识该参与者的数据包。
四、协议规范4.1 RTP数据包格式RTP数据包采用以下格式：- RTP头部：包含版本号、填充位、扩展位、CSRC计数、标记位、负载类型、序列号、时间戳、同步信源标识符等字段。
- CSRC列表：包含零个或多个CSRC标识符，用于标识参与者。
- 扩展头部：可选字段，用于扩展RTP头部。
- 有效载荷：包含音频和视频数据。
4.2 RTP会话管理RTP会话的建立和终止应遵循以下规范：- 参与者加入：新参与者加入RTP会话时，应向其他参与者发送加入请求，并等待其他参与者的确认。
- 参与者退出：参与者退出RTP会话时，应向其他参与者发送退出通知，并等待其他参与者的确认。
- 同步信源标识符：每个参与者在加入RTP会话时，应生成唯一的同步信源标识符，用于标识该参与者的数据包。
RTP协议中文版
RTP协议中文版一、引言RTP（实时传输协议）是一种用于在互联网上传输音频和视频的协议。
该协议旨在提供实时传输、容错和流控制的功能，以满足实时通信应用的需求。
本协议旨在规范RTP协议的中文版，以便更好地促进国内实时通信领域的发展。
二、定义1. RTP会话：指一组参与者之间的通信，通过RTP协议进行音频和视频的传输。
2. RTP数据包：指通过RTP协议传输的音频和视频数据的单元。
3. RTP流：指一组连续的RTP数据包，用于传输音频或视频数据。
三、协议规范1. RTP协议版本RTP协议的当前版本为2.0。
2. RTP会话的建立2.1 RTP会话的参与者应使用RTP协议的版本2.0。
2.2 RTP会话的参与者应通过SDP（会话描述协议）进行会话的描述和协商。
2.3 RTP会话的参与者应遵循SDP中关于媒体类型、编码格式和传输协议的描述。
3. RTP数据包格式3.1 RTP数据包由头部和有效载荷组成。
3.2 RTP数据包头部包含以下字段：- 版本：指示RTP协议的版本号。
- 填充位：用于填充RTP数据包，以满足特定的传输要求。
- 扩展位：用于指示RTP数据包是否包含扩展头部。
- CSRC计数：指示RTP数据包中CSRC标识符的数量。
- 标志位：用于指示RTP数据包的特性，如是否包含扩展头部、是否加密等。
- 序列号：用于标识RTP数据包的顺序。
- 时间戳：用于同步音频和视频数据。
- SSRC标识符：用于标识RTP数据包的源。
3.3 RTP数据包的有效载荷应根据媒体类型进行适当的编码和压缩。
4. RTP流控制4.1 RTP流控制应根据网络状况和参与者的能力进行适当的调整。
4.2 RTP流控制应遵循RTCP（RTP控制协议）的规范。
4.3 RTP流控制应包括以下功能：- 带宽管理：根据网络带宽的可用性和参与者的需求进行带宽分配。
- 拥塞控制：根据网络拥塞程度进行数据传输的控制。
- 延迟控制：根据实时通信应用的需求进行延迟控制，以保证音频和视频的实时性。
RTP协议的中文版
RTP协议的中文版协议名称：实时传输协议（RTP）中文版一、引言本协议旨在定义实时传输协议（RTP）的中文版，以促进多媒体数据在网络中的实时传输。
本协议适用于音频、视频和其他类型的实时数据传输。
二、定义1. 实时传输协议（RTP）：一种用于在网络上传输实时数据的协议，提供时间戳、序列号和负载类型等功能。
2. RTP数据包：由RTP头部和有效载荷组成的数据单元。
3. RTP头部：包含序列号、时间戳、负载类型和其他控制信息的数据结构。
4. RTP有效载荷：音频、视频或其他实时数据的实际内容。
三、协议规范1. RTP会话的建立和终止a. 参与者应通过协商确定RTP会话的相关参数，如传输协议、端口号和编解码器类型。
b. RTP会话的终止应由参与者中的任一方发起，并通过发送终止消息通知其他参与者。
2. RTP数据包的格式a. RTP数据包由RTP头部和有效载荷组成。
b. RTP头部包含以下字段：i. 版本号：占2比特，用于指示RTP协议的版本。
ii. 填充位：占1比特，用于指示有效载荷是否填充额外的字节。
iii. 扩展位：占1比特，用于指示是否存在RTP头部的扩展字段。
iv. CSRC计数：占4比特，用于指示CSRC标识符的数量。
v. 标记位：占1比特，用于指示RTP数据包是否具有特殊含义。
vi. 负载类型：占7比特，用于指示有效载荷的类型。
vii. 序列号：占16比特，用于标识RTP数据包的顺序。
viii. 时间戳：占32比特，用于标识RTP数据包的时间戳。
ix. SSRC标识符：占32比特，用于唯一标识RTP流。
x. CSRC标识符：占32比特，用于标识贡献源。
3. RTP数据传输a. RTP数据包应按照协商的传输协议进行传输，如UDP或TCP。
b. RTP数据包的传输应具有实时性，以保证音频、视频等实时数据的连续性。
c. RTP数据包的传输应具有可靠性，以保证数据的完整性和准确性。
4. RTP负载类型a. RTP负载类型应根据实际应用需求进行协商，并在RTP头部中进行标识。
RTP协议中文版
RTP协议中文版协议名称：RTP协议中文版一、引言RTP（Real-time Transport Protocol）是一种用于实时传输音频和视频数据的协议。
本协议旨在提供一种标准化的通信方式，以确保实时传输的数据能够在网络中以高效、可靠的方式传输。
本协议的中文版旨在为中文用户提供更便捷的参考和理解。
二、范围本协议适用于所有需要实时传输音频和视频数据的应用程序和系统。
三、术语定义1. RTP数据包（RTP Packet）：包含音频或视频数据的最小传输单位，由RTP头部和有效载荷组成。
2. RTP头部（RTP Header）：包含RTP数据包的相关信息，如序列号、时间戳等。
3. 有效载荷（Payload）：RTP数据包中携带的音频或视频数据。
4. SSRC（Synchronization Source）：用于唯一标识RTP数据流的32位标识符。
5. CSRC（Contributing Source）：用于标识贡献该RTP数据包的参与者。
四、协议规范1. RTP数据包格式RTP数据包由RTP头部和有效载荷组成，其格式如下：```0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | Sequence number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSRC |: :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ```- V：协议版本号，占2位，当前版本为2。
RTP协议的中文版
RTP协议的中文版一、引言本协议旨在规定实时传输协议（Real-time Transport Protocol，简称RTP）的中文版标准格式，以便于中文用户理解和使用该协议。
RTP是一种用于在互联网上传输音频和视频数据的协议，它提供了实时传输和同步的功能，适用于各种实时应用场景，如音视频会议、流媒体传输等。
二、术语和定义2.1 RTP：实时传输协议（Real-time Transport Protocol），用于在互联网上传输音频和视频数据的协议。
2.2 数据包：RTP协议传输的基本单位，包含音频或视频数据以及相关的控制信息。
2.3 SSRC：同步信源标识符（Synchronization Source Identifier），用于唯一标识一个RTP数据流的源。
2.4 RTP会话：一组使用相同的传输协议和同步信源标识符的RTP数据流。
三、协议规范3.1 RTP数据包格式RTP数据包由头部和有效载荷两部分组成。
头部包含版本号、填充位、扩展位、CSRC计数器、标记位、负载类型、序列号、时间戳和同步信源标识符等字段。
有效载荷部分用于存储音频或视频数据。
3.2 RTP会话的建立和维护RTP会话的建立和维护过程应遵循以下步骤：3.2.1 客户端向服务器发送请求，请求建立RTP会话。
3.2.2 服务器接收到请求后，生成一个唯一的同步信源标识符（SSRC）并返回给客户端。
3.2.3 客户端收到服务器返回的SSRC后，将其作为该会话的标识符，并开始发送RTP数据包。
3.2.4 服务器接收到客户端发送的RTP数据包后，根据SSRC标识符进行数据处理和同步。
3.3 RTP数据包的传输和接收RTP数据包的传输和接收过程应遵循以下步骤：3.3.1 发送方将音频或视频数据封装成RTP数据包，并通过网络发送给接收方。
3.3.2 接收方接收到RTP数据包后，根据头部中的同步信源标识符（SSRC）进行数据处理和同步。
3.3.3 接收方根据RTP数据包的时间戳信息，恢复音频或视频数据，并进行播放或显示。
RTP协议中文版
RTP协议中文版1. 引言本协议旨在定义实时传输协议（RTP）的中文版标准格式，以便于中文用户理解和使用。
RTP是一种用于音频和视频传输的协议，广泛应用于实时通信、流媒体和视频会议等领域。
2. 范围本协议适用于所有使用RTP协议进行音频和视频传输的应用程序和设备。
3. 规范参考本协议参考以下文档：- RFC 3550: RTP: A Transport Protocol for Real-Time Applications- RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control- RFC 4566: SDP: Session Description Protocol4. 术语定义在本协议中，以下术语的定义适用于所有章节：- RTP：实时传输协议，一种用于音频和视频传输的协议。
- SSRC：同步信源标识符，用于唯一标识RTP数据流中的同步信源。
- RTCP：实时传输控制协议，用于传输RTP会话的控制信息。
- SDP：会话描述协议，用于描述会话的媒体参数和网络地址等信息。
5. RTP数据包格式RTP数据包由固定长度的头部和可变长度的有效载荷组成。
头部包含以下字段：- 版本（V）：协议版本号，占2位。
- 填充（P）：指示数据包是否有填充字节，占1位。
- 扩展（X）：指示数据包是否包含扩展头部，占1位。
- CSRC计数（CC）：指示CSRC标识符的数量，占4位。
- 标记（M）：用于指示数据包是否为关键帧，占1位。
- 负载类型（PT）：指示有效载荷类型，占7位。
- 序列号（SN）：用于标识RTP数据包的顺序，占16位。
- 时间戳（TS）：用于同步RTP数据流的时间戳，占32位。
- 同步信源标识符（SSRC）：用于唯一标识RTP数据流中的同步信源，占32位。
- CSRC标识符（CSRC）：用于标识参与混合的源，每个CSRC标识符占32位。
英文文献和中文翻译{RTP-实时软件传输协议}
RTP: A Transport Protocol for Real-Time Applications1 IntroductionThis memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, times tamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 10). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network.Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.While RTP is primarily designed to satisfy the needs of multi- participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.This document defines RTP, consisting of two closely-linked parts:[1].The real-time transport protocol (RTP), to carry data that has real-time properties.[2]. The RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RTCP may be sufficient for "loosely controlled" sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an application's control communication requirements. This functionality may be fully or partially subsumed by a separate session control protocol, which is beyond the scope of this document.RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse [1]. That is, RTP is intended to be malleable to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed. Examples are given in Sections 5.3 and 6.3.3.Therefore, in addition to this document, a complete specification of RTP for a particular application will require one or morecompanion documents (see Section 12):[1].A profile specification document, which defines a set of payload type codes and their mapping to payload formats (e.g., media encodings). A profile may also define extensions or modifications to RTP that are specific to a particular class of applications. Typically an application will operate under only one profile. A profile for audio and video data may be found in the companion RFC TBD.[2].Payload format specification documents, which define how a particular payload, such as an audio or video encoding, is to be carried in RTP.A discussion of real-time services and algorithms for their implementation as well as background discussion on some of the RTP design decisions can be found in [2].Several RTP applications, both experimental and commercial, have already been implemented from draft specifications. These applications include audio and video tools along with diagnostic tools such as traffic monitors. Users of these tools number in the thousands. However, the current Internet cannot yet support the full potential demand for real-time services. High-bandwidth services using RTP, such as video, can potentially seriously degrade the quality of service of other network services. Thus, implementors should take appropriate precautions to limit accidental bandwidth usage. Application documentation should clearly outline the limitations and possible operational impact of high-bandwidth real- time services on the Internet and other network services.2 RTP Use ScenariosThe following sections describe some aspects of the use of RTP. The examples were chosen to illustrate the basic operation of applications using RTP, not to limit what RTP may be used for. In these examples, RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion Internet-Draft draft-ietf-avt-profile2.1 Simple Multicast Audio ConferenceA working group of the IETF meets to discuss the latest protocol draft, using the IP multicast services of the Internet for voice communications. Through some allocation mechanism the working group chair obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. If privacy is desired, the data and control packets may be encrypted as specified in Section 9.1, in which case an encryption key must also be generated and distributed. The exact details of these allocation and distribution mechanisms are beyond the scope of RTP.The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet so that senders can change the encoding during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion.The Internet, like other packet networks, occasionally loses andreorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example, chunks of audio are contiguously played out the speaker every 20 ms. This timing reconstruction is performed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimate how many packets are being lost.Since members of the working group join and leave during the conference, it is useful to know who is participating at any moment and how well they are receiving the audio data. For that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodings. In addition to the user name, other identifying information may also be included subject to control bandwidth limits. A site sends the RTCP BYE packet (Section 6.5) when it leaves the conference. 2.2 Audio and Video ConferenceIf both audio and video media are used in a conference, they are transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated.One motivation for this separation is to allow some participants in the conference to receive only one medium if they choose. Furtherexplanation is given in Section 5.2. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTCP packets for both sessions.2.3 Mixers and TranslatorsSo far, we have assumed that all sites want to receive media data in the same format. However, this may not always be appropriate. Consider the case where participants in one area are connected through a low-speed link to the majority of the conference participants who enjoy high-speed network access. Instead of forcing everyone to use a lower-bandwidth, reduced-quality audio encoding, an RTP-level relay called a mixer may be placed near the low-bandwidth area. This mixer resynchronizes incoming audio packets to reconstruct the constant 20 ms spacing generated by the sender, mixes these reconstructed audio streams into a single stream, translates the audio encoding to a lower-bandwidth one and forwards the lower- bandwidth packet stream across the low-speed link. These packets might be unicast to a single recipient or multicast on a different address to multiple recipients. The RTP header includes a means for mixers to identify the sources that contributed to a mixed packet so that correct talker indication can be provided at the receivers.Some of the intended participants in the audio conference may be connected with high bandwidth links but might not be directly reachable via IP multicast. For example, they might be behind an application-level firewall that will not let any IP packets pass. For these sites, mixing may not be necessary, in which case another type of RTP-level relay called a translator may be used. Two translatorsare installed, one on either side of the firewall, with the outside one funneling all multicast packets received through a secure connection to the translator inside the firewall. The translator inside the firewall sends them again as multicast packets to a multicast group restricted to the site's internal network.Mixers and translators may be designed for a variety of purposes. An example is a video mixer that scales the images of individual people in separate video streams and composites them into one video stream to simulate a group scene. Other examples of translation include the connection of a group of hosts speaking only IP/UDP to a group of hosts that understand only ST-II, or the packet-by-packet encoding translation of video streams from individual sources without resynchronization or mixing. Details of the operation of mixers and translators are given in Section 7.中文翻译RTP-----------实时软件传输协议1 介绍实时传输协议RTP，可以对于那些具有实时特征的数据，比如交互式的音频、视频提供端到端的传输服务。
RTP协议中文版
RTP协议中文版一、引言本协议旨在规范实时传输协议（RTP）的使用，以确保数据的实时传输和接收的可靠性。
RTP协议是一种应用层协议，用于在因特网上传输音频和视频数据。
本协议适用于各种实时应用，如语音通信、视频会议和流媒体。
二、范围本协议适用于使用RTP协议进行实时数据传输的所有相关实体，包括发送端、接收端和中间设备。
三、术语定义1. RTP（Real-time Transport Protocol）：实时传输协议，用于在因特网上传输音频和视频数据。
2. SSRC（Synchronization Source）：同步源标识符，用于唯一标识RTP数据流的源。
3. RTP数据包：包含音频或视频数据的RTP协议数据单元。
4. RTCP（RTP Control Protocol）：RTP控制协议，用于传输RTP数据流的控制信息。
5. NTP（Network Time Protocol）：网络时间协议，用于同步RTP数据流的时间戳。
四、协议规范1. RTP数据包格式1.1 RTP数据包由RTP头部和有效载荷组成。
1.2 RTP头部包含以下字段：- 版本号：指示RTP协议的版本。
- 填充位：用于填充RTP头部，以满足特定的传输要求。
- 扩展位：用于指示RTP头部是否包含扩展字段。
- CSRC计数器：指示CSRC列表的长度。
- 标识位：用于指示RTP数据包的类型。
- 序列号：用于标识RTP数据包的顺序。
- 时间戳：用于同步RTP数据流的时间。
- SSRC：用于唯一标识RTP数据流的源。
1.3 有效载荷可以是音频或视频数据。
2. RTP数据传输2.1 RTP数据包通过UDP协议进行传输。
2.2 发送端将RTP数据包封装为UDP数据包，并通过网络发送给接收端。
2.3 接收端接收UDP数据包，并将其解析为RTP数据包。
2.4 接收端根据RTP头部中的时间戳信息进行数据同步和播放。
3. RTCP控制3.1 RTCP协议用于传输RTP数据流的控制信息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
RFC3550RTP：实时应用程序传输协议摘要本文描述RTP（real-time transport protocol），实时传输协议。
RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。
RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。
数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。
RTP和RTCP被设计成和下面的传输层和网络层无关。
协议支持RTP标准的转换器和混合器的使用。
本文的大多数内容和旧版的RFC1889相同。
在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。
为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。
目录（Table of Contents）1. 引言（Introduction）1 1 术语（Terminology）2 RTP使用场景（RTP Use Scenarios）2 1 简单多播音频会议（Simple Multicast Audio Conference）2 2 音频和视频会议（Audio and Video Conference）2 3 混频器和转换器（Mixers and Translators）2 4 分层编码（Layered Encodings）3 定义（Definitions）4 字节序，校正和时间格式（Byte Order, Alignment, and Time Format）5 RTP数据传输协议（RTP Data Transfer Protocol）5 1 RTP固定头域（RTP Fixed Header Fields）5 2 多路复用RTP会话（Multiplexing RTP Sessions）5 3 RTP头的配置文件详细变更（Profile-Specific Modifications to the RTP Header）5 3 1 RTP报头扩展（RTP Header Extension）6 RTP控制协议（RTP Control Protocol）-- RTCP6 1 RTCP包格式（RTCP Packet Format）6 2 RTCP传输间隔（RTCP Transmission Interval）6 2 1 维护会话成员数目（Maintaining the number of session members）6 3 RTCP包的发送与接收规则（RTCP Packet Send and Receive Rules）6 3 1 计算RTCP传输间隔（Computing the RTCP Transmission Interval）6 3 2 初始化（Initialization）6 3 3 接收RTP或RTCP（非BYE)包（Receiving an RTP or Non-BYE RTCP Packet）6 3 4 接收RTCP（BYE）包（Receiving an RTCP BYE Packet）6 3 5 SSRC计时失效（Timing Out an SSRC）6 3 6 关于传输计时器的到期（Expiration of Transmission Timer）6 37 传输一个BYE 包（Transmitting a BYE Packet）6 3 8 更新we_sent（Updating we_sent）6 3 9 分配源描述带宽（Allocation of Source Description Bandwidth）6 4 发送方和接收方报告（Sender and Receiver Reports）6 4 1 SR：发送方报告的RTCP包（SR: Sender report RTCP packet）6 4 2 RR：接收方报告的RTCP包（RR: Receiver Report RTCP Packet）6 4 3 扩展发送方和接收方报告（Extending the Sender and Receiver Reports ）6 4 4 分析发送方和接收方报告（Analyzing Sender and Receiver Reports ）6 5 SDES：源描述RTCP包（SDES: Source description RTCP packet）6 5 1 CNAME：规范终端标识符的SDES数据项(CNAME: Canonical End-Point Identifier SDES Item）6 5 2 NAME：用户名的SDES数据项（NAME: User name SDES item)6 5 3 EMAIL:电子邮件地址的SDES数据项（EMAIL: Electronic Mail Address SDES Item）6 5 4 PHONE：电话号码的SDES数据项（PHONE: Phone Number SDES Item）6 5 5 LOC:地理用户地址的SDES数据项（LOC: Geographic User Location SDES Item）6 5 6 TOOL：应用程序或工具名字的SDES数据项（TOOL: Application or Tool Name SDES Item）6 57 NOTE：通知/状态的SDES数据项（NOTE: Notice/Status SDES Item）6 5 8 PRIV:私有扩展的SDES数据项（PRIV: Private Extensions SDES Item）6 6 BYE：Goodbye RTCP包（BYE: Goodbye RTCP packet）6 7 APP:定义应用程序的RTCP包（APP: Application-Defined RTCP Packet）7 RTP转换器和混频器（RTP Translators and Mixers）7 1 概述（General Description ）7 2 在转换器中的RTCP数据处理（RTCP Processing in Translators）7 3 在混频器中的RTCP数据处理（RTCP Processing in Mixers ）7 4 级联混频器（Cascaded Mixers）8 SSRC标识符的分配和使用（SSRC Identifier Allocation and Use）8 1 冲突概率（Probability of Collision ）8 2 冲突解决和循环检测（Collision Resolution and Loop Detection）8 3 在分层编码中使用（Use with Layered Encodings）9 安全（Security ）9 1 机密性（Confidentiality）9 2 身份验证和消息完整性（Authentication and Message Integrity）10 拥塞控制（Congestion Control）11 网络和传输协议之上的RTP（RTP over Network and Transport Protocols）12 协议常量摘要（Summary of Protocol Constants）12 1 RTCP 包类型（RTCP Packet Types）12 2 SDES 类型（SDES Types）13 RTP概况和负载格式详细说明（RTP Profiles and Payload Format Specifications）14 安全考虑（Security Considerations）15 IANA考虑（IANA Considerations）16 知识产权声明（Intellectual Property Rights Statement）17 鸣谢（Acknowledgments）附录A 算法（Algorithms）附录A 1 RTP数据头有效性检查（RTP Data Header Validity Checks ）附录A 2 RTCP数据头有效性检查（RTCP Header Validity Checks）附录A 3 确定RTP包预期数目和丢失数目（Determining Number of Packets Expected and Lost）附录A 4 生成SDES RTCP包（Generating RTCP SDES Packets）附录A 5 解析RTCP SDES包（Parsing RTCP SDES Packets）附录A 6 生成32位随机标识符（Generating a Random 32-bit Identifier附录A 7 计算RTCP传输间隔（Computing the RTCP Transmission Interval）附录A 8 估测两次到达间隔的抖动（Estimating the Interarrival Jitter）附录B 与RFC1889不同之外（Changes from RFC 1889）参考书目（References）标准化引用（Normative References ）资料性引用（Informative References）作者地址完整的版权声明1.绪论本文详细的介绍实时传输协议RTP，RTP提供带有实时特性的端对端数据传输服务，传输的数据如：交互式的音频和视频。
那些服务包括有效载荷类型定义，序列号，时间戳和传输监测控制。
应用程序在UDP上运行RTP来使用它的多路技术和checksum服务。
2种协议都提供传输协议的部分功能。
不过，RTP可能被其他适当的下层网络和传输协议使用（见11节）。
如果下层网络支持，RTP支持数据使用多播分发机制转发到多个目的地。
注意RTP本身没有提供任何的机制来确保实时的传输或其他的服务质量保证，而是由低层的服务来完成。
它不保证传输或防止乱序传输，它不假定下层网络是否可靠，是否按顺序传送数据包。
RTP包含的序列号允许接受方重构发送方的数据包顺序，但序列号也用来确定一个数据包的正确位置，例如，在视频解码的时候不用按顺序的对数据包进行解码。
但是RTP原先的设计是用来满足多参与者的多媒体会议的需要，它没有限定于专门的应用。
连续数据的储存，交互分布式仿真，动态标记，以及控制和测量应用程序也可能会适合使用RTP。
该文档定义RTP，由2个密切联系的部分组成：○实时传输协议RTP，用于实时传输数据。