本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
SPEKE API v2
为了兼容 Speke，您的 DRM 密钥提供商必须公开本规范中描述的 REST API。加密程序对您的密钥提供程序进行 API 调用。
本规范中的代码示例仅用于说明目的。您无法运行这些示例，因为它们不是完整的 SPEKE 实现的一部分。
Secure Packager 和 Encoder Key Exchange 使用 DASH 行业论坛内容保护信息交换格式 (DASH-IF-CPIX) 数据结构定义进行密钥交换，但有一些限制。DASH-IF-CPIX 定义一个架构来提供从 DRM 平台到加密程序的可扩展的多 DRM 交换。这使得在内容压缩和打包时允许对所有自适应比特率打包格式进行内容加密。自适应比特率打包格式包括 HLS、DASH 和 MSS。
从其 2.0 版本开始，SPEKE 在特定的 CPIX 版本上保持一致：
在 SPEKE 方面，这是通过使用X-Speke-Version HTTP 标头强制执行的，在 CPIX 方面，这是通过使用CPIX@version属性来强制执行的。请求中缺少这些元素是 SPEKE v1 传统工作流程的典型特征。在 SPEKE v2 工作流程中，密钥提供者只有在同时支持两个版本参数时才需要处理 CPIX 文档。
有关交换格式的详细信息，请参阅 DASH 行业论坛 CPIX 2.3 规范
总体而言，与 SPEKE v1.0 相比，SPEKE v2.0 带来了以下演变：
-
不推荐使用 SPEKE XML 命名空间中的所有标签，取而代之的是 CPIX XML 命名空间中的等效标签
-
SPEKE:ProtectionHeader已弃用并替换为CPIX:DRMSystem.SmoothStreamingProtectionHeaderData -
CPIX:URIExtXKey，SPEKE:KeyFormat并SPEKE:KeyFormatVersions已弃用并替换为CPIX:DRMSystem.HLSSignalingData -
CPIX@id被替换为CPIX@contentId -
新的强制性 CPIX 属性：
CPIX@version，ContentKey@commonEncryptionScheme -
新的可选 CPIX 元素：
DRMSystem.ContentProtectionData -
Support 多个内容密钥
-
SPEKE 和 CPIX 之间的跨版本控制机制
-
HTTP 标头的演变：新
X-Speke-Version标头，Speke-User-Agent标头重命名为X-Speke-User-Agent -
Heartbat API 弃用
由于 SPEKE v1.0 规范保持不变，因此无需更改现有实现即可继续支持 SPEKE v1.0 工作流程。
主题
