RTSP（Real Time Streaming Protocol）实时流传输协议，定义在 RFC2326，是 TCP/IP 协议体系中的一个应用层协议，由哥伦比亚大学、网景和 RealNetworks 公司提交的 IETF RFC 标准。该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成数据传输。HTTP 与 RTSP 相比，HTTP 请求由客户机发出，服务器作出响应；使用 RTSP 时，客户机和服务器都可以发出请求，即 RTSP 可以是双向的。RTSP 是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用 TCP 或 UDP 来传送串流内容，它的语法和运作跟 HTTP 1.1 类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。因为与 HTTP 1.1 的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于 RTSP，并因 RTSP 具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
RTSP 是基于文本的协议，采用 ISO 10646 字符集，使用 UTF-8 编码方案。行以 CRLF 中断，包括消息类型、消息头、消息体和消息长。但接收者本身可将 CR 和 LF 解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用 SDP 作为描述语言。
RTSP 是应用级协议，控制实时数据的发送。RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如 UDP、组播 UDP 与 TCP 提供途径，并为选择基于 RTP 上发送机制提供方法。
RTSP 建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP 充当多媒体服务器的网络远程控制。RTSP 连接没有绑定到传输层连接，如 TCP。在 RTSP 连接期间，RTSP 用户可打开或关闭多个对服务器的可传输连接以发出 RTSP 请求。
一、RTP
RTP（Real-time Transport Protocol）实时传输协议，是一种在 IP 网络上传输音频和视频的网络协议。RTP 用于涉及流媒体的通信和娱乐系统，如电话、视频会议（包括 WebRTC）、电视服务和基于 web 的“一键通话”（push-to-talk）功能。
RTP 通常运行在用户数据报协议（UDP）之上。RTP 与 RTP 控制协议（RTCP）一起使用。RTP 传输媒体流（如音频和视频），而 RTCP 用于监控传输统计数据和服务质量（QoS），并帮助多流的同步。RTP 是 VoIP（Voice over IP） 的技术基础之一，在这种情况下经常与发信协议（如建立网络连接的会话初始化协议（SIP））一起使用。
RTP 由互联网工程任务组（IETF）的音视频传输工作小组开发，并于 1996 年首次发表为 RFC 1889，然后于 2003 年被 RFC 3550 取代。
1.1 RTP 概述
RTP 协议是为流媒体端到端的实时传输而设计的。该协议提供了抖动补偿和数据包丢失和乱序的检测功能，这些在 IP 网络上的 UDP 传输中很常见。RTP 允许通过 IP 组播将数据传输到多个目的地。RTP 被认为是 IP 网络中音频/视频传输的主要标准，并与相关的配置文件和有效载荷格式一起使用。RTP 的设计基于被称为应用层分帧的架构原则，其中协议功能在应用程序中实现，而不是在操作系统的协议栈中实现。
实时多媒体流应用要求信息的及时传递，通常可以容忍一些丢包来达到这一目的。例如，在音频应用中丢包可能会导致音频数据的几分之一秒丢失，使用适当的错误隐藏算法可以使其变得不明显。传输控制协议（TCP）虽然是为 RTP 而制定的标准，但通常不用于 RTP 应用程序，因为相对于时效性，TCP 更看重可靠性。相反，大多数 RTP 实现都基于用户数据报协议（UDP）。其他专门为多媒体会话设计的传输协议有 SCTP（Stream Control Transmission Protocol） 和 DCCP（Datagram Congestion Control Protocol），尽管（截至 2012 年）它们的应用并不广泛。
RTP 是由 IETF 标准组织的音频/视频传输工作组开发的。RTP 与 H.323 和 RTSP 等其他协议一起使用。RTP 规范描述了两个协议：RTP 和 RTCP。RTP 协议用于多媒体数据的传输，RTCP 协议用于周期性地发送控制信息和 QoS 参数。
数据传输协议 RTP 携带实时数据。该协议提供的信息包括时间戳（用于同步）、序列号（用于丢包和重排检测）和表示数据编码格式的有效载荷格式。RTCP 协议用于媒体流之间的服务质量反馈和同步。与 RTP 相比，RTCP 流量的带宽很小，通常在 5% 左右。
RTP 会话通常是使用 H.323、SIP、RTSP 或 Jingle（XMPP）等信令协议在通信的对等体之间发起的。这些协议可以使用会话描述协议来指定会话的参数。
为每个多媒体流建立一个 RTP 会话。音频和视频流可以使用单独的 RTP 会话，使接收端有选择地接收特定流的部分。RTP 和 RTCP 的设计独立于传输协议。应用程序通常使用 UDP，端口号在非特权范围内（1024 到 65535）。当需要可靠的传输协议时，可以使用 SCTP 和 DCCP 。RTP 规范建议 RTP 使用偶数端口号，而相关的 RTCP 会话使用奇数端口号。在多协议复用的应用中，一个端口可以用于 RTP 和 RTCP。
RTP 发送端捕获多媒体数据，然后对帧进行编码，并将其作为带有适当时间戳和递增时间戳和序列号的 RTP 包进行传输。发送端根据连接协商和使用的 RTP 描述文件设置有效载荷类型字段。RTP 接收端检测到丢失的分组，并可能对分组重新排序。它根据负载类型对数据包中的媒体数据进行解码，并将流呈现给用户。
1.2 RTP 数据包格式
RTP 被设计用来传输多种多媒体格式，这允许开发新的格式而无需修订 RTP 标准。为此，通用 RTP 头中不包括协议的特定应用所需的信息。对于每一类应用（例如音频、视频），RTP 都定义了一个配置文件和相关的有效载荷格式。特定应用程序中的每个 RTP 实例都需要一个配置文件和有效载荷格式规范。
该描述文件定义了用于编码有效载荷数据的编解码器，以及 RTP 首部的协议字段有效载荷类型（PT）中有效载荷格式代码的映射。每个配置文件都有几个有效载荷格式规范，每个规范都描述了特定编码数据的传输。音频有效载荷格式的例子有 G.711、G.723、G.726、G.729、GSM、QCELP、MP3 和 DTMF，视频有效载荷的例子有 H.261、H.263、H.264、H.265 和 MPEG-1/MPEG-2。RFC 3016 规定了 MPEG-4 音频/视频流到 RTP 分组的映射，RFC 2429 描述了 H.263 视频有效载荷。
RTP 分组在应用层创建，然后交给传输层。应用程序创建的 RTP 媒体数据的每个单元都始于 RTP 分组头。
RTP 首部的最小大小为 12 字节。在 header 之后，可能存在可选的 header 扩展。紧随其后的是 RTP 有效载荷，其格式由特定类别的应用确定。header 中的字段如下：
V：（2 bits）协议版本。当前版本是 2。
P（填充）：（1 bit）用于表示在 RTP 分组的末尾是否有额外的填充字节。如果设置了填充位，则分组在末尾包含一个或多个额外的填充字节，它们不是有效载荷的一部分。填充的最后八位包含了应该忽略多少个填充字节的计数。某些固定块大小的加密算法或在较低层次的协议数据单元中携带多个 RTP 分组时，可能需要填充。
X（扩展）：（1 bit）如果设置了扩展位，则固定的首部后面紧跟着一个扩展头。扩展头是特定于应用程序或配置文件的。
CC（CSRC 计数）：（4 bits）指示固定头后 CSRC 标识符的个数。
M（标记）：（1 bit）在应用程序级别以特定于配置文件的方式使用的信令。如果设置了该属性，则意味着当前数据与应用程序有某种特殊的相关性。
PT（有效载荷类型）：（7 bits）表示有效载荷的格式，从而决定应用对其的解释。值是特定于配置文件的，可以动态分配。
序列号：（16 bits）每发送一个 RTP 数据包，序列号就加 1。接收端使用序列号来检测丢包和适应乱序交付。对序列号的初始值进行随机化处理，使得对安全实时传输协议的已知明文攻击更加困难。
时间戳：（32 bits）接收端以适当的时间和间隔回放接收到的样本。当存在多个媒体流时，每个媒体流中的时间戳可能是独立的。计时的粒度取决于应用程序。例如，一个音频应用程序每 125μs （8kHz，数字电话中常见的采样率）采样一次，将使用该值作为其时钟分辨率。视频流通常使用 90kHz 时钟。时钟粒度是为应用程序在 RTP 配置文件中指定的细节之一。
SSRC（同步信源标识符）：（32 bits）同步源标识符唯一标识流的来源。同一个 RTP 会话中的同步源是唯一的。
CSRC（提供信源标识符）:（每个 32 bits，条目的数量由 CSRC 计数字段表示）如果有超过 15 个贡献来源，只能识别出 15 个。每个 CSRC 标识了包含在 RTP 报文有效载荷中的所有提供信源。提供信源用来标识对一个 RTP 混合器产生的新包有贡献的所有 RTP 包的源。是指当混合器接收到一个或多个同步信源的 RTP 报文后，经过混合处理产生一个新的组合 RTP 报文，并把混合器作为组合 RTP 报文的 SSRC，将原来所有的 SSRC 都作为 CSRC 传送给接收者，使接受者知道组成组合报文的各个 SSRC。例如，音频会议中，混音器（混合器）会混合讲话者的音频产生一个新的音频分组，CSRC 则标识了当前所有讲话者，这允许在接收端正确地指示出讲话人。
扩展头：（可选，存在由扩展字段表示）第一个 32 位字包含一个配置文件特定的标识符（16 bits）和一个长度说明符（16 bits），该说明符以 32 bits 为单位表示扩展的长度，不包括扩展首部的 32 bits。接下来是扩展头数据。它提供了一种扩展机制，允许各个实现试验新的与有效载荷格式无关的函数，这些函数需要在 RTP 分组头中携带额外的信息。这种机制的设计目的是使其他没有扩展的互操作实现可以忽略扩展头。
二、RTCP
RTCP，即 RTP 控制协议是实时传输协议（RTP）的姊妹协议。RFC 3550 定义了它的基本功能和分组结构。RTCP 提供 RTP 会话的带外统计和控制信息。它与 RTP 合作交付和打包多媒体数据，但本身不传输任何媒体数据。
RTCP 的主要功能是通过周期性地向流媒体用户发送诸如发送字节数、分组数目、分组丢失率、分组延迟变化和往返延迟时间等统计信息，对媒体分发中的服务质量（QoS）提供反馈。应用程序可以使用此信息来控制服务质量参数，可以通过限制流量或使用不同的编解码器。
2.1 RTCP 概述
通常 RTP 会在偶数 UDP 端口上发送，而 RTCP 消息会在下一个更高的奇数端口上发送。
RTCP 本身不提供任何流加密或身份验证方法。这种机制可以用 RFC 3711 中定义的安全实时传输协议（SRTP）来实现。
RTCP 提供了预期在所有 RTP 会话中实现的基本功能：
RTCP 的主要功能是收集会话期间媒体分发质量方面的统计数据，并将这些数据传输给会话媒体源和其他会话参与者。这些信息可以被信源用于自适应媒体编码（编解码器）和传输故障的检测。如果会话通过多播网络传输，则允许非侵入式会话质量监控。
RTCP 为所有会话参与者提供规范的端点标识符（CNAME）。尽管 RTP 流的源标识符（SSRC）应该是唯一的，但源标识符与端点的瞬时绑定可能会在会话期间发生变化。CNAME 建立了跨应用程序实例（多种媒体工具的使用）和第三方监控的端点的唯一标识。
提供会话控制功能。RTCP 是一种方便的访问所有会话参与者的方式，而 RTP 本身不是。RTP 只通过媒体源传输。
RTCP 报告期望由所有参与者发送，即使在可能涉及数千个接收者的多播会话中也是如此。这样的流量将随着参与者的数量成比例地增加。因此，为了避免网络拥塞，协议必须包含会话带宽管理。这是通过动态控制报告传输的频率来实现的。RTCP 带宽利用率一般不应超过会话总带宽的 5%。此外，应该始终为媒体源保留 25% 的 RTCP 带宽，以便在大型会议中，新与会者可以及时收到发送方的 CNAME 标识符。
RTCP 报告间隔是随机的，以防止意外的报告同步。建议每个站点上报 RTCP 的最小时间间隔为 5 秒。
2.2 RTCP 数据包格式
每个 RTCP 分组都以一个固定的部分开始，类似于 RTP 分组，后面是一些结构元素，根据分组类型的不同，长度可能是可变的，但必须在 32 位边界上结束。在每个分组的固定部分中包括对齐要求和长度字段，以使 RTCP 分组“可堆叠”。多个 RTCP 分组可以在没有任何分隔符的情况下连接起来，形成复合的 RTCP 分组（多个报告可以连接成一个复合的 RTCP 数据包，每个都有自己的包头），然后使用底层协议（如 UDP）的单个分组发送。复合分组中各个 RTCP 分组的数目是不明确的，因为底层协议需要提供一个总长度，以确定复合分组的结束。
2.2.1 RTCP 数据包头
Version（版本）：（2 bits）RTP 版本号，RTCP 报文中的版本号与 RTP 数据包中的版本号相同。
P（填充）：（1 bits）如果设置了填充位，则该 RTCP 分组在末尾包含一些额外的填充字节，这些字节不是控制信息的一部分，但包含在 length 字段中。填充的最后一个字节是应该忽略的填充字节的数量，包括它自己（它是 4 的倍数）。某些固定块大小的加密算法可能需要填充。
RC（接收报告计数）：（5 bits）该数据包中包含的接收报告块的数量。值 0 是有效的。
PT（数据包类型）：（8 bits）包含一个常量，用于标识RTCP数据包类型。
Length（长度）：（16 bits）该 RTCP 报文的长度（包括首部和任何填充），32 位字减 1（偏移量 1 使零成为有效长度，从而避免扫描复合 RTCP 分组时可能出现的无限循环，而计数 32 位字则避免了对 4 的倍数进行有效性检查）。
SSRC（同步源标识符）：（32 bits）同步源标识符唯一标识流的来源。
2.2.2 RTCP 数据包种类
RTCP 区分多种类型的数据包：发送者报告（sender report）、接收者报告（receiver report）、源描述（source description）和再见(（goodbye）。此外，该协议是可扩展的，允许发送特定应用的 RTCP 报文。RFC 3611 引入的扩展报告包类型是 RTCP 的一种基于标准的扩展。
2.2.2.1 发送者报告 SR
发送者报告由会话中活跃的发送者周期性发送，用于报告该时间间隔内所有 RTP 包发送和接收的统计情况。发送者报告包含两个不同的时间戳，一个是绝对时间戳，使用 NTP （Network Time Protocol，网络时间协议）的时间戳格式表示（以秒为单位，相对于 1900 年 1 月 1 日午夜的 UTC 时间），另一个是 RTP 时间戳，与 NTP 时间戳对应的时间相同，但其单位和随机偏移量与发送者报告中描述的数据包中的 RTP 时间戳相同。绝对时间戳允许接收方同步 RTP 消息。当音频和视频同时传输时，这一点尤为重要，因为音频和视频流使用独立的相对时间戳。
NTP 时间戳：（64 bits）表示该报告发送时的 wallclock（绝对日期和时间，使用网络时间协议 NTP 的时间戳格式表示，以秒表示相对于 1900 年 1 月 1 日 0 时 UTC 的时间）时间，以便它可以与其他接收方返回的接收报告中的时间戳结合使用，以测量到这些接收方的往返传播。接收端应该预料到时间戳的测量精度可能远小于 NTP 时间戳的分辨率。没有指出时间戳的测量不确定性，因为它可能是未知的。在没有 wallclock 时间概念的系统上，但有一些系统特定的时钟，如“系统正常运行时间”，发送端可以使用该时钟作为参考来计算相对的 NTP 时间戳。选择一个常用的时钟是很重要的，这样如果使用不同的实现来产生多媒体会话的各个流，那么所有的实现都会使用相同的时钟。在 2036 年之前，相对时间戳和绝对时间戳的高位会有所不同，因此（无效）比较会显示出很大的差异；人们希望到那时相对时间戳将不再需要。没有 wallclock 或 elapsed time（运行时间）概念的发送端可以将 NTP 时间戳设置为 0。
wallclock 时间使用网络时间协议（NTP）的时间戳格式表示，以秒为单位，相对于 1900 年 1 月 1 日 0 时 UTC。全分辨率 NTP 时间戳是一个 64 位无符号定点数，前 32 位为整数部分，后 32 位为小数部分。在一些更紧凑的表示形式字段中，只使用中间的 32 位，也就是说，整数部分的低 16 位和小数部分的高 16 位。
RTP 时间戳：（32 bits）对应于与 NTP 时间戳相同的时间，但单位与数据包中的 RTP 时间戳具有相同的随机偏移量。这种对应关系可用于 NTP 时间戳已同步的源的媒体内和媒体间同步，也可用于媒体无关的接收端来估计 RTP 时钟频率。请注意，在大多数情况下，此时间戳不会与任何相邻数据包中的 RTP 时间戳相等。相反，它必须从相应的 NTP 时间戳计算出来，利用 RTP 时间戳计数器和实时时间之间的关系，实时时间是通过定期检查某个采样瞬间的 wallclock 时间来维护的。
发送者 RTP 数据包计数：（32 bits）从开始传输到 SR 报文产生为止，发送者发送的 RTP 数据包总数。如果发送者更改其 SSRC 标识，则该计数将被重置。
发送者 RTP 数据包有效载荷计数：（32 bits）自 RTP 数据包开始传输到 SR 数据包生成为止，发送者在 RTP 数据包中传输的负载字节数（即不包括 RTP 头或填充）。如果发送者更改其 SSRC 标识，则该计数将被重置。该字段可用于估计平均有效载荷数据速率。
接下来的部分包含零个或多个报告块，这取决于自上次报告以来发送者监听到源的数量。每个报告块传递来自同一个同步源的 RTP 报文的统计信息。当一个源由于冲突而改变它的 SSRC 标识符时不携带统计信息。这些统计信息如下：
SSRC_n（源标识符）：（32 bits）此报告块中的信息所属的源的 SSRC 标识符。
RTP 数据包丢失百分比：（8 bits）从源 SSRC_n 发送上一个 SR 或 RR 报文以来，RTP 数据包丢失的百分比，用丢失百分比乘以 256 后的整数部分填充字段。这个百分比被定义为丢失的包数除以预期的包数，如果由于重复而丢失为负，则丢失百分比设置为零。
累计丢包计数：（24 bits）从接收开始以来，从源 SSRC_n 丢失的 RTP 数据包总数。这个数字定义为期望的包数减去实际收到的包数，其中收到的包数包括任何延迟或重复的包数。因此，延迟到达的数据包不被计算为丢失，如果有重复的数据包，则丢失可能为负。预期的包数定义为接收到的扩展的最后序列号（如 next 所定义）减去接收到的初始序列号。
接收到的扩展最高序列号：（32 bits）低 16 位包含源 SSRC_n 收到的 RTP 数据包的最高序列号，高 16 位对该序列号进行了相应的序列号循环数的扩展，注意，如果同一会话中的不同接收方的起始时间差异很大，则它们将生成不同的序列号扩展。
数据包到达时延抖动 J：（32 bits）RTP 数据包到达间隔时间的统计方差的估计值，用时间戳单位度量并表示为无符号整数。数据包到达时延抖动 J 定义为一对包在接收端与发送端之间的包间距差 D 的平均偏差（平滑绝对值）。如下式所示，这相当于两个数据包的“相对传输时间”之差；相对传输时间是指包的 RTP 时间戳和接收方到达时的时钟之间的差值，以相同的单位测量。
如果 Si 是数据包 i 的 RTP 时间戳，Ri 是数据包 i 的 RTP 时间戳单位的到达时间，那么对于两个数据包 i 和 j，D 可以表示为：
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
当从源 SSRC_n 接收到每个数据包 i 时，根据公式，使用该数据包和前一个数据包 i-1 的这个差值 D 数据包到达时延抖动 J：
J=J+(|D(i-1,i)|-J)/16
每当发出报告时，对 J 的当前值进行采样。
该算法是最优一阶估计器，增益参数 1/16 在保持合理收敛速度的同时具有较好的降噪率。
上一个 SR 时间戳（LSR）：（32 bits）NTP 时间戳中 64 位的中间 32 位作为来自源 SSRC_n 的最新 RTCP 发送者报告（SR）包的一部分接收并使用。如果还没有收到 SR，则该字段置零。
自上次 SR 以来的延迟（DLSR）：（32 bits）从源 SSRC_n 收到最后一个 SR 报文到发送此报告块之间的延迟，以 1/65536 秒为单位。如果还没有收到来自 SSRC_n 的 SR 报文，则将 DLSR 字段置零。
2.2.2.2 接收者报告 RR
接收者报告是被动参与者，那些不发送 RTP 包的接收者。该报告告知发送方和其他接收方服务质量。
RR（receiver report）报文的格式与 SR 报文相同，不同之处是报文类型字段中包含固定的 201，而且发送方信息的 5 个字（分别是 NTP 和 RTP 时间戳以及发送方的包数和字节数）被省略。其余字段的含义与 SR 报文相同。
当没有数据传输或接收需要报告时，一个空 RR 包（RC = 0）被放在复合 RTCP 包的头部。
如果应该定期报告关于发送者或接收者的附加信息，profile 应该为发送者报告和接收者定义特定于 profile 或应用程序的扩展。这个方法应该优先于定义另一种 RTCP 数据包类型，因为它需要更少的开销：
- 数据包中的字节数更少（没有 RTCP 报头或 SSRC 字段）；
- 更简单和更快的解析，因为在该 profile 下运行的应用程序将被编程为在接收报告之后始终期望扩展字段位于直接可访问的位置。
2.2.2.3 来源说明 SDES
来源说明消息用于向会话参与者发送 CNAME 项。它还可以用于提供额外的信息，如所有者的姓名、电子邮件地址、电话号码和地址或者源的控制者。
每个块包含一个 SSRC/CSRC 标识符，后面是一个包含零个或多个条目的列表，其中包含关于 SSRC/CSRC 的信息。每个块都从 32 位边界开始。每一项由 8 位类型字段、描述文本长度的 8 位字节数（因此，不包括这个两个字节的头）和文本本身组成。注意，文本不能超过 255 字节，但这与限制 RTCP 带宽消耗的需要是一致的。文本按国际标准化组织 10646 标准附件 F 指定的 UTF-2 编码编码。这种编码也称为 UTF-8 或 UTF-FSS。
项是连续的，也就是说，项没有单独填充到 32 位边界。文本不是空终止的，因为一些多字节编码包含空字节。每个块中的项列表由一个或多个空字节结束，第一个空字节被解释为 0 的项类型，以表示列表的结束，其余的根据需要填充到下一个 32 位边界。零项（四个空字节）的块是有效的，但无用。
终端系统发送一个 SDES 包，其中包含自己的源标识符（与固定 RTP 报头中的 SSRC 相同）。混合器为它正在接收的每个源发送一个包含块的 SDES 包。
只有 CNAME 项是必选的。
CNAME：规范端点标识符 SDES 项
CNAME 标识符具有以下属性：
- 因为随机分配的 SSRC 标识符可能在发现冲突或重新启动程序时发生变化，所以需要 CNAME 项提供从 SSRC 标识符到源标识符的绑定，该绑定保持不变。
- 与 SSRC 标识符一样，CNAME 标识符在一个 RTP 会话中的所有参与者之间也应该是唯一的。
- 为了在一组相关 RTP 会话中的一个参与者使用的多个媒体工具之间提供绑定，应该为该参与者固定 CNAME。
- 为了方便第三方监控，CNAME 应该适合程序或人定位源。
因此，CNAME 应该通过算法生成，而不是在可能的情况下手动输入。为了满足这些要求，除非 profile 指定了替代语法或语义，否则应该使用以下格式。CNAME 项的格式应该是“user@host”，如果用户名在单用户系统中不可用，则应该是“host”。对于这两种格式，“host”要么是实时数据来源的主机的完全限定域名，按照 RFC 1034、RFC 1035 和 RFC 1123 第 2.1 节规定的规则进行格式化；或用于 RTP 通信的接口上主机数字地址的标准 ASCII 表示形式。例如，IPv4 的标准 ASCII 表示形式是“点分十进制”。其他地址类型应该具有相互唯一的 ASCII 表示。完全限定的域名对人类观察者来说更方便，并且可能避免另外发送 NAME 项的需要，但是在某些运行环境中可能很难或不可能可靠地获得它。可能在这种环境中运行的应用程序应该使用地址的 ASCII 表示形式。
对于多用户系统，例如 “[email protected]” 或 “[email protected]”。在没有用户名的系统上，示例是 “sleepy.megacorp.com” 或 “192.0.2.89”。
NAME：用户名 SDES 项
这是用来描述来源的真实名称，例如，“John Doe, Bit Recycler, Megacorp”。它可以是用户想要的任何形式。对于会议等应用程序，这种形式的名称可能最适合显示在与会者列表中，因此可能是 CNAME 以外最频繁发送的项目。profile 可以建立这样的优先级。NAME 值至少在会话期间保持不变。不应指望它在所有与会者中是独一无二的。
EMAIL：电子邮件地址 SDES 项
邮件地址按照 RFC 822 格式，例如“[email protected]”。期望 EMAIL 值在会话期间保持不变。
PHONE：电话号码 SDES 项
电话号码格式应该用加号代替国际接入码。例如，美国的一个号码是“+1 908 555 1212”。
LOC：地理用户位置 SDES 项
根据应用程序的不同，这一项的详细程度不同。对于会议应用程序，像“Murray Hill, New Jersey”这样的字符串可能就足够了，而对于有源标记系统，像“Room 2A244, AT&T BL MH”这样的字符串可能更合适。细节的程度留给实现或用户，但格式和内容可以由 profile 规定。LOC 值期望在会话期间保持不变，移动主机除外。
TOOL：应用程序或工具名称 SDES 项
一个字符串，给出生成流的应用程序的名称和可能的版本，例如"videotool 1.2"。此信息可能对调试有用，并且类似于 Mailer 或 Mail-System-Version SMTP 头。TOOL 值在会话期间应该保持不变。
NOTE: 通知/状态 SDES 项
建议对此项使用以下语义，但这些或其他语义可以由 profile 显式定义。备注项用于描述信息源当前状态的瞬态消息，例如，“在电话中，不能通话”。或者，在研讨会上，这个项目可以用来传达演讲的标题。它应该只用于携带异常信息，而不应该被所有参与者例行地包含，因为这将减慢接收报告和 CNAME 的发送速度，从而损害协议的性能。
PRIV：私有扩展 SDES 项
此项用于定义实验性或特定于应用程序的 SDES 扩展。项包含一个由长度字符串对组成的前缀，后面是填充项的剩余部分并携带所需信息的值字符串。前缀长度字段为 8 位长。前缀字符串是定义 PRIV 项的人选择的名称，使其相对于该应用程序可能接收的其他 PRIV 项是唯一的。如果需要，应用程序创建者可以选择使用应用程序名称加上额外的子类型标识。或者，建议其他人根据它们所代表的实体选择名称，然后在该实体中协调名称的使用。
注意，前缀占用了该项 255 字节的总长度中的一些空间，因此应该尽可能地保持前缀短。SDES PRIV 前缀将不会被 IANA 注册。如果某种形式的 PRIV 项目被证明是通用的，那么应该为它分配一个在 IANA 注册的常规 SDES 项目类型，这样就不需要前缀了。这简化了使用，提高了传输效率。
2.2.2.4 再见 BYE
源发送 BYE 消息关闭流。它允许终端宣布它将要离开会话。尽管其他源可以检测到源的缺失，但此消息是一个直接通知。它对媒体混合器也很有用。
如果一个 BYE 分组被一个混合器接收到，混合器应该转发 SSRC/CSRC 标识符不变的 BYE 分组。如果一个混合器关闭了，它应该发送一个 BYE 包，列出它处理的所有贡献源，以及它自己的 SSRC 标识符。可选的，BYE 包可以包括一个 8 位的字节数，后面跟着许多字节的文本，表明离开的原因，例如，“相机故障”或“RTP循环检测”。该字符串的编码与 SDES 中描述的相同。如果字符串填充到下一个 32 位边界，则字符串不以空结束。否则，BYE 分组必须向下一个 32 位边界填充 null 字节。该填充与 RTCP 首部中的 P 比特位表示的填充是分开的。
2.2.2.5 应用特定消息 APP
特定于应用程序的消息提供了一种机制来设计特定于应用程序的 RTCP 协议扩展。
APP 数据包的目的是在开发新应用程序和新功能时试验性使用，不需要注册数据包类型值。名称未知的应用程序数据包应该被忽略。经过测试，如果有理由更广泛地使用，建议重新定义每个 APP 分组，去掉 subtype 和 name 字段，并使用 RTCP 分组类型向 IANA 注册。
子类型：（5 bits）可以用作子类型，以允许一组应用程序数据包在一个唯一的名称下定义，或用于任何应用程序依赖的数据。
名称：（4 字节）定义一组应用程序数据包的人选择的名称，与该应用程序可能收到的其他应用程序数据包相比，该名称是唯一的。应用程序创建者可以选择使用应用程序名称，然后协调子类型值的分配，以便为应用程序定义新的数据包类型。或者，建议其他人根据他们所代表的实体选择一个名称，然后在该实体内协调该名称的使用。这个名称被解释为由四个 ASCII 字符组成的序列，大写和小写字符被视为不同的。
依赖于应用程序的数据：（可变长度）依赖于应用程序的数据可能出现在应用程序数据包中，也可能不出现。它由应用程序解释，而不是 RTP 本身。它必须是 32 位长的倍数。
三、RTSP
RTSP 协议用于在端点之间建立和控制媒体会话。客户端发出播放、录制和暂停等命令，以便实时控制从服务器到客户端的流媒体（视频点播）或从客户端到服务器的流媒体（语音录制）。
3.1 RTSP 历史
RTSP 是由 RealNetworks、Netscape 和哥伦比亚大学开发的。1996 年 10 月，Netscape 和 Progressive Networks 向 IETF（互联网工程任务组） 提交了第一份草案。随后，哥伦比亚大学的 Henning Schulzrinne 在 1996 年 12 月提交了“RTSP’”(“RTSP prime”)。IETF 的多方多媒体会话控制工作组（MMUSIC 工作组）合并了这两个草案以进行标准化，工作组还发布了进一步的草案。RTSP 的建议标准于 1998 年发布为 RFC 2326。RTSP 2.0 于 2016 年作为 RFC 7826 发布，取代了 RTSP 1.0。RTSP 2.0 是在 RTSP 1.0 的基础上发展起来的，但除了基本的版本协商机制外，没有向后兼容，目前仍是一个“建议标准”。
3.2 RTSP 协议
虽然在某些方面与 HTTP 类似，但 RTSP 定义了控制多媒体播放时有用的控制序列。HTTP 是无状态的，而 RTSP 是有状态的；标识符在需要跟踪并发会话时使用。像 HTTP 一样，RTSP 使用 TCP 来维护端到端连接，虽然大多数 RTSP 控制消息是由客户端发送到服务器，但有些命令是反向传播的（即从服务器到客户端）。
下面介绍一些基本的 RTSP 请求。还有一些典型的 HTTP 请求，如 OPTIONS 请求。TCP 和 UDP 的默认传输层端口号都是 554，后者很少用于控制请求。
3.2.1 OPTIONS
OPTIONS 请求返回服务器将接受的请求类型。
C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
3.2.2 DESCRIBE
DESCRIBE 方法从服务器检索表示的描述或媒体对象，这些资源通过请求统一资源定位符（URL）识别。此方法可能结合使用 Accept 首部域来指定客户端理解的描述格式。服务器端用被请求资源的描述对客户端作出响应。 DESCRIBE 的答复-响应对（reply-response pair）组成了 RTSP 的媒体初始化阶段。
C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 2
S->C: RTSP/1.0 200 OK
CSeq: 2
Content-Base: rtsp://example.com/media.mp4
Content-Type: application/sdp
Content-Length: 460
m=video 0 RTP/AVP 96
a=control:streamid=0
a=range:npt=0-7.741000
a=length:npt=7.741000
a=rtpmap:96 MP4V-ES/5544
a=mimetype:string;"video/MP4V-ES"
a=AvgBitRate:integer;304018
a=StreamName:string;"hinted video track"
m=audio 0 RTP/AVP 97
a=control:streamid=1
a=range:npt=0-7.712000
a=length:npt=7.712000
a=rtpmap:97 mpeg4-generic/32000/2
a=mimetype:string;"audio/mpeg4-generic"
a=AvgBitRate:integer;65790
a=StreamName:string;"hinted audio track"
3.2.3 SETUP
SETUP 请求指定单个媒体流必须如何传输。这必须在发送 PLAY 请求之前完成。该请求包含媒体流 URL 和传输说明符。这个标识符通常包括一个用于接收 RTP 数据（音频或视频）的本地端口，以及另一个用于接收 RTCP 数据（元信息）的本地端口。服务器的应答通常确认所选择的参数，并填写缺失的部分，例如服务器所选择的端口。在发送聚合播放请求之前，每个媒体流都必须使用 SETUP 进行配置。
C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001
S->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
Session: 12345678
C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD
Session: 12345678
3.2.4 PLAY
PLAY 请求将导致一个或所有媒体流被播放。PLAY 请求可以通过发送多个 PLAY 请求进行堆叠。URL 可以是聚合 URL（播放所有媒体流），也可以是单个媒体流 URL（只播放该媒体流）。可以指定一个范围。如果没有指定范围，流将从头播放到尾；如果流暂停，则从暂停的地方重新开始播放。
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Range: npt=5-20
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
3.2.5 PAUSE
PAUSE 请求暂时停止一个或所有媒体流，以便稍后通过 PLAY 请求恢复。该请求包含聚合或媒体流 URL。暂停请求的范围参数指定何时暂停。当 range 参数被省略时，会立即并无限期地暂停。
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 5
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 5
Session: 12345678
3.2.6 TEARDOWN
TEARDOWN 请求用于终止会话。它停止所有媒体流并释放服务器上所有与会话相关的数据。
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 8
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 8
3.2.7 GET_PARAMETER
GET_PARAMETER 请求检索 URI 中指定的表示或流的参数值。回复和响应的内容留给实现。没有实体主体的 GET_PARAMETER 可用于测试客户端或服务器是否还“活着”（“ping”）。
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 9
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 9
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
3.2.8 SET_PARAMETER
此方法请求为 URI 指定的表示或流设置参数的值。
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 10
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 10
Content-length: 10
Content-type: text/parameters
barparam
四、实例分析
下面一段 Log 是使用抓包工具 Wireshark 抓取的 RTSP 视频流从建立到结束的全过程。涵盖了 RTSP、RTP 和 RTCP 协议的数据包，同时也可以较为直观的看出 RTSP 整个建立到结束的流程。
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.43.147 192.168.43.1 TCP 66 49515 → 8554 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
2 0.006807 192.168.43.1 192.168.43.147 TCP 66 8554 → 49515 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1 WS=256
3 0.006869 192.168.43.147 192.168.43.1 TCP 54 49515 → 8554 [ACK] Seq=1 Ack=1 Win=131328 Len=0
4 0.006920 192.168.43.147 192.168.43.1 RTSP 181 OPTIONS rtsp://192.168.43.1:8554/video RTSP/1.0
5 0.010321 192.168.43.1 192.168.43.147 TCP 54 8554 → 49515 [ACK] Seq=1 Ack=128 Win=87808 Len=0
6 0.012485 192.168.43.1 192.168.43.147 RTSP 132 Reply: RTSP/1.0 200 OK
7 0.012550 192.168.43.147 192.168.43.1 RTSP 207 DESCRIBE rtsp://192.168.43.1:8554/video RTSP/1.0
8 0.016664 192.168.43.1 192.168.43.147 RTSP/SDP 559 Reply: RTSP/1.0 200 OK
9 0.017597 192.168.43.147 192.168.43.1 RTSP 238 SETUP rtsp://192.168.43.1:8554/video/track0 RTSP/1.0
10 0.021702 192.168.43.1 192.168.43.147 RTSP 174 Reply: RTSP/1.0 200 OK
11 0.022250 192.168.43.147 192.168.43.1 RTSP 254 SETUP rtsp://192.168.43.1:8554/video/track1 RTSP/1.0
12 0.028242 192.168.43.1 192.168.43.147 RTSP 174 Reply: RTSP/1.0 200 OK
13 0.028491 192.168.43.147 192.168.43.1 RTP 46 Unknown RTP version 3
14 0.028558 192.168.43.147 192.168.43.1 RTCP 46 57887 → 49559 Len=4
15 0.028589 192.168.43.147 192.168.43.1 RTP 46 Unknown RTP version 3
16 0.028611 192.168.43.147 192.168.43.1 RTCP 46 57887 → 49559 Len=4
17 0.028656 192.168.43.147 192.168.43.1 RTP 46 Unknown RTP version 3
18 0.028703 192.168.43.147 192.168.43.1 RTCP 46 57889 → 55747 Len=4
19 0.028730 192.168.43.147 192.168.43.1 RTP 46 Unknown RTP version 3
20 0.028751 192.168.43.147 192.168.43.1 RTCP 46 57889 → 55747 Len=4
21 0.028795 192.168.43.147 192.168.43.1 RTSP 213 PLAY rtsp://192.168.43.1:8554/video RTSP/1.0
22 0.037557 192.168.43.1 192.168.43.147 RTSP 129 Reply: RTSP/1.0 200 OK
23 0.086202 192.168.43.147 192.168.43.1 TCP 54 49515 → 8554 [ACK] Seq=824 Ack=899 Win=130304 Len=0
24 0.301375 192.168.43.147 192.168.100.53 TCP 66 49511 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
25 0.928478 192.168.43.1 192.168.43.147 RTP 71 PT=DynamicRTP-Type-96, SSRC=0x2BB75BE5, Seq=37838, Time=4225410, Mark
(RTP)......
468 2.371754 192.168.43.147 192.168.43.1 RTCP 94 Receiver Report Source description
469 2.376858 192.168.43.1 192.168.43.147 RTP 1506 PT=DynamicRTP-Type-96, SSRC=0x2BB75BE5, Seq=38132, Time=4380030
(RTP)......
483 2.466966 192.168.43.147 192.168.43.1 RTCP 94 Receiver Report Source description
484 2.481548 192.168.43.1 192.168.43.147 RTP 337 PT=DynamicRTP-Type-97, SSRC=0x6C931156, Seq=50548, Time=33689357, Mark
(RTP)......
697 3.407428 192.168.43.1 192.168.43.147 RTP 341 PT=DynamicRTP-Type-97, SSRC=0x6C931156, Seq=50631, Time=2189212, Mark
698 3.411393 192.168.43.147 192.168.43.1 RTSP 198 TEARDOWN rtsp://192.168.43.1:8554/video RTSP/1.0
699 3.411457 192.168.43.147 192.168.43.1 RTCP 82 Receiver Report Goodbye
700 3.411536 192.168.43.147 192.168.43.1 RTCP 82 Receiver Report Goodbye
701 3.411599 192.168.43.147 192.168.43.1 TCP 54 49515 → 8554 [FIN, ACK] Seq=968 Ack=899 Win=130304 Len=0
702 3.417119 192.168.43.1 192.168.43.147 RTSP 98 Reply: RTSP/1.0 200 OK
- 客户端（192.168.43.147）和服务端（192.168.43.1）建立 TCP（三次握手）连接；
- 客户端发出 RTSP OPTIONS 请求，服务端答复 200 OK；
C->S:
S->C:
3. 客户端发出 RTSP DESCRIBE 请求，服务端答复 200 OK；
C->S:
S->C:
4. 客户端发出 RTSP SETUP 请求（SETUP rtsp://192.168.43.1:8554/video/track0 和 SETUP rtsp://192.168.43.1:8554/video/track1），服务端答复 200 OK；
C->S:
S->C:
5. 客户端发出 RTSP PLAY 请求，服务端答复 200 OK；
C->S:
S->C:
6. 服务端源源不断向客户端发送 RTP 音视频数据包，期间客户端向服务端发送 RTCP 包；
S->C(RTP 数据包):
C->S(RTCP 数据包):
7. 客户端发出 TEARDOWN 请求，服务端答复 200 OK；
C->S:
S->C:
8. 客户端向服务端发送 RTCP RR&BYE 聚合包。
C->S(RTCP 数据包):
五、参考资料
1.https://handwiki.org/wiki/Real-time_Transport_Protocol
2.https://www.rfc-editor.org/rfc/rfc1889
3.https://handwiki.org/wiki/RTP_Control_Protocol
4.https://www.rfc-editor.org/rfc/rfc2326
5.https://handwiki.org/wiki/Real%20Time%20Streaming%20Protocol
六、备注
ISO 10646 字符集
通用多八位编码字符集（Universal Multiple-Octet Coded Character Set）也叫通用字符集（Universal Character Set, UCS），是由 ISO 制定的 ISO 10646（或称 ISO/IEC 10646）标准所定义的标准字符集。
通用多八位编码字符集包括了其他所有字符集。它保证了与其他字符集的双向兼容，即，如果你将任何文本字符串翻译到 UCS 格式，然后再翻译回原编码，你不会丢失任何信息。UCS 包含了已知语言的所有字符。除了拉丁语、希腊语、斯拉夫语、希伯来语、阿拉伯语、亚美尼亚语、格鲁吉亚语，还包括中文、日文、韩文这样的方块文字，UCS 还包括大量的图形、印刷、数学、科学符号。ISO/IEC 10646 定义了一个 31 位的字符集。UCS 不仅给每个字符分配一个代码，而且赋予了一个正式的名字。表示一个 UCS 或 Unicode 值的十六进制数通常在前面加上“U+”，例如“U+0041”代表字符“A”。
SIP
SIP（Session initialization Protocol）会话初始协议，是由 IETF 制定的多媒体通信协议。它是一个基于文本的应用层控制协议，用于创建、修改和释放一个或多个参与者的会话。SIP 是一种源于互联网的 IP 语音会话控制协议，具有灵活、易于实现和便于扩展等特点。
SCTP
Stream Control Transmission Protocol，流控制传输协议是 IETF 新定义的一个传输层协议（2000）。RFC 2960 详细说明了 SCTP，介绍性的文档是 RFC 3286。
作为一个传输层协议，SCTP 可以理解为和 TCP 及 UDP 相类似的。事实上，它提供的服务有点像 TCP ——保证可靠、有序传输消息。同时 TCP 是面向字节的，而 SCTP 是针对成帧的消息。SCTP 主要的贡献是对多重联外线路的支持，一个端点可以由多于一个 IP 地址组成，使得传输可在主机间或网卡间做到透明的网络容错备援。
DCCP
Datagram Congestion Control Protocol，数据拥塞控制协议是由因特网工程工作小组提出一个针对传输层中 UDP 的新传输的协议而发展出来，用来传输实时业务。它是一个可以进行拥塞控制的非可靠传输协议，并同时提供多种拥塞控制机制，在通信开始时由用户进行协商选择。除预留和自定义方式外，目前 DCCP 定义了两种拥塞控制机制：TCP-Like 和 TFRC。TCP-Like 类似 TCP 的 AIMD 机制，而 TFRC 是 TCP 友好的速率控制机制。
建立、维护和拆卸不可靠连接的数据流以及对不可靠性数据流进行拥塞控制，是 DCCP 主要提供的两大功能。实时业务需要快速且低开销的传输协议，要使包头带来的开销和终端处理的工程量尽量小。因此，DCCP 尽可能做到简单合理、低延迟和快速响应，避免提供更高层的传输功能。DCCP 没有 TCP 的可靠性和顺序发送的特性。基于单播的应用功能也被涵盖在 DCCP 中。
VoIP
Voice over IP，基于 IP 的语音传输协议，是一种语音通话技术，经由网际协议（IP）来达成语音通话与多媒体会议，也就是经由互联网来进行通信。其他非正式的名称有 IP 电话（IP telephony）、互联网电话（Internet telephony）、宽带电话（broadband telephony）以及宽带电话服务（broadband phone service）。
WebRTC
Web Real-Time Communications， WebRTC 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。WebRTC 包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，创建点对点（Peer-to-Peer）的数据分享和电话会议成为可能。
QoS
Quality of Service，服务质量，指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力，是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。QoS 的保证对于容量有限的网络来说是十分重要的，特别是对于流多媒体应用，例如 VoIP 和 IPTV 等，因为这些应用常常需要固定的传输率，对延时也比较敏感。
H.323
基于包交换网络的多媒体通信系统，此协议总体上介绍了基于包交换网络的视频会议系统和终端的要求，解释了呼叫建立的基本过程。在传统电话系统中，一次通话从建立系统连接到拆除连接都需要一定的信令来配合完成。同样，在 IP 电话中，如何寻找被叫方、如何建立应答、如何按照彼此的数据处理能力发送数据，也需要相应的信令系统，一般称为协议。在国际上，比较有影响的 IP 电话方面的协议包括 ITU-T 提出的 H.323 协议和 IETF 提出的 SIP 协议。
XMPP
eXtensible Messaging and Presence Protocol，可扩展通讯和表示协议，是一种基于标准通用标记语言的子集 XML 的协议，它继承了在 XML 环境中灵活的发展性。因此，基于 XMPP 的应用具有超强的可扩展性。经过扩展以后的 XMPP 可以通过发送扩展的信息来处理用户的需求，以及在 XMPP 的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP 包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。
SRTP
Secure Real-time Transport Protocol，即安全实时传输协议，其是在实时传输协议（Real-time Transport Protocol）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。