PlayReady Client-Server 兼容性和迁移注意事项

抽象

® Microsoft PlayReady® 3.0 带来了 OEM 想要在其设备中集成的重要新功能。 这为 5 多年前设计的服务带来了一些兼容性问题。 本文讨论它们,并为 PlayReady 3.0 升级路径中的服务和 OEM 提供指南

目录

概述

PlayReady 兼容性矩阵

PlayReady 服务的建议

PlayReady 设备制造商的建议

服务迁移说明

将 PlayReady 服务迁移到服务器 SDK 3.0

编译和部署更新的许可证处理程序需要考虑以下事项

提供对服务的不同版本服务器 SDK 的支持

使用旧版许可证服务支持基于 PK 3.0 的客户端

支持适用于服务的 PlayReady 3.0 功能

在服务中支持 SL2000 和 SL3000

使用 PlayReady Server SDK 的版本测试 PlayReady 客户端

方案 1:非永久性许可证

方案 2:永久性许可证

场景 3:链式许可证

方案 4:域绑定许可证

概述

PlayReady 许可证服务维护旧版 PlayReady 设备的向后兼容性。 例如,使用 PlayReady Server SDK 3.0 开发的新许可证服务可以将许可证传送到使用 PlayReady 移植工具包(PK)1.2(2008 年)开发的旧版设备。

但是,当服务和设备进入 PlayReady 3 版本时,兼容性存在一些细微差别。 使用 3.0 移植工具包开发的 PlayReady 客户端无法从 2011 年 Server SDK 2.0 版本之前生成的许可证服务获取许可证。 运行早期版本的服务器 SDK 的服务需要升级才能与 PlayReady 3.0 兼容。

PlayReady 兼容性矩阵

客户端上的大多数 PlayReady 版本都可以使用 PlayReady Server SDK 的不同版本。 下面指出了一些细微之处,以及 3.0 移植工具包上开发的 PlayReady 客户端的更改。

  服务器 SDK 1.x 服务器 SDK 2.0 (2011) 服务器 SDK 2.1 (2013) 服务器 SDK 2.9 (2014) 服务器 SDK 3.0 (2015)
PK 1.x (2008) * * * *
PK 2.x (2011)
PK 3.0 (2015) ** *** *** ***
  服务器 SDK v1.5.2 服务器 SDK v2.1 和服务器 SDK v2.9 服务器 SDK v3.0 服务器 SDK v4.0
PK v4.x 是的 是的 是的
PK v3.x 是的 是的 是的
PK v2.5 和 v2.11 是的 是的 是的 是的
不相容的 相容

* 某些 PK 1.2 客户端不支持吊销,服务器 SDK 2.x+ 中是必需的。 这并不常见。

** PK3.0 客户端无法使用版本 2.0 之前的服务器 SDK 获取媒体播放许可证。

PK3.0 客户端可以使用 2.X SDK 的许可证服务器,但只能获取具有 SL2000 安全级别的许可证。 此外,在创建许可证时,不支持版本 4.2 标头(多个密钥)和策略(如安全停止和 MaxResDecode)等新功能。 某些具有服务器 SDK 2.0 的 PK3.0 客户端上存在链接许可证(根/叶)问题。 服务需要测试客户端以验证兼容性。 本文档末尾有一组有助于测试的方案。

PlayReady 服务的建议

  1. 确保服务升级到最新版本的 PlayReady SDK。 这将跨新旧设备提供最佳兼容性。 最新版本的服务器 SDK 也增加了显著的性能和稳定性改进。 请注意,升级到最新的 PlayReady Server 3.0 不需要额外的许可或许可证费用

  2. 随着新设备继续将 PlayReady 迁移到硬件(SoC),越来越多的设备以 PlayReady 3.0 和 SL3000 的形式向服务报告。 例如,所有 Windows 10 设备现在都报告为 PlayReady 3.0 设备。 建议服务升级到最新版本的服务器 SDK,以保持兼容性,并利用一些新功能。

  3. 使用本指南处理边缘情况,例如在支持新设备时维护旧版许可证服务 as-is。

  4. 被许可方可以联系 askdrm@microsoft.com 以获取我们反馈站点的访问权限,并提交迁移问题。

PlayReady 设备制造商的建议

强烈建议 OEM 将其设备升级到 2015 年 4 月发布的 PK3.0,这是允许设备利用顶级媒体服务实施的最新功能的唯一版本。

Pros 缺点 - 注意点
可以支持 SL3000 与服务器 SDK 1.X 不兼容
可以实现 SecureStop、MaxResDecode 等最新功能。
更好的基本代码
确保可以强制实施内容所有者请求的新许可证策略

OEM 升级计划

  1. 请与服务联系,并确保它们全部迁移或添加服务器 SDK 2.0+ 版本 o 验证其服务器 SDK 版本

    • 重申服务注意事项: Microsoft没有额外的许可要求,也无需额外付费

    • 如果运行基于服务器 SDK v2.0+ 的许可证服务,则它们可能兼容。 下一部分中的服务 URL 和方案可以帮助进行兼容性测试。 o 如果他们运行服务器 SDK v1。基于 X 的许可证服务器,他们可以迁移其许可证服务器,或为新客户端添加较新的许可证服务器 - 基于服务器 SDK 2.0+ (建议使用最新版本)。

  2. 从 Microsoft 下载 PK3.0

  3. 从微软的合作伙伴处或直接从微软那里获得支持https://connect.microsoft.com/playready

  4. 实现 PK3.0 并发布产品。

服务迁移说明

为获得最佳设备兼容性,请确保许可证服务器正在运行最新版本的服务器

SDK。 无论使用的移植工具包版本如何,最新的服务器 SDK 都可以向所有 PlayReady 客户端传送许可证。 如果使用 3.0 移植工具包开发的客户端尝试使用 PlayReady SDK 1.x 从许可证服务获取许可证,则许可证服务将返回特定于泛型服务的 SOAP 错误。 服务器会将异常记录到 Windows 日志,指出质询缺少客户端证书链。

将 PlayReady 服务迁移到服务器 SDK 3.0

服务升级通常不涉及任何代码更改,而只是重新编译和部署更新的库。 在某些情况下,由于某些已弃用的 API,可能会发生少量代码更改。 对访问服务的设备而言,许可证处理程序库的重新编译和部署应该是透明的。

编译和部署更新的许可证处理程序需要考虑以下事项

  • 项目需要删除对旧 PlayReady 库的引用,并在重新编译之前引用新库。

  • 较新的服务器 SDK 需要 .NET 4.0 或更高版本。 从早期版本(如 1.52)升级许可证服务处理程序时,需要在项目属性中将目标框架更新为 4.0 或更高版本。

  • 如果旧处理程序引用了面向低于 4.0 的 .NET 版本的其他库,则可能会执行其他迁移步骤。 但是,.NET 库可以引用较低版本,但一般情况下没有任何问题。 有必要调查将引用的库重新编译到处理程序版本或获取第三方组件的库更新的机会。

  • 只需在项目中引用 Microsoft.Media.Drm.RMCore。 部署解决方案时,需要在网站的 bin 目录中部署其他 DLL。 无需在项目中引用它们,就像之前 SDK 的情况一样。

  • 许可证服务的应用程序池需要最低 .NET CLR 版本 4.0。 如果许可证服务运行的是 2.0 或更早版本,则可能是在低于 4.0 的 .NET CLR 版本中运行。

  • 最新的 PlayReady Server SDK 仅在 Windows Server 2012 及更高版本下受支持。 但是,Windows Server 2008 R2 不知道服务器 SDK 存在任何问题。

支持服务的不同服务器 SDK 版本

建议在发布 SDK 后不久迁移到最新版本的 SDK。 但在某些情况下,服务可能想要运行多个版本的服务器 SDK。 这可能是由于维护旧服务和存档服务和终结点而不容易更新的。 在这种情况下,服务可以将新客户端指向更新的许可证服务,同时使旧服务保持不变。 例如,服务在其生态系统中可能有多个旧设备,运行使用 PlayReady PK 1.2 生成的客户端。 他们的新设备是使用 PlayReady PK 3.0 开发的。 新客户端需要指向使用服务器 SDK 2.0 或更高版本生成的许可证服务。 如果旧设备和新设备都使用相同的应用程序(例如基于 HTML 的应用平台),则需要将逻辑添加到应用程序以检测客户端的版本。 然后,客户端应用程序可以将许可证请求定向到较新的许可证服务。

建议的迁移是将许可证服务更新到最新版本的服务器 SDK。 这可以为许多服务提供跨所有设备的兼容性。 服务需要跨客户端进行测试,以验证兼容性。

如果服务不想对旧客户端和服务配置进行更改,建议托管已升级到最新版本的 SDK 并被新式客户端使用的第二个许可证服务。

如果服务对旧版新设备使用相同的应用程序,则可以在旧版设备中配置代理,需要继续使用旧服务。

服务还可以将旧客户端定向到旧服务,并将新客户端定向到更新的服务。 可以通过检查许可证质询在代理中完成此操作。 PK 版本将记录在 <CLIENTVERSION> 元素中。

该元素位于以下元素下的 SOAP 质询中:

<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>

使用旧版许可证服务支持基于 PK 3.0 的客户端

使用 PlayReady 移植工具包 3.0 开发的客户端设备可能适用于使用服务器 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,而其他客户端报告为 SL3000。 例如,在 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 测试网站包含一组许可证服务,这些服务使用服务器 SDK 的当前版本和旧版本。 这些许可证服务可用于帮助测试客户端兼容性。 例如,将客户端更新到 PK 3.0 时,可以针对以前的服务版本测试客户端以查看兼容性。

下表中列出了版本控制服务。

SDK 版本 许可证服务 URL
SDK 1.52 https://test.playready.microsoft.com/directtaps/svc/pr152/rightsmanager.asmx
SDK 2.0 https://test.playready.microsoft.com/directtaps/svc/pr20/rightsmanager.asmx
SDK 2.1 https://test.playready.microsoft.com/directtaps/svc/pr21/rightsmanager.asmx
SDK 2.9 https://test.playready.microsoft.com/directtaps/svc/pr29/rightsmanager.asmx
SDK 3.0 https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx

这些版本控制服务可以利用 PlayReady 测试站点中列出的参数来测试特定策略: https://testweb.playready.microsoft.com/

[注意!] 并非所有策略参数都适用于每个服务版本。 例如,MaxResDecode 是一个新策略,仅适用于使用 Server SDK 3.0 或更高版本开发的服务。

为了帮助进行功能测试,可以将以下测试与不同的版本控制许可证服务一起使用,以涵盖四种独特的许可方案。

方案 1:非永久性许可证

非持久性许可证是流式处理服务使用的最常见许可证方案。

测试步骤:

  1. 使用 PlayReady 测试网站上记录的 KeySeed 打包内容。 对于此测试,打包时可以使用任何 KeyID。

  2. 使用以下 URL 从客户端测试许可证请求:

    {versioned *license service* URL}?UseSimpleNonPersistentLicense=1

    例:

    https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1

  3. 验证是否返回许可证并成功播放。

方案 2:永久性许可证

永久许可证通常由使播放内容脱机的服务使用。

测试步骤:

  1. 使用 PlayReady 测试网站上记录的 KeySeed 打包内容。 对于此测试,打包时可以使用任何 KeyID。

  2. 使用以下 URL 从客户端测试许可证请求:

    {versioned license service URL}?PlayRight=1&FirstPlayExpiration=60

此参数将指示许可证服务返回在首次播放后 60 秒过期的许可证。 例:

https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?PlayRight=1&FirstPlayExpiration=60

  1. 验证是否返回许可证,以及播放是否成功。 添加或更改测试站点中列出的基于时间的策略参数,以测试其他持久性方案。

方案 3:链接许可证

某些订阅服务最常用于音乐的根绑定许可证。 使用根绑定方案,多个叶许可证可以绑定到单个根许可证。 根许可证过期时,除非重新颁发新根,否则叶许可证不再可用。

测试步骤:

  1. 使用 PlayReady 测试站点和以下 KeyID 上记录的 KeySeed 打包内容:

    Base64: uPeXHrR3K0icGCpYMBGsZw==

  2. 使用以下 URL 测试客户端以请求许可证:

    {versioned license service URL}不带任何参数 例:

    https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1

  3. 验证是否返回许可证,以及播放是否成功。 在此方案中,服务的单个响应应包含两个许可证。 其中一个是根许可证,另一个是叶许可证。 许可证应在向客户端颁发后 5 分钟过期。

方案 4:域绑定许可证

域不如服务通常使用。 PlayReady 域为服务提供一种方法,用于管理帐户中的活动设备数以及帐户中的设备脱机共享内容和许可证。

  1. 使用 PlayReady 测试站点和以下 KeyID 上记录的 KeySeed 打包内容:

    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==

  1. 让测试客户端生成并发送 JoinDomain 质询,并验证服务响应中是否存在域证书。

  2. 让测试客户端使用相同的 URL(包括 accountID)向服务发送许可证请求。

  3. 验证是否返回许可证,以及播放是否成功。 还可以将 LeaveDomain 请求发送到许可证服务以重置方案。