INTERNATIONAL ORGANISATION FOR STANDARDISATION
ORGANISATION INTERNATIONALE DE NORMALISATION
ISO/IEC JTC 1/SC 29/WG 11
CODING OF MOVING PICTURES AND AUDIO
ISO/IEC JTC 1/SC 29/WG11 N4701
March 2002
Source:
Title:
Editor:
Cheju IPMP Break out group
FPDAM ISO/IEC 14496-1:2001 / AMD3
Craig A. Schultz
Status:
Approved
ISO/IEC 13818-1:2000/PDAM 1
ISO/IEC TC JTC 1/SC 29 N
Date: 2002-03-21
ISO/IEC 13818-1:2000/PDAM 2
ISO/IEC TC JTC 1/SC 29/WG 11
Secretariat:
Information technology — Coding of audio-visual objects — Part 1:
Systems, Amendment 3: Intellectual Property Management and Protection
(IPMP) extensions
Élément introductif — Élément central — Partie 1: Titre de la partie
Warning
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change
without notice and may not be referred to as an International Standard.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.
2
ISO/IEC 14496-1:2000/Amd.3:2000(E)
Copyright notice
This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of
working drafts or committee drafts in any form for use by participants in the ISO standards development process is
permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or
transmitted in any form for any other purpose without prior written permission from ISO.
Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or
to ISO's member body in the country of the requester:
[Indicate the full address, telephone number, fax number, telex number, and electronic mail address, as appropriate, of
the Copyright Manger of the ISO member body responsible for the secretariat of the TC or SC within the framework of
which the working document has been prepared.]
Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ISO/IEC 14496-1:2001/Amd.3
Contents
1
INTRODUCTION ................................................................................................................................................................ 1
1.1
Compatibility with 14496 :1-2001 ................................................................................................................................ 1
1.2
Organization of this Document ................................................................................................................................... 1
2
NORMATIVE REFERENCES ............................................................................................................................................ 1
3
TERMS AND DEFINITIONS .............................................................................................................................................. 1
3.1
Authorized User ............................................................................................................................................................ 1
3.2
Binary Representation ................................................................................................................................................. 2
3.3
Content .......................................................................................................................................................................... 2
3.4
Content Consumption .................................................................................................................................................. 2
3.5
Content Stream ............................................................................................................................................................. 2
3.6
Control Point ................................................................................................................................................................. 2
3.7
IPMP Information .......................................................................................................................................................... 2
3.8
IPMP Tool ...................................................................................................................................................................... 2
3.9
IPMP Tool Identifier ...................................................................................................................................................... 2
3.10
IPMP Tool List ........................................................................................................................................................... 2
3.11
IPMP Tool Manager ................................................................................................................................................... 2
3.12
IPMP Tool Message .................................................................................................................................................. 2
3.13
IPMP Tool Stream ..................................................................................................................................................... 2
3.14
IPMP Tool Verification Information ......................................................................................................................... 2
3.15
Message Router ........................................................................................................................................................ 2
3.16
Mutual Authentication .............................................................................................................................................. 3
3.17
Parametric Configuration ......................................................................................................................................... 3
3.18
Parametric Description ............................................................................................................................................. 3
3.19
Renewability .............................................................................................................................................................. 3
3.20
Representation Format ............................................................................................................................................. 3
3.21
Rights Authentication ............................................................................................................................................... 3
ii
ISO/IEC 14496-1:2001/Amd.3
3.22
Scope of Protection .................................................................................................................................................. 3
3.23
Scope of Service ....................................................................................................................................................... 3
3.24
Terminal ..................................................................................................................................................................... 3
3.25
User ............................................................................................................................................................................ 3
3.26
Verification................................................................................................................................................................. 3
4
OVERVIEW OF IPMP EXTENSIONS (INFORMATIVE).................................................................................................... 3
4.1
Walkthrough .................................................................................................................................................................. 3
4.1.1
User requests specific content ................................................................................................................................ 4
4.1.2
IPMP Tools description access ............................................................................................................................... 4
4.1.3
IPMP Tools retrieval ................................................................................................................................................ 4
4.1.4
Instantiation of IPMP Tools ..................................................................................................................................... 4
4.1.5
IPMP Initialization and Update – In parallel with Content Consumption .................................................................. 4
4.2
Overview of the Normative Elements ......................................................................................................................... 5
4.2.1
IPMP Tool List ......................................................................................................................................................... 5
4.2.1.1
The Parametric Infrastructure .......................................................................................................................... 5
4.2.2
Tools in the Content ................................................................................................................................................ 5
4.2.3
Instantiation of IPMP Tools ..................................................................................................................................... 5
4.2.4
Mutual Authentication .............................................................................................................................................. 5
4.2.5
IPMP Information ..................................................................................................................................................... 6
4.2.6
IPMP Information Routing ....................................................................................................................................... 6
4.2.7
Consumption Permission ........................................................................................................................................ 6
SPECIFICATIONS..................................................................................................................................................................... 7
4.3
Extended MPEG-4 Architecture................................................................................................................................... 7
4.3.1
Additional Tag Specifications for MPEG-4 OD Syntax ............................................................................................ 7
List of Class Tags for Descriptors ......................................................................................................................................... 7
4.4
Standardized Processes .............................................................................................................................................. 8
4.4.1
IPMP Tool List Specification .................................................................................................................................... 8
4.4.2
IPMP Tool Identifier ................................................................................................................................................. 8
4.4.2.1
IPMP_ToolListDescriptor ................................................................................................................................. 9
4.4.2.1.1 Syntax........................................................................................................................................................... 9
4.4.2.1.2 Semantics..................................................................................................................................................... 9
4.4.2.2
IPMP_Tool........................................................................................................................................................ 9
4.4.2.2.1 Syntax........................................................................................................................................................... 9
4.4.2.2.2 Semantics................................................................................................................................................... 10
4.4.3
Parametric Infrastructure ....................................................................................................................................... 10
4.4.3.1.1 Details of Parametric Description ............................................................................................................... 11
4.4.3.1.2 Details of Parametric Configuration ........................................................................................................... 11
4.4.4
Delivery of Tools via Content................................................................................................................................. 11
4.4.4.1
IPMP Tool Streams in MPEG-4 Content ........................................................................................................ 11
4.4.4.2
IPMP_ToolES ................................................................................................................................................. 12
4.4.4.2.1 Decoder Specific Information ..................................................................................................................... 12
4.4.4.2.1.1 Syntax .................................................................................................................................................. 12
4.4.4.2.1.2 Semantics ............................................................................................................................................ 12
4.4.4.2.2 Bitstream .................................................................................................................................................... 12
4.4.4.2.2.1 Syntax .................................................................................................................................................. 12
4.4.4.2.2.2 Semantics ............................................................................................................................................ 13
4.4.5
IPMP Tool Instantiation ......................................................................................................................................... 13
iii
ISO/IEC 14496-1:2001/Amd.3
4.4.5.1
Instantiation and Termination through MPEG-4 Content ............................................................................... 13
4.4.5.1.1 IPMP_Initialize ............................................................................................................................................ 14
4.4.5.1.1.1 Syntax .................................................................................................................................................. 14
4.4.5.1.1.2 Semantics: ........................................................................................................................................... 14
4.4.5.1.2 IPMPToolDescriptorPointer ........................................................................................................................ 15
4.4.5.1.2.1 Syntax .................................................................................................................................................. 15
4.4.5.1.2.2 Semantics: ........................................................................................................................................... 15
4.4.5.1.3 IPMP_ToolDescriptor ................................................................................................................................. 15
4.4.5.1.3.1 Syntax .................................................................................................................................................. 15
4.4.5.1.3.2 Semantics ............................................................................................................................................ 15
4.4.5.1.4 IPMP_ToolDescriptor OD Commands ....................................................................................................... 16
4.4.5.1.4.1 IPMP_ToolDescriptorUpdate ............................................................................................................... 16
4.4.5.1.4.2 IPMP_ToolDescriptorRemove ............................................................................................................. 16
4.4.5.1.5 IPMPDecoderConfiguration........................................................................................................................ 17
4.4.5.1.5.1 Syntax .................................................................................................................................................. 17
4.4.5.1.5.2 Semantics ............................................................................................................................................ 17
4.4.5.1.6 IPMP_StreamDataUpdate .......................................................................................................................... 17
4.4.5.1.6.1 Syntax .................................................................................................................................................. 17
4.4.5.1.6.2 Semantics ............................................................................................................................................ 17
4.4.5.1.6.3 IPMP Stream Considerations .............................................................................................................. 18
4.4.6
Information Routing ............................................................................................................................................... 18
4.4.7
Mutual Authentication ............................................................................................................................................ 18
4.4.8
Trust and Security Metadata ................................................................................................................................. 18
4.4.8.1.1 Specification ............................................................................................................................................... 19
4.5
XML Schema ............................................................................................................................................................... 19
4.5.1
Syntax .................................................................................................................................................................... 19
4.5.2
Semantics .............................................................................................................................................................. 19
4.5.3
DateClass .............................................................................................................................................................. 19
4.5.3.1
Syntax ............................................................................................................................................................ 19
4.5.4
Semantics .............................................................................................................................................................. 19
4.6
TrustSecurityMetadata ............................................................................................................................................... 19
4.6.1
Syntax .................................................................................................................................................................... 19
4.6.2
Semantics .............................................................................................................................................................. 20
4.7
Permission for Content Consumption...................................................................................................................... 20
4.8
Tool Manager .............................................................................................................................................................. 21
4.8.1.1
Obtaining Missing Tools ................................................................................................................................. 21
5
MESSAGING INFRASTRUCTURE ................................................................................................................................. 21
5.1
Introduction ................................................................................................................................................................. 21
5.1.1
Message Router .................................................................................................................................................... 21
5.1.2
Addressing............................................................................................................................................................. 21
5.2
IPMP_ToolMessageBase ........................................................................................................................................... 21
5.2.1
Syntax .................................................................................................................................................................... 21
5.2.2
Semantics .............................................................................................................................................................. 22
5.3
IPMP_ToolSecureMessage ........................................................................................................................................ 22
5.3.1
Syntax .................................................................................................................................................................... 22
5.3.2
Semantics .............................................................................................................................................................. 23
5.4
Instantiation and Notification Messages .................................................................................................................. 23
5.4.1
IPMP_GetTools ..................................................................................................................................................... 23
5.4.1.1
Syntax ............................................................................................................................................................ 23
5.4.1.2
Semantics ...................................................................................................................................................... 23
iv
ISO/IEC 14496-1:2001/Amd.3
5.4.1.3
Response ....................................................................................................................................................... 23
5.4.2
IPMP_GetToolsResponse ..................................................................................................................................... 24
5.4.2.1
Syntax ............................................................................................................................................................ 24
5.4.2.2
Semantics ...................................................................................................................................................... 24
5.4.2.3
Response ....................................................................................................................................................... 24
5.4.3
IPMP_GetToolContext .......................................................................................................................................... 24
5.4.3.1
Syntax ............................................................................................................................................................ 24
5.4.3.2
Semantics ...................................................................................................................................................... 24
5.4.3.3
Response ....................................................................................................................................................... 24
5.4.4
IPMP_GetToolContextResponse .......................................................................................................................... 24
5.4.4.1
Syntax ............................................................................................................................................................ 24
5.4.4.2
Semantics ...................................................................................................................................................... 25
5.4.4.3
Response ....................................................................................................................................................... 25
5.4.5
IPMP_ConnectTool ............................................................................................................................................... 25
5.4.5.1
Syntax ............................................................................................................................................................ 25
5.4.5.2
Semantics ...................................................................................................................................................... 25
5.4.5.3
Response ....................................................................................................................................................... 25
5.4.6
IPMP_DisconnectTool ........................................................................................................................................... 25
5.4.6.1
Syntax ............................................................................................................................................................ 25
5.4.6.2
Semantics ...................................................................................................................................................... 25
5.4.6.3
Response ....................................................................................................................................................... 25
5.4.7
IPMP_ToolConnectNotification ............................................................................................................................. 25
5.4.7.1
Syntax ............................................................................................................................................................ 25
5.4.7.2
Semantics ...................................................................................................................................................... 25
5.4.7.3
Response ....................................................................................................................................................... 26
5.5
Event Notification Messages ..................................................................................................................................... 26
5.5.1
IPMP_AddToolNotificationListener ........................................................................................................................ 26
5.5.1.1
Syntax ............................................................................................................................................................ 26
5.5.1.2
Semantics ...................................................................................................................................................... 26
5.5.1.3
Response ....................................................................................................................................................... 26
5.5.2
IPMP_RemoveToolNotificationListener ................................................................................................................. 26
5.5.2.1
Syntax ............................................................................................................................................................ 26
5.5.2.2
Semantics ...................................................................................................................................................... 26
5.5.2.3
Response ....................................................................................................................................................... 26
5.5.3
IPMP_NotifyToolEvent .......................................................................................................................................... 27
5.5.3.1
Syntax ............................................................................................................................................................ 27
5.5.3.2
Semantics ...................................................................................................................................................... 27
5.5.3.3
Response ....................................................................................................................................................... 27
5.6
IPMP Information Delivery Functions ....................................................................................................................... 27
5.6.1
IPMP_MessageFromBitstream ............................................................................................................................. 27
5.6.1.1
Syntax ............................................................................................................................................................ 27
5.6.1.2
Semantics ...................................................................................................................................................... 27
5.6.1.3
Response ....................................................................................................................................................... 27
5.6.2
IPMP_ToolDescriptorFromBitstream .................................................................................................................... 27
5.6.2.1
Syntax ............................................................................................................................................................ 27
5.6.2.2
Semantics ...................................................................................................................................................... 27
5.6.2.3
Response ....................................................................................................................................................... 28
5.7
Consumption Permission .......................................................................................................................................... 28
5.7.1
IPMP_CanProcess ................................................................................................................................................ 28
5.7.1.1
Syntax ............................................................................................................................................................ 28
5.7.1.2
Semantics ...................................................................................................................................................... 28
5.8
User Interaction Messages ........................................................................................................................................ 28
5.8.1
ToolToUserMessage ............................................................................................................................................. 28
5.8.1.1
Syntax ............................................................................................................................................................ 28
5.8.1.1.1 ByteArray .................................................................................................................................................... 29
5.8.1.1.2 DTArray ...................................................................................................................................................... 29
v
ISO/IEC 14496-1:2001/Amd.3
5.8.1.1.3 RTArray ...................................................................................................................................................... 29
5.8.1.1.4 OptionArray ................................................................................................................................................ 29
5.8.1.2
Response ....................................................................................................................................................... 30
5.8.2
UserToToolMessage ............................................................................................................................................. 30
5.8.2.1
Syntax ............................................................................................................................................................ 30
5.8.2.2
Semantics ...................................................................................................................................................... 30
5.8.2.3
Response ....................................................................................................................................................... 30
5.9
Mutual Authentication Messages.............................................................................................................................. 30
5.9.1
IPMP_InitAuthentication ........................................................................................................................................ 30
5.9.1.1
Syntax ............................................................................................................................................................ 30
5.9.1.2
Semantics ...................................................................................................................................................... 31
5.9.1.3
Response ....................................................................................................................................................... 31
5.9.2
IPMP_Mutual_Authentication ................................................................................................................................ 31
5.9.2.1
Syntax ............................................................................................................................................................ 31
5.9.2.2
Semantics ...................................................................................................................................................... 32
5.9.2.3
Response ....................................................................................................................................................... 32
5.10
Key Descriptor......................................................................................................................................................... 33
5.10.1 Syntax .................................................................................................................................................................... 33
5.10.2 Semantics .............................................................................................................................................................. 33
5.11
AlgorithmDescriptor ............................................................................................................................................... 33
5.11.1 Syntax .................................................................................................................................................................... 33
5.12
Semantics ................................................................................................................................................................ 33
5.12.1 Generation of a MAC ............................................................................................................................................. 34
5.12.2 Generation of Keys for Message Encryption ......................................................................................................... 34
5.13
Parametric Messages ............................................................................................................................................. 35
5.13.1 IPMP Tool Parametric Capabilities Query ............................................................................................................. 35
5.13.1.1 Syntax ............................................................................................................................................................ 35
5.13.1.2 Semantics ...................................................................................................................................................... 35
5.13.1.3 Response ....................................................................................................................................................... 35
5.13.2 IPMP Tool Parametric Capabilities Query Response ............................................................................................ 35
5.13.2.1 Syntax ............................................................................................................................................................ 35
5.13.2.2 Semantics ...................................................................................................................................................... 35
5.13.2.3 Response ....................................................................................................................................................... 35
ANNEX A SELECTIVE DECRYPTION CONFIGURATION MESSAGE (NORMATIVE) ..................................................... 36
A.1 IPMP_SelectiveDecryptionMessage.............................................................................................................................. 36
A1.1 Syntax ...................................................................................................................................................................... 36
A.1.2 Semantics ............................................................................................................................................................... 37
A.2 An example of a selective decryption configuration message (Informative) ................................................................. 39
ANNEX B USE OF IPMP DECODERCONFIGINFORMATION (INFORMATIVE) ............................................................... 41
B.1 IPMP Descriptor Example ............................................................................................................................................. 41
B.2 IPMP Stream Example ................................................................................................................................................. 42
ANNEX C SCHEMA FOR TERMINAL PLATFORM (NORMATIVE)................................................................................... 43
ANNEX D SCHEMA FOR PARAMETRIC DESCRIPTION (NORMATIVE) .......................................................................... 46
ANNEX E LIST OF REGISTRATION AUTHORITIES (NORMATIVE) ................................................................................. 47
ANNEX F ILLUSTRATION OF USE AND SCOPE OF IPMP DESCRIPTORS AND DECLARATORS (NORMATIVE)....... 48
vi
ISO/IEC 14496-1:2001/Amd.3
ANNEX G – TRUST MODEL XML SCHEMA ......................................................................................................................... 55
G.1 Trust Model Schema................................................................................................................................................. 55
ANNEX H: WATERMARKING CONFIGURATION AND NOTIFICATION MESSAGES ........................................................ 57
H.1 IPMP_AudioWatermarkingInit ................................................................................................................................. 57
H.1.1 Syntax ..................................................................................................................................................................... 57
H.1.2 Semantics ............................................................................................................................................................... 57
H.2 IPMP_SendAudioWatermark................................................................................................................................... 58
H.2.1 Syntax ..................................................................................................................................................................... 58
H.2.2 Semantics ............................................................................................................................................................... 59
ANNEX I: TOOL/CONTENT TRANSFER MESSAGES AMONG DISTRIBUTED IPMP DEVICES (INFORMATIVE) .......... 59
I.1 Addressing of distributed devices ................................................................................................................................... 60
I.2 IPMP_DeviceMessageBase ........................................................................................................................................... 60
I.2.1 Syntax....................................................................................................................................................................... 60
I.1.2 Semantics................................................................................................................................................................. 60
I.2 Various Device to Device IPMP Messages ..................................................................................................................... 60
I.2.1 Content Transfer Messages ..................................................................................................................................... 60
I.2.1.1 IPMP_RequestContent ...................................................................................................................................... 60
I.2.1.2 IPMP_ResponseToContentRequest ................................................................................................................. 61
I.2.1.3 IPMP_ContentTransfer ...................................................................................................................................... 61
I.2.2 Tool Transfer Messages .......................................................................................................................................... 61
I.2.2.1 IPMP_RequestTool............................................................................................................................................ 62
I.2.2.2 IPMP_ResponseToToolRequest ....................................................................................................................... 62
I.2.3 Device ID messages ................................................................................................................................................ 62
I.2.3.1 IPMP_DeviceID_Broadcasting Message ........................................................................................................... 62
I.2.3.2 IPMP_DeviceID_Received ................................................................................................................................ 63
vii
ISO/IEC 14496-1:2001/Amd.3
Information technology — Coding of audio-visual objects : — Part 1:
Systems, Amendment 3: Intellectual Property Management and
Protection (IPMP) extensions
1
Introduction
This document contains specifications that extend the current IPMP capabilities of MPEG-4. The text of this document shall
be added as a clause in 14496-1.
1.1
Compatibility with 14496 :1-2001
This document specifies IPMP extensions for all MPEG content (“Extensions”).For its MPEG-4 mapping, it provides
extensions to the currently specified IPMP specification (the “Hooks”), documented in ISO/IEC 14496-1:2001.
“Hooks” Terminals do not support the additional functionality specified here. Hence, “Hooks” Terminals will not be able to
fully process “Extensions” content. However, the syntax and semantics here are compliant with the “Hooks” framework, and
therefore allow for graceful failure of a well-designed Terminal.
“Extensions” Terminals shall be able to play “Hooks” content, in compliance with the “Hooks” specification.
enhancements specified here shall be applied by an “Extensions” Terminal to the processing of “Hooks” content.
No
Behavior in response to hybrid “Hooks-Extensions” content is outside the scope of this specification and depends on the
implementation of a given Terminal.
1.2
Organization of this Document
This document is organized as follows:
Clause 0 provides an introduction to the document. Clause 4 provides an overview of the process supported by the IPMP
Extensions, and identifies different normative elements in this process. Clause 0 provides specifications for all components
identified in Clause 4. Clause 5 provides specifications for the messaging architecture and all supported messages.
2
Normative References
[1] ISO/IEC 14496-1:2001, Information Technology -- Coding of audio-visual objects -- Part 1 :Systems
[2] ISO/IEC 14496-2:2001, Information technology -- Coding of audio-visual objects -- Part 2: Visual
[3] W3C recommendation, Extensible Markup Language (XML) 1.0, http://www.w3.org/TR/REC-xml, 10 December 1998
[4] W3C recommendation, Extensible Markup Language (XML) 1.0 (2nd Edition), http://www.w3.org/TR/2000/REC-xml20001006, 6 October 2000
[5] W3C working draft, XML Schema Part 0: Primer, http://www.w3.org/TR/2000/WD-xmlschema-0-2000407/, 7 April 2000
[6] ISO/IEC 10646-1:1993, Information technology – Universal Multiple-Octet Coded Character Set (UCS) –
Part 1: Architecture and Basic Multilingual Plane.
3
3.1
Terms and Definitions
Authorized User
A user upon whom Rights Authentication has successfully been performed, within the scope of such Authentication.
1
ISO/IEC 14496-1:2001/Amd.3
3.2
Binary Representation
In the context of an IPMP Tool, this is the format of the implementation of that IPMP Tool, Examples: Platform Dependent
Native Code, Java ™ bytecode.
3.3
Content
This implies part or whole of an MPEG presentation.
3.4
Content Consumption
Any experience of given Content implies consumption of that content. Access, Playback, Denial of Access and Creation of a
Copy are all types of content consumption.
3.5
Content Stream
This is the incoming content, of MPEG-4 format.
3.6
Control Point
A point on a given elementary stream or given object in a Terminal where IPMP Processing for media data shall be carried
out.[4.4.5.1.1]
3.7
IPMP Information
Information directed to a given IPMP Tool to enable, assist or facilitate its operation.
3.8
IPMP Tool
IPMP tools are modules that perform (one or more) IPMP functions such as authentication, decryption, watermarking, etc.
3.9
IPMP Tool Identifier
This refers to the IPMP Tool ID. It identifies a Tool in an unambiguous way, at the presentation level or at a universal level
3.10 IPMP Tool List
The IPMP Tool List identifies, and enables selection of, the IPMP Tools required to process the Content.
3.11 IPMP Tool Manager
The IPMP Tool Manager is a conceptual entity within the Terminal that processes IPMP Tool List(s) and retrieves the Tools
that are specified therein.
3.12 IPMP Tool Message
A message passed between any combination of IPMP Tool or Terminal.
3.13 IPMP Tool Stream
An elementary stream carrying an implementation of an IPMP Tool.
3.14 IPMP Tool Verification Information
An IPMP Tool Identifier, together with other information to be used during mutual authentication between a given Tool, and a
Terminal or another IPMP Tool, constitutes IPMP Tool Verification Information.
3.15 Message Router
2
ISO/IEC 14496-1:2001/Amd.3
A conceptual entity within the Terminal that implements the Terminal-side behavior of the Terminal-Tool interface.
3.16 Mutual Authentication
Protocols carried out to determine the proper and correct identity of a communicating entity and to secure the
communication channels between communicating entities.
3.17 Parametric Configuration
Information that carries task-specific parameter specification, in an extensible form, and the process of such specification.
3.18 Parametric Description
Parametrically described tools shall be defined by a schema that governs a given description, the parametric configuration
and other interface message(s) that drive the tool and the behavior defined for fulfillment of such a description.
3.19 Renewability
Renewability implies that a Terminal shall acquire missing IPMP Tools, or update an existing IPMP Tool with an updated
version.
3.20 Representation Format
The binary format, platform and communication mechanisms applicable to a given implementation of an IPMP Tool or
Terminal.
3.21 Rights Authentication
The process of verifying the authentication of the stated Rights descriptions and the validity of their assignment to, and
fulfillment by, a given User.
3.22 Scope of Protection
Scope of protection refers to the elementary stream and/or object governed by a given IPMP Tool instance.
3.23 Scope of Service
Scope of service of an IPMP Elementary Stream refers to the set of IPMP Tool instances that are served by IPMP Tool
Messages sent in the stream
3.24 Terminal
A Terminal is an environment that consumes possibly protected Content in compliance with the usage rules.
3.25 User
A hardware, software or human entity that is the initiator and/or target of content consumption.
3.26 Verification
Establishing, to an acceptable level of certainty, that a certain condition that was claimed to be true is true.
4
4.1
Overview of IPMP Extensions (Informative)
Walkthrough
This clause describes a possible sequence of steps involved in the consumption of content protected by the IPMP
Extensions. This walkthrough identifies the technologies required for interoperability and renewability of IPMP Tools. Figure
1 provides an architecture diagram for the walkthrough concepts.
3
ISO/IEC 14496-1:2001/Amd.3
Missing IPMP
Tools
Obtain Missing IPMP
Tool(s)
Content
IPMP Tool Manager
IPMP Tool List
IPMP Tool ID(s)
Alternate IPMP Tool ID(s)
Content Request
Parametric Tool
Description(s)
Content Delivery
Terminal
IPMP Tool Elementary
Stream
IPMP Information
Terminal-Tool Message Interchange Interface
Terminal-IPMP Tool
Communications
IPMP Tool 1
IPMP Tool 2
...
IPMP Tool n
Figure 1 - Architecture Diagram for Walkthrough Concepts
4.1.1
User requests specific content
The manner in which Content is requested is out of scope of this document. However, the following recommendations are
made for the order in which different parts of the Content are received and used:
1. IPMP Requirements on the Terminal should be placed with or before media requirements on the Terminal.
2. Access Information and/or restrictions should precede media stream delivery information.
4.1.2
IPMP Tools description access
1. The terminal accesses the IPMP Tool List [4.2.1].
2. Using the IPMP Tool List, the Terminal determines the IPMP Tools required to consume the content.
4.1.3
IPMP Tools retrieval
IPMP tools retrieved out of band are outside the scope of IPMP extensions spec. Missing IPMP tools may be retrieved
through an IPMP tool stream if available.
4.1.4
Instantiation of IPMP Tools
1. The Terminal instantiates [4.4.5.1] the IPMP Tool(s) locally or remotely.
2. The instantiated Tools are provided [5.6] with initial IPMP Information from the Content.
4.1.5
IPMP Initialization and Update – In parallel with Content Consumption
1. The Message Router routes [4.2.6] IPMP Information [4.2.5] to the IPMP Tools.
2. The terminal consumes the content if allowed [4.2.7] by the requisite IPMP Tools.
3. During content consumption, the complete walkthrough can be requested again. Requests for content consumption
are implicit within the process, or are requested [4.2.7] by the User.
This architecture supports both transparent and opaque IPMP Information. An IPMP Information ID will be part of the IPMP
Information, such ID shall be assigned by a Registration Authority.
4
ISO/IEC 14496-1:2001/Amd.3
4.2
Overview of the Normative Elements
The following elements from the above walkthrough are identified as areas of standardization. The functions that each
normative element shall fulfill are briefly described below.
4.2.1
IPMP Tool List
1. The IPMP Tool List [4.4.1] supports indication of independent or alternative Tools.
2. For each tool in the IPMP Tool List, the following information is provided:
a. IPMP Tool Identifier: A given IPMP tool is identified to other entities via its IPMP Tool Identifier, and an
optional Parametric Description.
b. Possible alternatives to a given Tool.
c. Optional Tool List Signature
4.2.1.1
The Parametric Infrastructure
This is a light, structured language based representation [4.4.3] to accomplish the following:
1. Enables the selection of an implementation of a Tool, usually available at the Terminal that satisfies specified
functionality. This is called Parametric Description.
2. The ability to configure tools, whether parametric or not in a parametric manner.
Note that all parametric tools shall be subject to the same authentication processes as other IPMP Tools.
Note also that the exact values of parameters controlling a parametrically described tool are carried in Parametric
Configuration. Such information shall be carried in the Content or generated by other IPMP Tools during Content
Consumption.
4.2.2
Tools in the Content
Specific IPMP Tool implementations may be carried within the bitstream. In such case, the representation format [4.4.4]
shall be carried in the information [4.4.4] describing such a stream. The representation indicates the Interface
implementation, binary representation, packaging mechanism, instantiation and initialization for the specific Tool
implementation, and is provided by a Registration Authority. Registration of tool implementation specific information not
only applies to tools in the content but all tools.
4.2.3
Instantiation of IPMP Tools
Instantiation creates an instance of protection for a specific context, and results in a mechanism of communication from the
Message Router to the IPMP Tool. The actual instantiation mechanism is implementation dependent and is not described in
this specification although supported via the use of a Registration Authority.
4.2.4
Mutual Authentication
Tools that must communicate with one another or with the Terminal must do so in a way that meets the security
requirements of the Tools and the Terminal. Tools may establish trust with the Terminal and possibly with one another to
enable secure communication. Support for the establishment of a communication channel that reflects the nature of intertool trust can be accomplished via the use of secure, trusted authenticated channels. Mutual authentication is the first part of
protocols designed for such communication.
Different types of Mutual Authentication support the following functionalities:
1. Entities needing to verify each other’s identity without requiring secure communication.
2. Entities not needing to verify each other’s identity but yet need to secure communication channels.
3. Entities needing to verify each other’s identity and secure channels of communication.
Messages supporting the following functionalities together enable Mutual Authentication:
1. A negotiation mechanism whereby involved parties may agree on protocols to be used during the mutual
authentication process and communication channel securing.
2. Authentication of the involved entities using the agreed upon protocol.
5
ISO/IEC 14496-1:2001/Amd.3
3. Establishment of communication channels using a shared secret resulting from a successful mutual authentication
in a way consistent with the negotiated algorithms from 1.
4. Messages encrypted using keys generated from a shared secret.
5. Messages signed or attached with MAC (message authentication codes).
Note: The generation and use of a shared secret depends on algorithms and/or protocols selected during the negotiation
phase found in 1.
4.2.5
IPMP Information
IPMP Information is of two types. The first type is based on a fixed syntax that is meant for use both by the Terminal and
the IPMP Tool, to initialize or configure the Tool to protect specific media stream(s) in the Content. The second type is fully
opaque and is meant for use only by the IPMP Tool. Note that one or both types of information may be contained in a single
IPMP Message or IPMP Tool Message.
IPMP Information may come from four sources.
1.
2.
3.
4.
4.2.6
The Content
The terminal resources
Remote resources
Another IPMP Tool
IPMP Information Routing
IPMP Information Routing mechanisms [5.1.1] depend on the following parameters:
1. A unique identification of the sender of the IPMP Information.
2. A unique identification of the intended recipient of the IPMP Information
Routing considerations are manifested by encapsulating the IPMP Information in an IPMP Tool Message [5.2] or IPMP
Message, or are implicit [4.4.5.1] by the location of the IPMP Information in a bitstream.
4.2.7
Consumption Permission
The course of processing content involves a number of different types of application specific content use. Although
communications required to query rights processing and governance tools is out of the scope of these specifications, the
specifications provide a message, IPMP_CanProcess, to allow tools to notify the Terminal of the ability to proceed with
and/or continue processing given content.
6
ISO/IEC 14496-1:2001/Amd.3
Specifications
4.3
Extended MPEG-4 Architecture
Figure 2: Mapping of IPMP Extensions to MPEG-4 Systems Architecture
4.3.1
Additional Tag Specifications for MPEG-4 OD Syntax
List of Class Tags for Descriptors
Tag value
Tag name
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11
0x12
0x13
Forbidden
ObjectDescrTag
InitialObjectDescrTag
ES_DescrTag
DecoderConfigDescrTag
DecSpecificInfoTag
SLConfigDescrTag
ContentIdentDescrTag
SupplContentIdentDescrTag
IPI_DescrPointerTag
IPMP_DescrPointerTag
IPMP_DescrTag
QoS_DescrTag
RegistrationDescrTag
ES_ID_IncTag
ES_ID_RefTag
MP4_IOD_Tag
MP4_OD_Tag
IPL_DescrPointerRefTag
ExtendedProfileLevelDescrTag
7
ISO/IEC 14496-1:2001/Amd.3
0x14
0x15-0x3F
0x40
0x41
0x42
0x43
0x44
0x45
0x46
0x47
0x48
0x49
0x4A
0x4B-0x5F
0x60
0x61
0x62
0x63
0x64-0xBF
0xC0-0xFE
0xFF
4.4
profileLevelIndicationIndexDescrTag
Reserved for ISO use
ContentClassificationDescrTag
KeyWordDescrTag
RatingDescrTag
LanguageDescrTag
ShortTextualDescrTag
ExpandedTextualDescrTag
ContentCreatorNameDescrTag
ContentCreationDateDescrTag
OCICreatorNameDescrTag
OCICreationDateDescrTag
SmpteCameraPositionDescrTag
Reserved for ISO use (OCI extensions)
IPMP_ToolsListDescrTag
IPMP_ToolParamDescrTag
IPMP_ToolDescrTag
IPMP_ToolDescrPtrTag
Reserved for ISO use
User private
Forbidden
Standardized Processes
4.4.1
IPMP Tool List Specification
For each tool, this includes
1. IPMP Tool Identifier [4.4.2]
2. Optional Parametric Description of the Tool [4.4.3].
3. Alternative Tools to the given Tool, any one of which replace the others without loss of functionality.
The Tool List shall be in the IOD, in an IPMP_ToolListDescriptor. Binary IPMP Tools are carried in separate elementary
streams associated with the IOD. The specification of the syntax for the Tool List is as follows.
4.4.2
IPMP Tool Identifier
The IPMP Tool Identifier (or IPMP Tool ID) is 128-bits long. It is platform independent and arrives in the Content?, and shall
contain a unique identification number for the IPMP Tool. A registration authority for IPMP Tools that use a unique ID is
required. The registration authority shall maintain an optional association of the download URLs for various implementations
of the given tool for various platforms. These platforms will be described to adequate detail using a structured
representation. The IPMP ToolID identifies a specific IPMP Tool (not a specific implementation of such a tool), unless in the
reserved range for parametrically defined tools. Currently assigned 16-bit IPMPS_Types shall be directly mapped to a 128bit ID by prepending with 112 zero bits; the RA will be initialized with such values. Specific values within this 128-bit space
are reserved for indicating parametric tools, the bitstream, the terminal, and other special addresses. These values shall not
be assigned to registered Tools.
Table 1 - Values of IPMP_ToolID
IPMP_ToolID
0x0000
0x0001
0x0002
0x0003 - 0x2000
0x2001 - 0xFFFF
8
Semantics
Forbidden
Content
Terminal
Reserved for ISO use
Carry over from 14496-1 RA
ISO/IEC 14496-1:2001/Amd.3
0x10000 - 0x100FF
0x100FF – 2^128-2
2^128-1
4.4.2.1
Parametric Tools or Alternative Tools
Open for registration
Forbidden
IPMP_ToolListDescriptor
The IPMP_ToolListDescriptor conveys the list of IPMP tools required to access the content associated with the
InitialObjectDescriptor in which it is described, and may include a list of alternate IPMP tools or parametric
descriptions [4.4.3.1.1] of tools required to access the content. The list may be digitally signed to protect the integrity of the
list.
class InitialObjectDescriptor extends ObjectDescriptorBase :
bit(8) tag=InitialObjectDescrTag
{
bit(10) ObjectDescriptorID;
bit(1) URL_Flag;
bit(1) includeInlineProfileLevelFlag;
const bit(4) reserved=0b0000;
if (URL_Flag) {
bit(8) URLLength;
bit(8) URLstring[URLLength];
} else {
bit(8) ODProfileLevelIndication;
bit(8) sceneProfileLevelIndication;
bit(8) audioProfileLevelIndication;
bit(8) visualProfileLevelIndication;
bit(8) graphicsProfileLevelIndication;
ES_Descriptor esDescr[1 .. 255];
OCI_Descriptor ociDescr[0 .. 255];
IPMP_ToolDescriptorPointer ipmpDescrPtr[0 .. 255];
IPMP_DescriptorPointer ipmpDescrPtr[0 .. 255];
IPMP_ToolListDescriptor toolListDescr[0 .. 1];
IPMP_ToolDescriptor[0 .. 255];
}
ExtensionDescriptor extDescr[0 .. 255];
}
4.4.2.1.1
Syntax
class IPMP_ToolListDescriptor extends BaseDescriptor :
bit(8) tag=IPMPToolListDescrTag
{
bit(8) numTools;
IPMP_Tool ipmpTool[numTools];
}
4.4.2.1.2
Semantics
IPMP_Tool – a class describing a logical IPMP Tool required to access the content.
4.4.2.2
4.4.2.2.1
IPMP_Tool
Syntax
class IPMP_Tool
{
bit(128) IPMP_ToolID;
bit(1)
isAltGroup;
bit(1)
isParametric;
const bit(6)
reserved=0b0000.00;
9
ISO/IEC 14496-1:2001/Amd.3
if(isAltGroup){
bit(8)
numAlternates;
bit(128) specificToolID[numAlternates];
}
if(isParametric)
ByteArray toolParamDesc;
int(8) numURLs;
ByteArray ToolURL[numURLs];
}
4.4.2.2.2
Semantics
Each instance of Class IPMP_Tool identifies one IPMP Tool that is required by the Terminal to Consume the Content. This
Tool shall be specified either as a unique implementation, as one of a list of alternatives, or through a parametric
description.
A unique implementation is indicated by the isAltGroup and isParametric fields both set to zero. In this case, the
IPMP_ToolID shall be from the range reserved for specific implementations of an IPMP Tool and shall directly indicate the
required Tool.
In all other cases, the IPMP_ToolID serves as a Content-specific abstraction for an IPMP Tool ID since the actual IPMP
Tool ID of the Tool is not known at the time of authoring the Content, and will depend on the Terminal implementation at a
given time for a given piece of Content.
A parametric description is indicated by setting the isParametric field to one. In this case, the Terminal shall select an IPMP
Tool that meets the criteria specified in the following parametric description. In this case, the IPMP_ToolID shall be from the
range reserved for Parametric Tools or Alternative Tools. The actual IPMP Tool ID of the Tool that the terminal
implementation selects to fulfill this parametric description is known only to the Terminal. All the Content, and other tools,
will refer to this Tool, for this Content, via the IPMP_ToolID specified. Note, this is not for message addressing.
A list of alternative Tools is indicated by setting the isAltGroup flag to ”1”. The subsequent specific ToolIDs indicate the
Tools that are equivalent alternatives to each other. If the isParametric field is also set to one, any Tool that is selected
under the conditions for parametric tools (as discussed in the paragraph above) shall be considered by the Terminal to be
another equivalent alternative to those specified via specific ToolIDs. The Terminal shall choose one from these equivalent
alternatives at its discretion. The actual IPMP Tool ID of this Tool is known only to the Terminal.
IPMP_ToolID – the identifier of the IPMP Tool, as discussed above.
isAltGroup – if set to one, this IPMP_Tool contains a list of alternate IPMP Tools.
numAlternates – the number of alternative IPMP Tools specified in IPMP_Tool.
specificToolID – an array of the IDs of specific alternative IPMP Tools that can allow consumption of the content.
isParametric – IPMP_Tool contains a parametric description of an IPMP Tool. In this case, IPMP_ToolID is an identifier
for the parametrically described IPMP Tool, and the Terminal shall route information specified in the bitstream for
IPMP_ToolID to the specific IPMP Tool instantiated by the terminal.
ToolURL – An array of numURL informative URLs from which one or more tools specified in IPMP_Tool may be obtained.
4.4.3
Parametric Infrastructure
In several cases of IPMP Tools, the tools required are unique, and therefore shall be uniquely identified by a simple fixed
length ID.
For some classes of tasks within an IPMP chain, however, the following conditions are likely to hold true:
1. They will be based on popular public algorithms.
2. There will be a wide variety of equivalent implementations of the same available.
10
ISO/IEC 14496-1:2001/Amd.3
3. They will be computationally intensive, leading to platform-specific optimized implementations, from a wide variety of
vendors.
Information that carries functional/process specification, in an extensible form, is called Parametric Configuration.
A Parametric Configuration message can be used to cause an initialization or mode change of a given tool.
4.4.3.1.1
Details of Parametric Description
This clause contains an illustration of the hierarchy that a parametric description would follow. It does not attempt to define
any specific schema for any specific Tool type. It is anticipated that such definitions will be added over time to the overall
schema as a need is identified and an optimal schema developed. We anticipate that only a basic framework will appear in
the current version of the specification, and enhancements to the same will be left for future addendums and/or versions.
1. Version of parametric description syntax
2. Class of Tool
e.g. Decryption, Rights Language Parser
3. Sub-class of Tool
a. e.g. for Decryption: AES, DES, NESSIE etc
b. e.g. for Watermarking: “Panos’s watermarking tool” etc
c. e.g. for Rights Language Parser: “Fred’s Rights Parser”
d. e.g. for Protocol Parser: “Mary’s Protocol Parser”
4. Sub-class-specific information
a. e.g. for DES: number of bits, stream and/or block decipher capability
b. e.g. for Rights Language Parser : version
The XML schema is defined in Annex .
4.4.3.1.2
Details of Parametric Configuration
Parametric configuration information is contained in IPMP Descriptors and in IPMP_StreamDataUpdate’s that are
addressed to a parametric tool. Such information would typically be contained inside opaque IPMP_Data fields. However, it
is necessary that such information be of standard syntax, for reasons described earlier.
As specific classes and sub-classes of parametric tools are defined and specified, their interfaces and configuration
messages must also be defined. This specification does not aim to provide any such definitions, except as noted, but
simply to provide a framework within which such definitions shall be made.
4.4.4
Delivery of Tools via Content
One or more Binary Representations of IPMP Tools may be carried directly or by reference in an MPEG presentation.
4.4.4.1
IPMP Tool Streams in MPEG-4 Content
A streamType “IPMPToolStream” is defined to carry binary IPMP Tools. The value assigned to this streamType shall be set
as 0x0A, from the currently ISO-reserved range. The modified streamType table would be as below. The objectType for this
streamType shall be set to 0xFF.
Table 2 - streamType Table
streamType value
streamType description
0x00
0x01
0x02
0x03
0x04
0x05
Forbidden
ObjectDescriptorStream
ClockReferenceStream
SceneDescriptionStream
VisualStream
AudioStream
11
ISO/IEC 14496-1:2001/Amd.3
0x06
0x07
0x08
0x09
0x0A
0x0B - 0x1F
0x20 - 0x3F
MPEG7Stream
IPMPStream
ObjectContentInfoStream
MPEGJStream
IPMPToolStream
reserved for ISO use
user private
One implementation of a given tool is carried as the payload of one IPMP Tool stream, the representation format, package
information and IPMP Tool ID of which is specified in DecoderConfigDescriptor in the associated ESD.
IPMP_ToolESs shall be referenced through the IOD. The IPMP Tool Manager serves as a decoder for IPMP Tool Streams.
IPMP Tools carried within IPMP_ToolESs become part of the Terminal resources, and shall be installed, used and retained
at the discretion of the Terminal implementation. As such, once the downloaded tool is installed or otherwise made available
to the Terminal implementation, it shall be referenced via its IPMP Tool ID just like any other IPMP Tool.
4.4.4.2
IPMP_ToolES
This is the syntax of the IPMP_ToolES stream.
4.4.4.2.1
4.4.4.2.1.1
Decoder Specific Information
Syntax
class IPMPToolES_DecoderConfig extends DecoderSpecificInfo : bit(8) tag=DecSpecificInfoTag
{
bit(128)
IPMP_ToolID;
bit(32)
Tool_Format_ID;
bit(16)
Tool_Package_ID;
}
4.4.4.2.1.2
Semantics
IPMP_ToolID – the ID of the Tool carried in this stream.
Tool_Format_ID - This is defined as 0x0001 for a structurally described tool. Otherwise, the Tool_Format_ID
indicates the Binary Representation of the Tool and is assigned by a registration authority.
Tool_Package_Id – a 16-bit unsigned integer that indicates the details of the package of the Tool – examples are CAB,
Zip, TAR. Values are assigned by a registration authority.
4.4.4.2.2
Bitstream
This clause specifies the container syntax for the bitstream carrying an IPMP tool within an IPMP tool stream.
4.4.4.2.2.1 Syntax
class IPMP_ToolES_AU
{
bit(1) isSigned;
const bit(7) reserved = 0b0000.000;
if (isSigned)
{
ByteArray IPMP_Tool_Signature;
bit(16) numCerts;
for(int i=0; i<numCerts; i++)
{
bit(8) CertType;
Certificate certificate[numCerts];
}
bit(128) Verifying_Tool_Id;
12
ISO/IEC 14496-1:2001/Amd.3
}
bit(32) sizeOfTool;
bit(8) Tool_Body[sizeOfTool];
}
4.4.4.2.2.2
Semantics
IsSigned – When set to ‘1’, shall Indicate the presence of a signature in the tool stream.
IPMP_Tool_Signature - the signature of the data being delivered in the tool stream.
CertType – The type of certification mechanism being used.
NumCerts – The number of certificates included.
Certificate - The array of certificates. The data format of the certificates is defined in section 5.9.
Verifying_Tool_Id – The ID of the Tool that is required to verify the certificate(s). This shall be the ID of the Terminal
or a trusted tool. When the Verifying_Tool_ID is implicit by the CertType and/or Certificate, this shall be set to 0.
SizeOfTool – the size in bytes of the Tool Body
Tool_Body – the data for the Tool.
4.4.5
IPMP Tool Instantiation
Instantiation of the Tools is implementation dependent. A registration authority shall register instantiation mechanisms for
particular platforms.
Upon instantiation of an IPMP Tool, all IPMP Tools already instantiated by the Terminal shall be notified of [5.4] such
instantiation, if they have explicitly requested such notification. At the same time, the newly instantiated IPMP Tool may
request to be informed of other IPMP Tools running on the Terminal [5.4].
Each instantiation of an IPMP Tool shall establish a new logical instance of the tool, for that particular scope of protection.
The Terminal assigns a context identifier for the logical instance of the tool, which maps to the specific tool instance, and
therefore to the associated scope of protection. These context identifiers shall be unique to ensure unambiguous addressing.
Events triggering the instantiation of an IPMP Tool come from the following two sources, with associated issues being
specified.
1. The Content
a. The syntax and context that trigger instantiation
b. The scope of protection
c. The relationship of one IPMP Tool with other IPMP Tools in the same scope of protection.
2. Another IPMP Tool
a. Clear method of requesting the logical address of a required tool.
The process of instantiation involves the following steps
1. Establish a context for the Tool being instantiated
2. Establish a link between the MR and the Tool instance
3. Establish a link between the Tool instance and the MR.
Details of this process are implementation specific. The normative result is a context/address being made available for
communication and use of the instantiated tool by other tools as well as the Terminal.
4.4.5.1
Instantiation and Termination through MPEG-4 Content
IPMPDescriptors and IPMPDescriptorPointers shall not be used within the IPMP Extensions framework.
An
IPMPToolDescriptor shall be used to indicate the IPMP Tool to be used for protection of a given stream / object and convey
associated control point information. IPMPToolDescriptors are carried or removed through IPMPDescriptorUpdate and
IPMPDescriptorRemove commands in the OD stream; these commands may carry both IPMPDescriptor and
IPMPToolDescriptor. Note that usage of IPMPDescriptor and IPMPToolDescriptor in a single presentation defines hybrid
IPMP content. This practice is discouraged, and shall result in non-normative behaviour. IPMPToolDescriptors may also be
carried in the IPMP Stream Decoder Specific Configuration descriptor of an IPMP Stream.
MPEG-4 Streams and Objects shall be associated with a specific IPMP Tool through an IPMPToolDescPointer which is
carried in an OD or an ESD IPMP_ToolDescPointer[ ] array.
13
ISO/IEC 14496-1:2001/Amd.3
Instantiation of an IPMP Tool shall occur whenever an IPMPToolDescPointer in an OD or an ESD is given, and the
associated IPMPToolDescriptor is known at the terminal. If an IPMPToolDescriptor is received through an
IPMPDescriptorUpdate and no IPMPToolDescPointer refering to this IPMPToolDescriptor is found, the Terminal shall ignore
this IPMPToolDescriptor. IPMP streams do NOT instantiate IPMP Tools and therefore have no impact on ESDescriptor or
ObjectDescriptor protection. IPMP Streams are only used to convey data to IPMP Tool instances.
The scope of protection of an IPMPTool is defined as follows:
- If the IPMP Tool was instantiated in response to an IPMPToolDescPointer in an ObjectDescriptor, the IPMP tool protects
all streams described in this OD.
- If the IPMP Tool was instantiated in response to an IPMPToolDescPointer in an ESDescriptor, the IPMP tool protects the
stream described by this ESD.
An IPMP Tool may be loaded upon request from another loaded IPMP Tool. Such an instantiation request is communicated
by an IPMP_RequestToolInstantiation message, which shall specify the control point at which to place the instantiated tool.
In this case, the latter tool inherits the scope of protection of the former and may use any possible control points on the set
of streams in its scope. Note that some control points are not associated with any known point on an Elementary Stream.
Note that there are issues with scoping and scenarios that are somewhat illogical, especially as related to BIFS notes
referencing ODs.
The tool requesting instantiation shall receive an IPMP_ToolInstNotification message indicating the instantiation of the IPMP
Tool, and its associated context. The requesting tool and the instantiated tool may perform mutual authentication thereafter.
4.4.5.1.1
4.4.5.1.1.1
IPMP_Initialize
Syntax
class IPMP_Initialize()
{
bit(8) controlPointCode;
bit(8) sequenceCode;
ByteArray opaqueData;
}
4.4.5.1.1.2
Semantics:
The IPMP_Initialize class conveys the control point information of the IPMP Tool, including the control point at which
the tool resides, and its sequence in relation to other possible tool contexts residing at that control point.
controlPointCode – specifies the IPMP control point at which the IPMP Tool resides, and is one of the following values:
controlPointCode
Description
0x00
No control point.
0x01
Control Point between the decode buffer and the decoder. This is
between the decode buffer and class loader for MPEG-J streams.
0x02
Control Point between the decoder and the composition buffer.
0x03
Control Point between the composition buffer and the compositor.
0x04
BIFS Tree
0x05-0xDF
ISO Reserved
0xE0-0xFE
User defined
0xFF
Forbidden
sequenceCode - The higher the sequence code, the higher the sequencing priority of the IPMP Tool instance at the
given control point. Thus the tool with the highest sequenceCode for a given control point on a given stream shall process
data first for that control point for that stream. Two tools shall not have the same sequence number at the same control point
for the same stream.
14
ISO/IEC 14496-1:2001/Amd.3
OpaqueData is opaque information that is private data for the given IPMP Tool.
4.4.5.1.2
4.4.5.1.2.1
IPMPToolDescriptorPointer
Syntax
class IPMP_ToolDescriptorPointer extends BaseDescriptor :
bit(8) tag = IPMP_ToolDescrPtrTag
{
bit(16) IPMP_ToolDescriptorID;
}
4.4.5.1.2.2
Semantics:
The IPMP_ToolDescriptorPointer appears in the ipmpToolDescPtr section of an OD or ESD structures.
The presence of this descriptor in an object descriptor indicates that all streams referred to by embedded
ES_Descriptors are subject to protection and management by the IPMP Tool specified in the referenced
IPMP_ToolDescriptor.
The presence of this descriptor in an ES_Descriptor indicates that the stream associated with this descriptor is subject
to protection and management by the IPMP Tool specified in the referenced IPMP_ToolDescriptor.
Each IPMP_ToolDescriptorPointer results in a unique instance of the corresponding IPMP Tool.
4.4.5.1.3 IPMP_ToolDescriptor
4.4.5.1.3.1
Syntax
class IPMP_ToolDescriptor() extends BaseDescriptor : bit(8) tag = IPMP_ToolDescrTag
{
bit(16) IPMP_ToolDescriptorID;
bit(128) IPMP_ToolID;
if (IPMP_ToolID == 0)
ByteArray URLString;
else
{
bit(1) isInitialize;
const bit(7) reserved = 0b0000.000
if(isInitialize)
IPMP_Initialize init;
ByteArray IPMP_data;
}
}
4.4.5.1.3.2
Semantics
The IPMP_ToolDescriptor carries IPMP information for one or more IPMP Tool instances. It shall also contain optional
instantiation information for one or more IPMP Tool instances. IPMP_ToolDescriptors are conveyed in object descriptor
streams via IPMP_ToolDescriptorUpdate commands or as part of the decoder specific information of an IPMP
stream. Multiple definitions of the same IPMP_ToolDescriptor within a single IPMP_ToolDescriptorUpdate command or a
single decoder specific information structure for an IPMP stream are not allowed. The behavior in such a situation is
undefined.
Note that, however, an IPMP_ToolDescriptor may be modified/updated through subsequent
IPMP_ToolDescriptorUpdate commands received in the OD stream. IPMP_ToolDescriptors shall be referenced by object
descriptors or ES_Descriptors, using IPMP_ToolDescriptorPointer.
The behavior of IPMP systems that contains IPMP_Descriptors as defined in 14496-1:2001 (“hybrid” content) is not defined
by this specification.
IPMP_ToolDescriptorID - a unique ID for this IPMP_ToolDescriptor within its name scope. Values of 0x0000 and
15
ISO/IEC 14496-1:2001/Amd.3
0xFFFF are forbidden.
IPMP_ToolID – the IPMP_ToolID of the IPMP Tool described by this IPMP_ToolDescriptor. A zero value does not
correspond to an IPMP Tool but is used to indicate the presence of a URL.
URLString[] - contains a UTF-8 encoded URL that shall point to the location of a remote IPMP_ToolDescriptor. If the
IPMP_ToolID of this IPMP_ToolDescriptor is 0, another URL is referenced. This process continues until an
IPMP_ToolDescriptor with a non-zero IPMP_ToolID is accessed.
isInitialize – if set to ‘1’ this indicates that a new instance of the tool is to be created as indicated in the subsequent
IPMP_Initialize data structure.
init – This contains IPMP Tool initialization information and shall be present if and only if isInitialize is set to ‘1’. Presence
of this data structure indicates that a new instance of the IPMP Tool is to be created, as discussed above, in accordance
with the syntax and semantics for IPMP_Initialize as defined in section 4.4.5.1.1.
IPMP_data - opaque data to control the IPMP Tool. Its size is greater or equal to 0.
4.4.5.1.4
IPMP_ToolDescriptor OD Commands
OD Commands are required as defined below. The corresponding change to the table in 14496-1 that discusses tag values
for BaseCommand is as follows :
Table14496-1 : 3 - List of Class Tags for Commands
4.4.5.1.4.1
Tag value
Tag name
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0C-0xBF
0xC0-0xFE
0xFF
forbidden
ObjectDescrUpdateTag
ObjectDescrRemoveTag
ES_DescrUpdateTag
ES_DescrRemoveTag
IPMP_DescrUpdateTag
IPMP_DescrRemoveTag
ES_DescrRemoveRefTag
IPMP_ToolDescrUpdateTag
IPMP_ToolDescrRemoveTag
Reserved for ISO (command tags)
User private
forbidden
IPMP_ToolDescriptorUpdate
class IPMP_ToolDescriptorUpdate extends BaseCommand :
bit(8) tag=IPMP_ToolDescrUpdateTag
{
IPMP_ToolDescriptor ipmp_ToolDescr[1..255];
}
The IPMP_ToolDescriptorUpdate class conveys a list of new or updated IPMP_ToolDescriptors.
The first IPMP_ToolDescriptor with a given IPMPToolDescriptorID that is received by the Terminal shall have its isInitialized
flag set to true. All following IPMPToolDescriptors with the same IPMPToolDescriptorID shall have their isInitialized flag set
to false. In the latter case the IPMP_ToolDescriptorUpdate command only updates the opaque data field of the
IPMP_ToolDescriptor. Data shall be notified to the associated IPMP tool(s) using the message specified in clause 5.6.2
4.4.5.1.4.2
16
IPMP_ToolDescriptorRemove
ISO/IEC 14496-1:2001/Amd.3
class IPMP_ToolDescriptorRemove extends BaseCommand :
bit(8) tag=IPMP_ToolDescrRemoveTag
{
bit(16) IPMP_ToolDescriptorID[1..255];
}
The IPMP_ToolDescriptorRemove command carries a list of IPMP_ToolDescriptorIDs to be removed from the current
namescope. All IPMP Tools being instantiated through these IPMP_ToolDescriptors shall be terminated.
4.4.5.1.5
4.4.5.1.5.1
IPMPDecoderConfiguration
Syntax
expandable
class
IPMPDecoderConfiguration
tag=DecSpecificInfoTag {
IPMPToolDescriptor ipmpToolDesc[1..255];
}
4.4.5.1.5.2
extends
DecoderSpecificInfo
:
bit(8)
Semantics
The IPMP_DecoderConfiguration is carried in the ESD of an IPMP Elementary Stream. It describes the IPMP Tools
that will be served by messages carried in that stream.
All IPMP_ToolDescriptors defined in the IPMPDecoderConfiguration shall have their isInitialized flag set to one. These
descriptors specify all those IPMP Tool instances that shall be served by the given IPMP stream i.e. the scope of service of
this stream. Any IPMPToolMessage targeting an IPMPToolDescriptor not in the scope of service of the IPMP elementary
stream shall be ignored. All IPMP Tool Messages carried in an IPMP Elementary Stream are addressed to the ID of the
IPMP_Descriptor corresponding to the creation of one or more Tool instances within this scope of service.
4.4.5.1.6
4.4.5.1.6.1
IPMP_StreamDataUpdate
Syntax
aligned(8) expandable(228-1) class IPMP_StreamDataUpdate
{
bit(16) IPMPS_Type;
if (IPMPS_Type == 0)
(
bit(8) URLString[sizeOfInstance-2];
)
else (if (IPMPS_Type == 1)
(
bit(16) IPMP_ToolDescriptorID;
bit(8) IPMP_ExtendedData[sizeOfInstance-4]
} else {
bit(8) IPMP_data[sizeOfInstance-2];
}
}
4.4.5.1.6.2
Semantics
The IPMP_StreamDataUpdate conveys time-varying IPMP information for associated IPMP Tool instances.
IPMPS_Type – The type of the IPMP System, in “Hooks“ compliant Terminals as specified in ISO 14496-1:2001. The
values 0x0002 to 0x2000 are reserved for future ISO use. A Registration Authority, as designated by ISO, shall assign a
unique valid value for this field for a specific IPMP System Type.
URLString[] - contains a UTF-8 [6] encoded URL that shall point to the location of a remote
IPMP_StreamDataUpdate.
IPMP_ToolDescriptorID – this is one of the IPMP_ToolDescriptorIDs in the scope of service of this IPMP Stream
and identifies the recipient(s) of the IPMP_StreamDataUpdate. If the IPMP_ToolDescriptorID is 0, another URL is referenced.
17
ISO/IEC 14496-1:2001/Amd.3
This process continues until an IPMP_StreamDataUpdate with a non-zero IPMP_ToolDescriptorID is accessed.
IPMP_ExtendedData - opaque data to be delivered to the IPMP Tool.
IPMP_data - opaque data to be delivered to the IPMP Tool.
Note: This definition overrides the definition of IPMP_Message in a backward compatible manner.
4.4.5.1.6.3
IPMP Stream Considerations
The IPMP_StreamDataUpdate is backward compatible with the IPMP_Message of ISO/IEC 14496-1 : 2000. However, in
order to unambiguously identify the version of the IPMP stream, the ObjectTypeIndication shall be set to 0x02 for streams
complying with this part of the specification. IPMP Streams complying with ISO/IEC 14496-1:2000 shall use an
ObjectTypeIndication of 0xFF as specified for in 8.6.6.2. A single IPMP Stream shall not carry both IPMP_Messages and
IPMP_StreamDataUpdates.
4.4.6
Information Routing
IPMP Information is routed using normative addressing methods. The addressee of a specific message is implicit either by
bitstream context or by process context. In the MPEG-4 bitstream context, the addressee is the IPMP Tool whose identity is
indicated in the IPMP message or IPMP descriptor header.
Information is delivered at a specific time, specified in the bitstream or implicit by process.
Physical routing of information and context resolution are handled by an entity called the Message Router. The Message
Router abstracts all platform-dependent routing and delivery issues, from the IPMP Tools. The interface between the
Message Router and the Tools, is non-normative and is not defined in this specification. A separate entity called the IPMP
Tool Manager handles the download of IPMP Tools. Both the IPMP Tool Manager and Message Router are conceptual
entities that are integral parts of the Terminal implementation.
4.4.7
Mutual Authentication
At any point in IPMP Information or Content processing, IPMP Tools may be required to communicate with one another or
the Terminal. The degree of security required for such communication is determined by a number of variables including
information that may be included by the content provider in the Content and conditions of trust established between tool
providers a priori and out of band. It is generally the case that a given ES is protected by multiple tools but that certain types
of tools are complex (e.g. Rights Management tools) and others are utilities (e.g. Decryption engines). Complex tools may
control the instantiation of other tools or make decisions about content use in response to usage queries from the terminal.
Mutual authentication may occur between any pair of tools but the level of security required for this communication will in
part be dictated by data contained in the bitstream in an opaque manner. The mechanism for making the determination of
this security level is non- normative.
Mutual authentication is executed as follows:
1. The Tool that initiates mutual authentication with another tool determines the conditions of trust to be achieved by such
authentication, i.e. the initiating tool determines whether it needs integrity protected communication or full secure,
authenticated communication. This level may or may not be dictated by IPMP Information in the Content.
2. The communicating tools then engage in a message exchange to determine which authentication protocol will be used.
In some cases, this protocol will have been determined by an a priori out of band negotiation between the tool providers
in their security audits of one another.
4.4.8
Trust and Security Metadata
The trust relationship is established by out of band relationships between the different entities involved in protecting and
managing the content. The trust metadata that results from such relationships needs to be made available to permit static
and dynamic verification of trust. This data structure encapsulates such information.
Trust and Security Metadata may include zero or more Certificates, credentials or integrity verification information.
18
ISO/IEC 14496-1:2001/Amd.3
4.4.8.1.1
Specification
The trust metadata, if it is present, shall be digitally signed with the private key of the audit agency and be an integral part of
the IPMP system. This metadata shall be expressed in XML and SDL. It shall be verifiable by the terminal without
instantiating any part of the IPMP system.
4.5
XML Schema
4.5.1
Syntax
Textual representation of the above is included in Annex G.
4.5.2
Semantics
The trust metadata described by the above XML schema shall be a component of the XML signature[2] for a given tool or
set of tools.
For each tool referenced by ToolReference, the trust metadata shall consist of either
 The date of audit, AuditDate by the trust auditor
 For each StartDate, the tool, referenced by ToolReference, shall be trusted to protect against the specified
AttackerProfile for the TrustedDuration minutes.
 Attacker profile is defined as class 1, 2, or 3.
Or an alternative, though opaque, means of specifying the trust metadata using Common Criteria (CCTrustMetadata).
4.5.3
DateClass
4.5.3.1
Syntax
class DateClass : {
bit(40) Date;
}
4.5.4
Semantics
This descriptor identifies the date on which the audit took place.
Date – contains the audit date of IPMP tool in question, in Universal Time, Co-ordinated (UTC) and Modified Julian Date
(MJD). This field is coded as 16 bits giving the 16 least significant bits of MJD followed by 24 bits coded as 6 digits in 4-bit
Binary Coded Decimal (BCD). If the audit date is undefined all bits of the field are set to 1.
4.6
4.6.1
TrustSecurityMetadata
Syntax
19
ISO/IEC 14496-1:2001/Amd.3
Abstract expandable class TrustSecurityMetadata :
{
bit(16) numTrustedTools;
for (int I=0; I<numTrustedTools; I++)
{
bit(128)
toolID;
DateClass
AuditDate;
bit(16)
numTrustSpecification;
for (int i=0; i<numTrustSpecification; ++i)
{
bit (1)
hasCCBasedTrustMetadata;
const bit(7) reserved = 0b0000.000;
if (!hasCCBasedTrustMetadata) {
DateClass
startDate;
bit(2)
attackerProfile;
const bit(6) reserved = 0b0000.00;
bit(32)
trustedDuration;
} else {
ByteArray
CCTrustMetadata;
}
}
}
}
4.6.2
Semantics
For numTrustedTools referenced by IPMPToolDescriptor, the trust metadata for each tool consists of either
the date of audit, AuditDate by the trust auditor
For each of numTrustSpecification, the tool shall be trusted as of startDate , to protect against the specified AttackerProfile
for the TrustedDuration minutes.
Or an alternative, though opaque, means of specifying the trust metadata using Common Criteria contained in
CCTrustMetadata.
Attacker profile is defined as class I, II, or III where;
0x00
0x01
0x02
0x03
0x04 – 0x0F
0x10 – 0xFE
0xFF
4.7
forbidden
Class I
Class II
Class III
User defined
ISO reserved
forbidden
Permission for Content Consumption
Permission for processing a given stream shall be received from each tool connected to any control point in the given
stream. Processing of content shall not proceed until this permission is received. Permission may also be terminated at
any time by any of the mentioned tools at which time processing of the given stream shall stop.
Permission is granted in true-false form by each IPMP Tool. Any pre-conditions that the user is required to satisfy are
checked, ensured and obtained in a non-normative manner.
20
ISO/IEC 14496-1:2001/Amd.3
4.8
Tool Manager
The IPMP Tool Manager is a conceptual entity in a given IPMP Terminal. Upon receipt of the Tool List, the IPMP Tool
Manager parses the IOD for Tool retrieval. The Tool Manager also processes parametric descriptions, resolves alternative
tools, and receives binary Tools that arrive in the Content.
The following steps detail the process of parsing and retrieval of Tools in an MPEG-4 Terminal.
1.
2.
3.
4.
The IPMP Tool List arrives in the IOD and is processed by the Tool Manager.
The Tool Manager parses information for the IPMP Tools as per the syntax in clause 2.2.2.1.
The Tool Manager checks if the required Tools are available.
The Tool Manager is also responsible for parsing the IPMP Tool ESD and retrieving the binary IPMP Tool that is
carried inside IPMP Tool ES. Thus the IPMP Tool Manager acts as an ES decoder for IPMPToolStreams.
The IPMP Tool Manager is further responsible for resolving parametric descriptions and loading associated information in
the Message Router as defined in clause 4.4.3.1.1
4.8.1.1
Obtaining Missing Tools
Obtaining missing tools is one of the functions of the Tool Manager. Missing IPMP Tools are either contained within the
Content or require external retrieval. The platform and implementation details of the Terminal are critical to choosing a
compatible implementation of the IPMP Tool. The XML schema in Annex C is normative for such representation.
5
Messaging Infrastructure
5.1
Introduction
This clause provides specifications for the following components of the IPMP Tool Interaction Framework:
1. Interaction (or communication) between Terminal and IPMP Tool(s), realized via “messaging” between the Terminal
and IPMP Tools.
2. The messages (syntax and semantics)
3. The process of message routing
All IPMP Tool interactions take place via the Terminal. IPMP Tools do not communicate directly with each other within the
scope of the standard.
5.1.1
Message Router
All IPMP Tool Messages are routed through the Terminal. To represent this function, an entity called the Message Router
(MR) is defined in the architecture. The MR connects and communicates with supported IPMP Tool(s). It thus abstracts the
physical interface of one IPMP Tool from any other IPMP Tool that wishes to communicate with it. Message Routing is
assumed to be instantaneous. In case of an MR error, an appropriate error status is returned by the MR. In all other cases,
the MR is required to route, without a change in semantic meaning, information and responses as received.
5.1.2
Addressing
The tool instance ID is 32-bits long and assigned by the terminal (or tool manager) based on the
IPMP_ToolDescriptorPointer that causes the creation of the given Tool instance. Information regarding the location of the
IPMP_ToolDescriptorPointer, i.e. either the ES_ID (if it occurs in an ESD) or the OD_ID (if it occurs in the OD) is referred to
as context data. Messages are defined for Tools to obtain a toolInstanceID based on context data and vice versa. The value
0x00 for a tool instance ID is always reserved for the Terminal.
5.2
5.2.1
IPMP_ToolMessageBase
Syntax
Aligned(8) expandable(228-1)class IPMP_ToolMessageBase{
bit(8) Version;
bit(32) Msg_ID;
21
ISO/IEC 14496-1:2001/Amd.3
bit(32) sender;
bit(32) recipient;
}
5.2.2
Semantics
IPMP_ToolMessageBase is an expandable base class for IPMP Tool Messages. The extension tags are defined in Table
4.
Version indicates the version of syntax used in the messages and shall be set to 0x01.
Msg_ID is a message identifier specified by the message originator. All messages sent in response to a message shall
include the identifier of the original message.
Sender indicates the context ID of the originator of the message. The value 0x00 is reserved for the terminal.
Recipient indicates the context ID of the intended recipient of the message. 0x00 is reserved for the terminal.
Table 4 - Tags for messages extending IPMP_ToolMessageBase
8-bit Tag Value
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11
0x12
0x13
0x14
0x15
0x16
0x17 – 0xCF
0xD0 – 0xFE
0xFF
5.3
Symbolic Name
Forbidden
IPMP_Tool_Secure_Message_tag
IPMP_MessageFromBitstream_tag
IPMP_ToolDescriptorFromBitstream_tag
IPMP_AddToolNotificationListener_tag
IPMP_RemoveToolNotificationListener_tag
IPMP_InitAuthentication_tag
IPMP_MutualAuthentication_tag
IPMP_KeyDescr_tag
IPMP_ToolToUserMessage_tag
IPMP_AlgorithmDescr_tag
IPMP_UserToToolMessage_tag
IPMP_ToolParamCapabilitiesQuery_tag
IPMP_ToolParamCapabilitiesResponse_tag
IPMP_SelectiveDecryptionMessage_tag
IPMP_AudioWatermarkingInit_tag
IPMP_SendAudioWatermark_tag
IPMP_GetTools_tag
IPMP_GetToolsResponse_tag
IPMP_GetContext_tag
IPMP_GetToolContextResponse_tag
IPMP_ConnectTool_tag
IPMP_DisconnectTool_tag
ISO Reserved
User Defined
Forbidden
IPMP_ToolSecureMessage
5.3.1
Syntax
class IPMP_SecureToolMessage extends IPMP_ToolMessageBase
: bit(8) tag = IPMP_Tool_Secure_Message_tag
{
bit(1)
hasEncryption;
bit(1)
hasMAC;
bit(1)
isMACEncrypted;
const bit(5) reserved=0b0000.0;
if(hasEncryption)
ByteArray
22
encryptedData;
ISO/IEC 14496-1:2001/Amd.3
if(hasMAC && !isMACencrypted) {
ByteArray MAC;
}
}
else {
IPMP_ToolMessageBase
if(hasMAC) {
ByteArray
}
protectedMsg;
MAC;
}
}
5.3.2
Semantics
This forms a secure container for any other IPMP_Tool_Message that is derived from IPMP_Tool_Message_Base. The
payload message is optionally encrypted. The MAC allows verification of the integrity of the protectedMsg, and is optionally
encrypted. isMACEncrypted is not explicitly carried in the secure message, but is negotiated as part of an external
authentication mechanism, as is the key and algorithm for creating and verifying the MAC, and decrypting the encrypted
payload.
No Encryption w/ MAC
MSG
TYPE
EXPANDABLE SIZE
VER
MSG ID
MSG
TYPE
ENC
MAC
1 OCTET
EXPANDABLE SIZE
PROTECTED
MESSAGE
VER
MSD ID
MAC
SIZE
MAC
MSG TYPE-SPECIFIC
DATA
w/ Encryption and MAC (not encrypted)
MSG
TYPE
EXPANDABLE SIZE
VER
MSG ID
ENC
MAC
1 OCTET
ENCRYPTED DATA
SIZE
ENCRYPTED BLOB
MAC
SIZE
MAC
w/ Encryption and MAC (encrypted)
MSG
TYPE
5.4
EXPANDABLE SIZE
VER
MSG ID
ENC
MAC
1 OCTET
ENCRYPTED DATA
SIZE
ENCRYPTED BLOB
Instantiation and Notification Messages
These messages are used to instantiate new Tools, inform newly instantiated Tools of existing Tools, and to notify existing
Tools of a new instantiation.
5.4.1
5.4.1.1
IPMP_GetTools
Syntax
class IPMP_GetTools extends IPMP_ToolMessageBase :
bit(8) IPMP_ToolMessageType = IPMP_GetTools_tag
{
}
5.4.1.2
Semantics
Message IPMP_GetTools allows a tool to find all the Tools available on the terminal.
5.4.1.3
Response
23
ISO/IEC 14496-1:2001/Amd.3
IPMP_GetToolsResponse.
5.4.2
5.4.2.1
IPMP_GetToolsResponse
Syntax
class IPMP_GetToolsResponse extends IPMP_ToolMessageBase:
bit(8) tag = IPMP_GetToolsResponse_tag
{
bit(16) toolCount;
bit(128) IPMP_ToolID[toolCount];
}
5.4.2.2
Semantics
Each IPMP_ToolID is the identifier of a Tool. Parametric tools are assigned a temporary unique IPMP_ToolID by the terminal.
5.4.2.3
Response
None required
5.4.3
5.4.3.1
IPMP_GetToolContext
Syntax
class IPMP_GetToolContext extends IPMP_ToolMessageBase :
bit(8) IPMP_ToolMessageType = IPMP_GetContext_tag
{
bit(1) hasToolDescriptorID;
bit(1) hasObjectDescriptorID;
bit(1) hasES_ID;
const bit(4) reserved = 0b0000.00;
if (hasToolDescriptorID)
bit(16) IPMP_ToolDescriptorID;
else if (hasES_ID)
bit(16) ES_ID;
else if (hasObjectDescriptorID) {
bit(10) objectDescriptorID;
const bit(6) reserved = 0b0000.00;
}
}
5.4.3.2
Semantics
Message IPMP_GetToolContext allows a tool to find a particular Tool Context within a specified scope.
IPMP_ToolDescriptorID, the IPMP_ToolDescriptorID of the IPMP_ToolDescriptor in which the Tool is described.
IPMP_ES_ID, the ES_ID of the ES_Descriptor in which the Tool Context is described.
ObjectDescriptorID - the ObjectDescriptorID of the ObjectDescriptor in which the given IPMP_ToolDescriptorPointer is
declared.
Note, an IPMP_ToolDescriptorID is only returned for the exact scope that was requested, i.e. if the scope of OD is
requested, contained ESs containing tools are not considered.
5.4.3.3
Response
IPMP_GetToolContextResponse.
5.4.4
5.4.4.1
IPMP_GetToolContextResponse
Syntax
class IPMP_GetToolContextResponse extends IPMP_ToolMessageBase:
bit(8) tag = IPMP_GetToolContextResponse_tag
{
bit(32) IPMP_ToolContextID;
}
24
ISO/IEC 14496-1:2001/Amd.3
5.4.4.2
Semantics
IPMP_ToolContextID - is the identifier of the tool Context. A null value indicates that this context does not exist.
5.4.4.3
Response
None required.
5.4.5 IPMP_ConnectTool
5.4.5.1
Syntax
class IPMP_ConnectTool extends IPMP_ToolMessageBase :
bit(8) IPMP_ToolMessageType = IPMP_ConnectTool_tag
{
IPMP_ToolDescriptor toolDescriptor;
}
5.4.5.2
Semantics
Message IPMP_ConnectTool allows a tool to create a new Tool Context.
toolDescriptor - contains a tool descriptor to be used for determining scope and location of new tool context to be connected.
The Terminal shall link the new Tool Context to the specified control point, if specified, before it responds to this message.
5.4.5.3
Response
IPMP_NotifyToolEvent with an eventType of “CONNECTED” or an eventType of “CONNECTIONFAILED”.
5.4.6
5.4.6.1
IPMP_DisconnectTool
Syntax
class IPMP_DisconnectTool extends IPMP_ToolMessageBase :
bit(8) IPMP_ToolMessageType = IPMP_DisconnectTool_tag
{
bit(32) IPMP_ToolContextID;
}
5.4.6.2
Semantics
Message IPMP_DisconnectTool allows a tool to disconnect a tool it has previously connected at a control point.
IPMP_ToolContextID is the ID of the Tool Context to be disconnected.
5.4.6.3
Response
IPMP_NotifyToolEvent - with an eventType of “DISCONNECTED” or an eventType of “DISCONNECTIONFAILED”.
5.4.7
5.4.7.1
IPMP_ToolConnectNotification
Syntax
class IPMP_ToolConnectNotification extends IPMP_ToolMessageBase:
bit(8) tag = IPMP_ToolConnectNotification_tag
{
bit(32) IPMP_ToolContextID;
bit(1) toolConnected;
const bit(7) reserved = 0b000000.00;
}
5.4.7.2
Semantics
IPMP_ToolContextID - is the identifier of the tool Context.
toolConnected - indicates whether the specified IPMP_ToolContextID is currently connected or not.
25
ISO/IEC 14496-1:2001/Amd.3
0x00
0x01
Disconnected
Connected
Note : In the case of toolConnected being “0x00“, the IPMP_ToolContextID is only informative and can not be addressed.
5.4.7.3
Response
None required.
5.5
Event Notification Messages
5.5.1
5.5.1.1
IPMP_AddToolNotificationListener
Syntax
class IPMP_AddToolNotificationListener extends IPMP_ToolMessageBase :
bit(8) tag = IPMP_AddToolNotificationListener_tag
{
bit(8) eventTypeCount;
bit(8) eventType[eventTypeCount];
}
5.5.1.2
Semantics
Message IPMP_AddToolNotificationListener allows an existing IPMP Tool running on the terminal to request notification any
defined event at the terminal.
eventType – Type of event for which the sender shall receive notifications for and defined by the following table.
5.5.1.3
0x00
CONNECTED
0x01
CONNECTIONFAILED
0x02
DISCONNECTED
0x03
DISCONNECTIONFAILED
Response
None required.
5.5.2
5.5.2.1
IPMP_RemoveToolNotificationListener
Syntax
class IPMP_RemoveToolNotificationListener extends IPMP_ToolMessageBase :
bit(8) IPMP_ToolMessageType = IPMP_RemoveToolNotificationListener_tag
{
bit(8) eventTypeCount;
bit(8) eventType[eventTypeCount];
}
5.5.2.2
Semantics
Message IPMP_RemoveToolNotificationListener allows an existing IPMP Tool running on the terminal to terminate the
receipt of a previous registered event listener. If an eventTypeCount of “0” is present, all previously registered event types
shall be unregistered.
5.5.2.3
Response
None required.
26
ISO/IEC 14496-1:2001/Amd.3
5.5.3
IPMP_NotifyToolEvent
5.5.3.1
Syntax
class IPMP_NotifyToolEvent extends IPMP_ToolMessageBase :
bit(8) tag = IPMP_NotifyToolEvent_tag
{
bit(8) eventType;
IPMP_ToolContextID toolContextID;
}
5.5.3.2
Semantics
Message IPMP_NotifyToolEvent notifies an IPMP Tool of a tool event for which it had previous registered as a listener.
toolContextID – the IPMP_ToolContextID of the tool either connected or disconnected, or the failed state of either, as
indicated by the eventType.
5.5.3.3
Response
None required.
5.6
IPMP Information Delivery Functions
These messages facilitate delivery of IPMP Information from the Content that is delivered to the Tools specified by the
information syntax.
5.6.1
5.6.1.1
IPMP_MessageFromBitstream
Syntax
class IPMP_MessageFromBitstream extends IPMP_ToolMessageBase :
bit(8) tag = IPMP_MessageFromBitstream_tag
{
bit(8) numMessages;
IPMP_StreamDataUpdate message[numMessages];
}
5.6.1.2
Semantics
Message IPMP_MessageFromBitstream is used to deliver IPMP_StreamDataUpdates received in the Content to the IPMP
Tool context specified in the IPMP_StreamDataUpdate. If an IPMP Access Unit delivered in the IPMP Elementary Stream
contains more than one IPMP_StreamDataUpdate for a specific IPMP Tool, all IPMP_StreamDataUpdate for that tool will be
included in a single IPMP_MessageFromBitstream message.
numMessages - the number of IPMP_StreamDataUpdate’s contained in the message.
message[] - an array of IPMP_StreamDataUpdate’s, the syntax for which is defined in clause 4.4.5.1.6.
5.6.1.3
Response
None required.
5.6.2
5.6.2.1
IPMP_ToolDescriptorFromBitstream
Syntax
class IPMP_ToolDescriptorFromBitstream extends IPMP_ToolMessageBase :
bit(8) tag = IPMP_ToolDescriptorFromBitstream_tag
{
IPMP_ToolDescriptor toolDescriptor;
}
5.6.2.2
Semantics
27
ISO/IEC 14496-1:2001/Amd.3
Message IPMP_ToolDescriptorFromBitstream is used to deliver an IPMP_ToolDescriptor received in the bitstream
to the IPMP Tool specified in the IPMP_ToolDescriptor.
toolDescriptor - the IPMP_ToolDescriptor received in the bitstream.
5.6.2.3
Response
None required.
5.7
Consumption Permission
This message enables the notification of the Terminal, by IPMP tools, as to the tools ability to begin or discontinue,
processing content.
5.7.1
IPMP_CanProcess
5.7.1.1
Syntax
class IPMP_CanProcess extends IPMP_Message_Base:
bit(8) tag = IPMP_CanProcess_tag
{
bit(1) canProcess;
bit(7) reserved = 0b0000.000;
}
5.7.1.2
Semantics
canProcess – used to indicate to the receiver of the message that the sender is able to begin processing data or must
discontinue processing.
0x0
0x1
5.8
DISCONTINUE
BEGIN
User Interaction Messages
These messages allow information to be exchanged between the User and a Tool using the Terminal implementation’s
interface resources.
5.8.1
5.8.1.1
ToolToUserMessage
Syntax
class Tool_User_Message extends IPMP_Message_Base:
bit(8) tag = IPMP_ToolToUserMessage_tag
{
bit(1)
inclDisplayTitle;
bit(1)
inclDisplayText;
bit(1)
needReplyText;
bit(1)
inclOptionSelect;
bit(1)
inclSMIL;
const bit(3)
reserved = 0b000;
bit(24)
numOfAltText;
int i;
for(i=0; i< numOfAltText; i++)
{
bit(24)
languageCode;
if (inclDisplayTitle) {
ByteArray titleText;
}
if (inclDisplayText) {
bit(16)
numOfDisplayText;
DTArray
displayText[numOfDisplayText];
}
if (needReplyText) {
28
ISO/IEC 14496-1:2001/Amd.3
bit(16)
RTArray
}
if
numOfPromptText;
promptText[numOfPromptText];
(inclOptionSelect) {
bit(16)
numOfOptions;
OptionArray
option[numOfOptions]
}
if (inclSMIL) {
bit(1)
const bit(7)
isReferenced;
reserved = 0b0000.000;
if (isReferenced){
ByteArray
SMIL_URL;
}
else {
ByteArray
SMIL;
}
}
}
}
5.8.1.2 Semantics:
languageCode– Contains the ISO 639-2:1998 [1] bibliographic three character language code of the corresponding
audio/speech or text object that is being described.
titleText : Title of dialog display.
displayText : Text to be displayed to the user.
needReplyText : Text expected back from the user.
promptText : Text to be displayed to the end user to indicate purpose of text input field, i.e. “User ID”, “Password”, “PIN”,
etc.
inclOptionSelect : An option, true/false, input is needed from the user.
isExclusive : If more than one option is associated with a given display text, this indicates mutual exclusivity of options.
optionText : Text to be displayed indicating purpose of option selection, i.e. “One month purchase”, “One time play”,
“Render at 1024/768”, etc.
SMIL_URL : Fully qualified location of SMIL file to be displayed.
SMIL : SMIL file to be displayed.
5.8.1.1.1
ByteArray
class ByteArray
{
unsigned long(32)
bit(8)
}
5.8.1.1.2
DTArray
class DTArray
{
bit(16)
ByteArray
}
5.8.1.1.3
ID;
displayText;
RTArray
class RTArray
{
bit(16)
bit(16)
ByteArray
}
5.8.1.1.4
SizeOfArray;
Data[SizeOfArrary + 1];
ID;
SubID;
promptText;
OptionArray
class OptionArray
{
bit(1)
isExclusive;
29
ISO/IEC 14496-1:2001/Amd.3
const bit(7) reserved = 0b0000.000;
bit(16)
ID;
bit(16)
SubID;
ByteArray
promptText;
}
Semantics:
IsExclusive : When set to ‘1’, this implies a mutually exclusive condition of the option selector.
ID : A serial number to be associated with the contained data or to associate contained data with other data.
SubID : A serial number to associate items within an ID group.
SizeOfArray : The size in bytes of the data contained in the field Data.
Data : Characters to be displayed.
5.8.1.2
Response
UserToToolMessage
5.8.2
UserToToolMessage
5.8.2.1
Syntax
class aligned (8)User_Tool_Message extends IPMP_Message_Base:
bit(8) tag = IPMP_UserToToolMessage_tag
{
bit(1)
inclReplyText;
bit(1)
inclOptionSelect;
const bit(6)
reserved = 0b0000.00;
bit(24)
languageCode;
if (inclReplyText) {
bit(16)
numOfReplyText;
RTArray
ReplyText[numOfReplyText];
}
if
(inclOptionSelect) {
bit(16)
numOfOptions;
bit(numOfOptions)
for (i=0; i<numOfOptions; i++)
{
bit(1) optionResult;// 0b1 = TRUE, 0b0 = FALSE;
}
}
}
5.8.2.2
Semantics
replyText : Text entered by user. Only fields with entered text need be included. If the original request contained reply text
fields but the terminal does not support text input then an inclReplyText of “0b0“ would indicate so.
optionResult : Identical semantics and rules as with replyText except that all options must be represented and in the
order they were initially specified.
5.8.2.3
Response
None Required.
5.9
Mutual Authentication Messages
These messages facilitate the process of mutual authentication.
5.9.1
5.9.1.1
IPMP_InitAuthentication
Syntax
class IPMP_InitAuthentication extends IPMP_Message_Base:
bit(8) tag = IPMP_InitAuthentication_tag
{
bit (16)
Context;
30
ISO/IEC 14496-1:2001/Amd.3
bit (8)
AuthType;
}
5.9.1.2
Semantics
Context is the 16-bit Context ID of the logical instance of the Tool with which mutual authentication is to be performed.
AuthType has the following values.
Value of AuthType
0x00
0x01
0x02
0x03
0x04
0x05-0xFE
0xFF
5.9.1.3
Semantic Meaning
Forbidden
No Authentication Required
No ID verify, Do secure channel
Do ID verify, No secure channel
Do ID verify, Do secure channel
ISO Reserved
Forbidden
Response
IPMP_Mutual_Authentication.
5.9.2
5.9.2.1
IPMP_Mutual_Authentication
Syntax
class IPMP_Mutual_Authentication extends IPMP_Message_Base
: bit(8) tag=IPMP_MutualAuthentication_tag;
{
bit (1)
requestNegotiation;
bit (1)
successNegotiation;
bit (1)
failedNegotiation;
bit (1)
inclAuthenticationData
bit (1)
inclAuthCodes;
const bit (3) reserved = 0b000;
{
if (requestNegotiation) {
unsigned int
nCandidate;
AlgorithmDesciptor
candidateAlgorithms[nCandidate];
}
if (successNegotiation)
unsigned int
nAlgorithms;
AlgorithmDescriptor agreedAlgorithms[nAlgorithms];
if (inclAuthenticationData) {
ByteArray
AuthenticationData
}
if (inclAuthCodes) {
unsigned int
type;
if (type == 0x01) {
unsigned int nCertificate;
unsigned int certType;
Certificate
certificates[nCertificate];
} elseif (type == 0x02) {
KeyDescriptor publicKey;
} elseif (type == 0xFE) {
ByteArray
opaque;
}
ByteArray
authCodes;
}
}
31
ISO/IEC 14496-1:2001/Amd.3
5.9.2.2
Semantics
An instance of IPMP_Mutual_Authentication is generated by and exchanged between IPMP tools, and IPMP Tools and a
Terminal for the purpose of mutual authentication.
inclAuthCodes – if this flag is set, authentication codes for the current message are specified.
type – specifying the type of the authentication codes. Semantics of each value for this variable is defined as follows
Value of Type
0x00:
0x01
Semantics
No information regarding the type is explicitly specified.
The value specified in the variable authCodes is digital signature. One or more
SPKI certificates or X.509 V3 certificates, depending on the value of certType are
specified as a method to verify the signature in the variable certificates[].
0x02
The value specified in the variable authCodes is a digital signature. At the same
time, a public key accompanied by algorithm specification is specified as a
method to verify the signature.
0x03 – 0xDF
ISO Reserved
0xE0 – 0xFD
User Private
0xFE
Application-dependent information regarding the type is specified in the variable
opaque.
0xFF
Forbidden
certificates [] – specifies data of one or more certificates. The certificate type is determined by the value of certType.
This variable is specified, only when the variable type specifies 0x01.
publicKey – specifies a cryptographic public key accompanied by algorithm specification. This variable is specified, if the
variable type specifies 0x02.
opaque – specifies an application-dependent method to verify the authentication codes. This variable is specified if the
variable type specifies 0xFE.
authCodes – specifies authentication codes to this message. Note that data to be signed excludes data beginning at the
type specification of the AuthCodes.
requestNegotiation – indicates that the originator is requesting negotiation about an authentication method to be used in
the subsequent communication.
candidateAlgorithms – specifies a list comprised of one or more
algorithm identifiers of candidate authentication
methods. The originator of the IPMP_Mutual_Authentication message shall specify identifiers of algorithms and/or protocols
that it supports. The recipient of this message shall select ones out of the list to fulfill the requirements, which the recipient
IPMP tool supports. The recipient sends another IPMP_Mutual_Authentication message such that agreedAlgorithm
specifies the identification of the selected algorithms and/or protocols. If the recipient cannot find algorithms and/or
protocols that it supports in the list, it returns an IPMP_Mutual_Authentication message specifying a 0b1 for
failedNegotiation. The syntax of AlgorithmDescriptor is provided in [5.11].
Note : When the field candidateAlgorithms contains algorithms of mutual authentication that support the generation of a
shared secret, additional algorithm identifiers are listed to support the negotiation of message encryption, and message
authentication. The purpose of each algorithm included will be implicit from its functionality. i.e. if DES is a candidate
algorithm it is assumed it is specified for message encryption/decryption.
Additional Note : For algorithms that support a number of options within one algorithm such as AES supporting a number of
block lengths and key lengths, only one configuration will be specified for a given identifier or registration authority listed ID.
Additionally padding requirements and solutions will be included in the identifiers and Ids as well.
inclAuthenticationData – when set to ‘1’, this implies that the message contains method specific data used during
mutual authentication.
AuthenticationData – specifies data to be used for mutual authentication and whose value depends on method specific
processing. This variable exists only when the flag inclAuthenticationData is set.
5.9.2.3
32
Response
ISO/IEC 14496-1:2001/Amd.3
IPMP_Mutual_Authentication, until authentication is successful.
5.10 Key Descriptor
5.10.1 Syntax
class KeyDescriptor extends AlgorithmDescriptor :
bit(8) tag = IPMP_KeyDescr_tag
{
ByteString keyBody;
}
5.10.2 Semantics
This class is for specifying a cryptographic algorithm and a key conforming to the algorithm.
keyBody – the body of the key. The value shall be data that conforms to a rule for data structure of the key defined outside
of this document.
Example – If an encryption algorithm is RSA, the value of this parameter shall be the BER encoded data which conforms to
PKCS#1.
RSAPublicKey ::=
SEQUENCE {
modulus
INTEGER, -- n
publicExponent
INTEGER -- e
}
5.11 AlgorithmDescriptor
5.11.1 Syntax
class AlgorithmDescriptor extends BaseIPMPDescriptor:
bit(8) IPMPMessagePurpose = IPMP_AlgorithmDescr_tag {
bit (1)
isRegistered;
const bit (7)
reserved = 0b0000.000;
if (isRegistered) {
bit (16)
regAuthID;
}
else {
ByteArray
specAlgoID;
}
ByteArray OpaqueData;
}
5.12 Semantics
This class is for specifying an identifier of an arbitrary algorithm.
isEnumerated – a 0b1 indicates the ID included is a normative identifier of the algorithm. A 0b0 indicates the algorithm is
identified by an ID assigned by a registration authority
enumeratedAlgoID – a normative identifier of the algorithm.
Note : to be made normative outside the scope of this
specification.
regAuthID – a identifier of the algorithm as assigned by a registration authority.
SpecAlgoID –
SpecAlgoID Value
Symbol
Content
Confidentiality
Integrity
33
ISO/IEC 14496-1:2001/Amd.3
0x0001
DH-G-H-x-y
0x0002
EDH-G-H-x-y
0x0003
DH-G-E-H-x-y-z
0x0004
EDH-G-E-H-x-y-z
0x0005
RSA-OAEP-H-x
0x0006
RSA-OAEP-E-H-x-z
0x0007
SCHNRR- G-x-y
0x0008-0x00FF
0x0100-0x01FE
0x01FF-0xFFFF
ISO Reserved
User Defined
Forbidden
Diffie-Hellman Key Agreement Scheme
on a base group G. The parameter
setting of the both parties is specified in
certificates.
Ephemeral
Diffie-Hellman
Key
Agreement Scheme on a base group G.
Both parties are assumed to agree on
the base group G, and each party is
supposed to generate ephemeral
parameters (a public key pair) for the
purpose of authentication and the
parameters are submitted being signed
by the party. A certificate of the party is
used for the opponent party to verify the
signature.
DH-G-H-x-y being used in combination
with a symmetric key cipher algorithm E.
EDH-G-H-x-y being used in combination
with a symmetric key cipher algorithm E.
Needham-Schroeder Scheme deploying
RSA-based OAEP as the public key
encryption.
RSA-OAEP-H-x
being
used
in
combination with a symmetric key cipher
algorithm E.
Schnorr Identification Scheme on a base
group G.
No
Yes
No
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
No
For use by registration authority
In the above table, the significance of the variables is as follows:
Variable
G
E
H
x
y
z
Definition
Specifies the type of a base group (e.g. a sub-groups of an elliptic curve)
Specifies a symmetric key cipher algorithm to realize confidentiality of messages.
Specifies a hash function to realize message integrity.
Specifies a size of a base group (e.g. the length in bits of the base field of an elliptic curve).
Specifies a size of a base group (e.g. the length in bits of the order of a base group).
Specifies the length in bits of keys of a symmetric key cipher to be used in conjunction.
Remark. The actual cryptographic scheme is constructed on a proper sub-group instead of being constructed on an entire
elliptic curve or an entire multiplicative group of a finite field. Further, the order of the base sub-group shall be a prime
number, and its length is specified to be y bits. This value of y influences the strength of the scheme against the PohligHellman method, which finds out solutions to DLP on arbitrary groups.
5.12.1 Generation of a MAC
In the case where a value is specified for the variable H, if either or both of the parties require the functionality of message
integrity, MAC (Message Authentication Code) is attached to messages. Usage of a MAC as part of the message is
optional. MAC is generated based on the hash function specified by the variable H and the shared secret being used a key
to generate MAC. Actually, MAC is generated in accordance with the following formula.
MAC = H(H(Shared_Secret)| Message | H(Shared_Secret))
5.12.2 Generation of Keys for Message Encryption
Keys of a symmetric key cipher to be used between the parties are generated from the secret shared by the parties through
the authentication procedures. For example, in the case that the key length is specified as 56 bits, the write_key_A, which
the party A uses to encrypt messages, is generated by the following formula.
write_key_A =
34
TRUNC(56, SHA-1(100_LSBits_Of_Secret | “WRITE” | ID_Of_A | Rest_Of_Secret))
ISO/IEC 14496-1:2001/Amd.3
ID_Of_A is defined as the byte data with value 0 if Party A is the initiator of the communication, whilst it is the byte data with
value 0xFF otherwise.
5.13 Parametric Messages
5.13.1 IPMP Tool Parametric Capabilities Query
5.13.1.1 Syntax
class IPMP_ToolParamCapabilitiesQuery extends IPMP_ToolMessageBase
: bit(8) tag = IPMP_ToolParamCapabilitiesQuery_tag
{
IPMPToolParametricDescriptor toolParamDesc;
}
5.13.1.2 Semantics
This message allows a terminal to query a tool as for support for a specific parametric description. The contents of the
message are the actual tool parametric descriptor that would be contained in the tools list.
toolParamDesc: The parametric description of the capability being queried.
5.13.1.3 Response
IPMP_ToolParamCapabilitiesResponse.
5.13.2 IPMP Tool Parametric Capabilities Query Response
5.13.2.1 Syntax
class IPMP_ToolParamCapabilitiesResponse extends IPMP_ToolMessageBase
: bit(8) tag = IPMP_ToolParamCapabilitiesResponse_tag
{
bit(1) capabilitiesSupported;
const bit(7) reserved = 0b0000.000;
}
5.13.2.2 Semantics
This message is the response to the above parametric capabilities query and simply returns a boolean value as to whether
or not the parametric description is supported by the tool.
capabilitiesSupported: If this bit is set to ‘1’, this implies that the tool does support the parametric description queried
in the preceding message. If set to ‘0’ this implies that the tool does not support the parametric description.
5.13.2.3 Response
None required.
35
ISO/IEC 14496-1:2001/Amd.3
Annex A
Selective Decryption Configuration Message
(Normative)
The selective decryption configuration message is used to communicate to the decryptor, how the encryption of the received
content bitstream is encrypted, whether all bits are encryption or only portions of the received bits are encrypted. In the case
when only portions of the received bits are encrypted, what portions of the received are encrypted and therefore need to be
decrypted.
A.1 IPMP_SelectiveDecryptionMessage
A1.1 Syntax
class IPMP_SelectiveDecryptionMessage extends IPMP_ToolMessageBase
: bit(8) tag = IPMP_SelectiveDecryptionMessage_tag;
{
bit(8) mediaTypeExtension;
bit(8) mediaTypeIndication;
bit(8) profileLevelIndication;
bit(8) compliance;
bit(8) numBufs;
for(i=0, i<numBufs; i++)
Struct bufInfoStruct {
bit(128) cipher_Id;
bit(8) syncBoundary;
bit(1) isBlock;
const bit(7) reserved = 0b0000.000;
if(isBlock) {
bit(8) mode;
bit(16) blockSize;
bit(16) keySize;
} else {
Struct Stream_Cipher_Specific_Init_Info;
}
}
}
bit(1) isContentSpecific;
const bit(7) reserved = 0b0000.000;
if(isContentSpecific) {
bit(8) numFields;
for(i=0, i< numFields; i++) {
Struct fieldStruct {
bit(8) field_Id;
bit(3) field_Scope;
const bit(5) reserved = 0b0000.000;
bit(8) buf;
bit(1) isMapped;
const bit(7) reserved = 0b0000.000;
if(isMapped){
bit(1) sendMapTable;
bit(1) isShuffled;
const bit(6) reserved = 0b0000.000;
if(sendMapTable){
bit(16) sizeMapTable;
bit(16) mappingTable[sizeMapTable]
}
if(isShuffled){
36
ISO/IEC 14496-1:2001/Amd.3
Struct Shuffle_Specific_Info shuffleSpecificInfo;
}
}
}
}
} else {
bit(16) nSegments;
bit(16) RLE_Data[nSegments]
}
}
A.1.2 Semantics
This message allows a terminal to configure a selective decryption tool.
mediaTypeExtension: extends mediaTypeIndication below; The following values are defined.
mediaTypeExtension
0x00
0x01
0x02 – 0xCF
0xD0 – 0xFE
0xFF
Semantics
ISO/IEC
ITU
ISO Reserved
User Defined
Forbidden
mediaTypeIndication: indication of format definition, e.g., MPEG-4 or MPEG-2 etc.; example values could be those of
objectTypeIndication in 8.6.6 of [1].
profileLevelIndication: indication of profile/level
visualProfileLevelIndication in 8.6.4 of [1].
of
mediaTypeIndication;
example
values
could
be
those
of
compliance: level of compliance to the compression format, i.e, the smallest logical unit in the encrypted bitstream that are
correctly recognizable/parsable by the media decoder. For any non-compliant stream, the decryption tool will need to know
what marker emulation prevention mechanism was deployed by the encryption tool. The method to emulation prevention is
out of scope of this definition. The following values are defined.
Compliance
0x00
0x01
0x02
0x03
0x04
0x05-2F
0x30
0x31
0x32 – 0x5F
0x60 – 0xCF
0xD0 – 0xFE
0xFF
Semantics
fully compliant for video
compliant to video packet level for video
compliant to VOP level for video
non-compliant for video
Compliant to GOB level for H.263 baseline
ISO Reserved for video
compliant to data frame level for AAC audio
non-compliant for AAC audio
ISO Reserved for audio
ISO Reserved
User Defined
Forbidden
numBufs: number of buffers needed to hold data to be decrypted separately. The cipher text will be de-multiplexed into
different buffers for separate decryption.
bufInfoStruct: a structure holding information needed for each buffer
cipher_Id: type of decryption algorithm used, e.g. , DES, 3DES, AES etc., registered through an RA.
37
ISO/IEC 14496-1:2001/Amd.3
syncBoundary: this field provides the tool information on what shall be considered a “unit of cipher-text”. Bits from different
cipher-text unit are decrypted separately. The following values are defined.
syncBoundary
0x00
0x01
0x02
0x03-2F
0x30
0x31 – 0x5F
0x60 – 0xCF
0xD0 – 0xFE
0xFF
Semantics
Video packet for video
VOP (AU) for video
GOV for video
ISO Reserved for video
Data frame for AAC audio
ISO Reserved for audio
ISO Reserved
User Defined
Forbidden
isBlock: block or stream cipher.
mode: mode of block cipher, e.g., CBC, ECB, CFB, OFB, etc., registered through an RA [Annex E].
blockSize: block size, in bytes, used for the block cipher
keySize: key size, in bytes, used for the block cipher.
cipher_specific_init_info: normative initialization information if a stream cipher is specified by the cipher_Id.
The above data structures are for representing information pertaining to the buffers used for the decryption process. Below
is information pertaining to the fields chosen for decryption.
isContentSpecific: a value of 0b1 indicates that the selective decryption is based on the selection of the fields. Otherwise
RLE_Data will specify a collected range of the bitstream selected for decryption, using run length coding of this range
information.
numFields: number of fields to be selected for decryption, e.g., MV, DC, DCTsign, Dquant, etc.
fieldStruct: a structure holding information about the fields chosen for decryption
field_Id: index of field based on a predefined list for the given syntax. The following values are defined.
field_Id
0x00
0x01
0x02
0x03
0x04
Semantics
Motion vector (MV) for video
DC coefficients for video
DCT sign bits for video
Quantization parameter Dquant for video
DCT coefficients for video
0x05
All fields ie. All bits in a “unit of cipher text”
0x06-2F
0x30
0x31
0x32
0x32 – 0x5F
0x60 – 0xCF
0xD0 – 0xFE
0xFF
ISO Reserved for video
Sign bits for AAC audio
Run-length codewords for AAC audio
Scale factors for AAC audio
ISO Reserved for audio
ISO Reserved
User Defined
Forbidden
field_scope: represented in three bits, i.e., b2b1b0. A value of 0b1 for b2, b1, and b0 indicates that this field in I, P, and B
VOPs, respectively, is selected and put into the buffer that it is associated with.
38
ISO/IEC 14496-1:2001/Amd.3
buf: which buffer this field will be put into.
isMapped: a value of 0b1 indicates that the codewords of a specific field will be mapped, using a mapping table, to an index
which is then subject to decryption.
sendMapTable: a value of 0b1 indicates that the mapping table mappingTable will follow. Otherwise, the default mapping of
the codeword table defined in the media format definition (e.g. MPEG4 video specification) is used.
sizeMapTable: size, number of entries of the mapping table.
mappingTable: entries of the mapping table. MappingTable[i] indicates that the ith codeword in the codeword table defined
in the media format definition is mapped to the index of MappingTable[i].
isShuffled: a value of 0b1 indicates the mapped index sequence will be shuffled using a shuffling table specified in
Shuffle_Specific_Info.
nSegments: number of disjoint segments that have been generated to signify which segments are selected for decryption
RLE_Data: specifies the number of bits that are to be decrypted or skipped interleavingly, starting from the first segment that
is to be decrypted. If the first segment is not to be decrypted, then the value of the first entry shall be zero.
A.2 An example of a selective decryption configuration message (Informative)
One good example of using parametrically configured tools is a configurable selective encryption framework for securing
MPEG-4 video content.
It is recognized that for some applications, simplistic, direct application of encryption to content bitstreams poses many
problems, most often due to the lack of syntactic structure of the result. The complexity of encrypting the entire content
bitstream can also be prohibitive for both very high bit rate content and low power devices. Selective encryption solves both
of these problems, the latter due to the reduced complexity associated with only encrypting a portion of the stream and the
former by designing the encryption method such that it results in a format compliant, yet encrypted stream. To achieve
format compliance, the tool extracts bits from the fields that have been chosen for encryption, concatenates them in an
appropriate way, encrypts the concatenation with a chosen cipher appropriate for the application, and then puts the
encrypted bits back into their original positions. To maintain compliance, a fixed length index is assigned to each codeword
in the VLC code table, and instead of encrypting the code word concatenation, the index concatenation is encrypted, and
then the encrypted index concatenation is mapped back to codeword. Any pattern resulting from the encryption of index
concatenation can be mapped back to a compliant codeword concatenation. FLC coded fields are treated as special cases
of VLC, where the code length does not vary.
In MPEG IPMP extensions, the goal to define a standardized messaging interface between the tools and the terminal
provides for an important functionality, namely that of a single configurable tool that could support a wide range of
requirements and could be configured to apply only the subset of those that a particular application specified. Using the
guidelines for field selection and tools for encrypting VLC in a syntax compliant way, this section illustrates an example of a
selective decryption configuration message. It shall be noted that in designing these messages, it is assumed that the
framework is intended to be applied to MPEG-4 video.
An example of a message is defined here that could be used to configure a format-compliant, selective decryption tool that
implemented the method described above. The for-loops are unrolled, but the for-loop syntax is there so it is clear that
repetition of various fields was a result of the logic in the data structures. This particular example message tells the
decryption tool that it is working with a compliant bit stream. The tool will need two buffers, both of which will use DES as
the decryption algorithm in CBC mode with a block size of 64 and a key length of 64. The fields will be grouped on a video
packet basis. The fields involved will be MV, DC, DCT sign, and Dquant. The latter three are inserted into a buffer using
the values that they take on in the bit stream, while the MVs are mapped to a set of 64 indices (known by the tool) and those
are inserted in a separate buffer.
Syntax field name
Syntactic
Value
Semantic value
Bits
39
ISO/IEC 14496-1:2001/Amd.3
mediaTypeExtension
mediaTypeIndication
(visual)profileLevelIndication
compliance
numBufs
/* For(i=0;i<numBufs;i++) */
/* numBufs=2 */
/* buffer 0: motion vectors */
cipher_Id
syncBoundary
isBlock
if(isBlock==1) {
mode
blockSize
keySize
}
0
32
3
0
2
ISO/IEC MPEG set
Visual ISO/IEC 14496-2
Simple Profile @ Level 1
Bit-level compliant
2 buffers
8
8
8
8
8
0
0
1
DES
Video packet
Block cipher
128
8
1
1
64
64
CBC
64
64
8
16
16
0
0
1
DES
Video packet
Block cipher
128
8
1
1
64
64
CBC
64
64
8
16
16
1
4
Based on the selection of the fields
4 fields for decryption
1
8
0
2
0
1
0
0
0 (MV)
encrypt MVs for P frames
0 (mv buff)
mapped
no shuffle of the index
don’t send mapping
8
3
8
1
1
1
/* i=1, DC */
field_Id
field_scope
buf
isMapped
1
6
1
0
1 (DC)
encrypt DCs for I and P frames
1 (other buffer)
not mapped
8
3
8
1
/* i=2, DCT sign */
field_Id
field_scope
buf
isMapped
2
6
1
0
2 (DCT sign)
encrypt DCT signs for I and P frames
1 (other buffer)
not mapped
8
3
8
1
/* i=3, Dquant */
field_Id
field_scope
buf
isMapped
3
6
1
0
3 (Dquant)
encrypt Dquants for I and P frames
1 (other buffer)
not mapped
8
/* i=1 buffer 1: DCT information
buffer */
cipher_Id
syncBoundary
isBlock
if(isBlock==1) {
mode
blockSize
keySize
}
}
IsContentSpecific
numFields
/* For(i=0;i<numFields;i++) *//*
numFields = 4 */
/* i=0, MV */
field_Id
field_scope
buf
isMapped
isShuffled
sendMapTable
}
40
8
1
ISO/IEC 14496-1:2001/Amd.3
Annex B
Use of IPMP DecoderConfigInformation
(Informative)
This is an informative annex, details the use of DecoderConfigInformation for media streams controlled only by an IPMP
stream, the recipient IPMP Tool(s) are not known, and hence cannot be instantiated, until a message addressed to that Tool
is received in the stream. The walkthroughs below indicate the implications of this problem. The first walkthrough illustrates
the process of the terminal associating a media stream with an IPMP system when only IPMP descriptors are used. The
second walkthrough goes through the same process when only IPMP streams are used.
B.1 IPMP Descriptor Example
CONTROL POINT
8
MEDIA
DB
3
OD
DB
MEDIA
DECODE
11
9
IOD
1
4
10
OD
DECODE
2
5
IPMP TOOLS LIST
TOOLS MANAGER
MESSAGE ROUTER
2
5
6
7
9
10
IPMP TOOL
Figure 3 - Flowchart for Protection with IPMP Descriptors only
The above diagram illustrates the process of the terminal receiving the IPMP tools list all the way through instantiating the
tools and sending the appropriate media streams to the tools. Each step in the process in numbered accordingly and is
described in the following paragraph. For simplicity, a single media stream and a single OD stream are depicted. Details on
the BIFS stream and the process of the terminal opening connections with the server are left out for clarity.
1.
2.
3.
4.
An IPMP Descriptor Pointer is received in the OD Stream.
The terminal instantiates the necessary IPMP tool.
The terminal receives an AU on the OD stream.
The terminal parses the OD AU to get the ESD for the media stream and any IPMP streams. In this case, the OD
contains a single media ES descriptor and a single IPMP descriptor pointer as in the figure above. A subsequent
OD command would contain the IPMP Descriptor.
At this point, the terminal associates the media from the ES descriptor to the IPMP system referenced by the IPMP
descriptor.
The terminal sends the IPMP descriptor to the IPMP tool.
The terminal contacts the tool to tell it that it will be receiving data from the particular elementary stream and also to find out
at which control point the tool is residing for that stream.
1. The tool returns the control point at which it is residing for the particular elementary stream.
2. Media access units are received by the terminal
3. The terminal routes the AUs to the IPMP tool based on the control point(s) for that elementary stream.
4. The tool returns the processed media.
5. The terminal continues with decoding the content.
The above walkthrough works just fine for ODs that contain only IPMP descriptor pointers. When the OD only contains ES
descriptors for an IPMP stream, this process breaks, as illustrated in the following walkthrough illustrates this.
41
ISO/IEC 14496-1:2001/Amd.3
B.2 IPMP Stream Example
CONTROL POINT
11
8
MEDIA
DB
7
IPMP
DB
3
OD
DB
MEDIA
DECODE
IPMP
DECODE
9
10
7
IOD
1
4
OD
DECODE
2
4
IPMP TOOLS LIST
TOOLS MANAGER MESSAGE
ROUTER
2
5
6
7
9
10
IPMP TOOL
Figure 4 - Flowchart for Protection with IPMP Streams only
The above diagram again illustrates the process of the terminal receiving the IPMP tools list all the way through instantiating
the tools and sending the appropriate media streams to the tools. This is again a simplified example that only utilizes a
single media stream, the OD stream, and now a single IPMP stream. Details on the BIFS stream are left out just for clarity
purposes. Details on the BIFS stream and the process of the terminal opening connections with the server are left out for
clarity.
1. The terminal receives an AU on the OD stream.
2. The terminal parses the OD AU to get the description of the media stream and any IPMP systems. In this case, the
OD contains a single media ES descriptor and a single ES descriptor for an IPMP stream as shown in the figure
above.
At this point, the terminal shall be able to associate the media from the ES descriptor to the IPMP system referenced by the
ES descriptor of the IPMP stream. Unless the Terminal knows, a priori, the IPMP Systems, there is no way for the terminal
to know which IPMP tool to send the information to. This is because the IPMPTool ID is not identified in the ES descriptor,
only in messages the IPMP elementary stream. In the latter case, the following steps cannot occur.
1. The terminal sends the ES descriptor for the IPMP stream to the IPMP tool and tells it that it will be receiving data
from the particular elementary stream and also to find out at which control point the tool is residing for that stream.
2. The tool returns the control point at which it is residing for the particular elementary stream.
3. IPMP access units are received by the terminal and are routed to the appropriate IPMP tool.
4. Media access units are received by the terminal
5. The terminal routes the AUs to the IPMP tool based on the returned control point.
6. The tool returns the processed media.
7. The terminal continues with decoding the content.
Thus, the tools cannot be instantiated until IPMP AUs are received at the terminal, which is inconsistent with the normal
decoder operation that enables decoder instantiation prior to opening of a stream.
42
ISO/IEC 14496-1:2001/Amd.3
Annex C
Schema for Terminal Platform
(Normative)
The XML schema for terminal platform specification supports the specification of CPU, memory, Operating system, virtual
machine, etc. Two possible applications within the IPMP scope are:

Based on the terminal platform XML schema, an IPMP terminal can describe what it is, what the CPU is, what the
operating system is, whether there are any assistant hardwares, etc. The IPMP terminal can send the information to the
remote site while trying to retrieve a missing IPMP tool. The remote site, after receiving the information, and XML schema
parsing, can then decide which tool (a windows DLL or a Java Byte Code, for example) to send.

Based on the terminal platform XML schema, an IPMP tool can also describe on what platform it can run, and carry the
information in the metadata associated with the IPMP tool, or in the Tool ESD associated with a Tool ES. When receiving
such an IPMP tool, an IPMP terminal can decide whether this tool can run on it.
Figure 5 - Schema for Platform Representation
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.0 beta 1 build Jun 13 2001 (http://www.xmlspy.com) by Ji Ming (Panasonic Singapore Laboratories Pte Ltd)
-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xsd:element name="TerminalID">
<xsd:annotation>
<xsd:documentation>Identification of a terminal</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
43
ISO/IEC 14496-1:2001/Amd.3
<xsd:element name="TerminalType">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Vendor" type="xsd:string"/>
<xsd:element name="Model" type="xsd:string"/>
<xsd:element name="SerialNO" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="OperatingSystem">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Vendor" type="xsd:string"/>
<xsd:element name="Model" type="xsd:string"/>
<xsd:element name="Version" type="xsd:string"/>
<xsd:element name="SerialNO" type="xsd:string" minOccurs="0"/>
<xsd:element name="VirtualMachine" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Vendor" type="xsd:string"/>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="Version" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CPU">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Vendor" type="xsd:string"/>
<xsd:element name="Model" type="xsd:string"/>
<xsd:element name="Speed" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Memory">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Vendor" type="xsd:string"/>
<xsd:element name="Model" type="xsd:string"/>
<xsd:element name="Size" type="xsd:integer"/>
<xsd:element name="Speed" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="AsstHardware" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SmartCard" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Vendor" type="xsd:string"/>
<xsd:element name="Model" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="HardKey" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Type" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
44
ISO/IEC 14496-1:2001/Amd.3
</xsd:element>
<xsd:element name="Network" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Type" type="xsd:string"/>
<xsd:element name="Details" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="RPCMechanism" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Type" type="xsd:string"/>
<xsd:element name="Details" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="Type" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
45
ISO/IEC 14496-1:2001/Amd.3
Annex D
Schema for Parametric Description
(Normative)
The parametric description is defined to allow a generic description of any type of IPMP tool, whether it is a decryption tool or a
watermarking tool or a rights management tool.
Based on the parametric description XML schema, the content provider can now describe what type of tool is required to
playback the content, instead of using fixed tool IDs. For example, the content provider can specify that an AES tool, with block
size of 128 bits is required to decrypt video stream. The IPMP terminal, upon receiving such XML language specifying this tool,
can then choose an optimised AES tool from the embedded tools.
Some of the elements are defined below:
CLASS : class of the parametrically described tool, for example, decryption.
SUBCLASS : sub-class of the parametrically described tool, for example, AES under decryption class.
TYPEDATA : specific type data to describe a particular type of tool, for example, Block_length, to further specify a AES
decryption tool
TYPE (attribute) : value of the type data above, for example, 128 for the Block_length.
ADDITIONAL_DATA : Any additional data which may help to further describe the parametrically defined tool.
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.0 beta 1 build Jun 13 2001 (http://www.xmlspy.com) by JimmyJi (Panasonic Singapore Laboratories Pte Ltd) -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xsd:element name="PARAMETRIC_DESCRIPTION">
<xsd:annotation>
<xsd:documentation>Comment describing your root element</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="VERSION">
<xsd:complexType>
<xsd:attribute name="MAJOR_VERSION" type="xsd:string"/>
<xsd:attribute name="MINOR_VERSION" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="CLASS" type="xsd:string"/>
<xsd:element name="SUBCLASS" type="xsd:string"/>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="TYPEDATA" maxOccurs="unbounded">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:anySimpleType">
<xsd:attribute name="type" type="xsd:anySimpleType"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="type" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="ADDITIONAL_DATA" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
46
ISO/IEC 14496-1:2001/Amd.3
Annex E
List of Registration Authorities
(Normative)
This specification requires registration authorities for the following :
1. The IPMP_ToolID for a specific implementation of an IPMP Tool.
2. The implemented API (including the instantiation, initialization and termination mechanisms) for an IPMP Tool and
Terminal on a given platform (see 3 below).
3. The platform information about an IPMP Tool in the Content
4. The packaging information about an IPMP Tool in the Content.
5. Certificate Type and format of Certificates
6. Algorithm ID and algorithm modes
47
ISO/IEC 14496-1:2001/Amd.3
Annex F
Illustration of Use and Scope of IPMP Descriptors and Declarators
(Normative)
These scenarios indicate how different configurations of IPMP protection may be indicated for MPEG-4 content, and how it
shall be interpreted. Different instances of tools are identified by their ToolInstanceID. ToolInstanceIDs are uniquely mapped
to the OD_ID, possible ES_ID, and Descriptor or Declarator ID that caused the instantiation of the Tool.
OD UPDATE
OD=A
IPMP UPDATE
OD=B
IPMP DSCR=E
ESD=C
ESD=D
AUDIO
VIDEO
IPMP PTR
IPMP PTR
TOOL ID
CONTEXT ID=A_F
AUDIO
DB
DEC
VIDEO
DB
DEC
INITIALIZ
IPMP DSCR=F
TOOL ID
INITIALIZ
CONTEXT ID=B_E
This is the base case for IPMP Descriptors. An IPMP Descriptor Pointer in an OD points to a given IPMP Descriptor. One
corresponding instance of that IPMP Tool is created. Note that the IPMP Descriptor contains the initialize information, and
the context is determined by the OD_ID that holds the descriptor pointer and the ID of the IPMP Descriptor.
OD UPDATE
OD=A
ESD=C
IPMP UPDATE
OD=B
ESD=D
AUDIO
IPMP PTR
VIDEO
IPMP DSCR=G
TOOL ID
INITIALIZ
ESD=E
IPMP DECL=F
CONTEXT ID=A_G
AUDIO
DB
DEC
VIDEO
DB
DEC
INITIALIZ
CONTEXT ID=BEF
This is a base case where a presentation uses both Descriptor and Declarator based protection. Since the IPMP Declarator
F does not depend on another IPMP Descriptor, it therefore contains IPMP_Initialize information that causes instantiation of
a new instance of the Tool (context BEF). In the case that a Declarator causes instantiation, the context of the Tool is
mapped to the OD_ID of the object (B) that holds the IPMP Stream, the ID of the IPMP Stream itself (E) and the ID of the
IPMP Declarator (F). The ESID of the media streams being protected have no bearing on the context ID of the Tool.
OD UPDATE
OD = A
IPMP UPDATE
OD=B
ESD=C
ESD=D
AUDIO
VIDEO
IPMP PTR
IPMP PTR
IPMP DSCR=E
TOOL ID
INITIALIZ
CONTEXT ID=A_E
AUDIO
DB
DEC
VIDEO
DB
DEC
CONTEXT ID=B_E
IPMP Descriptor Pointers in two independent objects may point to the same IPMP Descriptor. This results in two separate
intances of the same Tool, one for each object. Both instances receive data from the Descriptor, and any Descriptor
Updates. Both instances are terminated when Descriptor E is removed. Only instance A_E is removed if the Descriptor
Pointer in OD A is removed, and only instance B_E is removed if the Descriptor Pointer in OD B is removed.
48
ISO/IEC 14496-1:2001/Amd.3
CONTEXT ID=AEF
OD UPDATE
OD=A
ESD=C
AUDIO
OD=B
AUDIO
DB
DEC
VIDEO
DB
DEC
ESD=D
VIDEO
ESD=E
ESD=E
IPMP DECL=F
IPMP DECL=F
INITIALIZ
INITIALIZ
CONTEXT ID=BEF
IPMP
DB
MR
An Elementary Stream having more than one independent object reference must have identical ESDs. In this case, the
same IPMP Elementary Stream (with ESD E) is being referenced from OD A and OD B. The stream E is created only once.
However, two separate instances of the corresponding IPMP Tool are created, one for object A and one for object B. Both
these instances receive any information in the Declarator and any IPMP messages addressed to that Declarator in stream
E. Both instances are terminated when stream E is removed. Only AEF is removed if the ESD for E is removed from OD A.
Only BEF is removed if the ESD for E is removed from OD B.
CONTEXT ID=AEG
OD UPDATE
OD=A
ESD=C
AUDIO
OD=B
CONTEXT ID=AEF
AUDIO
DB
DEC
VIDEO
DB
DEC
ESD=D
VIDEO
ESD=E
ESD=E
IPMP DECL=F
IPMP DECL=F
INITIALIZ
INITIALIZ
IPMP DECL=G
IPMP DECL=G
INITIALIZ
INITIALIZ
CONTEXT ID=BEG
CONTEXT ID=BEF
IPMP
DB
MR
CONTEXT ID=AEG
OD UPDATE
OD=A
ESD=C
AUDIO
OD=B
ESD=D
VIDEO
ESD=E
ESD=F
IPMP DECL=G
IPMP DECL=H
INITIALIZ
INITIALIZ
AUDIO
DB
DEC
VIDEO
DB
DEC
CONTEXT ID=BFH
IPMP
DB
MR
IPMP
DB
This is the base case for IPMP Declarators. An OD contains the only reference to a given IPMP ESD, whose
DecoderConfigInfo contains the Declarator, and one corresponding instance of that IPMP Tool is created.
49
ISO/IEC 14496-1:2001/Amd.3
CONTEXT ID=A_J
OD UPDATE
OD=A
ESD=C
IPMP UPDATE
OD=B
ESD=D
AUDIO
VIDEO
IPMP DSCR=I
DEC
VIDEO
DB
DEC
TOOL ID
INITIALIZ
ESD=E
ESD=F
IPMP DECL=G
IPMP DECL=H
TOOL ID
SERVES
SERVES
INITIALIZ
IPMP PTR
AUDIO
DB
IPMP DSCR=J
CONTEXT ID=B_I
IPMP
DB
IPMP PTR
MR
IPMP
DB
This is a base case for an object that contains an IPMP Stream, one of whose Declarator depends on an IPMP Descriptor
referenced by an IPMP Descriptor Pointer in the same OD as the IPMP ESD belongs to.
OD UPDATE
IPMP UPDATE
CONTEXT ID=A_G
OD=A
ESD=C
AUDIO
OD=B
IPMP DSCR=G
ESD=D
VIDEO
ESD=E
ESD=E
IPMP DECL=F
IPMP DECL=F
SERVES
SERVES
IPMP PTR
TOOL ID
AUDIO
DB
DEC
VIDEO
DB
DEC
INITIALIZ
CONTEXT ID=B_G
IPMP PTR
IPMP
DB
MR
If the same IPMP stream (E) is used across diferent objects, its decoder config info in both objects (A and B) must be
identical. Hence, if a Declarator (F) within the ESD in one object (A) is dependent on a Descriptor (G), then the same
Declarator in the other object must indicate similar dependence. Thus, both objects must carry an IPMP Descriptor Pointer
to the same IPMP Descriptor. Two instances are created in response to the two descriptor pointers, hence their contexts are
identified by the OD_ID and the IPMP_DID. Both instances are populated with data from the same descriptor, and from the
same declarator. Note that in this case, the IPMP Descriptor contains IPMP_Initialize information.
CONTEXT ID=AEG
OD UPDATE
OD=A
ESD=C
AUDIO
IPMP UPDATE
OD=B
ESD=D
VIDEO
ESD=E
ESD=F
IPMP DECL=G
IPMP DECL=H
INITIALIZ
SERVES
IPMP PTR
IPMP DSCR=I
AUDIO
DB
DEC
VIDEO
DB
DEC
TOOL ID
INITIALIZ
CONTEXT ID=B_I
IPMP
DB
MR
IPMP
DB
This case indicates the difference between instances that come from an independent IPMP Declarator and IPMP Declarator
that depends upon an IPMP Descriptor (via an IPMP Descriptor Pointer in the same OD as its ESD). In the case of object A,
IPMP stream E is specified to serve the Tool described by Declarator G. G is meant to cause a new instance of an IPMP
Tool, and hence contains the IPMP_Initialize data structure. Any opaque information in G is carried to the Tool instance
50
ISO/IEC 14496-1:2001/Amd.3
AEG, as are any IPMP Messages addressed to G that appear in stream E. No other means of populating AEG with
information is available. Removal of G from the ESD (or removal of stream E altogether) causes termination of this instance.
In the case of object B, IPMP Declarator H serves the instance of the Tool (B_I) created by the IPMP Descriptor Pointer in B
that references IPMP Descriptor I. Hence, it does not contain IPMP_Initialize information. B_I receives data from H and any
messages addressed to H via IPMP Stream F. However, it also receives data from I and any updates to I. Removal of
Declarator H or stream F does not cause Termination of B_I. Removal of I or the IPMP Pointer that references I causes
Termination of B_I and any subsequent messages received for H via stream F will have an invalid recipient address.
CONTEXT ID=AEG
OD UPDATE
OD=A
ESD=C
AUDIO
IPMP UPDATE
OD=B
ESD=D
VIDEO
ESD=E
ESD=F
IPMP DECL=G
IPMP DECL=H
INITIALIZ
INITIALIZ
IPMP DSCR=I
AUDIO
DB
DEC
VIDEO
DB
DEC
CONTEXT ID=BFH
CONTEXT ID=B_I
TOOL ID
INITIALIZ
IPMP
DB
IPMP PTR
MR
IPMP
DB
It is possible for both an IPMP Descriptor and an independent IPMP Declarator (note the IPMP_Initialize structure within
Declarator H) to protect the same stream. In this case, the tools instantiated by these structures work independently to
protect the stream. If they occur at the same control point, their sequence numbers determine the order in which they
receive data for processing.
CONTEXT ID=AEG
OD UPDATE
OD=A
ESD=C
AUDIO
OD=B
ESD=D
VIDEO
ESD=E
ESD=F
IPMP DECL=G
IPMP DECL=H
INITIALIZ
INITIALIZ
IPMP PTR
CONTEXT ID=A_I
IPMP UPDATE
IPMP DSCR=I
AUDIO
DB
DEC
VIDEO
DB
DEC
CONTEXT ID=BFH
CONTEXT ID=B_I
TOOL ID
INITIALIZ
IPMP
DB
IPMP PTR
MR
IPMP
DB
Extending on the case above, two independent instances of the Tool described by IPMP Descriptor I are created. Instance
B_I works in a determinate order with instance BFH, and instance A_I works in a determinate order with instance AEG.
CONTEXT ID=AEG
OD UPDATE
OD=A
ESD=C
AUDIO
IPMP UPDATE
OD=B
ESD=D
VIDEO
IPMP DSCR=I
INITIALIZ
ESD=F
IPMP DECL=G
IPMP DECL=H
TOOL ID
INITIALIZ
INITIALIZ
INITIALIZ
IPMP PTR
DEC
VIDEO
DB
DEC
CONTEXT ID=BFH
CONTEXT ID=B_I
TOOL ID
ESD=E
IPMP PTR
CONTEXT ID=A_J
AUDIO
DB
IPMP DSCR=J
IPMP
DB
MR
IPMP
DB
This is yet another possible variation of the above scenario, where are IPMP Tools being used are of independent types.
51
ISO/IEC 14496-1:2001/Amd.3
IPMP UPDATE
OD UPDATE
OD=B
OD=A
ESD=C
AUDIO
ESD=E
ESD=D
VIDEO
IPMP DSCR=H
TOOL ID
CONTEXT ID=AEG
CONTEXT ID=AEF
AUDIO
DB
DEC
VIDEO
DB
DEC
INITIALIZ
IPMP PTR
IPMP DECL=F
CONTEXT ID=B_H
INITIALIZ
IPMP DECL=G
INITIALIZ
IPMP
DB
MR
If two IPMP Declarators are contained in the ESD of an IPMP Elementary Stream, the instances created to serve these will
work in determinate order to manage and protect the media stream. IPMP_Intialize information describes which control
points they are active at. If they serve the same control point, this information additionally provides an unambiguious
sequencing order at a given control point. Relative sequencing orders is nondeterministic at different control points.
OD UPDATE
OD=A
IPMP UPDATE
OD=B
ESD=C
AUDIO
IPMP PTR
ESD=D
VIDEO
IPMP PTR
IPMP DSCR=E
INITIALIZ
INITIALIZ
IPMP DSCR=G
IPMP PTR
CONTEXT ID=A_G
AUDIO
DB
DEC
VIDEO
DB
DEC
CONTEXT ID=B_E
CONTEXT ID=B_F
IPMP DSCR=F
TOOL ID
IPMP PTR
CONTEXT ID=A_E
TOOL ID
TOOL ID
INITIALIZ
This is a similar case, but where more than one tool instances that are created via IPMP Descriptor Pointers protect the
same streams. Similar considerations to the case above hold here as well.
OD UPDATE
OD=A
CONTEXT ID=ADE
ESD=B
VIDEO-BL
ESD=C
VIDEO-EL
ESD=D
IPMP DECL=E
VIDEOBL DB
DEC
VIDEOEL DB
IPMP
DB
MR
INITIALIZ
This demonstrates scoping issues where an IPMP Tool is created by an OD that contains more than one media stream. If
these media streams are not dependent on each other, then MPEG-4 Systems states that only one of the streams will be
instantiated, and the cases revert to those discussed above. If the streams are one base layer and other enhancement
layers, then only one tool instance is created to service all streams. For any control points for the Tool that occur prior to
decoding, each access unit from each stream is sent to the Tool for data processing. Subsequent to decoding, the
combined data from these streams is sent to the Tool for data processing. Permissions for each stream shall be
independently queried for the same Tool for processes that occur before decoding.
52
ISO/IEC 14496-1:2001/Amd.3
OD UPDATE
IPMP UPDATE
OD=A
IPMP DSCR=G
TOOL ID
ESD=B
INITIALIZ
VIDEO-BL
IPMP PTR
ESD=C
CONTEXT ID=ABG
VIDEOBL DB
IPMP DSCR=H
TOOL ID
VIDEO-EL
DEC
INITIALIZ
VIDEOEL DB
IPMP PTR
CONTEXT ID=ACH
ESD=D
IPMP DECL=E
IPMP
DB
SERVES
MR
IPMP DECL=F
SERVES
The case above illustrates the use of more than one IPMP Tool in an OD that contains more than one dependent media
streams.
The following scenarios of usage are illegal because they violate one or more syntactical conditions, from 14496-1:2000,
from this specification, or both.
Two streams with single IPMP stream and different serves descriptors – not allowed
OD UPDATE
OD
IPMP UPDATE
OD
ESD
VIDEO
TOOL ID
NO INIT
ESD
ESD
IPMP DECL
IPMP DECL
TOOL ID
INITIALIZ
SERVES
INITIALIZ
IPMP PTR
DEC
VDEO
DB
DEC
IPMP
DB
MR
IPMP DSCR
ESD
AUDIO
AUDIO
DB
IPMP DSCR
IPMP PTR
AUDIO
DB
DEC
VIDEO
DB
DEC
IPMP
DB
MR
Two streams with multiple IPMP streams and different serves descriptors – not allowed
OD UPDATE
OD
IPMP UPDATE
OD
ESD
AUDIO
DEC
VIDEO
DB
DEC
IPMP
DB
MR
IPMP DSCR
ESD
VIDEO
TOOL ID
INITIALIZ
ESD
ESD
IPMP DECL
IPMP DECL
TOOL ID
INITIALIZ
INITIALIZ
INITIALIZ
IPMP DECL
IPMP DECL
INITIALIZ
INITIALIZ
IPMP PTR
AUDIO
DB
IPMP PTR
IPMP DSCR
AUDIO
DB
DEC
VIDEO
DB
DEC
IPMP
DB
MR
Two streams initialized through single IPMP stream with two separate descriptors not used for initialization – not allowed
53
ISO/IEC 14496-1:2001/Amd.3
OD UPDATE
IPMP UPDATE
OD
OD
ESD
IPMP DSCR
ESD
AUDIO
TOOL ID
NO INIT
VIDEO
ESD=A
ESD=A
IPMP DECL
IPMP DECL
TOOL ID
INITIALIZ
INITIALIZ
NO INIT
IPMP PTR
IPMP DSCR
IPMP PTR
DB
DEC
DB
DEC
IPMP
DB
MR
Two streams with single IPMP stream and different serves descriptors – not allowed
OD UPDATE
OD
IPMP UPDATE
OD
ESD
VIDEO
TOOL ID
NO INIT
ESD
ESD
IPMP DECL
IPMP DECL
TOOL ID
INITIALIZ
SERVES
INITIALIZ
IPMP PTR
DEC
VDEO
DB
DEC
IPMP
DB
MR
IPMP DSCR
ESD
AUDIO
AUDIO
DB
IPMP DSCR
IPMP PTR
AUDIO
DB
DEC
VIDEO
DB
DEC
IPMP
DB
MR
AUDIO
DB
DEC
VDEO
DB
DEC
IPMP
DB
MR
Two streams with single IPMP stream with one serves descriptor – not allowed
OD UPDATE
OD
IPMP UPDATE
OD
ESD
AUDIO
DEC
VIDEO
DB
DEC
IPMP
DB
MR
IPMP DSCR
ESD
VIDEO
ESD=A
ESD=A
IPMP DECL
IPMP DECL
INITIALIZ
SERVES
IPMP PTR
54
AUDIO
DB
TOOL ID
INITIALIZ
ISO/IEC 14496-1:2001/Amd.3
Annex G:
Trust Model XML Schema
(Normative)
G.1 Trust Model Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="TrustSpecification">
<xs:annotation>
<xs:documentation> IPMP trust model specification
schema</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="TrustSpecificationType">
<xs:attribute/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="TrustSpecificationType">
<xs:sequence>
<xs:element name="ToolReference" type="ToolReferenceType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ToolReferenceType">
<xs:sequence>
<xs:element name="AuditDate" type="xs:date"/>
<xs:element name="TrustInfo" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="TrustInfoType">
<xs:choice>
<xs:sequence>
<xs:element name="StartDate"
type="xs:date"/>
<xs:element name="AttackerProfile"
type="AttackerProfileType"/>
<xs:element name="TrustDuration"
type="xs:int"/>
</xs:sequence>
<xs:element name="CCTrustMetadata"
type="xs:unsignedByte" maxOccurs="unbounded"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="URI" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="TrustInfoType"/>
<xs:simpleType name="AttackerProfileType">
<xs:restriction base="xs:positiveInteger">
55
ISO/IEC 14496-1:2001/Amd.3
<xs:maxInclusive value="3"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
56
ISO/IEC 14496-1:2001/Amd.3
Annex H:
Watermarking Configuration and Notification Messages
(Normative)
This annex details two new messages for audio watermarking. The IPMP_AudioWatermarkingInit message is sent to a
Watermarking Tool in order to intialise the process of insertion/extraction of the watermarking payload into/from an audio
stream. The Watermarking Tool receives the audio stream and in case of watermarking extraction, replies with an
IPMP_SendAudioWatermark message carrying the watermarking payload .
These messages are also extended to provide means for facilitating audio watermarking technologies capable not only for
insertion/extraction but also for remarking and perhaps the most important, distinguishing between legal from illegal audio
material.
H.1 IPMP_AudioWatermarkingInit
H.1.1 Syntax
class IPMP_AudioWatermarkingInit extends IPMP_ToolMessageBase :
bit(8) tag = IPMP_AudioWatermarkingInit_tag
{
bit(8) inputFormat;
bit(4) requiredOp;
bit(1) hasOpaqueData;
const bit(3) reserved = 0b000;
if (inputFormat == PCM)
{
bit(8) nChannels;
bit(8) bitPerSample;
bit(32) frequency;
}
if ((requiredOp == INSERT_WM)||(requiredOp == REMARK_WM))
{
bit(16) wmPayloadLen;
bit(8) wmPayload[wmPayloadLen];
}
if ((requiredOp == EXTRACT_WM)||(requiredOp == DETECT_COMPRESSION))
{
bit(16) wmRecipientId;
}
if (hasOpaqueData)
{
bit(16) opaqueDataSize;
bit(8) opaqueData[opaqueDataSize];
}
}
H.1.2 Semantics
The IPMP_AudioWatermarkingInit message delivers to a watermarking tool all the information about the characteristics of
the audio content, the type of action to be performed on it and, possibly other related proprietary data required by the
watermarking tool. Furthermore in case of:

insertion, the watermarking payload to be inserted;
57
ISO/IEC 14496-1:2001/Amd.3



extraction, the ID of the recipient of the watermarking payload is provided;
remarking, the watermarking payload to be inserted;
compression detection, the ID of the recipient of the decision (that compression has taken place or not) is provided.
As an example of compression detection, considering that the audio material has been distributed only in a noncompressed legacy (CD) format, thus, if detected that compression took place on it, it will be unauthorised (pirated)
content. This implies that the watermarking tool will be able to discriminate compression from other common signal
processing manipulations which may also took place in the signal but are not considered prohibited (as expressed by the
rights attached to the particular audio stream) such as sample rate conversion, tremble/bass, spatialisation, echo, etc. It
should be clear that this is only an example of the possible usages of this flag. Its goal in general is to facilitate means and
technologies for distinguishing legal from illegal audio content.
inputFormat
RequiredOp
The format of the audio input stream, as indicated in a Table to be maintained
by a registration authority. The Table shall contain at least the PCM format
and all audio formats indicated in Table 8 “ObjectTypeIndication values” in [3]
The operation that the watermarking tool is required to perform on the audio
stream. The following values are allowed:
INSERT_WM = 0
EXTRACT_WM=1
REMARK_WM =2
DETECT_COMPRESSION =3
ISO reserved = 4..10
User defined = 11..15
NChannels
the number of channels (1 = mono, 2 = stereo…) of the input stream
Frequency
the number of samples per second (in Hz. e.g. 44100) of the input stream
BitPerSample
the number of bits per sample (e.g. 8, 16) of the input stream
WmPayloadLen
the length of the watermarking payload in bytes to be inserted in the audio
content.
WmPayload
the watermarking payload to be inserted in the audio content
WmRecipientId
the context ID of the destination tool, to which the watermarking payload and
compression information must be delivered.
HasOpaqueData
a flag that indicates if the message also carries opaque data information for
the watermarking tool.
OpaqueDataSize
the length of the opaque data field in bytes
OpaqueData
the opaque data field carrying proprietary information to the watermarking
tool (e.g. initialisation parameters, like specific algorithm id, keys, etc. )
H.2 IPMP_SendAudioWatermark
H.2.1 Syntax
class IPMP_SendAudioWatermark extends IPMP_ToolMessageBase :
bit(8) tag = IPMP_SendAudioWatermark_tag
{
bit(2) wm_status;
bit(2) compression_status;
bit(1) hasOpaqueData;
bit(3) reserved = 0b000;
if (wm_status == WM_PAYLOAD)
{
ByteArray payload;
}
if (hasOpaqueData)
58
ISO/IEC 14496-1:2001/Amd.3
{
ByteArray opaqueData;
}
}
H.2.2 Semantics
A watermarking tool, which has been required to perform payload extraction by means of an IPMP_AudioWatermarkingInit
message will send this message to wmRecipientId each time a new watermarking payload is extracted from the audio
content.
A watermarking tool, which has been required to detect if compression has been taken place on a raw (PCM) audio stream,
will send this message to wmRecipientId each time it detects that the raw audio stream has been either compressed (and
as such perhaps has been illegally distributed) or not.
wm_status
hasOpaqueData
the result of the check if watermarking was present. If watermark
was detected, then this value also says if the payload extracted is
carried inside the message or not. Possible values are listed in the
wm_status table below.
the result of the check if the audio stream was compressed.
Possible values are listed in the compression_status table below.
a flag indicating whether this message carries opaque data.
payload
the watermarking payload extracted from the audio content.
opaqueData
opaque data from the Watermarking Tool.
compression_status
WM_PAYLOAD
WM_NOPAYLOAD
NO_WM
WM_UNKNOWN
COMPRESSION
NO_COMPRESSION
COMP_UNKNOWN
watermarking was present in the audio stream, payload is carried in the message.
watermarking was present in the audio stream, no payload is carried in the
message.
watermarking was not present in the audio stream.
the Watermarking Tool was unable to detect whether watermarking was present in
the audio stream or not.
Table 1: wm_status table
the audio stream was compressed
the audio stream was not compressed
the Watermarking Tool was unable to detect if the audio stream was
compressed
Table 2: compression_status table
Annex I:
Tool/Content Transfer Messages Among Distributed IPMP Devices
59
ISO/IEC 14496-1:2001/Amd.3
(Informative)
I.1 Addressing of distributed devices
To address different IPMP devices in a network domain, every IPMP device should be assigned with a unique 64 bit
deviceID. How the deviceID is assigned and maintained unique is an implementation issue. It may be assigned during the
manufacturing time.
I.2 IPMP_DeviceMessageBase
I.2.1 Syntax
abstract class IPMP_DeviceMessageBase extends ExpandableBaseClass: bit(8) tag = 0
{
bit(8) Version;
bit(64) sender_deviceID;
bit(64) recipient_deviceID;
bit(32) Msg_ID;
}
I.1.2 Semantics
IPMP_DeviceMessageBase is an expandable base class for IPMP Device to Device Messages. The extension tags are
defined in Table 4. The binary form of the message looks as follows.
MSG
TYPE
EXPANDABLE SIZE
VER
SENDER_DeviceID
RECIPIENT_DeviceID
MSG ID
MSG TYPE-SPECIFIC
DATA
Version indicates the version of syntax used in the messages and shall be set to 0x01.
Sender_DeviceID indicates the device ID of the originator of the message.
Recipient_DeviceID indicates the device ID of the intended recipient of the message.
Msg_ID is a message identifier specified by the message originator. All messages sent in response to a message shall
include the identifier of the original message.
Some messages extended from IPMP_ToolMessageBase can be extended from IPMP_DeviceMessageBase as well,
including IPMP_Tool_Secure_Message, IPMP_InitAuthentication as well as IPMP_MutualAuthentication.
On top of that, there are some specific Device to Device messages, that are defined below.
I.2 Various Device to Device IPMP Messages
I.2.1 Content Transfer Messages
I.2.1.1 IPMP_RequestContent
Syntax:
class IPMP_RequestContent extends IPMP_DeviceMessageBase :
bit(8) tag = CPMP_RequestContent_tag
{
bit(128) ContentID;
bit(32) IPMP_DomainID;
}
Semantics:
Content_ID – An identification number that uniquely identifies a recorded content. This Content_ID may possible be
assigned by user before the time of recording.
60
ISO/IEC 14496-1:2001/Amd.3
Domain_ID – it identifies the authorized domain. Every IPMP compatible device within the same authorized domain should
obtain the same Domain_ID via some secure means from the operator, possible during the time of registration to the
operator.
Response:
IPMP_ResponseToContentRequest.
I.2.1.2 IPMP_ResponseToContentRequest
Syntax:
class IPMP_ ResponseToContentRequest extends IPMP_DeviceMessageBase :
bit(8) tag = IPMP_ ResponseToContentRequest _tag
{
bit(2) response;
const bit(6) reserved=0b0000.00;
}
Semantics:
Table - Response Message for Content Request
Response
00
01
10
11
Note
You are not in authorized domain
No Such content
Prohibit in Copy/Move
Approved
I.2.1.3 IPMP_ContentTransfer
Syntax:
class IPMP_ ContentTransfer extends IPMP_DeviceMessageBase :
bit(8) tag = CPMP_ContentTransfer_tag
{
bit(128) ContentID;
bit(8)
Sequence;
bit(32) PayloadSize;
bit(8)
Payload[PayloadSize];
}
Semantics:
Sequence – an 8 bit field indicates the sequence number of this payload, this enables the recipient device to re-form the
content without mess up the content. It accumulates upon each IPMP_ContentTransfer message, and it is reset to 0 when it
reaches 256.
To securely transfer the content, this entire message could be set as a payload of the IPMP_Tool_Secure_Message as
defined in the currently IPMP Extension CD.
Response:
Not required
I.2.2 Tool Transfer Messages
61
ISO/IEC 14496-1:2001/Amd.3
I.2.2.1 IPMP_RequestTool
Syntax:
class IPMP_RequestTool extends IPMP_DeviceMessageBase :
bit(8) tag = IPMP_RequestTool_tag
{
bit(128) ToolID;
bit(32) IPMP_DomainID;
}
Response:
IPMP_ResponseToToolRequest.
I.2.2.2 IPMP_ResponseToToolRequest
Syntax:
class IPMP_ResponseToToolRequest extends IPMP_DeviceMessageBase :
bit(8) tag = IPMP_ResponseToToolRequest_tag
{
bit(128) ToolID;
bit(2)
response;
bit(6)
reserved;
if (response==0b11)
{
bit(32)
PayloadSize;
bit(8)
Payload[PayloadSize];
bit(16)
ToolDescriptionSize;
bit(8)
ToolDescription [ToolDescriptionSize];
}
}
Semantics:
Table - Response Message for Tool Request
Response
Note
00
You are not in authorized domain
01
No Such tool
10
Prohibit for transferring
11
Approved
Payload – carries binary tool
ToolDescription – description of the binary tool
To securely transfer the tool, this entire message could be set as a payload of the IPMP_Tool_Secure_Message as defined
in the currently IPMP Extension CD.
Response:
Not required
I.2.3 Device ID messages
For a device to know all other devices that are connected to it within the same network, there are two messages that a
device is used to broadcast its existence to all other device connected.
I.2.3.1 IPMP_DeviceID_Broadcasting Message
Syntax:
62
ISO/IEC 14496-1:2001/Amd.3
class IPMP_ DeviceID_Broadcasting extends IPMP_DeviceMessageBase :
bit(8) tag = IPMP_ DeviceID_Broadcasting_tag
{
bit(64) device_ID;
bit(32) IPMP_DomainID;
ByteArray
OpaqueData[];
}
Response:
IPMP_DeviceID_Received.
I.2.3.2 IPMP_DeviceID_Received
When device A received the IPMP_DeviceID_Broadcasting Message from device B, device A needs to send back an
acknowledgement message, and tell device B about device A’s deviceID. The message syntax is shown below
Syntax :
class IPMP_ DeviceID_Received extends IPMP_DeviceMessageBase :
bit(8) tag = IPMP_ DeviceID_Received_tag
{
bit(64) device_ID;
bit(32) IPMP_DomainID;
ByteArray
OpaqueData[];
}
Response :
None.
63