Migración desde versiones anteriores de la PK y el servidor
Recomendaciones para PlayReady Services
Microsoft recomienda las siguientes directivas de migración:
Asegúrese de que un servicio se actualiza 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 notifican como dispositivos PlayReady 3.0 y versiones posteriores. Se recomienda que los servicios 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 controlar casos perimetrales, como mantener los servicios de licencia heredados tal cual mientras se admiten 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.
| Ventajas | 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. | |
| Código base mejor | |
| 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 todos migran o agreguen una versión posterior del SDK de servidor 2.0.
Compruebe su versión del SDK de servidor.
Reitera las 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 o posterior, 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 de migraciones para 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 usada. 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 el SDK de PlayReady 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 indicando que faltaba el desafío 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 implica 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 de controladores 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 tendrá que 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 posterior. Al actualizar el controlador del servicio de licencias desde una versión temprana, como 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 en la versión del controlador o adquirir actualizaciones de biblioteca para componentes de terceros.
Solo es necesario 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 .NET CLR de 4.0 para el grupo de aplicaciones utilizado por el servicio de licencia. Si el servicio de licencia estaba ejecutando la versión 2.0 o anterior, es probable que se ejecute en 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. Windows Server 2008 R2, sin embargo, no se sabe que tiene ningún problema 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 mantener los servicios y puntos de conexión heredados y de archivo que no se actualizan fácilmente. En este caso, un servicio puede apuntar nuevos clientes a un servicio de licencia actualizado mientras deja el servicio heredado intacto. 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 apuntar a un servicio de licencia creado con 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 deberá 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 licencias 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 heredada de cliente y servicio, la recomendación es hospedar un segundo servicio de licencia que se haya actualizado a la versión más reciente del SDK y que los clientes modernos utilicen.
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 única 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 .
El elemento se encuentra dentro del desafío SOAP en 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 server SDK 2.0 o posterior. Como se indicó anteriormente, un servicio debe probar los clientes PK 3.0 o superior para validar la compatibilidad.
Si el dispositivo tiene un certificado SL3000, SecurityLevel expuesto a través del certificado de cliente en el controlador de licencias notificará como 3000. Esto puede causar problemas con algunos controladores de licencias si buscan un valor SecurityLevel específico para diferenciar entre los dispositivos de producción y prueba.
La diferenciación entre SecurityLevels es común para los servicios que proporcionan acceso limitado al contenido para los dispositivos de prueba para validar licencias de reproducción desde un servicio activo. 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 un error soap en el cliente.
En el ejemplo siguiente, securityLevel se comprueba en el certificado de cliente para asegurarse de que es un dispositivo de producción. Puesto que se ha codificado de forma dura hasta 2000, los dispositivos con el nivel de seguridad de 3000 no se verán como 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 tendrá que 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á la propiedad SupportedFeature.PlayReady3Features en la colección. Hay características adicionales útiles en la colección, como si el cliente usa un reloj seguro o un reloj antirreversión.
Este es un ejemplo de cómo detectar si el dispositivo es un cliente de PlayReady 3.0.
Una vez detectado que 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 en 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 informes como SL3000. Por ejemplo, en Windows, los dispositivos más antiguos que se han actualizado a Windows 10 pueden notificar como SL2000. Los nuevos dispositivos Windows 10 notificarán como SL3000 donde se ha incorporado DRM a 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 deben diferir las directivas entre los clientes DRM basados en software y los clientes DRM basados en hardware. Estas directivas pueden estar controladas por los requisitos de Studio. Por ejemplo, un estudio puede requerir en el futuro que el contenido Ultra-HD o 4K esté limitado a dispositivos que admiten DRM de PlayReady basado en hardware.
Las directivas de PlayReady 3.0 y versiones posteriores 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 adaptable 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 KeyID en el esquema.
Consulte también
Versiones de producto de PlayReady
Cómo probar clientes de PlayReady con versiones del SDK de PlayReady Server