每一个块中都包含多个描述内容，这些描述内容都是 32-bit 对齐的，其中前 8-bit 描述了类型，接着 8-bit 描述了信息长度（不包含前 16-bit），然后信息内容。注意信息部分不能超过 255 BYTE，这和前面的很多工作类似是为了约束 RTCP 的带宽。
描述的文本内容是 UTF-8 编码的。如果要使用多字节的编码，需要在醒目的地方表示用的什么的编码。
各个描述部分是没有中间分隔的，所以要用空字节来填充以达到对齐的效果。注意这里的填充和 RTCP 头部的 P 不是一个概念。
末端节点发送的 SDES 包含他自己的数据源标识。而 Mixer 发送的 SDES 包含多个 CSRC，如果 CSRC 的数量超过了 31 个，会拆分成多个 SDES 报文。
SDES 的所有类型会在后面一一介绍。其中只有 CNAME 是强制要有的。可能有一些类型的的描述只有部分预设才会使用。但是这些内容都是在一个共通的地方来记载，以防止不同的预设使用的描述类型发生冲突。如果要注册新的类型，需要通过 IANA 注册。
CNAME：权威的末端节点身份标识CNAME 有如下特征：
因为 SSRC 在许多意外情况下会重新生成，所以 CNAME 被用来绑定旧的 SSRC 和新的 SSRC，来保持数据源的连续。
和 SSRC 一样，CNAME 也需要保证唯一性（同一个 Session 中）。
为了让同一个参与者的多个 SSRC 绑定在一起，我们需要 CNAME 是固定的。
为了让第三方监控用起来方便，CNAME 应该即方便程序使用，也要设计成可读的，可以根据它确认来源。
因此 CNAME 应该通过算法来生成而不是手动生成。为了满足如上需要，一般来说是按照如下的格式来描述 CNAME:
"user@host" eg: "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24".
"host", 如果是单用户系统，获取不到 user 时只使用 host。eg: "sleepy.example.com","192.0.2.89" or "2201:056D::112E:144A:1E24".
有些人可能会发现，如果上述的 host 使用的是子网地址的话，就没办法保证整个 Session 的唯一性了，通常这类没有直接 IP 的使用者是通过一个 RTP 级别的 Translator 来访问公共网络。这个 Translator 会处理从私有地址到公网地址的转换工作。
NAME：用户名这个是描述数据源的真实名字，eg:"John Doe, Bit Recycler"。整个 Session 过程中希望这个值不变。全 Session 不需要唯一。
EMAIL：电子邮箱地址电子邮箱地址，eg: "John.Doe@example.com"。整个 Session 过程中希望这个值不变。
PHONE：电话号码电话号码需要以国际访问码开头，eg: "+1 908 555 1212"。
LOC：用户地理地址视应用不同，详细程度会各不相同。
TOOL：应用名或工具名带版本号的应用名，可以用来 DEBUG。
NOTE：提醒 / 状态用来发送暂时性的消息描述当前状态。eg: "on the phone, can't talk"。
PRIV：自定义拓展上层应用自定义的格式。一般都是用过一个前缀描述消息类型，然后后面跟着消息正文。
BYE 报文