摘要
Microsoft® PlayReady® 3.0 推出了 OEM 希望集成到其设备中的重要新功能。 这给 5 年前设计的服务带来了一些兼容性问题。 本文讨论了这些问题，并为服务和 OEM 提供了升级到 PlayReady 3.0 的指导
目录
使用 PlayReady Server SDK 的版本测试 PlayReady 客户端
概述
PlayReady 许可证服务为旧式 PlayReady 设备保持向后兼容性。 例如，使用 PlayReady Server SDK 3.0 开发的新许可证服务可以向使用 PlayReady 移植工具包(PK) 1.2 从最初版本（2008 年）开发的旧设备提供许可证。
然而，随着服务和设备迁移到 PlayReady 3 版本，在兼容性方面存在一些细微差别。 使用 3.0 移植工具包开发的 PlayReady 客户端无法从 2011 年发布的 Server SDK 2.0 之前构建的许可证服务中获得许可证。 运行早期版本的 Server SDK 的服务需要升级才能与 PlayReady 3.0 兼容。
PlayReady 兼容性矩阵
客户端上的大多数 PlayReady 版本都可以与不同版本的 PlayReady Server SDK 一起使用。 下面提到了一些微妙之处，以及在 3.0 移植工具包上开发的 PlayReady 客户端的变化。
| Server SDK 1.x | Server SDK 2.0 (2011) | Server SDK 2.1 (2013) | Server SDK 2.9 (2014) | Server SDK 3.0 (2015) | |
|---|---|---|---|---|---|
| PK 1.x (2008) | * | * | * | * | |
| PK 2.x (2011) | |||||
| PK 3.0 (2015) | ** | *** | *** | *** |
| Server SDK v1.5.2 | Server SDK v2.1 和 Server SDK v2.9 | Server SDK v3.0 | Server SDK v4.0 | |
|---|---|---|---|---|
| PK v4.x | 否 | 是 | 是 | 是 |
| PK v3.x | 否 | 是 | 是 | 是 |
| PK v2.5 和 v2.11 | 是 | 是 | 是 | 是 |
| 不兼容 | 兼容 |
|---|---|
* 一些 PK 1.2 客户端不支持 Server SDK 2.x+ 中要求的吊销。 这并不常见。
** PK3.0 客户端不能使用版本 2.0 之前的 Server SDK 获取媒体播放许可证。
*** PK3.0 客户端可以使用 2.X SDK 使用许可证服务器，但只能获得具有 SL2000 安全级别的许可证。 此外，创建许可证时，不支持版本 4.2 标头（多个密钥）和策略（如 Secure Stop 和 MaxResDecode）的新功能。 使用 Server SDK 2.0 的一些 PK3.0 客户端上的链式许可证（根/叶）存在问题。 服务需要测试客户端以验证兼容性。 本文档末尾有一组场景可以帮助测试。
PlayReady 服务的建议
确保服务升级到最新版本的 PlayReady SDK。 这将在新设备和旧设备之间提供最佳兼容性。 Server SDK 的最新版本也显著提高了性能和稳定性。 请注意，升级到最新的 PlayReady Server 3.0 不需要额外的许可或许可证费用 。
随着新设备继续将 PlayReady 迁移到硬件 (SoC)，将有越来越多的设备以 PlayReady 3.0 和 SL3000 的形式向服务报告。 例如，所有 Windows 10 设备现在都报告为 PlayReady 3.0 设备。 建议服务升级到最新版本的服务器 SDK，以保持兼容性，并利用一些新功能。
使用本指南处理边缘情况，例如在支持新设备时维护旧版许可证服务 as-is。
被许可方可以联系 askdrm@microsoft.com 以获取我们反馈站点的访问权限，并提交迁移问题。
PlayReady 设备制造商的建议
强烈建议 OEM 将其设备升级到 2015 年 4 月发布的 PK3.0，这是允许设备利用顶级媒体服务实施的最新功能的唯一版本。
| Pros | 缺点 - 注意点 |
|---|---|
| 可以支持 SL3000 与服务器 SDK 1.X 不兼容 | |
| 可以实现 SecureStop、MaxResDecode 等最新功能。 | |
| 更好的代码库 | |
| 确保可以强制实施内容所有者请求的新许可证策略 |
OEM 升级计划
请联系你的服务，确保他们都迁移或添加了 Server SDK 2.0+ 版本，以验证他们的 Server SDK 版本
重申服务注意事项： Microsoft没有额外的许可要求，也无需额外付费 。
如果运行基于 Server SDK v2.0+ 的许可证服务，则它们可能兼容。 下一节中的服务 URL 和场景可以帮助进行兼容性测试。 o 如果他们运行基于 Server SDK v1.X 的许可证服务器，则可以迁移许可证服务器或为新客户端添加基于 Server SDK 2.0+（建议使用最新版本）的较新许可证服务器。
从 Microsoft 下载 PK3.0
从微软的合作伙伴处或直接从微软那里获得支持https://connect.microsoft.com/playready。
实现 PK3.0 并发布产品。
服务迁移说明
为获得最佳设备兼容性，请确保许可证服务器运行的是最新版本的服务器
SDK。 最新的 Server SDK 将能够向所有 PlayReady 客户端提供许可证，而不管使用的移植工具包版本如何。 如果使用 3.0 移植工具包开发的客户端尝试使用 PlayReady SDK 1.x 从许可证服务获取许可证，则许可证服务将返回特定于通用服务的 SOAP 错误。 服务器将在 Windows 日志中记录一个异常，指出质询缺少客户端证书链。
将 PlayReady 服务迁移到 Server SDK 3.0
服务升级通常不涉及任何代码更改，而只是重新编译和部署更新的库。 在某些情况下，由于某些已弃用的 API，可能会发生少量代码更改。 许可证处理程序库的重新编译和部署应该对访问该服务的设备透明。
编译和部署更新的许可证处理程序需要考虑以下事项
在重新编译之前，该项目需要删除对旧 PlayReady 库的引用，并引用新库。
较新的 Server SDK 需要 .NET 4.0 或更高版本。 当从 1.52 等早期版本升级许可证服务处理程序时，需要在项目属性中将目标框架更新为 4.0 或更高版本。
如果旧处理程序引用了面向低于 4.0 的 .NET 版本的其他库，则可能会执行其他迁移步骤。 但是，.NET 库可以引用较低版本，通常不会出现任何问题。 值得研究的是，是否有机会将引用的库重新编译到处理程序的版本，或者为第三方组件获取库更新。
在项目中只需要引用 Microsoft.Media.Drm.RMCore。 部署解决方案时，其他 DLL 需要部署在网站的 bin 目录中。 它们不需要像早期的 SDK 那样在项目中引用。
许可证服务的应用程序池需要最低 .NET CLR 版本 4.0。 如果许可证服务运行的是 2.0 或更早版本，则可能是在低于 4.0 的 .NET CLR 版本中运行。
最新的 PlayReady Server SDK 仅在 Windows Server 2012 及更高版本下受支持。 然而，据了解，Windows Server 2008 R2 在 Server SDK 方面没有任何问题。
支持服务的不同服务器 SDK 版本
建议在 SDK 发布后立即迁移到最新版本。 然而，在某些情况下，服务可能希望运行多个版本的 Server SDK。 这可能是由于维护不易更新的旧和存档服务以及终结点。 在这种情况下，服务可以将新客户端指向更新的许可证服务，同时保持旧服务不变。 例如，一项服务的生态系统中可能有许多传统设备运行用 PlayReady PK 1.2 构建的客户端。 他们的新设备是使用 PlayReady PK 3.0 开发的。 新客户端需要指向使用 Server SDK 2.0 或更高版本生成的许可证服务。 如果旧设备和新设备都使用相同的应用程序（例如基于 HTML 的应用平台），则需要向应用程序添加逻辑以检测客户端的版本。 然后，客户端应用程序可以将许可证请求定向到较新的许可证服务。
建议迁移是将许可证服务更新到最新版本的 Server SDK。 这可以为许多服务提供跨所有设备的兼容性。 服务需要跨客户端进行测试，以验证兼容性。
如果服务不想更改旧客户端和服务配置，建议托管已升级到最新版本的 SDK 并由新式客户端使用的第二个许可证服务。
如果服务对旧版新设备使用相同的应用程序，则可以在需要继续使用旧服务的旧设备中配置代理。
服务还可以将旧客户端定向到旧服务，并将新客户端定向到更新的服务。 可以在代理中通过检查许可证质询来完成该任务。 PK 版本将记录在 <CLIENTVERSION> 元素中。
该元素位于 SOAP 质询中的以下元素下：
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
使用旧版许可证服务支持基于 PK 3.0 的客户端
使用 PlayReady 移植工具包 3.0 开发的客户端设备可能会与使用 Server SDK 2.0 及更高版本开发的现有服务兼容。 如上所述，服务需要测试 PK 3.0 客户端以验证兼容性。
如果设备具有 SL3000 证书，则通过许可证处理程序中的客户端证书公开的安全级别将报告为 3000。 如果某些许可证处理程序正在寻找特定的安全级别值来区分生产和测试设备，这可能会导致它们出现问题。
为了区分不同的安全级别，通常会有服务为测试设备提供有限的内容访问，以便验证来自实时服务的播放许可证。 只有报告为安全级别 2000 的设备才能获得商业内容的播放许可证。 该服务将引发一个特定于服务的异常，这将导致客户端出现 SOAP 错误。
在下面的示例中，正在客户端证书中检查安全级别，以确保它是一个生产设备。 由于它已被硬编码为 2000，因此安全级别为 3000 的设备将不会被视为生产设备。
此示例将安全级别检查更新为是否大于或等于 2000。 这将确保与 SL3000 设备的兼容性。
支持适用于服务的 PlayReady 3.0 功能
除了新的硬件 DRM 安全级别外，PlayReady 3 版本还推出了各种新功能。 为了利用这些新功能，服务首先需要确定客户端是否能够使用 PlayReady 3 功能。 客户端证书类现在支持
GetSupportedFeatures 方法，该方法将返回一组功能，以帮助在处理程序中定义策略的逻辑。 如果客户端是使用 3.0 移植工具包开发的，它将在集合中具有 SupportedFeature.PlayReady3Features。 集合中还有其他有用的功能，例如客户端是使用安全时钟还是防回滚时钟。
以下是一个如何检测设备是否为 PlayReady 3 客户端的示例。
一旦检测到，处理程序可以添加诸如“安全停止”、“实时许可证过期”和“MaxResDecode”等策略。
服务中同时支持 SL2000 和 SL3000
PlayReady 推出了新的安全级别 SL3000，该级别由满足以下条件的设备报告
用于在合规性和可靠性规则中定义的受信任执行环境中运行的 PlayReady 硬件安全级别。 服务通常会将一些客户端报告为 SL2000，而其他客户端报告为 SL 3000。 例如，在 Windows 中，已升级到 Windows 10 的较旧设备可能会报告为 SL2000。 新的 Windows 10 设备将报告为 SL3000，其中 DRM 已整合到较新的芯片中。
以下是一个服务示例，该服务根据来自客户端挑战报告的安全级别提供不同的策略：
服务将确定基于软件的 DRM 客户端与基于硬件的 DRM 客户端之间的策略应如何不同。 这些策略可能由工作室要求驱动。 例如，工作室将来可能需要将 Ultra-HD 或 4K 内容限制为支持基于硬件的 PlayReady DRM 的设备。
使用 PlayReady 3，解决方案策略可以通过几种不同的方式实现。 一种方法是将 SL2000 许可证的 MaxResDecode 策略设置为内容所有者提供的允许限制。 SL3000 设备不会收到此策略限制。 适用于自适应流式处理技术的另一种选择是在保护各种分辨率时使用不同的 KeyID。 在检测安全级别时，服务只能为基于软件的解决方案提供许可证。 报告安全级别为 SL3000 的客户端将获得所有分辨率的播放许可证。 PlayReady 引入了一个新的 DRM 标头，通过在架构中启用多个 KeyID 来支持后一种情况。
使用 PlayReady Server SDK 的版本测试 PlayReady 客户端
PlayReady 测试网站包含一组使用当前和旧版 Server SDK 的许可证服务。 这些许可证服务可用于协助测试客户端兼容性。 例如，当将客户端更新到 PK 3.0 时，可以根据以前的服务版本对客户端进行测试，以检查兼容性。
下表列出了版本控制服务。
这些版本控制服务可以利用 PlayReady 测试服务器服务 文档中列出的参数来测试特定策略。
[注意!] 并非所有策略参数都适用于每个服务版本。 例如，MaxResDecode 是一个新策略，仅适用于使用 Server SDK 3.0 或更高版本开发的服务。
为了帮助进行功能测试，以下测试可以与不同版本的许可证服务一起使用，以涵盖四种独特的许可方案。
方案 1：非持久性许可证
非持久性许可证是流服务中最常见的许可证使用场景。
测试步骤：
使用 PlayReady 测试网站上标注的 KeySeed 对内容进行打包。 对于此测试，打包时可以使用任何 KeyID。
使用以下 URL 测试客户端的许可证请求：
{versioned *license service* URL}?UseSimpleNonPersistentLicense=1示例：
https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1验证许可证已返回且播放成功。
方案 2：持久性许可证
持久许可证常用于支持离线播放内容的服务。
测试步骤：
使用 PlayReady 测试网站上标注的 KeySeed 对内容进行打包。 对于此测试，打包时可以使用任何 KeyID。
使用以下 URL 测试客户端的许可证请求：
{versioned license service URL}?PlayRight=1&FirstPlayExpiration=60
此参数将指示许可证服务返回一个在首次播放后 60 秒内过期的许可证。 示例：
https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?PlayRight=1&FirstPlayExpiration=60
- 验证许可证已返回且播放成功。 添加或更改测试站点中列出的基于时间的策略参数，以测试其他持久性方案。
场景 3：链式许可证
根绑定许可证被一些订阅服务使用，最常见的是音乐。 在根绑定方案中，可以将多个叶许可证绑定到一个根许可证。 当根许可证到期时，除非重新颁发新的根许可证，否则叶许可证将不再可用。
测试步骤：
使用 PlayReady 测试网站和以下 KeySeed，并使用以下 KeyID 对内容进行打包：
Base64： uPeXHrR3K0icGCpYMBGsZw==
使用以下 URL 测试客户端以许可证请求：
{versioned license service URL}不带任何参数 例：https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1验证许可证已返回且播放成功。 在此方案中，来自服务的单个响应包含两个许可证。 其中一个是根许可证，另一个是叶许可证。 许可证在颁发给客户端后 5 分钟到期。
方案 4：域绑定许可证
域的使用频率不如服务。 PlayReady 域为服务提供了一种管理帐户中活动设备数量的方法，也为帐户内的设备提供了离线共享内容和许可证的方法。
使用 PlayReady 测试网站和以下 KeySeed，并使用以下 KeyID 对内容进行打包：
Base64： m1HAERIu8E+uABCZY4TX2g==
测试客户端将使用以下 URL 加入域并获取许可证：
{versioned license service url}?AccountID=A/uHOj7F+UaM+Jlny2obFA==
示例：
http://playready.directtaps.nehttp/test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?AccountID=A/uHOj7F+UaM+Jlny2obFA==
让测试客户端生成并发送 JoinDomain 质询，并验证服务响应中是否存在域证书。
让测试客户端使用包含 accountID 的相同 URL 向服务发送许可证请求。
验证许可证已返回且播放成功。 还可以向许可证服务发送 LeaveDomain 请求以重置方案。