Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Resumo
O Microsoft® PlayReady® 3.0 traz novas funcionalidades importantes que os OEMs querem integrar em seus dispositivos. Isso traz alguns problemas de compatibilidade com serviços projetados há mais de 5 anos. Este documento os discute e fornece orientação para serviços e OEMs no caminho de atualização para o PlayReady 3.0
Índice
Matriz de compatibilidade PlayReady
Recomendações para os Serviços PlayReady
Recomendações para fabricantes de dispositivos PlayReady
Notas de migração para serviços
Migrando um serviço PlayReady para o Server SDK 3.0
Compilar e implantar um manipulador de licença atualizado precisará levar em conta o seguinte:
Suportando diferentes versões do SDK do Servidor para um Serviço
Suporte a clientes baseados em PK 3.0 com serviços de licença herdados
Suporte a recursos do PlayReady 3.0 para serviços
Suportar tanto SL2000 como SL3000 nos serviços
Testando clientes PlayReady com versões do SDK do servidor PlayReady
Cenário 1: licenças não persistentes
Cenário 2: licenças persistentes
Cenário 3: licenças encadeadas
Cenário 4: licença vinculada ao domínio
Visão geral
Os serviços de licença PlayReady mantêm compatibilidade retroativa para dispositivos PlayReady antigos. Por exemplo, um novo serviço de licença desenvolvido com o PlayReady Server SDK 3.0 pode fornecer licenças para um dispositivo legado que foi desenvolvido usando o PlayReady Porting Kit(PK) 1.2 desde sua versão inicial (2008).
Há, no entanto, algumas nuances na compatibilidade à medida que os serviços e dispositivos passam para as versões do PlayReady 3. Os clientes PlayReady desenvolvidos com o 3.0 Porting Kit não podem obter licenças de um serviço de licença criado antes da versão 2011 do Server SDK 2.0. Os serviços que executam versões anteriores do SDK do Servidor precisarão ser atualizados para serem compatíveis com o PlayReady 3.0.
Matriz de compatibilidade PlayReady
A maioria das versões do PlayReady no cliente pode funcionar com as diferentes versões do SDK do PlayReady Server. Existem algumas sutilezas, como observado abaixo, bem como uma mudança com os clientes PlayReady desenvolvidos no Kit de Portabilidade 3.0.
| SDK do servidor 1.x | SDK do Servidor 2.0 (2011) | SDK do Servidor 2.1 (2013) | SDK do Servidor 2.9 (2014) | Servidor SDK 3.0 (2015) | |
|---|---|---|---|---|---|
| PK 1.x (2008) | * | * | * | * | |
| PK 2.x (2011) | |||||
| PK 3.0 (2015) | ** | *** | *** | *** |
| SDK do servidor v1.5.2 | SDK do Servidor v2.1 e SDK do Servidor v2.9 | SDK do servidor v3.0 | SDK do servidor v4.0 | |
|---|---|---|---|---|
| PK v4.x | Não | Sim | Sim | Sim |
| PK v3.x | Não | Sim | Sim | Sim |
| PK v2.5 e v2.11 | Sim | Sim | Sim | Sim |
| Incompatível | Compatível |
|---|---|
* Alguns clientes PK 1.2 não suportaram a revogação que é necessária no Server SDK 2.x+. Isso não é comum.
** Os clientes PK3.0 não podem usar um SDK do servidor anterior à versão 2.0 para obter uma licença de reprodução de mídia.
Os clientes PK3.0 podem usar servidores de licença usando um SDK 2.X, mas só podem obter uma licença com um nível de segurança SL2000. Além disso, novos recursos, como suporte para cabeçalhos da versão 4.2 (várias chaves) e políticas como Secure Stop e MaxResDecode não estão disponíveis ao criar uma licença. Houve problemas com licenças encadeadas (raiz/folha) em alguns clientes PK3.0 com o Server SDK 2.0. Os serviços precisarão testar os clientes para validar a compatibilidade. Há um conjunto de cenários no final deste documento que podem ajudar nos testes.
Recomendações para os Serviços PlayReady
Certifique-se de que um serviço seja atualizado para a versão mais recente do SDK PlayReady. Isso proporcionará a melhor compatibilidade entre dispositivos novos e legados. As versões recentes do SDK do servidor também adicionaram melhorias significativas de desempenho e estabilidade. Observe que nenhuma licença adicional ou taxas de licença são necessárias para atualizar para o PlayReady Server 3.0 mais recente.
À medida que novos dispositivos continuam a migração do PlayReady para o hardware (SoC), haverá cada vez mais dispositivos reportando a um serviço como PlayReady 3.0 e SL3000. Por exemplo, todos os dispositivos Windows 10 agora são reportados como dispositivos PlayReady 3.0. Os serviços são incentivados a atualizar para a versão mais recente do SDK do servidor para manter a compatibilidade, bem como aproveitar alguns dos novos recursos.
Use este guia para lidar com casos de borda, como a manutenção de serviços de licença herdados as-is ao mesmo tempo em que oferece suporte a novos dispositivos.
Os licenciados podem entrar em contato com askdrm@microsoft.com para obter acesso ao nosso site de feedback e enviar perguntas sobre migração.
Recomendações para fabricantes de dispositivos PlayReady
É altamente recomendável que os OEMs atualizem seus dispositivos para PK3.0 lançado em abril de 2015, que é a única versão que permite que os dispositivos aproveitem as funcionalidades mais recentes que estão sendo implementadas pelos principais serviços de mídia.
| Prós | Contras – Pontos de atenção |
|---|---|
| Pode suportar SL3000, mas não é compatível com o Server SDK 1.X. | |
| Pode implementar as funcionalidades mais recentes como SecureStop, MaxResDecode, etc. | |
| Melhor base de código | |
| Garantir que novas políticas de licença, conforme solicitado pelos proprietários de conteúdo, possam ser aplicadas |
Plano de atualização OEM
Entre em contato com seus serviços e certifique-se de que todos eles migram ou adicionam uma versão do Server SDK 2.0+ o Verificar a versão do SDK do servidor
Reitere as considerações para o serviço: sem requisitos adicionais de licenciamento da Microsoft e sem taxas adicionais .
Se eles executarem um serviço de licença baseado no Server SDK v2.0+, eles provavelmente serão compatíveis. As URLs e os cenários de serviço na próxima seção podem ajudar nos testes de compatibilidade. o Se eles executarem um Server SDK v1. Servidor de licenças baseado em X, eles podem migrar seu servidor de licenças ou adicionar um servidor de licenças mais recente para os novos clientes - com base no Server SDK 2.0+ (a versão mais recente é recomendada).
Baixe o PK3.0 da Microsoft
Obtenha suporte dos parceiros da Microsoft ou diretamente da Microsoft em https://connect.microsoft.com/playready.
Implemente PK3.0 e libere seu produto.
Notas de migração para serviços
Para uma compatibilidade ideal do dispositivo, verifique se o servidor de licenças está executando a versão mais recente do servidor
SDK. O SDK de servidor mais recente será capaz de fornecer licenças para todos os clientes PlayReady, independentemente da versão do Porting Kit usada. Se um cliente desenvolvido com o Kit de portabilidade 3.0 tentar obter uma licença de um serviço de licença usando o PlayReady SDK 1.x, o serviço de licença retornará uma falha SOAP específica do serviço genérico. O servidor registará uma exceção no log do Windows, indicando que a cadeia de certificados do cliente estava ausente no desafio.
Migrando um serviço PlayReady para o Server SDK 3.0
Uma atualização de serviço geralmente não envolverá nenhuma alteração de código, mas apenas uma recompilação e implantação das bibliotecas atualizadas. Em alguns casos, pode haver pequenas alterações de código devido a algumas APIs obsoletas. A recompilação e a implantação da biblioteca do manipulador de licenças devem ser transparentes para os dispositivos que acessam o serviço.
Compilar e implantar um manipulador de licença atualizado precisará levar em conta o seguinte:
O projeto precisará remover referências às bibliotecas antigas do PlayReady e fazer referência à nova antes de recompilar.
Os SDKs de servidor mais recentes exigem .NET 4.0 ou superior. Ao atualizar o manipulador de serviço de licenças de uma versão inicial, como a 1.52, o framework de destino precisará ser atualizado nas propriedades do projeto para a versão 4.0 ou superior.
Se o manipulador herdado referenciar outras bibliotecas que visavam uma versão do .NET inferior a 4.0, poderá haver etapas adicionais de migração. No entanto, uma biblioteca .NET pode fazer referência a uma versão menor sem problemas em geral. Valeria a pena investigar a possibilidade de recompilar bibliotecas referenciadas para a versão do gestor ou adquirir atualizações das bibliotecas para componentes de terceiros.
Somente Microsoft.Media.Drm.RMCore precisa ser referenciado dentro do projeto. Ao implantar uma solução, as outras DLLs precisam ser implantadas no diretório bin do site. Eles não precisam ser referenciados dentro do projeto, como era o caso com SDKs anteriores.
Uma versão mínima do .NET CLR 4.0 é necessária para o pool de aplicativos utilizado pelo serviço de licença. Se o serviço de licença estava executando 2.0 ou anterior, é provável que ele esteja sendo executado em uma versão .NET CLR menor que 4.0.
O SDK mais recente do PlayReady Server só é suportado no Windows Server 2012 e superior. No entanto, o Windows Server 2008 R2 não é conhecido por ter problemas com o SDK do Servidor.
Suportando diferentes versões do SDK do Servidor para um Serviço
Recomenda-se migrar para a versão mais recente do SDK logo após seu lançamento. Em alguns casos, no entanto, um serviço pode querer executar várias versões do SDK do servidor. Isso pode ser devido à manutenção de serviços herdados e de arquivamento e pontos de extremidade que não são facilmente atualizados. Nesse caso, um serviço pode apontar novos clientes para um serviço de licença atualizado, deixando o serviço herdado intocado. Por exemplo, um serviço pode ter vários dispositivos herdados dentro de seu ecossistema executando um cliente criado com PlayReady PK 1.2. Seus novos dispositivos são desenvolvidos usando o PlayReady PK 3.0. O novo cliente precisaria apontar para um serviço de licença criado com o Server SDK 2.0 ou superior. Se os dispositivos herdados e novos usarem o mesmo aplicativo (como uma plataforma de aplicativo baseada em HTML), será necessário adicionar lógica ao aplicativo para detetar a versão do cliente. O aplicativo cliente pode direcionar solicitações de licença para um serviço de licença mais recente.
A migração recomendada é atualizar o serviço de licença para a versão mais recente do SDK do servidor. Isso pode fornecer compatibilidade em todos os dispositivos para muitos serviços. Um serviço precisará ser testado entre clientes para validar a compatibilidade.
Se um serviço não quiser fazer alterações em um cliente herdado e configuração de serviço, a recomendação é hospedar um segundo serviço de licença que tenha sido atualizado para a versão mais recente do SDK e seja utilizado por clientes modernos.
Se um serviço usa o mesmo aplicativo para dispositivos novos e herdados, pode-se configurar um proxy para que os dispositivos herdados continuem a usar o serviço herdado.
Um serviço também pode direcionar clientes herdados para um serviço herdado e novos clientes para um serviço atualizado. Isso pode ser feito em um proxy, verificando o desafio da licença. A versão PK será anotada no elemento <CLIENTVERSION>.
O elemento está localizado dentro do desafio SOAP sob o seguinte elemento:
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
Suporte a clientes baseados em PK 3.0 com serviços de licença herdados
Um dispositivo cliente desenvolvido com o PlayReady Porting Kit 3.0 provavelmente funcionará com serviços existentes desenvolvidos com o Server SDK 2.0 e superior. Como observado acima, um serviço precisa testar os clientes PK 3.0 para validar a compatibilidade.
Se o dispositivo tiver um certificado SL3000, o nível de segurança exposto através do certificado do cliente no manipulador de licenças será relatado como 3000. Isso pode causar problemas com alguns manipuladores de licença se eles estiverem procurando um valor de nível de segurança específico para diferenciar entre dispositivos de produção e de teste.
A diferenciação entre níveis de segurança é comum para serviços que fornecem acesso limitado ao conteúdo para dispositivos de teste para validar licenças de reprodução de um serviço ativo. Apenas os dispositivos reportados como Nível de Segurança 2000 teriam licenças de reprodução entregues para conteúdo comercial. O serviço lançaria uma exceção específica do serviço que resultaria em uma falha SOAP no cliente.
No exemplo abaixo, o nível de segurança está sendo verificado no certificado do cliente para garantir que seja um dispositivo de produção. Uma vez que foi codificado até 2000, os dispositivos com o nível de segurança de 3000 não serão vistos como dispositivos de produção.
Este exemplo atualiza a verificação do nível de segurança para saber se ele é maior ou igual a 2000. Isso garantirá a compatibilidade com dispositivos SL3000.
Suporte a recursos do PlayReady 3.0 para serviços
Além do novo nível de segurança DRM de hardware, a versão PlayReady 3 também introduziu uma variedade de novos recursos. A fim de tirar proveito desses novos recursos, o serviço precisará primeiro determinar se o cliente é capaz de recursos PlayReady 3. A classe de certificado de cliente agora suporta um
O método GetSupportedFeatures, que retornará uma coleção de funcionalidades para ajudar na lógica de definição de políticas dentro do manipulador. Se o cliente foi desenvolvido com o Kit de Portabilidade 3.0, ele terá o SupportedFeature.PlayReady3Features na coleção. Existem funcionalidades adicionais úteis na coleção, tais como verificar se o cliente está a usar um relógio seguro ou um relógio anti-retrocesso.
Aqui está um exemplo de como detetar se o dispositivo é um cliente PlayReady 3.
Uma vez detetado, o manipulador pode adicionar políticas como Secure Stop, expiração de licença em tempo real e MaxResDecode, por exemplo.
Suporte em serviços para SL2000 e SL3000
PlayReady introduziu um novo nível de segurança, o SL3000, que é indicado por dispositivos que o cumpriram.
Nível de segurança de hardware PlayReady para execução em um ambiente de execução confiável, conforme definido nas Regras de Conformidade e Robustez. Será comum que os serviços apresentem alguns relatórios de clientes como SL2000 e outros como SL3000. Por exemplo, no Windows, dispositivos mais antigos que atualizaram para o Windows 10 podem ser identificados como SL2000. Novos dispositivos com Windows 10 vão apresentar-se como SL3000, nos quais o DRM foi incorporado nos chips mais recentes.
Aqui está um exemplo de um serviço que fornece políticas diferentes com base no nível de segurança relatado do desafio do cliente:
Um serviço determinará como as políticas devem diferir entre clientes DRM baseados em software e clientes DRM baseados em hardware. Essas políticas podem ser orientadas por requisitos do estúdio. Por exemplo, um estúdio pode exigir no futuro que o conteúdo Ultra-HD ou 4K seja limitado a dispositivos que suportam DRM PlayReady baseado em hardware.
Com o PlayReady 3, as políticas em torno de resoluções podem ser realizadas de duas maneiras diferentes. Uma maneira é definir a política MaxResDecode de licenças SL2000 para os limites permitidos fornecidos pelo proprietário do conteúdo. Os dispositivos SL3000 não obteriam essa restrição de política. Outra opção aplicável às tecnologias de streaming adaptáveis é usar um KeyID diferente ao proteger as várias resoluções. Ao detetar o nível de segurança, um serviço poderá então apenas fornecer licenças para as resoluções permitidas baseadas em software. Clientes que relatassem um nível de segurança de SL3000 obteriam licenças de reprodução para todas as resoluções. PlayReady introduziu um novo cabeçalho DRM para suportar este último cenário, habilitando vários KeyIDs no esquema.
Testando clientes PlayReady com versões do SDK do servidor PlayReady
O site de teste PlayReady contém um conjunto de serviços de licença que usam versões atuais e herdadas do SDK do servidor. Esses serviços de licença podem ser usados para ajudar no teste de compatibilidade do cliente. Por exemplo, ao atualizar um cliente para PK 3.0, o cliente pode ser testado em relação a versões de serviço anteriores para revisar a compatibilidade.
Os serviços versionados estão listados na tabela abaixo.
Esses serviços versionados podem utilizar os parâmetros listados na documentação do Serviço de Servidor de Teste PlayReady para testar políticas específicas.
[NOTA!] Nem todos os parâmetros de política funcionarão com cada uma das versões do serviço. Por exemplo, MaxResDecode é uma nova política e só funciona com serviços desenvolvidos com o Server SDK 3.0 ou posterior.
Para ajudar no teste de capacidade, os testes a seguir podem ser usados com os diferentes serviços de licença versionados para cobrir quatro cenários de licenciamento exclusivos.
Cenário 1: licenças não persistentes
As licenças não persistentes são o cenário de licença mais comum usado pelos serviços de streaming.
Etapas de teste:
Embale o conteúdo usando o KeySeed documentado no site de teste PlayReady. Para este teste, qualquer KeyID pode ser utilizado durante o empacotamento.
Teste uma solicitação de licença do cliente usando a seguinte URL:
{versioned *license service* URL}?UseSimpleNonPersistentLicense=1Exemplo:
https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1Valide se uma licença foi retornada e se a reprodução foi bem-sucedida.
Cenário 2: licenças persistentes
As licenças persistentes são normalmente utilizadas por serviços que permitem a reprodução de conteúdo offline.
Etapas de teste:
Embale o conteúdo usando o KeySeed documentado no site de teste PlayReady. Para este teste, qualquer KeyID pode ser utilizado durante o empacotamento.
Teste uma solicitação de licença do cliente usando a seguinte URL:
{versioned license service URL}?PlayRight=1&FirstPlayExpiration=60
Este parâmetro direcionará o serviço de licença para retornar uma licença que expira 60 segundos após ser reproduzida pela primeira vez. Exemplo:
https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?PlayRight=1&FirstPlayExpiration=60
- Valide se uma licença foi devolvida e se a reprodução foi bem-sucedida. Adicione ou altere os parâmetros de política baseados em tempo, conforme listados no site de teste, para testar outros cenários persistentes.
Cenário 3: licenças encadeadas
Licenças vinculadas à raiz são utilizadas por alguns serviços de subscrição, principalmente para música. Com o cenário rootbound, várias licenças leaf podem ser vinculadas a uma única licença root. Quando a licença root expira, as licenças leaf não são mais utilizáveis, a menos que uma nova raiz seja reemitida.
Etapas de teste:
Empacote o conteúdo usando o KeySeed anotado no site de teste PlayReady e o seguinte KeyID:
Base64: uPeXHrR3K0icGCpYMBGsZw==
Teste o cliente usando a seguinte URL para solicitar uma licença:
{versioned license service URL}sem quaisquer parâmetros Exemplo:https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1Valide se uma licença foi devolvida e se a reprodução foi bem-sucedida. Nesse cenário, uma única resposta do serviço deve conter duas licenças. Uma delas será uma licença de raiz e a outra uma licença de folha. As licenças devem expirar 5 minutos após serem emitidas para o cliente.
Cenário 4: licença vinculada ao domínio
Os domínios não são tão comumente usados pelos serviços. Os domínios PlayReady fornecem uma maneira para o serviço gerenciar o número de dispositivos ativos em uma conta e para os dispositivos dentro da conta compartilharem conteúdo e licenças offline.
Empacote o conteúdo usando o KeySeed anotado no site de teste PlayReady e o seguinte KeyID:
Base64: m1HAERIu8E+uABCZY4TX2g==
O cliente de teste usará a seguinte URL para ingressar no domínio e adquirir uma licença:
{versioned license service url}?AccountID=A/uHOj7F+UaM+Jlny2obFA==
Exemplo:
http://playready.directtaps.nehttp/test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?AccountID=A/uHOj7F+UaM+Jlny2obFA==
Faça com que o cliente de teste gere e envie um desafio JoinDomain e valide se há um certificado de domínio na resposta do serviço.
Peça ao cliente de teste que envie uma solicitação de licença para o serviço usando a mesma URL, incluindo o ID da conta.
Valide se uma licença foi devolvida e se a reprodução foi bem-sucedida. Uma solicitação LeaveDomain também pode ser enviada ao serviço de licença para redefinir o cenário.