FairPlay + Media Services v2 key delivery URL returns HTTP 500

Question

Hello everybody,

We are trying to implement HLS/FairPlay streams. We have the Apple FPS deployment package, followed all instruction to generate PFX certificate.
Content key with content key policy and options were created successfully via REST API, although REST API requires to include Content Key Initialization Vector in the KeyDeliveryConfiguration of the ContentKeyAuthorizationPolicyOption. This is quite strange, because when using UI on portal.azure.com the IV is not shown, and if policy is updated via UI, the initialization vector is lost, so next time key delivery URL is requested, the Media Services API returns error "FairPlay ContentEncryptionIv is not set.".

Nevertheless, when initialization vector is set, the request from Safari browser (if it matters, we use CastLabs PrestoPlay SDK for browsers) to the key delivery URL with SCP payload and correct Authorization header results in HTTP 500 with the following payload

{  
  "Error": {  
    "Message": "",  
    "Code": "ServerException"  
  }  
}  

I tried to troubleshoot the issue by enabling diagnostics for out Media Services account, but unfortunately the generated log also lacks the details. The log message looks as follows (with some sensitive fields removed):

{  
  "time": "2022-11-18T17:37:49.9668506Z",  
  "operationName": "MICROSOFT.MEDIA/MEDIASERVICES/CONTENTKEYS/READ",  
  "category": "KeyDeliveryRequests",  
  "resultType": "Failed",  
  "resultSignature": "InternalServerError",  
  "durationMs": 107,  
  "level": "Error",  
  "location": "germanywestcentral",  
  "properties": {  
    "requestId": "bc4e7a52-b64f-473e-bd8d-a211ccc22cb7",  
    "statusMessage": "Server Error"  
  }  
}  

Would it be possible someone from MS team check the issue?

Answer 1

Couple of concerns - You are using the old legacy v2 REST API which is on the deprecation path. That will only be supported until Feb 29th 2024 and then shuts off completely.
If you are building a new solution, switch to the v3 API.

The v3 API should be used from one of our supported client language SDKS and not via REST directly if you can avoid it.

In v3, there is now only contentKeyPolicies and StreamingPolicies
https://learn.microsoft.com/en-us/azure/media-services/latest/drm-content-key-policy-concep t
https://learn.microsoft.com/en-us/azure/media-services/latest/stream-streaming-policy-concept

https://learn.microsoft.com/en-us/azure/media-services/latest/drm-fairplay-license-overview

There are two ways for protecting a content in v3:

1. Simpler but less flexible approach: use AMS v3 internally generated content key, and AMS built-in StreamingPolicy. This approach does not allow us to use our “pre-specified” content key with IV. So you may not be able to use this approach.
2. More flexible approach: Use a custom StreamingPolicy and StreamingLocator so that you can use our “pre-specified” content key. You might need to use this approach. This does require more code since you need to use the specified content key.

Create IV for each content key.
The content key can be generated in any way you prefer: with or without key seed, if with key seed: either fixed or random. After a content key is created, you specify its IV in the following way:

IV = GetIVFromKIDString(keyId.ToString())

public static byte[] StringToByteArray(string hex)
{
int numberChars = hex.Length;
byte[] bytes = new byte[numberChars / 2];
for (int i = 0; i < numberChars; i += 2)
bytes[i / 2] = Convert.ToByte(hex.Substring(i, 2), 16);
return bytes;
}

//currently IV=KID and is not exposed via API
public static string GetIVFromKIDString(string kid)
{
Guid guid = Guid.Parse(kid);
return Convert.ToBase64String(StringToByteArray(guid.ToString().Replace("-", string.Empty)));
}

Couple more things..

1. The CustomLicenseAcquisitionUrlTemplate API allows you to define the custom LA_URL template instead of actual value. The template variable is {ContentKeyId} for content key ID. For example: http://use2-2.api.microsoftstream.come/videos/video01/ProtectionKey?kid={ContentKeyId}. In this way, you can use a single StreamingPolicy for many assets instead of one for each asset. Therefore you do not need to increase the quota on your account if you have a lot of assets.
2. In general, you should use a single set of ContentKeyPolicy and StreamingPolicy for many assets (a type of assets) for better scalability. So that ContentKeyPolicy and StreamingPolicy are cached and reused across many assets.

UPDATED: Finally, I think this was your solution:
We looked into the specific failure for the request ID you shared and it is because the content IV is malformed. This may be because you are mixing V2 and V3 usage (portal uses V3 API). If you use V2 only please ensure that your IV is a hex string.