3. Registering Additional Encodings

3. 注册附加编码

本配置文件列出了一组编码，每个编码由特定的媒体数据压缩或表示方式，以及用于在 RTP 中封装它的有效载荷格式组成。其中部分有效载荷格式在本文档中规定，其他则在单独的 RFC 中规定。预计未来还会建立超出这组列出的编码之外的附加编码，并在附加的有效载荷格式 RFC 中规定。

本配置文件还为每种编码分配了一个名称，高层控制协议（例如会话描述协议（SDP），RFC 2327 [6]）MAY 使用该名称来标识为特定 RTP 会话选择的编码。

在此类上下文中，以 MIME content-type 的形式使用这些名称可能有用。为便于这样做，RFC 3555 [7] 根据 RFC 2048 [8] 中规定的 MIME 注册程序，为这里列出的所有编码名称提供了注册，将其作为 “audio” 和 “video” MIME 类型下的 MIME 子类型（subtype）名称。

要在本配置文件（或其他配置文件）下使用而规定的任何附加编码，都可以被分配在 Internet Assigned Numbers Authority（IANA）注册为 MIME 子类型名称。该注册表提供了一种方法，确保分配给附加编码的名称保持唯一。RFC 3555 规定了 RTP 注册程序。

除了为编码分配名称外，本配置文件还为其中一些编码分配了静态 RTP 有效载荷类型编号。然而，有效载荷类型编号空间相对较小，无法容纳所有现有和未来的编码分配。在 RTP 发展的早期阶段，必须使用静态分配的有效载荷类型，因为还没有将编码绑定到有效载荷类型的其他机制。当时预期超出本文档范围的附加编码将通过非 RTP 手段（例如目录服务或邀请协议）来建立有效载荷类型与编码之间的动态映射。现在，会话描述协议（SDP）以及 ITU-T 建议 H.323/H.245 等其他协议中已规定了定义动态有效载荷类型绑定的机制。这些机制把已注册的编码/有效载荷格式名称，连同任何额外部署参数（例如 RTP 时间戳时钟速率参数），关联到某个有效载荷类型编号。该关联仅在建立动态有效载荷类型绑定的 RTP 会话持续期间有效。该关联只用于建立它的 RTP 会话，因此该编号可在不同会话中为不同编码重复使用，从而避免编号空间限制。

本配置文件保留 96–127 范围内的有效载荷类型编号专用于动态分配。应用 SHOULD 首先使用此范围内的编号作为动态有效载荷类型。需要定义超过 32 个动态有效载荷类型的应用 MAY 绑定 96 以下的静态编号，在这种情况下 RECOMMENDED 首先使用未分配的有效载荷类型编号。然而，静态分配的有效载荷类型是默认绑定，所有静态编码 MAY 动态绑定到新的编号。如果尝试在未获取定义动态有效载荷类型的会话描述信息的情况下加入会话，重新定义 96 以下的某些有效载荷类型可能导致错误运行。

如果没有明确定义的机制来指示映射，SHOULD NOT 使用动态有效载荷类型。与运行在本配置文件下的其他系统互操作的系统 SHOULD NOT 自行把专有编码分配给特定的静态有效载荷类型。

本规则确立了如下策略：除本文档中定义的静态有效载荷类型之外，不再分配附加的静态有效载荷类型。确立此策略可避免试图建立一组接受静态分配标准的问题，并鼓励实现和部署动态有效载荷类型机制。

最终静态有效载荷类型分配的完整列表见表 4 和表 5。