Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Samenvatting
Microsoft® PlayReady® 3.0 biedt belangrijke nieuwe functies die OEM's op hun apparaten willen integreren. Dit brengt enkele compatibiliteitsproblemen met services die meer dan vijf jaar geleden zijn ontworpen. In dit document worden deze besproken en worden richtlijnen geboden voor zowel services als OEM's in het upgradepad naar PlayReady 3.0
Inhoudsopgave
PlayReady-compatibiliteitsmatrix
Aanbevelingen voor PlayReady-services
Aanbevelingen voor Fabrikanten van PlayReady-apparaten
Opmerkingen bij migraties voor services
Een PlayReady-service migreren naar Server SDK 3.0
Ondersteuning voor verschillende Server SDK-versies voor een service
Clients ondersteunen op basis van PK 3.0 met verouderde licentieservices
Ondersteuning voor PlayReady 3.0-functies voor services
Ondersteuning voor zowel SL2000 als SL3000 in services
PlayReady-clients testen met versies van de PlayReady Server SDK
Scenario 1: niet-permanente licenties
Scenario 2: doorlopende licenties
Scenario 3: gekoppelde licenties
Scenario 4: domeingebonden licentie
Overzicht
PlayReady-licentieservices behouden compatibiliteit met eerdere versies voor oudere PlayReady-apparaten. Een nieuwe licentieservice die is ontwikkeld met de PlayReady Server SDK 3.0 kan bijvoorbeeld licenties leveren aan een verouderd apparaat dat is ontwikkeld met behulp van de PlayReady Porting Kit(PK) 1.2 vanaf de eerste release (2008).
Er zijn echter enkele nuances in compatibiliteit wanneer services en apparaten overstappen op de PlayReady 3-releases. PlayReady-clients die zijn ontwikkeld met de 3.0 Porting Kit, kunnen geen licenties verkrijgen van een licentieservice die is gebouwd vóór de 2011-release van de Server SDK 2.0. Services met eerdere versies van de Server SDK moeten upgraden om compatibel te zijn met PlayReady 3.0.
PlayReady-compatibiliteitsmatrix
De meeste versies van PlayReady op de client kunnen werken met de verschillende versies van de PlayReady Server SDK. Er zijn enkele subtiliteiten zoals hieronder vermeld, evenals een verandering met PlayReady-clients die zijn ontwikkeld op de 3.0 Porting Kit.
| Server SDK 1.x | Server SDK 2.0 (2011) | Server SDK 2.1 (2013) | Server SDK 2.9 (2014) | Server SDK 3.0 (2015) | |
|---|---|---|---|---|---|
| PK 1.x (2008) | * | * | * | * | |
| PK 2.x (2011) | |||||
| PK 3.0 (2015) | ** | *** | *** | *** |
| Server-SDK v1.5.2 | Server SDK v2.1 en Server SDK v2.9 | Server SDK v3.0 | Server SDK v4.0 | |
|---|---|---|---|---|
| PK v4.x | Nee. | Ja | Ja | Ja |
| PK v3.x | Nee. | Ja | Ja | Ja |
| PK v2.5 en v2.11 | Ja | Ja | Ja | Ja |
| Onverenigbaar | Compatibel |
|---|---|
* Sommige PK 1.2-clients bieden geen ondersteuning voor intrekking die vereist is in Server SDK 2.x+. Dit is niet gebruikelijk.
** PK3.0-clients kunnen geen Server SDK gebruiken vóór versie 2.0 om een licentie voor het afspelen van media op te halen.
PK3.0-clients kunnen licentieservers gebruiken met behulp van een 2.X SDK, maar kunnen alleen een licentie verkrijgen met een SL2000-beveiligingsniveau. Daarnaast zijn nieuwe functies zoals ondersteuning voor versie 4.2-headers (meerdere sleutels) en beleidsregels zoals Secure Stop en MaxResDecode niet beschikbaar bij het maken van een licentie. Er zijn problemen met gekoppelde licenties (root/leaf) op sommige PK3.0-clients met Server SDK 2.0. Services moeten clients testen om compatibiliteit te valideren. Aan het einde van dit document vindt u een reeks scenario's die u kunnen helpen bij het testen.
Aanbevelingen voor PlayReady-services
Zorg ervoor dat een service wordt bijgewerkt naar de nieuwste versie van de PlayReady SDK. Dit biedt de beste compatibiliteit op nieuwe en verouderde apparaten. De recente versies van de Server SDK hebben ook aanzienlijke prestatie- en stabiliteitsverbeteringen toegevoegd. Houd er rekening mee dat er geen extra licentie- of licentiekosten nodig zijn om een upgrade uit te voeren naar de nieuwste PlayReady Server 3.0.
Naarmate nieuwe apparaten de migratie van PlayReady naar de hardware (SoC) voortzetten, worden er steeds meer apparaten gerapporteerd aan een service als PlayReady 3.0 en SL3000. Bijvoorbeeld, alle Windows 10-apparaten rapporteren nu als PlayReady 3.0-apparaten. Services worden aangemoedigd om een upgrade uit te voeren naar de nieuwste versie van de server-SDK om compatibiliteit te behouden en enkele van de nieuwe functies te gebruiken.
Gebruik deze handleiding voor het afhandelen van edge-zaken, zoals het onderhouden van verouderde licentieservices as-is tijdens het ondersteunen van nieuwe apparaten.
Licentienemers kunnen contact opnemen askdrm@microsoft.com om toegang te krijgen tot onze feedbacksite om migratievragen in te dienen
Aanbevelingen voor Fabrikanten van PlayReady-apparaten
Het wordt ten zeerste aanbevolen dat OEM's hun apparaten upgraden naar PK3.0 die in april 2015 zijn uitgebracht. Dit is de enige versie waarmee apparaten gebruikmaken van de nieuwste functies die door de belangrijkste mediaservices worden geïmplementeerd.
| Pros | Nadelen – Aandachtspunten |
|---|---|
| SL3000 kan ondersteund worden, niet compatibel met Server SDK 1.X. | |
| Kan de nieuwste functies implementeren, zoals SecureStop, MaxResDecode, enzovoort. | |
| Betere codebasis | |
| Zorg ervoor dat nieuwe licentiebeleidsregels, zoals aangevraagd door eigenaren van inhoud, kunnen worden afgedwongen |
OEM-upgradeplan
Neem contact op met uw services en zorg ervoor dat ze allemaal een Server SDK 2.0+ versie migreren of toevoegen o Hun Server SDK-versie controleren
Herhaal de overwegingen met betrekking tot de dienst: geen aanvullende licentievereisten van Microsoft en geen extra kosten.
Als ze een op Server SDK v2.0+ gebaseerde licentieservice uitvoeren, zijn ze waarschijnlijk compatibel. De service-URL's en scenario's in de volgende sectie kunnen helpen bij het testen van compatibiliteit. o Als ze een Server SDK v1 uitvoeren. Op X gebaseerde licentieserver kunnen ze hun licentieserver migreren of een nieuwere licentieserver toevoegen voor de nieuwe clients, op basis van Server SDK 2.0+ (meest recente versie wordt aanbevolen).
Pk3.0 downloaden van Microsoft
Vraag ondersteuning van Microsoft-partners of rechtstreeks vanuit Microsoft op https://connect.microsoft.com/playready.
Implementeer PK3.0 en laat uw product los.
Opmerkingen bij migraties voor diensten
Voor optimale apparaatcompatibiliteit zorgt u ervoor dat de licentieserver de nieuwste versie van de server uitvoert
SDK. De meest recente Server SDK kan licenties leveren aan alle PlayReady-clients, ongeacht de gebruikte Porting Kit-versie. Als een client die is ontwikkeld met de 3.0 Porting Kit een licentie probeert te verkrijgen van een licentieservice met behulp van PlayReady SDK 1.x, retourneert de licentieservice een algemene SOAP-fout. De server meldt een uitzondering op het Windows-logboek dat de uitdaging ontbreekt in de clientcertificaatketen.
Een PlayReady-service migreren naar Server SDK 3.0
Een service-upgrade omvat meestal geen codewijzigingen, maar alleen een hercompilatie en implementatie van de bijgewerkte bibliotheken. In sommige gevallen kunnen er kleine codewijzigingen zijn vanwege sommige afgeschafte API's. De hercompilatie en implementatie van de licentiehandlerbibliotheek moeten transparant zijn voor apparaten die toegang hebben tot de service.
Bij het compileren en implementeren van een bijgewerkte licentie-handler moet rekening worden gehouden met het volgende
Het project moet verwijzingen naar de oude PlayReady-bibliotheken verwijderen en verwijzen naar de nieuwe voordat u opnieuw gaat compileren.
Voor de nieuwere server-SDK's is .NET 4.0 of hoger vereist. Wanneer u de licentieservicehandler bijwerkt vanaf een vroege versie zoals 1.52, moet het doelframework worden bijgewerkt in de projecteigenschappen naar die van 4.0 of hoger.
Als de verouderde handler verwijst naar andere bibliotheken die zijn gericht op een .NET-versie kleiner dan 4.0, kunnen er extra migratiestappen zijn. Een .NET-bibliotheek kan echter verwijzen naar een mindere versie zonder problemen in het algemeen. Het is de moeite waard om de mogelijkheid te onderzoeken om bibliotheken waarnaar wordt verwezen, opnieuw te compileren naar de versie van de handler of om bibliotheekupdates voor onderdelen van derden te verkrijgen.
Alleen naar Microsoft.Media.Drm.RMCore moet binnen het project worden verwezen. Bij het implementeren van een oplossing moeten de andere DLL's worden geïmplementeerd in de bin-map van de website. Er hoeft niet naar ze binnen het project te worden verwezen, net als bij eerdere SDK's.
Een minimale .NET CLR-versie van 4.0 is vereist voor de groep toepassingen die wordt gebruikt door de licentieservice. Als de licentieservice 2.0 of eerder werd uitgevoerd, is het waarschijnlijk dat deze wordt uitgevoerd in een .NET CLR-versie lager dan 4.0.
De nieuwste PlayReady Server SDK wordt alleen ondersteund onder Windows Server 2012 en hoger. Windows Server 2008 R2 staat er echter om bekend geen problemen te hebben met de Server SDK.
Ondersteuning voor verschillende Server SDK-versies voor een service
Het is raadzaam om kort na de release naar de nieuwste versie van de SDK te migreren. In sommige gevallen wil een service echter mogelijk meerdere versies van de server-SDK uitvoeren. Dit kan worden veroorzaakt door het onderhouden van verouderde en archiefservices en eindpunten die niet eenvoudig worden bijgewerkt. In dit geval kan een service nieuwe clients naar een bijgewerkte licentieservice verwijzen terwijl de verouderde service ongewijzigd blijft. Een service kan bijvoorbeeld een aantal verouderde apparaten hebben in hun ecosysteem waarop een client wordt uitgevoerd die is gebouwd met PlayReady PK 1.2. Hun nieuwe apparaten worden ontwikkeld met behulp van de PlayReady PK 3.0. De nieuwe client moet verwijzen naar een licentieservice die is gebouwd met Server SDK 2.0 of hoger. Als zowel de verouderde als de nieuwe apparaten dezelfde toepassing gebruiken (zoals een op HTML gebaseerd app-platform), moet logica worden toegevoegd aan de toepassing om de versie van de client te detecteren. De clienttoepassing kan vervolgens licentieaanvragen doorsturen naar een nieuwere licentieservice.
De aanbevolen migratie is om de licentieservice bij te werken naar de nieuwste versie van de Server SDK. Dit kan compatibiliteit bieden voor alle apparaten voor veel services. Een service moet testen op verschillende clients om compatibiliteit te valideren.
Als een service geen wijzigingen wil aanbrengen in een verouderde client- en serviceconfiguratie, is het raadzaam om een tweede licentieservice te hosten die is bijgewerkt naar de nieuwste versie van de SDK en wordt gebruikt door moderne clients.
Als een service dezelfde applicatie gebruikt voor nieuwe apparaten in verouderde systemen, kan er een proxy worden geconfigureerd zodat oudere apparaten de verouderde service blijven gebruiken.
Een service kan ook verouderde clients doorsturen naar een verouderde service en nieuwe clients naar een bijgewerkte service. Dit kan in een proxy worden gedaan door de licentievraag te inspecteren. De PK-versie wordt vermeld in het <CLIENTVERSION> element.
Het element bevindt zich in de SOAP-uitdaging onder het volgende element:
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
Clients ondersteunen op basis van PK 3.0 met legacy-licentieservices
Een clientapparaat dat is ontwikkeld met de PlayReady Porting Kit 3.0 werkt waarschijnlijk met bestaande services die zijn ontwikkeld met de Server SDK 2.0 en hoger. Zoals hierboven vermeld, moet een service de PK 3.0-clients testen om compatibiliteit te valideren.
Als het apparaat een SL3000-certificaat heeft, wordt het beveiligingsniveau weergegeven via het clientcertificaat in de licentiehandler als 3000. Dit kan mogelijk problemen veroorzaken met sommige licentie-handlers als ze op zoek zijn naar een specifieke waarde op beveiligingsniveau om onderscheid te maken tussen productie- en testapparaten.
Differentiëren tussen beveiligingsniveaus is gebruikelijk voor services die beperkte toegang tot inhoud bieden voor testapparaten om afspeellicenties van een liveservice te valideren. Alleen apparaten die zijn gerapporteerd als Beveiligingsniveau 2000, hebben afspeellicenties voor commerciële inhoud. De service genereert een servicespecifieke uitzondering die zou leiden tot een SOAP-fout op de client.
In het onderstaande voorbeeld wordt het beveiligingsniveau gecontroleerd in het clientcertificaat om ervoor te zorgen dat het een productieapparaat is. Omdat het is vastgelegd in 2000, worden apparaten met het beveiligingsniveau van 3000 niet gezien als productieapparaten.
In dit voorbeeld wordt de controle op beveiligingsniveau bijgewerkt naar of deze groter is dan of gelijk is aan 2000. Dit zorgt voor compatibiliteit met SL3000-apparaten.
Ondersteuning voor PlayReady 3.0-functies voor services
Naast het nieuwe hardware-DRM-beveiligingsniveau heeft de PlayReady 3-release ook diverse nieuwe functies geïntroduceerd. Om te kunnen profiteren van deze nieuwe functies, moet de service eerst bepalen of de client geschikt is voor PlayReady 3-functies. De clientcertificaatklasse ondersteunt nu een
Methode GetSupportedFeatures die een verzameling functies retourneert om te helpen bij de logica van het definiëren van beleidsregels binnen de handler. Als de client is ontwikkeld met de 3.0 Porting Kit, zal hij de SupportedFeature.PlayReady3Features in de verzameling hebben. Er zijn extra nuttige functies in de verzameling, zoals of de client een beveiligde klok of anti-terugdraaiklok gebruikt.
Hier volgt een voorbeeld van hoe u kunt detecteren of het apparaat een PlayReady 3-client is.
Zodra de handler heeft gedetecteerd, kan er beleid worden toegevoegd, zoals Secure Stop, realtime licentieverloop en MaxResDecode.
Ondersteuning voor zowel SL2000 als SL3000 bij dienstverlening
PlayReady heeft een nieuw beveiligingsniveau, SL3000, geïntroduceerd dat wordt gerapporteerd door apparaten die aan de vereisten hebben voldaan.
PlayReady-hardwarebeveiligingsniveau voor uitvoering in een vertrouwde uitvoeringsomgeving, zoals gedefinieerd in de regels voor naleving en robuustheid. Het komt vaak voor dat diensten sommige klantenrapporten indelen als SL2000 en andere als SL3000. In Windows kunnen oudere apparaten die zijn bijgewerkt naar Windows 10 bijvoorbeeld rapporteren als SL2000. Nieuwe Windows 10-apparaten rapporteren als SL3000 waar de DRM is opgenomen in de nieuwere chips.
Hier is een voorbeeld van een service die verschillende beleidsregels biedt op basis van het gerapporteerde beveiligingsniveau van de uitdaging van de cliënt.
Een service bepaalt hoe beleid moet verschillen tussen op software gebaseerde DRM-clients en hardwaregebaseerde DRM-clients. Dit beleid kan worden aangestuurd door studiovereisten. Een studio kan bijvoorbeeld in de toekomst vereisen dat Ultra-HD of 4K-inhoud wordt beperkt tot apparaten die ondersteuning bieden voor PlayReady DRM op basis van hardware.
Met PlayReady 3-beleid voor oplossingen kan op een aantal verschillende manieren worden uitgevoerd. Een manier is om het MaxResDecode-beleid van SL2000-licenties in te stellen op de toegestane limieten van de inhoudseigenaar. De SL3000-apparaten krijgen deze beleidsbeperking niet. Een andere optie die van toepassing is op adaptieve streamingtechnologieën is het gebruik van een andere KeyID bij het beveiligen van de verschillende resoluties. Bij het detecteren van het beveiligingsniveau kan een service vervolgens alleen licenties bieden voor de resoluties die zijn toegestaan voor een softwaregebaseerd systeem. Een client die een beveiligingsniveau van SL3000 rapporteert, krijgt afspeellicenties voor alle resoluties. PlayReady heeft een nieuwe DRM-header geïntroduceerd ter ondersteuning van dit laatste scenario door meerdere KeyID's in het schema in te schakelen.
PlayReady-clients testen met versies van de PlayReady Server SDK
De playReady-testwebsite bevat een set licentieservices die gebruikmaken van de huidige en verouderde versies van de Server-SDK. Deze licentieservices kunnen worden gebruikt om te helpen bij het testen van clientcompatibiliteit. Wanneer u bijvoorbeeld een client bijwerkt naar PK 3.0, kan de client worden getest op basis van eerdere serviceversies om de compatibiliteit te controleren.
De versies van de diensten worden vermeld in de onderstaande tabel.
Deze versieservices kunnen gebruikmaken van de parameters die worden vermeld in de playReady Test Server-servicedocumentatie voor het testen van specifieke beleidsregels.
[OPMERKING!] Niet alle beleidsparameters werken met elk van de serviceversies. MaxResDecode is bijvoorbeeld een nieuw beleid en werkt alleen met services die zijn ontwikkeld met de Server SDK 3.0 of hoger.
Om u te helpen bij het testen van mogelijkheden, kunnen de volgende tests worden gebruikt met de verschillende versies van licentieservices om vier unieke licentiescenario's te behandelen.
Scenario 1: niet-permanente licenties
Niet-permanente licenties zijn het meest voorkomende licentiescenario dat wordt gebruikt door streamingservices.
Teststappen:
Pak de inhoud in met de KeySeed die is genoteerd op de PlayReady-testsite. Voor deze test kan elke KeyID worden gebruikt bij het verpakken.
Test een licentieaanvraag van de client met behulp van de volgende URL:
{versioned *license service* URL}?UseSimpleNonPersistentLicense=1Voorbeeld:
https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1Controleer of er een licentie wordt geretourneerd en of het afspelen succesvol is.
Scenario 2: permanente licenties
Permanente licenties worden meestal gebruikt door services waarmee de inhoud voor afspelen offline kan worden ingeschakeld.
Teststappen:
Pak de inhoud in met de KeySeed die is genoteerd op de PlayReady-testsite. Voor deze test kan elke KeyID worden gebruikt bij het verpakken.
Test een licentieaanvraag van de client met behulp van de volgende URL:
{versioned license service URL}?PlayRight=1&FirstPlayExpiration=60
Met deze parameter wordt de licentiedienst geïnstrueerd om een licentie te retourneren die 60 seconden na de eerste keer dat het wordt afgespeeld verloopt. Voorbeeld:
https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?PlayRight=1&FirstPlayExpiration=60
- Controleer of er een licentie wordt geretourneerd en of het afspelen is geslaagd. Voeg de op tijd gebaseerde beleidsparameters toe of wijzig deze zoals vermeld op de testsite om andere permanente scenario's te testen.
Scenario 3: gekoppelde licenties
Basislicenties worden meestal gebruikt door sommige abonnementsservices voor muziek. Met het rootbound-scenario kunnen verschillende leaf-licenties worden gebonden aan één basislicentie. Wanneer de rootlicentie verloopt, kunnen de dochterlicenties niet meer worden gebruikt, tenzij een nieuwe rootlicentie opnieuw wordt uitgegeven.
Teststappen:
Verpakt de inhoud met de KeySeed die is genoteerd op de PlayReady-testsite en de volgende KeyID:
Base64: uPeXHrR3K0icGCpYMBGsZw==
Test de client met behulp van de volgende URL om een licentie aan te vragen:
{versioned license service URL}zonder parameters Voorbeeld:https://test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?UseSimpleNonPersistentLicense=1Controleer of er een licentie wordt geretourneerd en of het afspelen is geslaagd. In dit scenario moet één reactie van de service twee licenties bevatten. Een van hen zal een basislicentie zijn en de andere een bladlicentie. De licenties moeten 5 minuten verlopen nadat ze aan de client zijn uitgegeven.
Scenario 4: domeingebonden licentie
Domein wordt niet zo vaak gebruikt door services. PlayReady-domeinen bieden beide een manier voor service om het aantal actieve apparaten in een account te beheren en voor apparaten binnen het account om inhoud en licenties offline te delen.
Verpakt de inhoud met de KeySeed die is genoteerd op de PlayReady-testsite en de volgende KeyID:
Base64: m1HAERIu8E+uABCZY4TX2g==
De testclient gebruikt de volgende URL voor het toevoegen van het domein en het verkrijgen van een licentie:
{versioned license service url}?AccountID=A/uHOj7F+UaM+Jlny2obFA==
Voorbeeld:
http://playready.directtaps.nehttp/test.playready.microsoft.com/directtaps/svc/pr30/rightsmanager.asmx?AccountID=A/uHOj7F+UaM+Jlny2obFA==
Laat de testclient een JoinDomain-uitdaging genereren en verzenden en valideren dat er een domeincertificaat in het serviceantwoord staat.
Laat de testclient een licentieaanvraag verzenden naar de service met behulp van dezelfde URL, inclusief de accountID.
Controleer of er een licentie wordt geretourneerd en of het afspelen is geslaagd. Een LeaveDomain-aanvraag kan ook worden verzonden naar de licentieservice om het scenario opnieuw in te stellen.