1、 ETSI TS 102 757 V1.1.1 (2008-07)Technical Specification Digital Video Broadcasting (DVB);Content Purchasing APIEuropean Broadcasting Union Union Europenne de Radio-Tlvision EBUUER floppy3 ETSI ETSI TS 102 757 V1.1.1 (2008-07) 2 Reference DTS/JTC-DVB-229 Keywords DVB, broadcast ETSI 650 Route des Lu
2、cioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: ht
3、tp:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the
4、printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at ht
5、tp:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright a
6、nd the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2008. European Broadcasting Union 2008. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit o
7、f its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 757 V1.1.1 (2008-07) 3 Contents Intellectual Property Rights4 Foreword.4 Introduction 5 1 Scope 6 2 References 6 2.1 Normative references .7 2.2 Informati
8、ve references7 3 Definitions and abbreviations.7 3.1 Definitions7 3.2 Abbreviations .8 4 General .8 4.1 APIs8 4.2 Platform dependencies .8 4.3 Throwing RuntimeExceptions8 4.4 Input and output parameters .8 5 System integration9 5.1 Parental and maturity rating .9 Annex A (informative): Use-cases and
9、 mapping to the APIs10 A.1 Example service configuration.10 A.2 Pull mode10 A.2.1 User experience 10 A.2.2 Mapping to application behaviour and API calls .11 A.3 Push mode 11 A.3.1 User experience 11 A.3.2 Mapping to application behaviour and API calls .12 History 13 ETSI ETSI TS 102 757 V1.1.1 (200
10、8-07) 4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual
11、Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation,
12、 including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (
13、TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comit Europen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI). NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordina
14、te the drafting of standards in the specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body by including in the Memorandum of Understanding also CENELEC, which is responsible for the standardization of radio and television receivers. The EBU is a prof
15、essional association of broadcasting organizations whose work includes the co-ordination of its members activities in the technical, legal, programme-making and programme-exchange domains. The EBU has active members in about 60 countries in the European broadcasting area; its headquarters is in Gene
16、va. European Broadcasting Union CH-1218 GRAND SACONNEX (Geneva) Switzerland Tel: +41 22 717 21 11 Fax: +41 22 717 24 81 Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in the television industry. Its aim is to establish the framework f
17、or the introduction of MPEG-2 based digital television services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the broadcast industry. The spec
18、ifications for the following Java packages are contained in archive ts_102757v010101p0.zip (in HTML and JAVA files) which accompanies the present document. it.dtt.ca it.dtt.ca.event it.dtt.ca.exception it.dtt.ca.history it.dtt.ca.ppv it.dtt.ca.request it.dtt.ca.response it.dtt.ca.util ETSI ETSI TS 1
19、02 757 V1.1.1 (2008-07) 5 Introduction Some years ago, the DAVIC organisation defined a conditional access API - which is included in MHP. This API can be implemented using both embedded conditional access and DVB common interface. In order to ensure the latter, the capabilities of this API were des
20、igned to fit those of the DVB common interface. A major part of this API is allowing MHP applications to receive so-called “high level“ MMI messages and present them with a look and feel determined by the application provider. Those high level MMI messages were developed at a time when conditionally
21、 accessed TV was a relatively simple operation, essentially based on a subscription TV model with set-top boxes implementing a single conditional access system. Today, recent developments have shown that those assumptions are no longer true: 1) CA systems are used for a variety of encrypted Free to
22、View Channels. 2) Commercial deployment of multi CA receivers (with as many as 3 resident systems) is becoming more common. 3) New business model based on Subscription VOD, Pay per Use, Pay per Time, Pay per Event, etc. are becoming more and more important. 4) Introduction of pre-paid CA smart cards
23、. 5) Introduction of wallet based payments (based on local transactions without return channel). 6) Interaction with the end user is generally based on broadcast MHP applications that can be customized both from the look and feel and the behaviour point of view. It is no longer reasonable to expect
24、that CA user interfaces can, or should, be limited to the implementation by the manufacturer. The present document is a formalisation of a specification developed by the DGTVi for MHP in Italy, under the name of MHP CA API 1.2 i.5. In the Italian market in fact the assumptions behind the original DA
25、VIC API were incorrect and, more than this, complex Pay TV services based on horizontal interactive MHP-based set-top boxes were introduced. Most MHP boxes in the Italian market include at least two conditional access systems with both connected to an implementation of that specification. The presen
26、t document is believed to be backwards compatible with the parts of that original work which are used in the market. Not all of the original specification is used in practice and the present document is not backwards compatible with some parts which are not used. ETSI ETSI TS 102 757 V1.1.1 (2008-07
27、) 6 1 Scope The present document defines an API whose main goal is to to permit MHP or GEM applications to purchase protected content. Several other features can be supported in addition to this main goal including secure messaging and access to smart cards - including ones not related to a conditio
28、nal access or content protection system. Although the package name includes “ca“, the API is not specific to content protected by a content protection system, the API can also be used with content protected by a DRM system or other means. Although the package name includes “dtt“, the API is neither
29、specific to DTT nor to broadcast content, as it can also be used with IPTV delivered content . These naming conventions are kept to maintain backwards compatibility with current implementation in the market. The scope of the API includes the following features: Obtaining lists of content available t
30、o be purchased. Requesting the purchasing of a one or more items of content from a content protection system. Support information about purchasing and smart card general management including, for example, giving access to purchase history, recharge history or information about the specific smart car
31、d. The API itself is not intended to be secure. All security requirements are intended to be addressed by the underlying content protection system. The present document is intentionally not a complete specification either for implementers or for application developers. It is intended to be read in c
32、onjunction with a document specific to a particular deployment of a particular content protection system. Such additional document would address issues such as the following: How many of the API features are implemented in that particular deployment. Which of the implemented API features are availab
33、le to which applications - with or without authentication. Neither of these are addressed in the present document. It is important to emphasize that the API defined in the present document is optional and that: - No conditional access or content protection system used in an MHP deployment is obligat
34、ed to use this API or any part of it. - Any MHP deployment that does choose to use this API, or any part of it, can extend it in any way. The specific extensions and the extension mechanism will be defined by an additional document specific to that deployment. Extensions should not override any func
35、tionality already defined in the API. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document o
36、r a part thereof and only in the following cases: - if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document; - for informative references. Referenced documents which are not found to be publicly available in the expec
37、ted location might be found at http:/docbox.etsi.org/Reference. ETSI ETSI TS 102 757 V1.1.1 (2008-07) 7 For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to
38、ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the method of access to the referenced document and the full network address, with the same punctuation and use of upper case and lower case let
39、ters. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are indispensable for the application of the present document. For dated references, only the edi
40、tion cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies. 1 Java TV API 1.0, part of ISBN:1-892488-25-6. NOTE: Available from http:/ 2 Java TV API 1.1 (JSR-927). NOTE: Available from http:/www.jcp.org/en/jsr/detail?id=927. 3 DA
41、VIC 1.4.1 Specification Part 9. NOTE: Available from http:/docbox.etsi.org/Reference/DAVIC. 2.2 Informative references The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-specific reference
42、s, the latest version of the referenced document (including any amendments) applies. i.1 ETSI ES 201 812: “Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3“. i.2 ETSI TS 102 812: “Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1
43、“. i.3 ETSI TS 102 590: “Digital Video Broadcasting (DVB); Mulimedia Home Platform 1.2“. i.4 ETSI EN 300 468: “Digital Video Broadcasting (DVB);Specification for Service Information (SI) in DVB systems“. 4 CENELEC EN 50221: “Common Interface Specification for Conditional Access and other Digital Vid
44、eo Broadcasting Decoder Applications“. i.5 DGTVi “DTT CA API 1.2“ specification. NOTE: Available on request from infodgtvi.it or from http:/ 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: API: interface between an
45、application and a particular feature, function or resource of the MHP ETSI ETSI TS 102 757 V1.1.1 (2008-07) 8 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: API Application Programming Interface DAVIC Digital Audio Visual Council DVB-SI Digital Video B
46、roadcasting - Service Information MMI Man-Machine Interface 4 General 4.1 APIs The present document requires the presence of the following packages - it.dtt.ca, it.dtt.ca.event, it.dtt.ca.exception, it.dtt.ca.history, it.dtt.ca.ppv, it.dtt.ca.request, it.dtt.ca.response, it.dtt.ca.util. The extent t
47、o which these are implemented in any particular deployment of a particular content protection system is defined by the additional document specific to that deployment. 4.2 Platform dependencies The present document requires the presence of an implementation of either one of the following: JavaTV 1.0
48、 1. JavaTV 1.1 2. The present document also requires the presence of the org.davic.resource.ResourceClient interface defined in DAVIC 1.4.1 part 9 3 as found in MHP 1.0 i.1, MHP 1.1 i.2 or MHP 1.2 i.3. The extent to which the methods on this interface are called in any particular deployment of a par
49、ticular content protection system is defined by the additional document specific to that deployment. 4.3 Throwing RuntimeExceptions The present document intentionally does not define when RuntimeExceptions (such as SecurityException) are thrown. When methods throw these and the circumstances under which they are thrown is expected to form part of the additional document containing content protection system and deployment specific
