RFC3605_RTCP(免费)

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提供带有实时特性的端对端数据传输服务，传输的数据如：交互式的音频和视频。

实时传输协议——RTP协议详细介绍随着以太网音视频桥接(AVB)技术的引入，汽车可支持各种基于音频、视频的流媒体服务。

在流媒体数据传输过程中，为保障音视频流的实时传输，需采用RTP和RTCP协议。

接下来，我们一起来了解下实时传输协议吧！1、什么是RTP？RTP定义：Real-time Transport Protocol，是由IETF的多媒体传输工作小组于1996年在RFC 1889中公布的。

RTP为IP 上的语音、图像等需要实时传输的多媒体数据提供端对端的传输服务，但本身无法保证服务质量（QoS），因此，需要配合实时传输控制协议（RTCP）一起使用。

RTCP定义：Real-time Transport Control Protocol，监控服务质量并传送会话参与者信息，服务器可利用RTCP数据包信息改变传输速率、负载数据类型。

2、RTP相关概念介绍流媒体：使用流式传输技术的连续时基媒体。

使用流式传输可以边下载边播放，无需等待音频或视频数据信息全部下载完成后再播放。

混频器（Mixer）：一种中间系统，将一个或多个源的RTP数据包合成一个新的RTP数据包，然后转发出去。

混频器可能会改变数据包的数据格式，并对各个流组合的新数据包生成一个新SSRC。

转换器（Translator）：一种中间系统，转发RTP数据包但不改变数据包的同步源标识符，可用于通过IP多播无法直接到达的用户区，如在防火墙两端使用转换器，外侧转换器通过安全连接将数据传输到内侧转换器。

RTP利用混频器和转换器完成实时数据传输，混频器接收来自一个或多个发送方的RTP数据包，并把它们组合成一个新的RTP 数据包继续转发。

这个组合数据包使用新的SSRC标识，组合数据包将作为新的发送方加入到RTP传输中。

混频器将不同的媒体流组合在一起，需要通过转换器来对单个媒体流进行操作，可进行编码转换或协议翻译。

典型的RTP数据包传输流程如下图所示，其中S1、S2、S3、S4是数据源的发送端，R4是RTP 数据包的接收端。

浅论GB28181平台视频流武汉烽火众智数字技术有限责任公司目录一、概述 (4)二、国标媒体流简介 (4)2.1视频流的数据要求 (4)2.2视频流编解码要求 (5)2.2.1基于H.264的视频编、解码技术要求 (5)2.2.2基于MPEG-4的视频编/、解码技术要求 (7)2.2.3 SIP信令中的SDP内容规范 (9)2. 3国标视频流示例 (11)三、实际问题浅析 (13)3.1 客户端解码花屏 (13)3.2 解码器无法解码 (15)3.3 画面出现卡顿 (18)四、小论总结 (19)4.1码流的不确定性 (19)4.2以国标为本 (20)一、概述GB/T 28181-2011是2011年由中华人民共和国公安部提出，中国国家标准化管理委员会发布的国家标准。

GB/T 28181-2011的正式实施规定了安全防范影像视频监控联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求。

适用于安全防范视频监控联网系统及城市监控报警联网系统的方案设计、系统检测、验收以及与之相关的设备研发、生产。

虽然该标准不可能一次性解决视频监控联网系统中的所有技术规定，但是比较清晰地定义了建议的通讯模型，重要的数据格式，和既有系统的兼容性方案，以及子系统和外部系统之间的通讯模式。

对大型系统建设，尤其是联网的社会共享性系统建设给出了明确的、可实施的技术标准。

本文主要结合贵州省国标平台项目的实施经验介绍并讨论GB/T 28181-2011中媒体流相关知识。

二、国标媒体流简介下面通过GB28181-2011中的媒体传输和编解码协议两方面，简单介绍下国标对媒体流的技术要求1：2.1视频流的数据要求GB/T 28181-2011中规定媒体流在联网系统IP网络上传输时应采用RFC 3550规定的RTP协议，提供实时数据传输中的时间戳信息及各数据流的同步；应采用RFC 3550规定的RTCP协议，为按序传输数据包提供可靠保证，提供流量控制和拥塞控制。

RTP与RTCP协议介绍转⾃：/113473/25481/本⽂主要介绍RTP与RTCP协议。

author: ZJ 06-11-17Blog:1．流媒体( Streaming Media)1.1流媒体概念流媒体技术是⽹络技术和多媒体技术发展到⼀定阶段的产物。

术语流媒体既可以指在⽹上传输连续时基媒体的流式技术,也可以指使⽤流式技术的连续时基媒体本⾝。

在⽹上传输⾳频、视频等多媒体信息⽬前主要有两种⽅式:下载和流式传输。

采⽤下载⽅式,⽤户需要先下载整个媒体⽂件,然后才能进⾏播放。

由于⽹络带宽的限制,下载常常要花很长时间,所以这种处理⽅式延迟很⼤。

⽽流媒体实现的关键技术是流式传输。

传输之前⾸先对多媒体进⾏预处理(降低质量和⾼效压缩) ,然后使⽤缓存系统来保证数据连续正确地进⾏传输。

使⽤流式传输⽅式,⽤户不必像采⽤下载⽅式那样要等到整个⽂件全部下载完毕,⽽是只需经过⼏秒到⼏⼗秒的启动延时即可在客户端进⾏播放和观看。

此时媒体⽂件的剩余部分将在后台继续下载。

与单纯的下载⽅式相⽐,这种对多媒体⽂件边下载边播放的流式传输⽅式不仅使启动延时⼤幅度地缩短,⽽且对系统缓存容量的需求也⼤⼤降低。

使⽤流式传输的另⼀个好处是使传输那些事先不知道或⽆法知道⼤⼩的媒体数据(如⽹上直播、视频会议等) 成为可能。

到⽬前为⽌,Internet 上使⽤较多的流式视频格式主要有以下三种:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

1.2⽀持流媒体的协议多媒体应⽤的⼀个显著特点是数据量⼤,并且许多应⽤对实时性要求⽐较⾼。

传统的TCP 协议是⼀个⾯向连接的协议,它的重传机制和拥塞控制机制都是不适⽤于实时多媒体传输的。

RTP 是⼀个应⽤型的传输层协议,它并不提供任何传输可靠性的保证和流量的拥塞控制机制。

RTP 位于UDP(User Datagram Protocol) 之上。

文件编号：SHDX/ZS/CZ/JG/005/B/2009中国电信上海公司IPTV机顶盒技术规范V2.2（修订版）1目的本规范是在中国电信集团公司发布的《IPTV机顶盒技术规范V2.0》的基础上，根据中国电信上海公司IPTV业务发展的需求以及IPTV运营的实际情况，进一步调整修订而成的。

本技术规范的增补、修订和解释权归中国电信上海公司所有。

如中国电信上海公司在此之前的文件与本技术规范有矛盾，按此技术规范执行。

本技术规范自发布之日起实施。

2适用范围本技术规范规定了IPTV终端的应用功能、操作要求、终端管理和接口要求等方面的内容。

本规范供中国电信上海公司引入机顶盒终端设备时参照执行。

同时，本规范也为终端厂商进行机顶盒终端设备开发制造提供依据。

3引用文件/标准下列标准所包含的条文，通过本技术要求的引用而构成本技术要求的条文。

在本技术要求出版时，所示版本均为有效。

所有标准都可能推出更新版本，使用本技术要求的各方应探讨使用下列标准最新版本的可能性。

GB13837-2003: 声音和电视广播接收机及有关设备无线电干扰特性限值和测量方法GB8898-2001: 音频、视频及类似电子设备安全要求RFC1889： A Transport Protocol for Real-Time ApplicationsSJ/T10730：电视广播接收机测量方法TR069：CPE WAN Management ProtocolYD/T 965-1998：电信终端设备的安全要求和试验方法YD/T 993-1998: 电信终端设备防雷技术要求及试验方法4定义/术语DHCP Dynamic Host Configuration Protocol 动态主机配置协议DNS Domain Name System 域名系统DRM Digital Rights Management 数字版权管理EPG Electronic Programmer Guide 电子节目单FTP File Transfer Protocol 文件传输协议HTML Hypertext Markup Language 超文本标记语言HTTP Hypertext Transfer Protocol 超文本传输协议HTTPS Hypertext Transfer Protocol Secure 安全超文本传输协议IGMP Internet Group Management Protocol 互连网组管理协议IP Internet Protocol 网络协议MAC Media Access Control 媒体访问控制层MPEG-4 Moving Picture Exp-erts Group 移动图像专家组定义NTP Network Time Protocol 网络时间协议OSD On-screen Display 屏幕视控系统OSS Operation Support System 运营支撑系统PPPoE PPP over Ethernet 基于以太网点对点协议RTCP Real-time Transport Control Protocol 实时传输控制协议RTP Real-time Transport Protocol 实时传输协议RTSP Real-time Transport Streaming Protocol 实时传输流媒体协议SIP Session Initiation Protocol 起始会话协议S/N Signal/Noise 信噪比SOAP imple Object Access Protocol 简单对象访问协议SSL Secure Socket Layer安全套接字层STB Set Top Box 机顶盒TCP Transmission Control Protocol 传输控制协议TFTP Trivial File Transfer Protocol 简单文件传输协议TS Transport Stream 传输流UDP User Datagram Protocol 用户数据报协议UPnP Universal Plug and Play 通用即插即用USB Universal Serial Bu 通用串行总线XML Extensible Markup Language 可扩展标记语言5机顶盒定义IPTV机顶盒终端是指具备网络接入和页面信息浏览、视音频播放等交互式应用功能，可直接连接电视机音响等播放设备的多媒体终端。

RTCP协议详解RTCP协议介绍RTCP概要实时传输控制协议(Real-time ControlProtocol，RTCP)与RTP 共同定义在1996年提出的RFC 1889中，是和 RTP一起工作的控制协议。

RTCP单独运行在低层协议上，由低层协议提供数据与控制包的复用。

在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，如下图所示。

对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

图每个参与者周期性地发送RTCP控制信息包RTCP功能1、为应用程序提供会话质量或者广播性能质量的信息RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。

每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端（和/ 或者）接收端的统计报表。

这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息反映了当前的网络状况，对发送端、接收端或者网络管理员都非常有用。

RT CP规格没有指定应用程序应该使用这些反馈信息做什么，这完全取决于应用程序开发人员。

例如，发送端可以根据反馈信息来调整传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

2、确定 RTP用户源RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonic al Name)标志符CNAME，接收者使用它来追踪一个RTP进程的参加者。

当发现冲突或程序重新启动时，RTP中的同步源标识符SSRC 可能发生改变，接收者可利用CNAME来跟踪参加者。

同时，接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。

当 RTP需要进行音视频同步的时候，接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

Southwest university of science and technology视频信息处置与传输实验报告报告名称RTP-RTCP协议专业班级电子1002班学生姓名学号指导教师实验四RTP-RTCP协议一、实验目的一、了解实时传输协议RTP和实时传输操纵协议RTCP的大体原理；二、学习利用RTP数据报发送实时数据，并接收重组；3、学会利用Wireshark进行抓包，并分析数据。

二、实验内容一、RTP协议报文段的说明语句RTP（Real-time Transport Protocol，实时传输协议）是一个网络传输协议。

RTP报文由两部份组成：报头和有效载荷。

RTP报头格式如图1所示，其中：图1 RTP报头格式V：RTP协议的版本号，占2位，当前协议版本号为2。

P：填充标志，占1位，假设是P=1，那么在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部份。

X：扩展标志，占1位，假设是X=1，那么在RTP报头后跟有一个扩展报头。

CC：CSRC计数器，占4位，指示CSRC 标识符的个数。

M: 标记，占1位，不同的有效载荷有不同的含义，关于视频，标记一帧的终止；关于音频，标记会话的开始。

PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。

序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。

接收者通过序列号来检测报文丢失情形，从头排序报文，恢复数据。

时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。

接收者使历时戳来计算延迟和延迟抖动，并进行同步操纵。

同步信源(SSRC)标识符：占32位，用于标识同步信源。

该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

特约信源(CSRC)标识符：每一个CSRC标识符占32位，能够有0～15个。

每一个CSRC标识了包括在该RTP报文有效载荷中的所有特约信源。

RTCP包括五种数据包类型（RFC3550 Page69）：abbrev. name value(该值RTCP头格式中的PT类型字段)SR sender report 200RR receiver report 201SDES source description 202BYE goodbye 203APP application-defined 204RTCP报文格式如下（RFC3550 Page35）：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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ sender | NTP timestamp, most significant word | info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+下面解释几个难懂的字段NTPNtp把当前时间（自1970.1.1以来的秒数）分为整数部分N和小数部分XNtp高位＝整数部分N＋2208988800UL（其中2208988800UL表示自1900.1.1到1970.1.1的秒数）Ntp低位＝小数部分X*4294967296 (其中4294967296为2^32)RTP时间戳以sample为单位，如音频8000HZ，一个packet为20ms，则两个rtp时间戳的间隔为160. 从rtp时间戳换算成ms的公式为：rtp时间戳*1000／samplerate。

RTP,RTCP,RTSP协议介绍流媒体是边下载边播放的⽅式, 是视频会议、IP电话等应⽤场合的技术基础。

为什么TCP/IP协议就不能满⾜多媒体通信的要求呢？因为TCP有以下4个特点:1.TCP重传机制2.TCP拥塞控制机制3.TCP报⽂头⽐UDP报⽂头要⼤4.TCP的启动速度慢对⽐：IP:数据传输 RTP:多媒体数据实时传输TCP:保证数据传输可靠 RTCP:保证多媒体数据传输的可靠RTP提供时间标志,序列号以及其他能够保证在实时数据传输时处理时间的⽅法RTCP是RTP的控制部分,是⽤来保证服务质量和成员管理的RTSP具体数据传输交给RTP,提供对流的远程控制RSVP预留带宽,提⾼QoS(Quality of Sever)RTP通常使⽤UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上⼯作。

当应⽤程序开始⼀个RTP会话时将使⽤两个端⼝：⼀个给RTP，⼀个给RTCP(RTP port + 1). RTP本⾝并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

通常RTP算法并不作为⼀个独⽴的⽹络层来实现，⽽是作为应⽤程序代码的⼀部分。

RTSP与RTP最⼤的区别在于：RTSP是⼀种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。

RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。

RTSP 默认使⽤554端⼝, ⾮常类似 HTTP 协议的流控制协议, rtsp 的命令总是按照顺序来发送.RTP/RTCP -------------------------RFC3550/RFC3551RTSP --------------------------RFC23262.1 RTP数据协议RTP 为实时应⽤提供端到端的运输，但不提供任何服务质量的保证，服务质量由RTCP来提供。

rtp语音传输协议篇一：RTP协议介绍3.1. RTP协议分析3.1.1. RTP是什么RTP全名是Real-time Transport Protocol（实时传输协议）。

它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。

RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。

RTP 用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。

RTP为Internet 上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。

3.1.2. RTP的协议层次——传输层的子层RTP被划分在传输层，它建立在UDP上。

同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。

RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。

服务质量由RTCP来提供。

3.1.3. RTP协议原理RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输，具体见本文2.2.1RTP数据格式；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

3.1.3.1. RTP的封装版本号（V）：2比特，用来标志使用的RTP版本。

填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。

扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩展头部。

CSRC计数器（CC）：4比特，含有固定头部后面跟着的CSRC的数目。

标记位（M）：1比特,该位的解释由配置文档（Profile）来承担。

载荷类型（PT）：7比特，标识了RTP载荷的类型。

RTP（Real-timeTransportProtocol）是用于Internet上针对多媒体数据流的一种传输协议。

RTP 被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。

RTP 通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。

当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。

RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。

实时传输控制协议RTCP。

RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和拥塞控制服务。

在RTP会话期间，各参与者周期性地传送RTCP包。

RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

6.2.1 RTP数据传输协议RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。

RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。

RTP与RTCP设计成独立传输和网络层。

2.1.1 RTP固定头RTP 头格式如下：-----------------------------------------------------------------------------------------------|V=2|P|X| CC |M| PT | 系列号|-----------------------------------------------------------------------------------------------| 时标|-----------------------------------------------------------------------------------------------| 同步源标识(SSRC) |-----------------------------------------------------------------------------------------------| 作用标识(CSRC) || .... |-----------------------------------------------------------------------------------------------开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。

rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。

RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。

在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。

本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。

二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。

它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。

三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。

2. 发送方主机将报文发送到网络中。

3.中间路由器收到报文后，将报文转发到下一跳路由器。

4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。

5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。

三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。

- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。

- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。

二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。

它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。

1.表格表1 协议列表说明：●Vxworks中网络协议基本与4.4BSD网络兼容，但增强了实时性和某些特性。

●Vxworks支持的网络协议如下，但并没有指明版本号：应用层：NFS FTP TFTP DHCP SNTP TELNET MIB-II HTTP；传输层：TCP UDP；网络层：IP IP多播CIDR RIP OSPF ICMP ARP IGMP；链路层：Ethernet PPP SLIP CSLIP。

各个版本之间差别不是很大，基本的功能都是相同的。

2．各个网络协议的部分RFC标准RFC1122, 标准RFC3168, RFC6093, RFC6528均为建议标准RFC2228, RFC2640, 建议标准RFC2773, 实验性EXPERIMENTALRFC3659, RFC5797建议标准RFC1782, RFC1783, RFC1784, 建议标准RFC1785, INFORMATIONALRFC2347, RFC2348, RFC2349DRAFT STANDARDRFC1349建议标准RFC950, 标准协议RFC4884建议标准RFC5227, RFC5494建议标准RFC1957, international RFC2449, RFC6186建议标准RFC5506, RFC5761, RFC6051, RFC6222建议标准（14）RSTPRFC3265, RFC3853, RFC4320, RFC4916,RFC5393, RFC5621, RFC5626, RFC5630 , RFC5922, RFC5954, RFC6026, RFC6141建议标准RFC4822HTTPS不应与在RFC 2660中定义的安全超文本传输协议（S-HTTP）相混RFC5785建议标准。

[webrtc]rtcp模块中rtt时间计算RTT指 round-trip time，即计算AB两端的往返时延这⾥可以分成两个问题：如何在A端估算A和B之间的RTT时间?如何在B端估算A和B之间的RTT时间?⼀、假设A -> B 发送视频. 那么如何在A端估算A->B之间的RTT时间?对应到webrtc中的实现.何时发送rtcp ?ModuleRtpRtcpImpl::Processif (rtcp_sender_.TimeToSendRTCPReport()) {rtcp_sender_.SendRTCP(GetFeedbackState(), kRtcpReport);}在RTCPSender::TimeToSendRTCPReport 详细说明了RTCP的发送频率.每次发送RTCP时都会计算出下⼀次发送rtcp的时间, 即_nextTimeToSendRTCP.对于 RR和SR包. 计算如下.RTCPSender::PrepareRTCP....if( rtcpPacketTypeFlags & kRtcpRr ||rtcpPacketTypeFlags & kRtcpSr){// generate next time to send a RTCP report// seeded from RTP constructorint32_t random = rand() % 1000;int32_t timeToNext = RTCP_INTERVAL_AUDIO_MS;if(_audio){timeToNext = (RTCP_INTERVAL_AUDIO_MS/2) +(RTCP_INTERVAL_AUDIO_MS*random/1000);}else{uint32_t minIntervalMs = RTCP_INTERVAL_AUDIO_MS;if(_sending){// Calculate bandwidth for video; 360 / send bandwidth in kbit/s.uint32_t send_bitrate_kbit = feedback_state.send_bitrate / 1000;if (send_bitrate_kbit != 0)minIntervalMs = 360000 / send_bitrate_kbit;}if(minIntervalMs > RTCP_INTERVAL_VIDEO_MS){minIntervalMs = RTCP_INTERVAL_VIDEO_MS;}timeToNext = (minIntervalMs/2) + (minIntervalMs*random/1000);}_nextTimeToSendRTCP = _clock->TimeInMilliseconds() + timeToNext;}依赖于随机值, ⽽且⾳视频的时间也不同.A -> 发送SR包.ModuleRtpRtcpImpl::ProcessRTCPSender::SendRTCPRTCPSender::PrepareRTCPRTCPSender::BuildSRPrepareRTCP 中通过_sending(是否是发送端) 状态判定发送SR或RR. SR包中含有发送时的NTP时间戳._lastSendReport 记录NTP时间的中间32位. 可以标识SR包, 也就是B回应RR包中report block的LSR字段(last SR timestamp ), 通过LSR可以查找_lastRTCPTime._lastRTCPTime记录RTCP_NUMBER_OF_SR个数的SR发送时间.这两个数组是⼀⼀对应的._lastRTCPTime[0] = Clock::NtpToMs(NTPsec, NTPfrac);_lastSendReport[0] = (NTPsec << 16) + (NTPfrac >> 16);最后SendToNetwork.B -> 接收到SR包.ModuleRtpRtcpImpl::IncomingRtcpPacketRTCPReceiver::IncomingRTCPPacketRTCPReceiver::HandleSenderReceiverReport在HandleSenderReceiverReport 中保存 SR包中的NTP时间戳_remoteSenderInfo.NTPseconds = rtcpPacket.SR.NTPMostSignificant;_remoteSenderInfo.NTPfraction = rtcpPacket.SR.NTPLeastSignificant;并记录SR包接到时的NTP时间戳_clock->CurrentNtp(_lastReceivedSRNTPsecs, _lastReceivedSRNTPfrac);B -> 发送RR包获取回馈状态, 并发送给AModuleRtpRtcpImpl::Process()if (rtcp_sender_.TimeToSendRTCPReport()) {rtcp_sender_.SendRTCP(GetFeedbackState(), kRtcpReport);}ModuleRtpRtcpImpl::GetFeedbackState()ModuleRtpRtcpImpl::LastReceivedNTPst_rr_ntp_secs 和st_rr_ntp_frac即为上⼀次接收到SR包时, 记录的_clock->CurrentNtp(_lastReceivedSRNTPsecs, _lastReceivedSRNTPfrac); 时间戳.state.remote_sr 通过_remoteSenderInfo.NTPseconds 和 _remoteSenderInfo.NTPfraction, 取中间32位算出.RTCPSender::PrepareReport在这⾥计算延时, 填充到report block中.// get our NTP as late as possible to avoid a race_clock->CurrentNtp(*ntp_secs, *ntp_frac);// Delay since last received reportuint32_t delaySinceLastReceivedSR = 0;if ((feedback_st_rr_ntp_secs != 0) ||(feedback_st_rr_ntp_frac != 0)) {// get the 16 lowest bits of seconds and the 16 higest bits of fractionsuint32_t now=*ntp_secs&0x0000FFFF;now <<=16;now += (*ntp_frac&0xffff0000)>>16;uint32_t receiveTime = feedback_st_rr_ntp_secs&0x0000FFFF;receiveTime <<=16;receiveTime += (feedback_st_rr_ntp_frac&0xffff0000)>>16;delaySinceLastReceivedSR = now-receiveTime;}report_block->delaySinceLastSR = delaySinceLastReceivedSR;report_block->lastSR = feedback_state.remote_sr;report_block->delaySinceLastSR 即为从接到SR包到发送RR包之间的延时.report_block->lastSR 即SR包中NTP时间戳的中间32位. (在A端_lastSendReport数组中记录).A 收到 B的RR包ModuleRtpRtcpImpl::IncomingRtcpPacketRTCPReceiver::IncomingRTCPPacketRTCPReceiver::HandleSenderReceiverReportRTCPReceiver::HandleReportBlock通过 lastSR 到sender模块中取出SR包的发送时间.uint32_t sendTimeMS =_rtpRtcp.SendTimeOfSendReport(stSR);uint32_t delaySinceLastSendReport =rtcpPacket.ReportBlockItem.DelayLastSR;// local NTP time when we received thisuint32_t lastReceivedRRNTPsecs = 0;uint32_t lastReceivedRRNTPfrac = 0;_clock->CurrentNtp(lastReceivedRRNTPsecs, lastReceivedRRNTPfrac);// time when we received this in MSuint32_t receiveTimeMS = Clock::NtpToMs(lastReceivedRRNTPsecs,lastReceivedRRNTPfrac);// Estimate RTTuint32_t d = (delaySinceLastSendReport & 0x0000ffff) * 1000;d /= 65536;d += ((delaySinceLastSendReport & 0xffff0000) >> 16) * 1000;int32_t RTT = 0;if (sendTimeMS > 0) {RTT = receiveTimeMS - d - sendTimeMS;....}注意delay since last SR (DLSR) 的单位是1/65536秒.⼆、另外⼀个问题, 那么如何在B端估算A和B之间的RTT时间?具体实现和SR⾮常类似.1. 开启XR协议 ModuleRtpRtcpImpl::SetRtcpXrRrtrStatus(true)webrtc的⽰例loopback 程序中可以这样启动receive_config.rtp.rtcp_xr.receiver_reference_time_report = true;接受者(B)发送RTCP时, 附加kRtcpXrReceiverReferenceTime发送者(A)发送RTCP时, 附加kRtcpXrDlrrReportBlockRTCPSender::PrepareRTCPif (xrSendReceiverReferenceTimeEnabled_ && !_sending){rtcpPacketTypeFlags |= kRtcpXrReceiverReferenceTime;}if (feedback_state.has_last_xr_rr){rtcpPacketTypeFlags |= kRtcpXrDlrrReportBlock;}B在发送kRtcpXrReceiverReferenceTime, 在last_xr_rr_ map中记录 NTP时间戳中间32位(key) 和发送时间(value).A 收到XR_RR包后在处理kRtcpXrReceiverReferenceTimeCodeRTCPReceiver::HandleXrReceiveReferenceTime_stRR = RTCPUtility::MidNtp(packet.XRReceiverReferenceTimeItem.NTPMostSignificant,packet.XRReceiverReferenceTimeItem.NTPLeastSignificant);_clock->CurrentNtp(_lastReceivedXRNTPsecs, _lastReceivedXRNTPfrac);记录lastRR和收到XR_RR包的时间.A 发送RTCP时, 会检查是否收到过xr_rr包.ModuleRtpRtcpImpl::GetFeedbackState()state.has_last_xr_rr = LastReceivedXrReferenceTimeInfo(&st_xr_rr);bool RTCPReceiver::LastReceivedXrReferenceTimeInfo(RtcpReceiveTimeInfo* info) const {assert(info);CriticalSectionScoped lock(_criticalSectionRTCPReceiver);if (_lastReceivedXRNTPsecs == 0 && _lastReceivedXRNTPfrac == 0) { return false;}info->sourceSSRC = _remoteXRReceiveTimeInfo.sourceSSRC;info->lastRR = _stRR;// Get the delay since last received report (RFC 3611).uint32_t receive_time = RTCPUtility::MidNtp(_lastReceivedXRNTPsecs, _lastReceivedXRNTPfrac);uint32_t ntp_sec = 0;uint32_t ntp_frac = 0;_clock->CurrentNtp(ntp_sec, ntp_frac);uint32_t now = RTCPUtility::MidNtp(ntp_sec, ntp_frac);info->delaySinceLastRR = now - receive_time;return true;}计算出从接到last_xr_rr 到当前的延时.然后发送 kRtcpXrDlrrReportBlock 出去.B 收到XR_SR后RTCPReceiver::HandleXrDlrrReportBlock计算出RTT时间. 保存在xr_rr_rtt_ms_rtp_rtcp_impl_ 测试程序.TEST_F(RtpRtcpImplTest, RttForReceiverOnly)。

rfc中常用的测试协议摘要：1.RFC 简介2.RFC 中常用的测试协议a.网络协议测试1.网络数据包抓取和分析2.网络仿真和测试工具b.应用层协议测试1.HTTP 和HTTPS 测试2.FTP 和FTPS 测试3.SMTP 和SMTPS 测试c.安全协议测试1.TLS 和SSL 测试2.IPsec 测试d.传输协议测试1.TCP 和UDP 测试e.无线网络协议测试1.802.11 无线网络测试正文：RFC（Request for Comments）是一个用于讨论和记录互联网协议的标准文档系列。

在RFC 中，有许多常用的测试协议，这些协议用于确保互联网协议在实际应用中能够正常工作。

本文将详细介绍这些测试协议。

首先，RFC 中包含了大量的网络协议测试。

网络数据包抓取和分析是网络协议测试的基础，这对于诊断网络问题和优化网络性能至关重要。

此外，网络仿真和测试工具也是必不可少的，例如，网络模拟器（如NS-3）和测试平台（如Ixia）可以帮助工程师在实验室环境中模拟实际网络状况，从而对协议进行更严格的测试。

其次，应用层协议测试在RFC 中也占据重要地位。

HTTP 和HTTPS 是Web 应用中最常用的协议，有许多测试工具可以对它们的性能和安全性进行测试，例如，JMeter 和Locust 等负载测试工具。

此外，FTP 和FTPS、SMTP 和SMTPS 等传输协议也是常用的测试对象。

在安全协议方面，RFC 中包含了TLS 和SSL、IPsec 等协议的测试方法。

这些协议对于保护互联网数据传输的安全至关重要，因此需要进行严格的测试以确保其性能和安全性。

传输协议方面，TCP 和UDP 是互联网中最常用的传输协议，它们的测试方法也是RFC 中的重要内容。

TCP 测试关注可靠性和流量控制等方面，而UDP 测试则更注重数据传输速率和丢包率等指标。

最后，无线网络协议测试在RFC 中也有一定的比重。

例如，802.11 无线网络测试是评估无线局域网性能的关键。

RFC3550 RTP 中文RFC 3550 - RTP: A Transport Protocol for Real-Time ApplicationsRFC3550RTP：实时应用程序传输协议摘要本文描述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提供带有实时特性的端对端数据传输服务，传输的数据如：交互式的音频和视频。