Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Raccomandazioni per i servizi PlayReady
Microsoft consiglia i criteri di migrazione seguenti:
Assicurarsi che un servizio venga aggiornato alla versione più recente di PlayReady SDK. In questo modo sarà possibile garantire la migliore compatibilità tra i dispositivi nuovi e legacy. Anche le versioni recenti di Server SDK hanno aggiunto miglioramenti significativi delle prestazioni e della stabilità. Si noti che non sono necessarie licenze aggiuntive o tariffe di licenza per eseguire l'aggiornamento al server PlayReady 4.0 più recente.
Man mano che i nuovi dispositivi continuano la migrazione di PlayReady all'hardware (SoC), ci saranno sempre più dispositivi che segnalano a un servizio come PlayReady 3.0 e versioni successive e SL3000. Ad esempio, tutti i dispositivi Windows 10 ora segnalano come dispositivi PlayReady 3.0 e versioni successive. I servizi sono invitati ad eseguire l'aggiornamento alla versione più recente dell'SDK del server per mantenere la compatibilità e sfruttare alcune delle nuove funzionalità.
Usare le informazioni fornite in questo argomento come guida per gestire i casi limite, ad esempio la manutenzione dei servizi di licenza legacy as-is mentre si supportano i nuovi dispositivi.
I licenziatari possono contattare askdrm@microsoft.com per ottenere l'accesso al sito di feedback per inviare domande sulla migrazione.
Raccomandazioni per i produttori di dispositivi PlayReady
È consigliabile che gli OEM aggiornino i propri dispositivi a PK4.0 rilasciati nell'ottobre 2017, ovvero l'unica versione che consente ai dispositivi di sfruttare le funzionalità più recenti implementate dai principali servizi multimediali.
| Vantaggi | Contro - Punti di attenzione |
|---|---|
| Può supportare SL3000 | Non compatibile con Server SDK 1.X |
| Può implementare funzionalità più recenti, ad esempio SecureStop, SecureDelete, MaxResDecode e così via | |
| Codebase migliore | |
| Assicurarsi che i nuovi criteri di licenza richiesti dai proprietari del contenuto possano essere applicati |
Piano di aggiornamento OEM
Contatta i tuoi servizi e assicurati che tutti eseguano la migrazione o aggiungano una versione di Server SDK 2.0+.
Verificare la versione dell'SDK del server.
Considerazioni ripetute per il servizio: nessun requisito aggiuntivo per le licenze di Microsoft e nessun costo aggiuntivo .
Se eseguono un servizio licenze basato su SERVER SDK v2.0+, probabilmente saranno compatibili. Gli URL e gli scenari del servizio nella sezione successiva possono essere utili per i test di compatibilità.
Se eseguono un server licenze basato su SDK v1.X, possono migrare il loro server licenze o aggiungere un server licenze più recente per i nuovi clienti, basato su server SDK 2.0+ (è consigliata la versione più recente).
Scarica il PK 4.0 da Microsoft.
Ottenere supporto dai partner Microsoft o direttamente da Microsoft inviando un messaggio di posta elettronica a AskDRM@microsoft.com.
Implementare PK 4.0 e rilasciare il prodotto.
Note sulle migrazioni per i servizi
Per garantire una compatibilità ottimale dei dispositivi, assicurarsi che il server licenze esegua la versione più recente di Server SDK. L'SDK server più recente sarà in grado di distribuire licenze a tutti i client PlayReady indipendentemente dalla versione di Porting Kit usata. Se un client sviluppato con device porting kit 3.0 o versione successiva tenta di ottenere una licenza da un servizio licenze tramite PlayReady SDK 1.x, il servizio licenze restituirà un errore SOAP specifico del servizio generico. Il server registrerà un'eccezione nel log di Windows, segnalando che alla sfida mancava la catena di certificati cliente.
Migrazione di un servizio PlayReady a Server SDK 4.0
Un aggiornamento del servizio in genere non comporta modifiche al codice, ma solo una ricompilazione e una distribuzione delle librerie aggiornate. In alcuni casi, potrebbero verificarsi modifiche minime del codice a causa di alcune API deprecate. La ricompilazione e la distribuzione della libreria del gestore licenze devono essere trasparenti per i dispositivi che accedono al servizio.
La compilazione e la distribuzione di un gestore licenze aggiornato dovranno tenere conto degli elementi seguenti:
Il progetto dovrà rimuovere i riferimenti alle librerie PlayReady precedenti e fare riferimento a quelli nuovi prima di ricompilare.
Gli SDK server più recenti richiedono .NET 4.0 o versione successiva. Quando si aggiorna il gestore del servizio licenze da una versione precedente, ad esempio 1.52, il framework di destinazione dovrà essere aggiornato nelle proprietà del progetto a quello della versione 4.0 o successiva.
Se il gestore legacy fa riferimento ad altre librerie destinate a una versione .NET inferiore alla 4.0, potrebbero essere necessari passaggi di migrazione aggiuntivi. Tuttavia, una libreria .NET può fare riferimento a una versione minore senza problemi in generale. Sarebbe opportuno esaminare l'opportunità di ricompilare le librerie a cui si fa riferimento alla versione del gestore o acquisire gli aggiornamenti della libreria per i componenti di terze parti.
È necessario fare riferimento solo a Microsoft.Media.Drm.RMCore all'interno del progetto. Quando si distribuisce una soluzione, è necessario distribuire le altre DLL nella directory bin del sito Web. Non è necessario fare riferimento all'interno del progetto, come nel caso degli SDK precedenti.
Per il pool di applicazioni utilizzato dal servizio licenze è necessaria una versione CLR minima di .NET 4.0. Se il servizio licenze è in esecuzione 2.0 o versioni precedenti, è probabile che sia in esecuzione in una versione CLR .NET precedente alla 4.0.
La versione più recente di PlayReady Server SDK è supportata solo in Windows Server 2012 e versioni successive. Windows Server 2008 R2, tuttavia, non è noto che si verifichino problemi con Server SDK.
Supporto di diverse versioni di Server SDK per un servizio
Microsoft consiglia di eseguire la migrazione alla versione più recente dell'SDK subito dopo il rilascio. In alcuni casi, tuttavia, un servizio può voler eseguire più versioni di Server SDK. Ciò può essere dovuto alla gestione di servizi e endpoint legacy e di archiviazione che non sono facilmente aggiornati. In questo caso un servizio può indirizzare nuovi clienti a un servizio di licenze aggiornato lasciando invariato il servizio legacy. Ad esempio, un servizio può avere diversi dispositivi legacy all'interno del proprio ecosistema che eseguono un client compilato con PlayReady PK 1.2. I nuovi dispositivi vengono sviluppati usando PlayReady PK 4.0. Il nuovo client dovrebbe puntare a un servizio di licenze costruito con Server SDK 2.0 o versione successiva. Se entrambi i dispositivi legacy e nuovi usano la stessa applicazione (ad esempio una piattaforma di app basata su HTML), la logica dovrà essere aggiunta all'applicazione per rilevare la versione del client. L'applicazione client può quindi indirizzare le richieste di licenza a un servizio licenze più recente.
La migrazione consigliata consiste nell'aggiornare il servizio licenze alla versione più recente di Server SDK. In questo modo è possibile garantire la compatibilità tra tutti i dispositivi per molti servizi. Un servizio dovrà testare i client per convalidare la compatibilità.
Se un servizio non vuole apportare modifiche a una configurazione del client e del servizio legacy, è consigliabile ospitare un secondo servizio licenze aggiornato alla versione più recente dell'SDK e utilizzato dai client moderni.
Se un servizio usa una singola applicazione client sia su dispositivi legacy (PlayReady 1.X) che su dispositivi più recenti (PlayReady 3.0 o versione successiva), è necessario usare due server licenze PlayReady (PlayReady 1.X e PlayReady 3.0 o versione successiva) per fornire licenze a tutti questi dispositivi. L'applicazione può includere la logica per instradare le richieste al server licenze appropriato in base alla versione del client PlayReady sottostante oppure il servizio può usare un proxy di servizio che instrada le richieste provenienti da tutti questi dispositivi in un singolo URL al server licenze appropriato.
Questa operazione può essere eseguita in un proxy esaminando la richiesta di licenza. La versione PK verrà annotata nell'elemento <CLIENTVERSION> .
L'elemento si trova all'interno della richiesta SOAP nell'elemento seguente:
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
Supporto ai clienti basati su PK 3.0 o versioni successive con servizi di licenze legacy
Un dispositivo client sviluppato con PlayReady Device Porting Kit 3.0 o versione successiva funzionerà probabilmente con i servizi esistenti sviluppati con Server SDK 2.0 o versione successiva. Come indicato in precedenza, un servizio deve testare i client PK 3.0 o versione successiva per convalidare la compatibilità.
Se il dispositivo ha un certificato SL3000, SecurityLevel esposto tramite il certificato client nel gestore licenze verrà indicato come 3000. Ciò può causare problemi con alcuni gestori di licenze se cercano un valore SecurityLevel specifico per distinguere tra dispositivi di produzione e test.
La differenziazione tra i SecurityLevels è comune per i servizi che forniscono accesso limitato ai contenuti per i dispositivi di test, al fine di convalidare le licenze di riproduzione attraverso un servizio live. Solo i dispositivi segnalati come SecurityLevel 2000 avrebbero concesso licenze di riproduzione per contenuti commerciali. Il servizio genera un'eccezione specifica del servizio che genera un errore SOAP nel client.
Nell'esempio seguente, il SecurityLevel viene verificato nel certificato client per garantire che si tratti di un dispositivo di produzione. Dal momento che è stato fissato a 2000, i dispositivi con livello di sicurezza 3000 non saranno considerati dispositivi di produzione.
In questo esempio seguente viene aggiornato il controllo del livello di sicurezza per verificare se è maggiore o uguale a 2000. In questo modo si garantisce la compatibilità con i dispositivi SL3000.
Supporto delle funzionalità PlayReady 3.X e successive per i servizi
Oltre al nuovo livello di sicurezza DRM hardware, PlayReady 3.0 e versioni successive hanno introdotto anche una varietà di nuove funzionalità. Per sfruttare queste nuove funzionalità, il servizio dovrà prima determinare se il client è in grado di eseguire playReady 3.0 e versioni successive. La classe di certificato client supporta ora un metodo GetSupportedFeatures che restituirà una raccolta di funzionalità utili per la logica di definizione dei criteri all'interno del gestore. Se il client è stato sviluppato con il Device Porting Kit 3.0, avrà la proprietà SupportedFeature.PlayReady3Features nella collezione. Nella raccolta sono disponibili funzionalità utili aggiuntive, ad esempio se il client usa un orologio protetto o un orologio anti-rollback.
Ecco un esempio di come rilevare se il dispositivo è un client PlayReady 3.0.
Dopo aver rilevato il gestore, è possibile, ad esempio, aggiungere criteri come l'arresto sicuro, la scadenza delle licenze in tempo reale e "MaxResDecode".
Supporto di SL2000 e SL3000 nei servizi
PlayReady ha introdotto un nuovo livello di sicurezza SL3000 segnalato dai dispositivi che hanno soddisfatto il livello di sicurezza hardware PlayReady per l'esecuzione all'interno di un ambiente di esecuzione attendibile come definito nelle regole di conformità e affidabilità. Sarà comune per i servizi avere alcuni client che segnalano come SL2000 e altri come SL3000. Ad esempio, in Windows, i dispositivi meno recenti aggiornati a Windows 10 possono segnalare sl2000. I nuovi dispositivi Windows 10 segnalano come SL3000 in cui la tecnologia DRM è stata incorporata nei chip più recenti.
Di seguito è riportato un esempio di servizio che fornisce criteri diversi in base al livello di sicurezza segnalato rispetto alla sfida del client:
Un servizio determinerà in che modo i criteri devono differire tra i client DRM basati su software e i client DRM basati su hardware. Questi criteri possono essere guidati dai requisiti dello studio. Ad esempio, uno studio potrebbe richiedere in futuro che il contenuto Ultra-HD o 4K sia limitato ai dispositivi che supportano la tecnologia DRM PlayReady basata su hardware.
Le politiche PlayReady 3.0 e superiori riguardanti le risoluzioni possono essere realizzate in un paio di modi diversi. Un modo consiste nell'impostare il criterio MaxResDecode delle licenze SL2000 sui limiti consentiti forniti dal proprietario del contenuto. I dispositivi SL3000 non otterrebbero questa restrizione dei criteri. Un'altra opzione applicabile alle tecnologie di streaming adattive consiste nell'usare un KeyID diverso quando si proteggono le varie risoluzioni. Quando si rileva il livello di sicurezza, un servizio può quindi fornire solo licenze per le risoluzioni consentite per un client basato su software. Un client che segnala un livello di sicurezza di SL3000 otterrebbe licenze di riproduzione per tutte le risoluzioni. PlayReady ha introdotto una nuova intestazione DRM (v4.2.0.0 e versioni successive) per supportare questo ultimo scenario abilitando più KeyID nello schema.
Vedere anche
Versioni del prodotto PlayReady
Come testare i client PlayReady con versioni di PlayReady Server SDK