Wave of errors with code 400 (MPE_ENC_ENCRYPTION_NOT_SPECIFIED_IN_URL) since January 10

Question

Greetings

Was the Azure Media Service spec changed recently? Many users get Error 400 (MPE_ENC_ENCRYPTION_NOT_SPECIFIED_IN_URL) because encryption=cenc param is not included in the request url for each audio segment. Is this a new requirement?

We suspect that because we use CDN to deliver our audio streams and their manifest files, the old manifest files that do not have the newly-required encryption=cenc param are still being delivered.

The streaming endpoint error page was last updated on January 10, exactly when we started seeing the problems, so we think that this issue is caused by a recent change.

I also attached a picture to show what we noticed was added recently in the delivered manifest files (that some users still don't receive) - please see the highlighted part with the encryption param.

How can we fix this? I appreciate your help, thanks!

Answer 1

Apologies for the issue here! This is known issue and PG is working on fix.

Description: AMS has updated Predefined_MultiDrmStreaming to enable Dash on commonEncryptionCbcs.

This allows you to configure HLS CMAF FairPlay streaming with predefined policy. You do not have to write custom streaming policy for this scenario.

One side effect of this change is that the request with legacy Dash streaming format (e.g format=mpd-time-csf) now requires encryption tag ( e.g encryption=cenc) in request URL when the asset is published with Predefined_MultiDrmStreaming. The tag is required to make clear what encryption scheme client is requesting.

Note that the updated Predefined_MultiDrmStreaming enables both cenc and cbcs on Dash. The request without encryption tag may introduce ambiguity when policy defines multiple encryption scheme on a protocol, which causes Streaming Endpoint to return 400 (MPE_ENC_ENCRYPTION_NOT_SPECIFIED_IN_URL) error.

 Suggested temporary workaround:

To mitigate this issue, you can apply one of mitigation.

• You may specify encryption scheme into URL. Ex) https://myaccount-uswc.streaming.media.azure.net/b26a0ac2-15f3-4ad1-a546-cb28f29a13ad/asset.ism/manifest(format=mpd-time-csf,encryption=cenc)
• Use AMP (2.3.11.1 or later) https://amp.azure.net/libs/amp/2.3.11.1/azuremediaplayer.min.js if using AMP

Please let us know if further query or issue remains.

Answer 2

Thank you for your response.

We are already specifying the encryption scheme in the URL for the Manifest file, and we have been since the beginning.

The problem is that, as you can see in the metrics graph from my initial post (status code 400), the CDN still returned cached manifest files that did not contain the encryption=cenc parameter in the SegmentTemplate block in the manifest XML. Our team purged the CDN caches but as you can see, the problem still persisted for a few days.

Also, our Android app allows users to download audiobooks - we implemented this feature by following this official guide, which also recommends using ExoPlayer on Android: https://learn.microsoft.com/en-us/azure/media-services/latest/drm-offline-streaming-how-to?tabs=widevine

During the days when this issue happened, after January 10, users who attempted to download audiobooks, only got the downloads partially completed, as the downloads would fail mid way.

We think this is because some audio segments were still cached in the CDN - hence the download would work only up to a point, and then the downloads would fail when segments had to be requested from the origin server, as the new segments required the encryption=cenc param, which was missing because the manifest file delivered to the device, when the download was initially started by the user, was still the old one, without this param. ExoPlayer internally builds the URL when requesting audio segments based on the values from SegmentTemplate

So we had a situation where many users were stuck with partial downloads. Attempting to resume downloads after all CDN caches were purged would still fail, because ExoPlayer still had the old Manifest file stored in its internal local database, and that's the template that it would continue using to download the remaining audio segments.

This is a logic that is implemented inside the ExoPlayer library.

The workaround was to instruct the users to remove any partially downloaded audiobooks, and retry, so customer support was a bit overwhelmed by this.

Considering the situation with partial downloads mentioned above, I would like to know what we can do to avoid another multi-day production incident when and if the team working on Azure Media Services changes the required URL structure of audio segments again.

Thanks for your assistance