End-to-end licence workflows
When a client (a set-top box or an open device) requires a licence so that it can play a piece of content, it initiates a sequence of requests and responses that involves various head-end modules.
Prior to making any such licence requests, an open device must be initialised – that is, assigned a unique ID and added to the appropriate head-end database. Initialisation happens every time an open device is started, however personalisation (where an unique DRM device ID is assigned) only happens if the device does not already have an ID (usually only on first use). If this DRM device ID is lost (for example, if the player application is re-installed or cannot persist the DRM device ID), personalisation must be done again.
Initialisation is only required for open devices. (Set-top-boxes are pre-provisioned.)
Licences can be delivered to a device at initialisation time, rather than when the user starts playing content. This is called licence predelivery, and ensures that licences for live content will be available on the device when the user selects a channel, so they do not have to wait for the relevant licence to be acquired. Licence predelivery is also used for Download2Go – it ensures that the licences for the downloaded content are stored and available on the device if the user tries to watch it offline.
The exact details of the licence acquisition requests and responses (that is, which APIs are used and the contents of the requests and responses) vary depending on a number of factors:
Whether direct mode (where the client calls the PRM directly) or non-direct mode (where the client calls MDRMM, which in turn calls the PRM) is being used.
Whether the client is a set-top-box (which means hardware PRM is used) or an open device (which means software PRM is used).
Whether licence predelivery is used (which is usually the case with live TV and Download2Go).
Note that licence predelivery must be used when using direct mode.
Whether the head-end uses SDP or a third-party portal.
This page explains the end-to-end workflow for license acquisition for both direct and non-direct modes, and for each, provides detailed information about the requests and responses for each stage, including differences in the way the requests must be made due to the above factors.
The diagrams and explanations in this section show a player application running on an open device as the client. For a set-top-box, the workflows will be basically the same, except the calls to the PAK within the client are not relevant.
Direct mode
STBs typically do not use direct mode.
In direct mode, this is the sequence of requests and responses:
PAK – PRM: this is transparent to the client app and the OpenTV Platform modules (which only have to handle the subsequent call from the PRM).
PRM – PAK
The app requests the encrypted content from the CDN.
The CDN starts sending video chunks to the player, which then (using the PAK) decrypts and plays them.
Non-direct mode
In non-direct mode, this is the sequence of requests and responses:
The player requests the encrypted content from the CDN.
The CDN starts sending video chunks to the player, which then (using the PAK) decrypts and plays them.