Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Recomendaciones para PlayReady Services
Microsoft recomienda las siguientes directivas de migración:
Asegúrese de que un servicio se actualice a la versión más reciente del SDK de PlayReady. Esto proporcionará la mejor compatibilidad entre dispositivos nuevos y heredados. Las versiones recientes del SDK del servidor también han agregado mejoras significativas de rendimiento y estabilidad. Tenga en cuenta que no se requieren licencias ni tarifas de licencia adicionales para actualizar a la versión más reciente de PlayReady Server 4.0.
A medida que los nuevos dispositivos continúan la migración de PlayReady al hardware (SoC), habrá más y más dispositivos que informan a un servicio como PlayReady 3.0 y versiones posteriores, y SL3000. Por ejemplo, todos los dispositivos Windows 10 ahora se reportan como dispositivos PlayReady 3.0 o superiores. Se recomienda que los servicios se actualicen a la versión más reciente del SDK del servidor para mantener la compatibilidad, así como aprovechar algunas de las nuevas características.
Use la información proporcionada en este tema como guía para manejar casos extremos, manteniendo servicios de licencias heredados as-is mientras se da soporte a nuevos dispositivos.
Las licencias pueden ponerse en contacto con askdrm@microsoft.com para obtener acceso a nuestro sitio de comentarios para enviar preguntas de migración.
Recomendaciones para fabricantes de dispositivos PlayReady
Se recomienda encarecidamente que los OEM actualicen sus dispositivos a PK4.0 publicados en octubre de 2017, que es la única versión que permite a los dispositivos aprovechar las funcionalidades más recientes implementadas por los principales servicios multimedia.
| Pros | Desventajas: puntos de atención |
|---|---|
| Puede admitir SL3000 | No es compatible con server SDK 1.X |
| Puede implementar funcionalidades más recientes como SecureStop, SecureDelete, MaxResDecode, etc. | |
| Mejor código base | |
| Asegúrese de que se pueden aplicar nuevas directivas de licencia solicitadas por los propietarios de contenido |
Plan de actualización de OEM
Póngase en contacto con los servicios y asegúrese de que todas migran o agreguen una versión de SDK de servidor 2.0 o posterior.
Compruebe su versión del SDK de servidor.
Reiteración de consideraciones para el servicio: no hay requisitos adicionales de licencias de Microsoft y sin cargos adicionales .
Si ejecutan un servicio de licencia basado en sdk de servidor v2.0+, es probable que sean compatibles. Las direcciones URL y escenarios de servicio de la sección siguiente pueden ayudar en las pruebas de compatibilidad.
Si ejecutan un SDK de servidor v1. Servidor de licencias basado en X, pueden migrar su servidor de licencias o agregar un servidor de licencias más reciente para los nuevos clientes, basados en el SDK de servidor 2.0+ (se recomienda la versión más reciente).
Descargue PK 4.0 de Microsoft.
Obtenga soporte técnico de los asociados de Microsoft o directamente desde Microsoft mediante el envío de correo electrónico a AskDRM@microsoft.com.
Implemente PK 4.0 y publique el producto.
Notas sobre la migración de servicios
Para lograr una compatibilidad óptima con los dispositivos, asegúrese de que el servidor de licencias ejecuta la versión más reciente del SDK del servidor. El SDK de servidor más reciente podrá entregar licencias a todos los clientes de PlayReady independientemente de la versión del Kit de portabilidad utilizada. Si un cliente desarrollado con la versión 3.0 o superior del Kit de portabilidad de dispositivos intenta obtener una licencia de un servicio de licencia mediante playReady SDK 1.x, el servicio de licencia devolverá un error SOAP específico del servicio genérico. El servidor registrará una excepción en el registro de Windows y observará que el desafío faltaba en la cadena de certificados de cliente.
Migración de un servicio PlayReady a Server SDK 4.0
Normalmente, una actualización del servicio no implicará ningún cambio de código, sino solo una recompilación e implementación de las bibliotecas actualizadas. En algunos casos, puede haber cambios de código menores debido a algunas API en desuso. La recompilación e implementación de la biblioteca del controlador de licencias debe ser transparente para los dispositivos que acceden al servicio.
La compilación e implementación de un controlador de licencias actualizado deberá tener en cuenta lo siguiente:
El proyecto deberá quitar las referencias a las bibliotecas de PlayReady antiguas y hacer referencia a las nuevas antes de volver a compilar.
Los SDK de servidor más recientes requieren .NET 4.0 o superior. Al actualizar el controlador de servicio de licencias desde una versión temprana, como la 1.52, el marco de trabajo de destino deberá actualizarse en las propiedades del proyecto a la versión 4.0 o posterior.

Si el controlador heredado hace referencia a otras bibliotecas destinadas a una versión de .NET inferior a la 4.0, podría haber pasos de migración adicionales. Sin embargo, una biblioteca de .NET puede hacer referencia a una versión menor sin problemas en general. Merece la pena investigar la oportunidad de volver a compilar las bibliotecas a las que se hace referencia a la versión del controlador o adquirir actualizaciones de biblioteca para componentes de terceros.
Solo se debe hacer referencia a Microsoft.Media.Drm.RMCore en el proyecto. Al implementar una solución, los demás archivos DLL deben implementarse en el directorio bin del sitio web. No es necesario hacer referencia a ellos dentro del proyecto, como era el caso de los SDK anteriores.

Se requiere una versión mínima de CLR de .NET de 4.0 para el grupo de aplicaciones utilizado por el servicio de licencias. Si el servicio de licencia estaba ejecutando la versión 2.0 o anterior, es probable que se ejecute dentro de una versión de CLR de .NET inferior a la 4.0.

El SDK de PlayReady Server más reciente solo se admite en Windows Server 2012 y versiones posteriores. Sin embargo, no se sabe que Windows Server 2008 R2 tiene problemas con el SDK de servidor.
Compatibilidad con diferentes versiones del SDK de servidor para un servicio
Microsoft recomienda migrar a la versión más reciente del SDK poco después de su lanzamiento. Sin embargo, en algunos casos, un servicio puede querer ejecutar varias versiones del SDK de servidor. Esto puede deberse a la necesidad de mantener servicios y puntos de conexión obsoletos y de archivo que no se actualizan fácilmente. En este caso, un servicio puede dirigir a nuevos clientes hacia un servicio de licencia actualizado mientras deja sin modificar el servicio heredado. Por ejemplo, un servicio puede tener varios dispositivos heredados dentro de su ecosistema que ejecutan un cliente creado con PlayReady PK 1.2. Sus nuevos dispositivos se desarrollan con playReady PK 4.0. El nuevo cliente tendría que dirigirse a un servicio de licencias utilizando el SDK de servidor 2.0 o posterior. Si los dispositivos heredados y nuevos usan la misma aplicación (por ejemplo, una plataforma de aplicaciones basada en HTML), la lógica tendrá que agregarse a la aplicación para detectar la versión del cliente. Después, la aplicación cliente puede dirigir las solicitudes de licencia a un servicio de licencia más reciente.
La migración recomendada es actualizar el servicio de licencia a la versión más reciente del SDK de Servidor. Esto puede proporcionar compatibilidad en todos los dispositivos para muchos servicios. Un servicio tendrá que probar entre clientes para validar la compatibilidad.

Si un servicio no desea realizar modificaciones en una configuración de cliente y servicio heredada, la recomendación es hospedar un segundo servicio de licencia que se ha actualizado a la versión más reciente del SDK y que los clientes modernos usan.

Si un servicio usa una sola aplicación cliente en dispositivos heredados (PlayReady 1.X) y dispositivos más recientes (PlayReady 3.0 o superior), debe operar dos servidores de licencias de PlayReady (PlayReady 1.X y PlayReady 3.0 o superior) para atender licencias a todos estos dispositivos. La aplicación puede incluir la lógica para enrutar las solicitudes al servidor de licencias adecuado en función de la versión del cliente de PlayReady subyacente, o bien el servicio puede usar un proxy de servicio que enrute las solicitudes procedentes de todos estos dispositivos en una sola dirección URL al servidor de licencias adecuado.

Esto se puede hacer en un proxy inspeccionando el desafío de licencia. La versión PK se anotará en el elemento <CLIENTVERSION>.
El elemento se encuentra dentro del desafío SOAP bajo el siguiente elemento:
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
Compatibilidad con clientes basados en PK 3.0 o superior con servicios de licencia heredados
Es probable que un dispositivo cliente desarrollado con playReady Device Porting Kit 3.0 o superior funcione con los servicios existentes desarrollados con el SDK de servidor 2.0 o posterior. Como se indicó anteriormente, un servicio debe probar PK 3.0 o clientes posteriores para validar la compatibilidad.
Si el dispositivo tiene un certificado SL3000, el NivelDeSeguridad expuesto a través del certificado del cliente en el controlador de licencias se informará como 3000. Esto puede provocar problemas con algunos controladores de licencias si buscan un valor SecurityLevel específico para diferenciar entre los dispositivos de producción y prueba.
Diferenciar entre Niveles de Seguridad es común en los servicios que proporcionan un acceso limitado al contenido para que los dispositivos de prueba puedan validar las licencias de reproducción de un servicio en vivo. Solo los dispositivos notificados como SecurityLevel 2000 tendrían licencias de reproducción entregadas para el contenido comercial. El servicio produciría una excepción específica del servicio que daría lugar a una falla SOAP en el cliente.
En el ejemplo siguiente, se comprueba el nivel de seguridad en el certificado del cliente para asegurarse de que sea un dispositivo de producción. Dado que se ha predefinido a 2000, los dispositivos con el nivel de seguridad de 3000 no serán considerados dispositivos de producción.

En este ejemplo siguiente se actualiza la comprobación del nivel de seguridad a si es mayor o igual que 2000. Esto garantizará la compatibilidad con dispositivos SL3000.

Compatibilidad con PlayReady 3.X y características posteriores para los servicios
Además del nuevo nivel de seguridad DRM de hardware, PlayReady 3.0 y versiones posteriores también introdujeron una variedad de nuevas características. Para aprovechar estas nuevas características, el servicio deberá determinar primero si el cliente es capaz de PlayReady 3.0 y características posteriores. La clase de certificado de cliente ahora admite un método GetSupportedFeatures que devolverá una colección de características para ayudar en la lógica de definir directivas dentro del controlador. Si el cliente se desarrolló con el Kit de portabilidad de dispositivos 3.0, tendrá en la colección la propiedad SupportedFeature.PlayReady3Features. Hay características adicionales útiles en la colección, como si el cliente usa un reloj seguro o un reloj anti-retroceso.
Este es un ejemplo de cómo detectar si el dispositivo es un cliente de PlayReady 3.0.

Una vez detectado, el controlador puede agregar directivas como Secure Stop, Expiración de licencias en tiempo real y MaxResDecode, por ejemplo.
Compatibilidad con SL2000 y SL3000 en servicios
PlayReady introdujo un nuevo nivel de seguridad SL3000 que notifican los dispositivos que han cumplido el nivel de seguridad de hardware de PlayReady para ejecutarse dentro de un entorno de ejecución de confianza, tal como se define en las reglas de cumplimiento y solidez. Será habitual que los servicios tengan algunos clientes que informen como SL2000 y otros como SL3000. Por ejemplo, en Windows, los dispositivos anteriores que se han actualizado a Windows 10 pueden informar como SL2000. Los nuevos dispositivos Windows 10 aparecerán como SL3000 cuando el DRM se haya incorporado en los chips más recientes.
Este es un ejemplo de un servicio que proporciona diferentes directivas en función del nivel de seguridad notificado del desafío del cliente:

Un servicio determinará cómo las directivas deben diferir entre los clientes DRM basados en software y los clientes DRM basados en hardware. Estas políticas pueden estar impulsadas por los requisitos del estudio. Por ejemplo, un estudio puede requerir en el futuro que el contenido de Ultra-HD o 4K esté limitado a dispositivos que admitan DRM de PlayReady basado en hardware.
Las directivas de PlayReady 3.0 y superiores en torno a las resoluciones se pueden lograr de dos maneras diferentes. Una manera es establecer la directiva MaxResDecode de licencias SL2000 en los límites permitidos proporcionados por el propietario del contenido. Los dispositivos SL3000 no obtendrían esta restricción de directiva. Otra opción aplicable a las tecnologías de streaming adaptables es usar un keyID diferente al proteger las distintas resoluciones. Al detectar el nivel de seguridad, un servicio solo puede proporcionar licencias para las resoluciones permitidas para un cliente basado en software. Un cliente que informa de un nivel de seguridad de SL3000 obtendría licencias de reproducción para todas las resoluciones. PlayReady introdujo un nuevo encabezado DRM (v4.2.0.0 y versiones posteriores) para admitir este último escenario habilitando varios identificadores de clave en el esquema.
Véase también
Versiones de producto de PlayReady
Cómo probar clientes de PlayReady con versiones del SDK del servidor PlayReady