Discussion Item: Signaling of DRM information via ServiceAccessInformation

[dsilhavy]

Problem description

TS 26.512 defines a way to signal the MPD URL as part of the ServiceAccessInformation resource. For that reason, the StreamingAccess.mediaPlayerEntry field can be used. To my best knowledge there is no similar mechanism to signal the corresponding DRM license server and DRM custom headers via the ServiceAccessInformation resource. Consequently, this information needs to be embedded in the DASH manifest or the DASH segments or provided via a different interface.

While a Playready DRM allows signaling the license server URL using the pssh box of the segments, this is not possible for Widevine.

For manifest files the DASH-IF Content Protection guidelines define the dashif:Laurl element to specify the license server:

<dashif:Laurl>https://example.com/AcquireLicense</dashif:Laurl>

However, this might not be supported by all media players, for instance I did not find any usage of the dashif:Laurl element in Exoplayer.

In addition, the DASH-IF Content Protection guidelines define the dashif:Authzurl element to retrieve authorization tokens that may be required for requesting a license from a license server:

<dashif:Authzurl>https://example.com/tenants/5341/authorize</dashif:Authzurl>

Again client support might be limited.

Suggested solution description

This is more a suggestion to discuss if it could be useful to signal DRM information as part of the ServiceAccessInformation resource. That would allow applications to pass the required parameters to the media player instead of expecting the media player to derive the required information from the manifest or the segments. In addition, it would allow for changes of the DRM information without touching the manifest or the segments.

[rjb1000]

My opinion on this is that DRM is beyond the scope of 3GPP standardisation. The DRM client does not appear as an actor in the 5GMS architecture described in TS 26.501. DRM licence acquisition doesn't appear in the generic procedural call flow in figure 5.1-1. It appears for the first time in figure 5.2-2 and later in 5.7-2, both of which are depicting the 5G Media Streaming architecture in the context of DASH streaming. The DRM licence acquisition is shown as coming from the Media Player.

My conclusion is that either:

• The DRM licence server is referenced from the MPD, as you describe above, or
• It is the application's responsibility to configure the DRM client privately.

I don't think it would be appropriate to include DRM information in the 5GMS Service Access Information.

[rjb1000]

Action: @haudiobe to discuss with @dsilhavy.

[dsilhavy]

Thanks for the feedback @rjb1000 . I would be interested to hear @haudiobe opinion on that as well.

What I find irritating is that we add the URL to the MPD to the ServiceAccessInformation. However, for playback of DRM protected content this is information is not sufficient in most cases as described above. From a client's perspective, I am unable to play this content without the URL to the DRM server and potential DRM headers. Consequently, I would argue that the ServiceAccessInformation is incomplete as I can't access the service without information provided by the application provider (probably via M8?)

From 26.501 4.2.3: The Service Access Information is the set of parameters and addresses which are needed by the 5GMSd Client to activate and control the reception of a downlink streaming session, and to report service/content consumption and/or QoE metrics

I guess it comes down to the definition of activate and control.

[rjb1000]

@haudiobe: Service Access Information is consumed by the Media Session Handler. What would the Media Session Handler do with the DRM server endpoint address?

[rjb1000]

Reassigned to Rel-19 label reflecting the likelihood that this topic will be studied in the Advanced Media Delivery feasibility study which was agreed at SA4#127 (Sophia Antipolis). The Work Item Description is to be considered for approval at SA#103 (Maastrict).