Example of a Client Session
This topic applies to Windows XP Home Edition and Windows XP Professional only.
In a traditional player application, the user selects a file and presses a "Play" button, and no other interaction is required. Conditional access requires more sophisticated interactions with the user. Any policy might impose a denial at any time. If a request is denied, the application must present a list of denials and tolls, and enable the user to select tolls for payment. Secondary denials complicate the situation: When a toll has a secondary denial, the application should display the toll, but disable payment until the user resolves the denial.
The following is a typical application scenario:
- The user starts the application. The Video Control creates and initializes the CA Manager. The CA Manager loads persistent policies from storage.
- The user tunes to a station. The Video Control creates a tune request and builds the filter graph. As DirectShow filters are added to the graph, they might create additional policies.
- The CA Manager iterates through the policies, giving each policy an opportunity to block the request. Each policy can add denials and tolls to the request or to stream components. These actions trigger events, which the application catches.
- If the application receives a request-denied event, it blocks the user from watching the program. It can do this by hiding the video window, placing a large bitmap over the window, or any similar technique.
- The application displays a list of denials and tolls.
- The user selects one or more tolls and attempts to pay them. Each toll implements a mechanism for paying the toll. Typically the toll displays a dialog box or some other user interface in the process.
- When the user pays a toll, the CA Manager removes the denial and fires an event.
- When the application receives a denial-removed event, it checks whether any more denials are pending. If not, it displays the video.