本文接着《音视频入门基础：RTCP专题（3）——RTCP协议简介（中）》，继续对RTCP协议进行简介。本文的一级标题从“十四”开始。
十四、SDES: Source Description RTCP Packet
本段内容对应《RFC 3550》的第6.5节：
根据《RFC 3550》第37页，SDES数据包是一种三级结构，由标头（header）和0个或多个数据块（chunks）组成，每个数据块都由描述该数据块所标识的信源的项目组成。这些项目将在随后的章节中逐一介绍。
version (V), padding (P), length：这几个字段跟SR数据包（Sender Report RTCP Packet）中的字段含义是一样的，见《RFC 3550》第6.4.1节。
packet type (PT)：占8位。包含常量202，用于将其标识为RTCP SDES数据包。
source count (SC)：占5位。该SDES数据包中包含的SSRC/CSRC数据块的数量。值可以为0但值为0时没有意义。
每个数据块由一个SSRC/CSRC标识符（SSRC/CSRC identifier）和一个由0个或多个项目（items）组成的列表组成，这些项目包含SSRC/CSRC的相关信息。每个数据块以32位边界开始。每个项目由一个8位类型字段（type field）、一个描述文本长度的8位八进制计数（因此不包括这两个八进制header）和文本本身组成。请注意，文本长度不能超过255个八位字节，但这符合限制RTCP带宽消耗的需要。
项目（Items）是连续的，即项目不会单独填充到32位边界。文本（Text）不以空字节结束，因为某些多八位位组编码（multi-octet encodings）包含空八位位组。每个数据块中的项目列表（list of items）必须以一个或多个空八位位组结束，第一个空八位位组被解释为项目类型为0，表示列表结束。空项目类型八位位组之后没有长度八位位组，但如果需要，必须包含额外的空八位位组，以填充到下一个32位边界。请注意，这种填充与RTCP报头中P位（P bit）指示的填充是分开的。包含0项（四个空八位位组）的数据块有效但无用。
终端系统（End systems）发送一个SDES数据包，其中包含自己的源标识符（source identifier，与fixed RTP header中的SSRC相同）。混音器（mixer）会发送一个SDES数据包，其中包含它从中接收SDES信息的每个贡献源（contributing source）的一个分块；如果有超过31个此类信息源，则会发送多个上述格式的完整SDES数据包（见《RFC 3550》第7节）。
目前定义的SDES项目将在接下来的章节中介绍。只有CNAME项是强制性的。此处显示的某些项目可能只对特定配置文件（particular profiles）有用，但所有项目类型都是从一个公共空间（common space）分配的，以促进共享使用并简化独立于配置文件的应用。如《RFC 3550》第15节所述，可通过向IANA注册类型编号在配置文件中定义其他项目。
十五、CNAME: Canonical End-Point Identifier SDES Item
本段内容对应《RFC 3550》的第6.5.1节：
根据《RFC 3550》第38页，CNAME标识符（CNAME identifier）具有以下属性：
1.由于随机分配的SSRC标识符在发现冲突或重新启动程序时可能会发生变化，因此必须包含 CNAME项，以便将SSRC标识符绑定到保持不变的源标识符（发送方或接收方）上。
2.与SSRC标识符（SSRC identifier）一样，CNAME标识符在一个RTP会话的所有参与者中也应是唯一的。
3.要在一组相关RTP会话中为一个参与者使用的多个媒体工具提供绑定，该参与者的CNAME应该是固定的。
4.为便于第三方监测，CNAME应适合程序或个人定位来源。
因此，在可能的情况下，CNAME应通过算法得出，而不是手动输入。为满足这些要求，除非某个配置文件指定了其他语法或语义，否则应使用以下格式。CNAME项的格式应为 “user@host”，如果在单用户系统中没有用户名，则应为 “host”。对于这两种格式，“host ”都是实时数据源主机的完全合格域名，格式符合《RFC 1034》、《RFC 1035》和《RFC 1123》第2.1节中规定的规则格式；或者是RTP通信所用接口上主机数字地址的标准ASCII表示法。例如，IP第4版（IP Version 4）地址的标准 ASCII表示法是“点十进制”，也称为点四进制，而对于IP第6版（IP Version 6），地址的文本表示法是由冒号分隔的十六进制数字组（《RFC 3513》中有详细说明）。对于人类观察者来说，完全合格的域名更方便，而且可以避免另外发送NAME项目，但在某些操作环境中可能很难或不可能可靠地获取该域名，因此可能在此类环境中运行的应用程序应使用地址的ASCII表示法。
例如，多用户系统中的 “[email protected]”、“[email protected] ”或 “doe@2201:056D::112E:144A:1E24”。在没有用户名的系统中，示例为 “sleepy.example.com”、“192.0.2.89 ”或 “2201:056D::112E:144A:1E24”。
用户名应采用 “finger ”或 “talk ”等程序可以使用的形式，即通常是登录名，而不是个人名。主机名不一定与参与者电子邮件地址中的主机名相同。
如果应用程序允许用户从一台主机生成多个数据源，则此语法无法为每个数据源提供唯一标识符。这种应用程序必须依靠SSRC来进一步识别源，或者该应用程序的配置文件必须为CNAME标识符指定额外的语法。
如果每个应用程序都独立创建其CNAME，则生成的CNAME可能不完全相同，而这正是在一组相关RTP会话中提供跨属于一个参与者的多个媒体工具绑定所需要的。如果需要跨媒体绑定，每个工具的CNAME可能需要由协调工具以相同的值进行外部配置。
应用程序编写者应注意，私有网络地址分配（如《RFC 1918》中提出的Net-10分配）可能会创建非全局唯一的网络地址。如果具有私有地址且没有直接 IP连接到公共互联网的主机通过RTP级转换器将其 RTP 数据包转发到公共互联网，这将导致非唯一的CNAME。这将导致非唯一的 CNAME。(另请参加《RFC 1627》）为处理这种情况，应用程序可提供一种配置唯一CNAME的方法，但翻译器（translator）有责任在必要时将 CNAME从私有地址翻译为公用地址，以防止私有地址被暴露。
十六、BYE: Goodbye RTCP Packet
本段内容对应《RFC 3550》的第6.6节：
根据《RFC 3550》第43页，BYE数据包表示一个或多个信号源不再活动。
version (V), padding (P), length：这几个字段跟SR数据包（Sender Report RTCP Packet）中的字段含义是一样的，见《RFC 3550》第6.4.1节。
packet type (PT)：占8位。包含常量203，用于将其标识为RTCP BYE数据包。
source count (SC)：占5位。此BYE数据包中包含的SSRC/CSRC标识符的数量。值可以为0但值为0时没有意义。
《RFC 3550》第6.3.7和8.2节规定了何时发送BYE数据包的规则。如果混音器（mixer）收到BYE 数据包，混音器应转发BYE数据包，并保持SSRC/CSRC标识符不变。如果混音器关闭，则应发送 BYE数据包，列出其处理的所有贡献源（contributing sources）及其自身的SSRC标识符。可选地，BYE数据包可包括一个8位八进制数，然后是表示退出原因的八进制文本，如 “摄像机故障（camera malfunction） ”或 “检测到RTP循环（RTP loop detected）”。字符串的编码与SDES的编码相同。如果字符串将数据包填满到下一个32位边界，则该字符串不以空值结束。否则，BYE 数据包必须使用空八位位组填充到下一个32位边界。这种填充与RTCP报头（RTCP header）中P位指示的填充不同。
十七、APP: Application-Defined RTCP Packet
本段内容对应《RFC 3550》的第6.7节：
根据《RFC 3550》第44页，APP数据包用于开发新应用和新功能时的试验性使用，无需注册数据包类型值。名称未被识别的APP数据包应被忽略。经过测试后，如果有理由更广泛地使用，建议重新定义每个APP数据包，去掉子类型（subtype）和名称（name）字段，并使用RTCP数据包类型向IANA注册。
version (V), padding (P), length：这几个字段跟SR数据包（Sender Report RTCP Packet）中的字段含义是一样的，见《RFC 3550》第6.4.1节。
subtype: 占5位。可作为子类型使用，以便在一个唯一名称下定义一组APP数据包，或用于任何与应用相关的数据。
packet type (PT)：占8位。包含常数 204，用于将其标识为RTCP APP数据包。
name：占4个八位字节。由定义APP数据包的人员选择的名称，相对于该应用程序可能收到的其他APP数据包而言是唯一的。应用程序创建者可以选择使用应用程序名称，然后协调分配子类型值给希望为应用程序定义新数据包类型的其他人。或者，建议其他人根据自己所代表的实体选择一个名称，然后在该实体内协调该名称的使用。名称被解释为由四个ASCII字符组成的序列，大写和小写字母被视为不同的字符。
application-dependent data：长度可变。APP 数据包中可能出现也可能不出现应用相关数据。它由应用程序而非RTP本身解释。长度必须是 32 位的倍数。
十八、Summary of Protocol Constants
本段内容对应《RFC 3550》的第12节，根据《RFC 3550》第58页，本节简要列出了《RFC 3550》中定义的常量。
RTP有效载荷类型 (RTP payload type，PT) 常量是在配置文件（profiles）而不是《RFC 3550》中定义的。但是，RTP报头（RTP header）中包含标记位（marker bit）和有效载荷类型的八位位组必须避免使用保留值200和201（十进制），以便在《RFC 3550》附录A.1中描述的报头验证程序中将RTP数据包与RTCP SR和RR数据包类型区分开来。对于《RFC 3550》中所示的一个标记位和一个7 位有效载荷类型字段的标准定义，这一限制意味着有效载荷类型72和73被保留。
（一）RTCP Packet Types
与RTP数据包或其他无关数据包相比，这些类型值的选择范围为200-204，以改进RTCP数据包的报头有效性检查。将RTCP数据包类型字段与RTP报头（RTP header）的相应八位字节进行比较时，该范围对应于标记位为1（数据包中通常不为 1）和标准有效载荷类型字段的高位为1（因为静态有效载荷类型通常定义在低半部分）。由于全0和全1是常见的数据模式，因此该范围在数值上与 0和255之间有一定的距离。
由于所有复合RTCP数据包都必须以SR或RR开头，因此这些代码被选为偶数/奇数对（even/odd pair），以便RTCP有效性检查（RTCP validity check）能测试带掩码和值的最大位数。
其他RTCP数据包类型可通过IANA注册（参见《RFC 3550》第15 节）
（二）SDES Types
其他SDES 类型可通过 IANA 注册（见《RFC 3550》第15节）。
十九、IANA Considerations
本段内容对应《RFC 3550》的第15节，根据《RFC 3550》第61页，其他RTCP数据包类型（Additional RTCP packet types）和SDES项目类型（SDES item types）可通过互联网编号（Internet As-signed Numbers）分配机构 (IANA) 注册。由于这些数字空间较小，允许不受限制地注册新值并非明智之举。为便于审查申请并促进多个应用程序共享新类型，注册新值的申请必须记录在RFC或其他永久性、随时可用的参考资料中，如其他合作标准机构（如 ITU-T）的产品。根据 “指定专家 ”的建议，也可接受其他申请。(有关当前专家的联系信息，请与IANA 联系）。
RTP预案规范应向IANA注册一个格式为“RTP/xxx ”的预案名称，其中xxx是预案标题的简短缩写。这些名称供高级控制协议使用，如会话描述协议（Session Description Protocol，SDP），《RFC 2327 》，用于指代传输方法。