| Microsoft DirectX 8.1 (C++) |
This topic applies to Windows XP Home Edition and Windows XP Professional only.
Two primary objects are responsible for managing the top layer of conditional access: the Video Control and the CA Manager. The Video Control accepts tune requests, builds the filter graph, and creates the CA Manager. The CA Manager supervises conditional access.
The following diagram illustrates the relationships among the high-level components used in conditional access:
Request: A request represents the user’s request for a service. When the user tunes to a new channel, the application uses a tune request object. In order to support possible extensibility in the future, Conditional Access wraps the tune request in a more generic "CA request" object. In the current implementation, the CA request is always a tune request.
Policy: A policy is an object that implements a particular set of conditions for user access. Multiple policies can be active at once. For example, one policy might charge a viewing fee while another checks for parental ratings.
Policies come in two varieties: software policies and filter policies. A software policy is a persistent, standalone component. The CA Manager automatically loads software policies from storage. A filter policy is created at run time by a DirectShow filter when it joins the filter graph. Typically a filter policy is associated with a device such as a smart card or tuner card, and is provided by the hardware vendor or service provider.
Denial: When a new request becomes active, any policy can block the request by creating a denial. For example, a pay-per-view policy would create a denial unless the user paid the viewing fee. A parental policy would create a denial if a show had an adult rating.
In this version of Microsoft TV Technologies, the application is responsible for enforcing denials. The Video Control will not prevent the application from showing a program that was denied. However, service providers can enforce conditional access at the hardware level by physically scrambling the signal until the denial is removed.
Toll: When a policy imposes a denial, it typically provides a way to remove the denial. It does this by attaching a toll to the denial. Each toll has its own mechanism for the user to "pay" the toll, which can be a monetary payment or something as simple as entering a password. When the user pays the toll, the owning policy removes the denial.
Third-Party Components
DirectShow does not provide any policies or tolls. Instead, third parties implement them using APIs that DirectShow has defined. Policies and tolls are tightly coupled. If you create a policy, you must implement the associated tolls. Typically, policies and tolls rely on a set of shared data. For example, the policy might check a subscription database. If the user has not paid, the policy would impose a denial. When the user pays the toll, the policy would update the database. For digital television, the filter that wraps the ring-0 hardware driver will also provide the policy for that television service.
Tolls and polices can have private interfaces as needed. DirectShow does not impose any interfaces on this level of the architecture. The payment mechanism can be implemented in hardware—for example, on a smart card. If a toll requires any form of monetary payment, it should also provide a way to refund the payment, at least until the service is provided.
DirectShow provides all of the other components needed for conditional access.