Open IPTV Forum
Release 2 Specification
[V2.3] - [2014-01-24]
Open IPTV Forum support office
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 43 83
Fax: +33 4 92 38 52 90
The Open IPTV Forum accepts no liability whatsoever for any use of this document.
No part may be reproduced except as authorized by written permission.
Any form of reproduction and/or distribution of these works is prohibited.
Copyright 2014 © Open IPTV Forum e.V.
All rights reserved.
This specification has been produced by the Open IPTV Forum (OIPF).
This specification accompanies the set of specifications (Volumes 1-7) that define the Open IPTV Forum Release 2 IPTV Solution.
This specification defines three profiles for the OIPF Release 2 IPTV Solution:
The three profiles are heirarchical in the sense that the Open Internet Profile is formed of a sub-set of the features of the Baseline Managed Profile, and that the Baseline Managed Profile is formed of a sub-set of the features of the Enhanced Managed Profile.
Note that these profile names are defined as technical terms and as such are not intended to be used for any logo mark or similar purpose.
If additional profiles are defined for the Release 2 IPTV Solution, these will be included in future revisions of this specification.
The Open IPTV Forum Release 2 IPTV Solution provides the specification for an end-to-end platform for the deployment of the set of Release 2 IPTV Services. The Open IPTV Forum has developed an end-to-end solution to allow any consumer end-device, compliant to the Open IPTV Forum specifications, to access enriched and personalised IPTV services either in a managed or a non-managed network.
The Release 2 IPTV Solution specification provides multiple options for some features. This specification complements the IPTV Solution specification by defining OIPF implementation and deployment profiles that remove uncertainty about what features are required in an implementation. Any implementation based on the Release 2 IPTV Solution specification must be in adherence to one of the profiles defined in the present specification in order to claim Open IPTV Forum compliance.
Profiles define the minimum set of features that a terminal must support in order to be able to claim compliance to that profile, and the maximum set of features that a service can rely on being present in the OITF. Some features are optional within a profile, and a service can use capability exchange protocols to determine if a terminal supports such features. Some features are mandatory or optional depending on the configuration of the OITF, for example whether the OITF is equipped with local storage or a broadcast tuner.
It is expected that this specification will be used as a key input to the interoperability and certification programs that will be defined for the Release 2 Solution by the Open IPTV Forum.
|[TS102034]||ETSI, TS 102 034 V1.4.1 (2007-10), "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Networks".|
|[TS102539]||ETSI, TS 102 539 V1.3.1 (2010-04), "Digital Video Broadcasting: Carriage of Broadband Content Guide (BCG) information over Internet Protocol"|
|[TS102809]||ETSI, TS 102 809 V1.1.1 (2010-01), "Digital Video Broadcasting (DVB); Signalling and carriage of interactive applications and services in hybrid broadcast / broadband environments".|
|[OIPF_ARCH2]||Open IPTV Forum, "Functional Architecture - V2.3", January 2014.|
|[OIPF_CSP2]||Open IPTV Forum, "Release 2 Specification, Volume 7 - Authentication, Content Protection and Service Protection", V2.3, January 2014.|
|[OIPF_DAE2]||Open IPTV Forum, "Release 2 Specification, Volume 5 - Declarative Application Environment", V2.3, January 2014.|
|[OIPF_HAS2]||Open IPTV Forum, "Release 2 Specification, Volume 2a - HTTP Adaptive Streaming", V2.3, January 2014.|
|[OIPF_MEDIA2]||Open IPTV Forum, "Release 2 Specification, Volume 2 - Media Formats", V2.3, January 2014.|
|[OIPF_META2]||Open IPTV Forum, "Release 2 Specification, Volume 3 - Content Metadata", V2.3, January 2014.|
|[OIPF_PROT2]||Open IPTV Forum, "Release 2 Specification, Volume 4 - Protocols", V2.3, January 2014.|
|[OIPF_PROT_EX2]||Open IPTV Forum, "Release 2 Specification, Volume 4a - Examples of IPTV Protocol Sequences", V2.3, January 2014.|
|[RFC2119]||S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt|
The key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in [RFC2119].
All sections and appendixes are normative, unless they are explicitly indicated to be informative.
|Access Network||The network infrastructure used by the Access Provider to deliver IPTV services to the Consumer.
The access network infrastructure is used for the delivery of the content and may include quality of service management to ensure that appropriate network resources are available for the delivery of the content.
|Application||Collection of assets and logic that together provide a Service to the User. Assets and logic may reside either in an application Server or in the ITF or both.|
|Consumer Domain||The domain where the IPTV services are consumed. A consumer domain can consist of a single terminal or a network of terminals and related devices for service consumption.|
|Consumer Network||The local area network in which the IPTV Terminal Function is located. Consumer Networks include Residential Networks, hot spots, hotel networks etc.|
|Consumer(s)||See End User(s).|
|Content||An instance of audio, video, audio-video information, or data.|
|Content Guide||An on-screen guide to Scheduled Content and Content on Demand, allowing a User to navigate, select, and discover content by time, title, channel, genre, etc.|
|Content on Demand (CoD)||A Content on Demand service is a service where a user can select the individual content items they want to watch from the list of available content. Consumption of the content is started upon user request.|
|Content Protection||Means to protect content from unauthorized usage such as re-distribution, recording, playback, duplication etc|
|Content Provider||Entity that provides Content and associated usage rights to the IPTV Service Provider.|
|End User(s)||The individual(s) (e.g., members of the same family) who actually use the IPTV Services.|
|Internet||The Internet is the worldwide, publicly accessible network of interconnected computer networks that transmit data by packet switching using the standard Internet Protocol (IP).|
|IPTV Service Provider||Entity that offers IPTV Services and which has a contractual relationship with the Subscriber.|
|IPTV Solution||Defined by the Forum’s specifications.|
|IPTV Terminal Function (ITF)||The functionality within the Consumer Network that is responsible for terminating the media and control for an IPTV Service.|
|Local Storage||Content storage within the administrative realm of the IPTV Service Provider, but not in their physical environment (for example, local storage could be a partition of storage located in the residential network and allocated to the Service Provider to pre-load CoD).|
|native HNI-IGI function||The procedures for interactions on the HNI-IGI interface are provided as part of the OITF implementation - typically in native code.|
|nPVR||Network based Personal Video Recorder. Provision of PVR functionality whereby the content is stored in the IPTV Service Provider domain. The nPVR allows a user to schedule recording of scheduled content programs. The user can later select the content they want to watch from the recorded content.|
|Portal||A function of a Service Platform that provides an entry point to individual IPTV Services to Users via a GUI.|
|Program||A segment of Scheduled Content with a defined beginning and end.|
|Program Guide||See Content Guide.|
|Push CoD||A type of Content on Demand where the content is pre-loaded to the ITF local storage by the Service Provider. The user has no direct control of what content is pre-loaded; however the Service Provider may make the choice based on user preferences and habits. Content is available for direct consumption after the user selection is confirmed.|
|Residential Network||The local network of devices (gateways and terminals) at the End User’s premises.|
|Scheduled Content||An IPTV Service where the playout schedule is fixed by an entity other than the User. The Content is delivered to the user for immediate consumption.|
|Service||Content and Applications provided by Service Platform Providers and Service Providers.|
|Service Access Protection||Means to protect IPTV Services from unauthorized usage/access, such as|
|Service Platform Provider||Entity which, based on a contractual relationship with IPTV Service Providers, provides the supporting functions for the delivery of IPTV Services, such as charging, access control and other functions which are not part of the IPTV Service, but required for managing its delivery.|
|Service Protection||Means to protect Contents (files or streams) during their delivery.|
|Session Portability||Ability of a given Service/Application to be switched from one device to another for a continuation of a session in real time.|
|Subscriber||The individual that makes the contract (subscription) with a Service Provider for the consumption of certain Services.|
|Subscriber Profile||Information associated with a subscription.|
|Trick Mode||Facility to allow the User to control the playback of Content, such as pause, fast and slow playback, reverse playback, instant access, replay, forward and reverse skipping.|
|User Profile||Information (e.g., viewing preferences) associated with a specific User who is a part of a subscription.|
|User(s)||See End User(s).|
|API||Application Programming Interface|
|AL-FEC||Application Layer FEC|
|A/V||Audio and Video|
|BCG||Broadband Content Guide (specified by the DVB Project)|
|BMP||Baseline Managed Profile|
|CAS||Conditional Access System|
|CDN||Content Delivery Network|
|CDS||Content Directory Service|
|CoD||Content on Demand|
|CPE||Customer Premise Equipment|
|CSP||Content and Service Protection|
|CSPG||Content and Service Protection Gateway|
|DAE||Declarative Application Environment|
|DHCP||Dynamic Host Configuration Protocol|
|DRM||Digital Rights Management|
|DSCP||DIFFServ Code Point|
|DTCP-IP||Digital Transmission Content Protection over Internet Protocol|
|DVB-IP||Digital Video Broadcasting (over) Internet Protocol|
|ECMA||European Computer Manufacturers Association, ECMA International - European association for standardizing information and communication systems|
|EIT||Event Information Table|
|EMP||Enhanced Managed Profile|
|EPG||Electronic Program Guide|
|FCC||Fast Channel Change|
|FEC||Forward Error Correction|
|GBA||Generic Bootstrapping Architecture|
|GCA||Gateway-Centric Approach (for CSP)|
|GUI||Graphical User Interface|
|HAS||HTTP Adaptive Streaming|
|HTTP||Hypertext Transfer Protocol|
|IGMP||Internet Group Management Protocol|
|IMS||IP Multimedia Subsystem|
|IPTV||Internet Protocol Television|
|ISP||Internet Service Provider|
|ITF||IPTV Terminal Function|
|LAN||Local Area Network|
|MAC||Message Authentication Code|
|NAT||Network Address Translation|
|nPVR||Network Personal Video Recorder|
|OIP||Open Internet Profile|
|OIPF||Open IPTV Forum|
|OITF||Open IPTV Terminal Function|
|OMA||Open Mobile Alliance|
|PAE||Procedural Application Environment|
|PVR||Personal Video Recorder|
|QoS||Quality of Service|
|RTP||Real Time Protocol|
|RTCP||Real Time Control Protocol|
|RTSP||Real Time Streaming Protocol|
|RMS||Remote Management System|
|SD&S||Service Discovery and Selection|
|SDP||Session Description Protocol|
|SIP||Session Initiation Protocol|
|SPI||Service Provider Interface|
|SPP||Service Platform Provider|
|STB||Set Top Box|
|TBD||To Be Determined|
|TCA||Terminal-Centric Approach (for CSP)|
|TCP/IP||Transmission Control Protocol/Internet Protocol|
|UNI||User Network Interface|
|URI||Uniform Resource Identifier|
|URL||Uniform Resource Locator|
|VoD||Video on Demand|
|WAN||Wide Area Network|
|XHTML||eXtensible Hypertext Markup Language|
|XML||eXtensible Markup Language|
An OIPF Release 2 IPTV Solution profile is a set of features and elements, as specified in the Open IPTV Forum Release 2 Solution specification, that will be used by any OIPF-defined interoperability and certification program to define equipment or services as being “OIPF compliant”.
The overall objective is to enable the best possible capability and flexibility for Service Providers to deploy Services to terminals that are available in the horizontal (i.e., non-subsidized) market in the near-term time frame. In selecting a set of features and elements that constitute a profile, a balance is made between the following factors:
Section 8 provides a normative specification of the set of features of each Profile in tabular form, with cross-references to the relevant clauses of the volumes in the Release 2 IPTV Solution specification.
In the present document the Open Internet Profile is referred to as “OIP”.
An OITF that is compliant with the OIP is referred to as an OIP-OITF.
In the Release 2 IPTV Solution specification, the terms “Unmanaged Network” and “Open Internet” are used interchangeably, to refer to the ability to access any Service Provider using any Access Network Provider without any quality of service guarantees.
Open Internet IPTV Services are accessed via the Internet, without QoS guarantees. They may be accessed via a service platform (e.g., a portal).
The OIP-OITF enables access to compliant services that do not provide QoS guarantees over at least one network segment between the IPTV Service Provider and the OITF, independently from their ISP – i.e. “over the top” (OTT) mode.
The OIP is a sub-set of the BMP and of the EMP in terms of the features included.
The following sub-sections summarise the features of the OIP.
The OIP-OITF shall support the Scheduled Content Service, using the HTTP transport method. Support of the multicast and unicast streamed via RTSP/RTP variants is optional.
The OIP-OITF shall support the Streamed CoD Service, using the HTTP transport method. Support of the Streamed CoD Service via RTSP/RTP is optional.
The OIP-OITF shall support Information Services, which are realised as DAE applications.
Support for the Download CoD and Local PVR services in the OIP-OITF is optional and depends on the provision of persistent storage in the OITF.
Support for the Hybrid Broadcast Broadband service in the OIP-OITF is optional and depends on the provision of at least one broadcast tuner in the OITF.
If an OIPF-compliant WAN Gateway is present then it may fulfill the relevant network attachment functions as specified in Volume 4 [OIPF_PROT2] section 12.1 in order to provide additional Service Provider discovery entry points as described in section 5.3.
The IMS Gateway (IG) functional entity is not necessary for access to services not relying on IMS using an OIP-OITF. However, if an IG is present, an OIP-OITF may use it to access some IMS-based managed network services.
The AG functional entity, as generally for the IPTV Release 2 Solution, is optional in the OIP.
The required features for the OIP-OITF are described in the following sub-sections, which deal with specific aspects of the IPTV Solution.
Section 8 provides details about the IPTV Solution features that shall be supported by the OIP-OITF.
The Release 2 IPTV Solution defines three methods for the provision of Service Provider discovery entry points to the OITF. The availability of these various methods enables the User to access various Service Providers’ IPTV Services in a convenient manner, namely entry points that are pre-configured in the OITF, manually entered or acquired entry points, and entry points provided by the Access Network Service Provider.
The OIP-OITF may provide means by which the User is able to enter his own chosen Service Provider discovery entry points via the OITF user interface, as specified in the Release 2 Architecture [OIPF_ARCH2] section 18.104.22.168.
The OIP-OITF shall offer the complete set of Service Provider discovery entry points acquired by all of the three above methods, if any are provided, but the method of presentation and relative positioning of the various Service Provider discovery entry points in the user interface is out of scope of the OIPF specifications.
If the OIP-OITF provides persistent storage and supports the Download CoD service then it shall support the provision of content metadata via the Content Access Descriptor for that service, otherwise all service discovery data and content metadata shall be embedded within the DAE application CE-HTML pages.
The OIP-OITF shall support the following authentication methods specified in the indicated sections of Volume 7 [OIPF_CSP2]:
The OIP-OITF shall support at least one of the CSP solutions specified in Volume 7 [OIPF_CSP2], i.e. it shall support either the TCA and/or CSPG-DTCP and/or CSPG-CI+, in order to support compliant services that deliver protected content.
The use of SVG Tiny 1.2 enables advanced graphics capabilities within a DAE application, but it is expected that not all terminals will be able to support SVG Tiny 1.2, hence the support of SVG Tiny 1.2 in the OIP-OITF is optional.
A DAE application may use SVG Tiny 1.2 as specified in Volume 5 [OIPF_DAE2], but it is recommended that Service Providers ensure that an OITF that does not support SVG Tiny 1.2 is nevertheless able to offer the full functionality of the Service to the User, except for the enhanced user interface.
The remote management feature for the OIP facilitates the function of basic inventory of OITFs that are accessing services, without the presence of a remote management server that provisions the OITF.
The OITF shall support an upgrade process that can be triggered via the DAE remote management API. The upgrade process remains manufacturer-specific and the provision of upgrades is subject to deployment needs.
In the present document the Baseline Managed Profile is referred to as “BMP”.
An OITF that is compliant with the BMP is referred to as a BMP-OITF.
The BMP is a super-set of the OIP, and a sub-set of the EMP in terms of the features included. All features that are MANDATORY in the OIP are also MANDATORY in the BMP.
The BMP-OITF extends the functions needed to provide the pure “Over-The-Top” (OTT) service support of the OIP with functions that make it able to access content delivery services with full QoS provision in a managed network environment. These functions are chosen in order to allow a BMP-OITF to be able to access the full range of IPTV content services, and act as a near-term intermediate step towards the full range of capabilities offered by the Enhanced Managed Profile (EMP), described in section 7.
Thus, the BMP-OITF enables access to several kinds of IPTV Service:
The following sub-sections summarise the features of the BMP.
IPTV services support in the BMP is the same as for the OIP, except that in addition to those services the BMP-OITF shall support the Scheduled Content and Streamed CoD Services, using the tools described in section 6.4.
If an OIPF compliant WAN Gateway is not present, for example when a non-OIPF compliant home broadband router is deployed instead, then the BMP-OITF might not be able to access the Scheduled Content and Streamed CoD services.
The IMS Gateway (IG) functional entity is not necessary for access to services using a BMP-OITF. However, if an IG is present, a BMP-OITF may use it to access IMS-based managed network services.
The AG functional entity, as generally for the IPTV Release 2 Solution, is optional in the BMP.
A DAE application in a BMP-OITF shall implement the non-native HNI-IGI interface, as specified in Volumes 4 [OIPF_PROT2] and 5 [OIPF_DAE2] of the Release 2 IPTV Solution specification, if it intends to make to use of IMS-based services.
Further required features for the BMP-OITF are contained in the following sub-sections, which deal with specific aspects of the IPTV Solution.
Section 8 provides details about the IPTV Solution features that shall be supported by the BMP-OITF.
The provisions for Service Provider discovery entry points for the BMP-OITF are the same as those specified for the OIP-OITF in section 5.3.
The Scheduled Content and Streamed CoD services are generally associated with managed networks, where the streamed content is provided within a distribution and delivery network that is managed by the Service Provider, so that the necessary level of QoS can be assured for those services.
The BMP-OITF includes support of the features that enable the reception of such services. These include:
The service list for the Scheduled Content service in the BMP may be provided by various methods:
The Service Provider may use either or both of these methods. The BMP-OITF shall support both of these methods.
Content metadata in addition to the service list may be provided within the DAE application or via in-band DVB Service Information (EIT), which shall be supported by the BMP-OITF.
The provisions for authentication methods for the BMP-OITF are the same as those specified for the OIP-OITF in section 5.5.
The provisions for content and service protection for the BMP-OITF are the same as those specified for the OIP-OITF in section 5.6.
It is recommended that the BMP-OITF support the concurrent decoding and rendering of one HD video stream and one SD video stream.
Services and DAE applications that foresee the concurrent rendering of more than one video stream (e.g. EPG with embedded video preview) should make provision for replacing the video display with an alternative asset e.g. still picture, in case the OITF does not support multiple video stream decoding and rendering.
The provisions for remote management for the BMP-OITF are the same as those specified for the OIP-OITF in section 5.8.
The Enhanced Managed Profile is defined as the combination of both Open Internet and IMS-based Managed Network models of IPTV service operation. In the present document the Enhanced Managed Profile is referred to as “EMP”.
An OITF that is compliant with the EMP is referred to as an EMP-OITF.
The EMP is a super-set of the BMP (also of the OIP), i.e. all features that are MANDATORY in the BMP are also MANDATORY in the EMP. The EMP adds IMS-based functionality, enhanced content delivery features and more extensive management capabilities of the residential network’s functional entities.
The following sub-sections summarise the features of the EMP.
In addition to the requirements around IPTV Services support in the BMP, the EMP-OITF shall support the communications services, namely messaging, chat sessions and presence as specified in Volume 4 [OIPF_PROT2] section 5.5. The support of audio and audio/video communication services is an OITF implementation are optional, also depending on the integration of corresponding audio and video input devices on the OITF.
The IMS Gateway (IG) shall implement the relevant procedures specified in Volume 4 [OIPF_PROT2].
The Application Gateway (AG) functional entity, as is the case generally for the IPTV Release 2 Solution, is optional in the EMP.
The EMP-OITF shall implement the HNI-IGI interface natively, as specified in Volume 4 [OIPF_PROT2], except in the case that a device implements both the OITF and the IG, where the use of the HNI-IGI interface is optional, as specified in section 3.1 of Volume 4 [OIPF_PROT2].
The EMP-OITF shall provide the capability for User input of text in order to use the messaging and chat services. A facility for text input may be included in DAE applications.
The provisions for Service Provider discovery entry points for the EMP-OITF are the same as those specified for the OIP-OITF in section 5.3.
The Scheduled Content and Streamed CoD services for the EMP are associated with the IMS control layer for managed networks. Therefore the necessary level of QoS is assured transparently (for the OITF) for those services.
The EMP-OITF includes support of the features that enable the reception of such services, namely:
In addition to the authentication methods mentioned for the OIP, the EMP-OITF shall support the GBA authentication method as specified in section 22.214.171.124 of Volume 4 [OIPF_PROT2] when the HNI-IGI function is implemented natively in the EMP-OITF.
The provisions for content and service protection for the EMP-OITF are the same as those specified for the OIP-OITF.
In addition to the “DAE method” mentioned for the OIP, Remote Management shall be supported also via the Broadband Forum TR-069 based approach, as specified in Volume 4 [OIPF_PROT2] section 126.96.36.199.2.
The TR-069 based method defines a similar level of monitoring and diagnostics capability as that specified in the DAE method, but it allows more convenient re-use of existing TR-069 based remote management infrastructure commonly used by managed network service providers.
Section 8.1 specifies the status of IPTV Services support for each of the profiles. The subsequent sub-sections specify the status of features grouped according to the Volume of the Release 2 Solution specification in which the respective features are specified. The reference to the specific section in the respective specification volume is provided, along with the status of that service or feature in each of the profiles. Table 1 gives the legend used for denoting the service and feature status in the following sub-sections. Requirements for the provision of IPTV Services are not described in sections 5, 6 and 7. Unless explicitly stated otherwise, a compliant IPTV Service (as listed in Table 2) shall support at least one of the options for each feature necessary to run the IPTV Service on the correspondingly profiled OITF.
|M||Feature is MANDATORY for the Profile|
|M-D||Feature is MANDATORY for the Profile if the Download CoD Service is supported|
|M-H||Feature is MANDATORY for the Profile if the Hybrid broadcast-broadband Service is supported|
|M-P||Feature is MANDATORY for the Profile if the PVR Service is supported|
|M-C||Feature is MANDATORY for the Profile if audio/video communication services are supported|
|O||Feature is optional for the Profile|
|O-D||Feature is optional for the Profile if the Download CoD Service is supported|
|O-H||Feature is optional for the Profile if the Hybrid broadcast-broadband Service is supported|
|O-P||Feature is optional for the Profile if the PVR Service is supported|
|O-C||Feature is optional for the Profile if audio/video communication services are supported|
|IPTV Service||Status in OIP||Status in BMP||Status in EMP|
|Local PVR and time-shift||O(3)||O(3)||O(3)|
|Network PVR and time-shift||O||O||M|
|Communication services (text-based - Caller ID, Chat Messaging, Presence Status)||O(5)||O(5)||M|
|Communication services (audio and audio/video communications)||O(5)||O(5)||O(6)|
|1.||The Scheduled Content and Streamed CoD services are realised using a profiled set of service enablers for BMP, specified in sections 8.4, 8.5, and 8.6.|
|2.||The hybrid broadcast-broadband service relies on the presence of a broadcast tuner in the OITF. The OITF may support the hybrid broadcast-broadband service if a broadcast tuner is equipped in the OITF.|
|3.||The local PVR, local time-shift and download CoD services rely on the presence of persistent local storage in the OITF. The OITF may support the local PVR and/or Local time-shift and/or download CoD services if persistent local storage is equipped in the OITF.|
|4.||The Scheduled Content and Streamed CoD services are realised in the OIP using HTTP transport, as specified in section 8.5.|
|5.||Communication services may be provided natively, or non-natively within a DAE application.|
|6.||Communication services are provided via IMS.|
Table 3 lists the status of Media Formats support for each profile, referring to Volume 2 [OIPF_MEDIA2]. Note that Volume 2 contains general Solution-wide stipulations for some of these features. The features subtitles, teletext, and supported video frame rate (25 or 30Hz) are orthogonal to the Profile definitions and thus retain their status as implementation choices.
Volume 2 [OIPF_MEDIA2] also identifies audio and video codecs for IPTV services delivered to mobile terminals via mobile networks. These, however, are not considered in the present Profiles specification.
|Status in OIP||Status in BMP||Status in EMP|
|MPEG-2 transport stream (TS)||4.1||M||M||M|
|Time-stamped TS (TTS)||4.1||O||O||O|
|MP4 file format (MP4)||4.2||M||M||M|
|Application signaling (TS)||4.1||M-H(1)||M||M|
|DAE application delivery via DSM-CC (TS)||4.1||M-H(1)||M||M|
|“Do it now” DSM-CC streaming events (TS)||4.1||M-H(1)||M||M|
|Media zones (TS and MP4)||4.1, 4.2||O||O||O|
|Video for content services|
|H.264/AVC HD video||188.8.131.52, 5.1.6||M||M||M|
|H.264/AVC 3D video||184.108.40.206||O||O||O|
|H.264/AVC SD video||220.127.116.11, 5.1.6||M||M||M|
|H.264/AVC SP video||18.104.22.168||M||M||M|
|MPEG-2 HD video||22.214.171.124||O||O||O|
|MPEG-2 SD video||126.96.36.199||O||O||O|
|MPEG-2 SP video||188.8.131.52||O||O||O|
|Video for communication services||5.1.3|
|MPEG-4 Part-2 Visual video||184.108.40.206||O-C||O-C||O-C|
|Audio for content services|
|HE-AAC v2 audio||8.1.1||O||O||O|
|Enhanced AC-3 audio||8.1.3||O||O||O|
|MPEG-1 L2 audio||8.1.4||O||O||O|
|MPEG-1 L3 audio||8.1.5||O||O||O|
|MPEG Surround with HE-AAC audio||8.1.8||O||O||O|
|MPEG Surround with MPEG-1 L2 audio||8.1.9||O||O||O|
|Audio for narrowband communication services||8.1.9|
|Audio for wideband communication services||8.1.9|
|Audio for super-wideband communication services||8.1.9|
|MPEG-4 AAC LD||220.127.116.11||O-C||O-C||O-C|
|MPEG-4 AAC ELD||18.104.22.168||O-C||O-C||O-C|
|Still pictures and graphics|
|1.||shall be supported where DVB-SI is supported.|
|2.||Subtitle formats are region-specific. The BMP-OITF and the EMP-OITF shall support at least one of the subtitle formats, possibly also as dictated by applicable regional requirements.|
|Status in OIP||Status in BMP||Status in EMP|
|MPEG-DASH for MPEG-2 TS||4, 4.2||O||O||O|
|MPEG-DASH for MP4||4, 4.3||O||O||O|
|OIPF HAS for MPEG-2 TS||5, 5.6.1||O||O||O|
|OIPF HAS for MP4||5, 5.6.2||O||O||O|
Volume 3, unless
|Status in OIP||Status in BMP||Status in EMP|
|Service provider discovery||22.214.171.124 of [TS102034]||O||M||M|
|Broadcast discovery – TS Optional SI||126.96.36.199 of [TS102034]||O||M||M|
|ApplicationDiscovery record||5.4.5 of [TS102809]||O||M||M|
|Package discovery||188.8.131.52 of [TS102034]||O||M||M|
|BCG discovery||184.108.40.206 of [TS102034]||O||O||M|
|Other SD&S types||[TS102034]||O||O||O|
|Extension of DVB SD&S|
|Service Provider Discovery Extensions|
|Emergency Notification Service||220.127.116.11, B.4||O||O||O|
|Service Discovery Extensions|
|Bandwidth Renegotiation||18.104.22.168, B.7||O||O||M|
|Purchasing Broadcast Services||22.214.171.124, B.7||O||O||M|
|Container Format Indication||126.96.36.199, B.7||O||O||M|
|FCC/RET Attribute Definition||188.8.131.52||O||M||M|
|Application Announcement and Signaling|
|Service provider related application signaling||184.108.40.206||O||M||M|
|Broadcast related application signaling||220.127.116.11||O||M||M|
|Platform specific Definitions|
|Type Element of ApplicationDescriptor||18.104.22.168.1||O||M||M|
|mhpVersion Element of Application Descriptor||22.214.171.124.2||O||O||O|
|Specific ApplicationUsage Element of ApplicationUsageDescriptor||126.96.36.199.3||O||M(1)||M(1)|
|Graphic format for application icons||188.8.131.52.4||O||M||M|
|DVB BCG and OIPF Extension||3.3||O||O||M|
|Metadata Delivery Mechanism|
|Carriage of SD&S Metadata||4.1.1||O||M||M|
|Carriage of BCG Metadata||4.1.2||O||O||M(2)|
|Event Information Table (EIT)||4.1.3||O||M||M|
|CRID Location Resolution||4.3 and [TS102539]||O||O||M|
|1.||Mandatory for service providers who signal applications providing the defined services. Service discovery and non-native HNI-IGI applications shall be supported by the OITF; other applications may be supported by the OITF.|
|2.||Support for metadata searches via SOAP protocol is optional.|
Volume 4a [OIPF_PROT_EX2] is informative, hence the profiles do not make any reference to that volume.
Volume 4, unless
|Status in OIP||Status in BMP||Status in EMP|
|Multicast content streaming||8.1.1, 9.1.1||O||M||M|
|Multicast content streaming with SIP session management||5.3.1, 184.108.40.206, 8.1.1, 9.1.1||O||O||M|
|Multicast content streaming with FCC||9.5, Annex M||O||M||M|
|Unicast content streaming over RTP||220.127.116.11, 9.1.2||O||M||M|
|Unicast content streaming over RTP with SIP session management||18.104.22.168, 22.214.171.124, 9.1.2||O||O||M|
|Unicast and multicast content streaming with Retransmission (RET)||9.4, Annex M||O||M||M|
|Unicast content streaming with SIP session management||5.3.2, 126.96.36.199||O||M||M|
|HTTP content streaming (CoD progressive)||188.8.131.52||M||M||M|
|Forced Play Out Control with SIP session management||5.3.3, 184.108.40.206||O||O||O|
|HTTP content download||5.3||M-D||M-D||M-D|
|Purchase of Digital Media using SIP||5.3.5, 220.127.116.11, 18.104.22.168||O||O||O|
|Pay Per View multicast content service with SIP session management||5.3.6, 22.214.171.124, 126.96.36.199||O||O||O|
|Parental Control for content using SIP||5.3.7, 188.8.131.52, 184.108.40.206||O(8)||O(8)||O(8)|
|Network-based user notification services||5.3.8, 220.127.116.11, 18.104.22.168||o||o||o|
|Network-centric Content Bookmarking||5.3.9, 22.214.171.124, 126.96.36.199||O||O||O|
|Local PVR using SIP||5.3.10, 188.8.131.52, 184.108.40.206||O(9)||O(9)||O(9)|
|Network PVR using SIP||5.3.11, 220.127.116.11, 18.104.22.168||O||O||O|
|Personalised Channel||5.3.12, 22.214.171.124, 126.96.36.199||O||O||O|
|Unicast content streaming session transfer with SIP session management||5.3.13, 188.8.131.52, 184.108.40.206||O||O||M|
|Service provider discovery||5.4.1|
|1) Web Page||M||M||M|
|2) SD&S records||O||See DVB SD&S section of Table 5||See DVB SD&S section of Table 5|
|1) Web Page||M||M||M|
|2) SD&S records||O||See DVB SD&S section of Table 5||See DVB SD&S section of Table 5|
|XCAP Application Usage for IPTV Service (profile)||220.127.116.11||O||O||M|
|Subscription to notification of changes in the IPTV Service Profile||18.104.22.168.1||O||O||M|
|Remote management of OITF||5.4.5|
|2) DAE App||22.214.171.124||M(7)||M||M|
|User registration and network authentication||5.4.6||O||O||M|
|Protocols for communication functions using SIP||5.5, 6.2.4|
|Caller ID||5.5.1, 126.96.36.199||O(5)||O(5)||M|
|Instant Messaging||5.5.2, 188.8.131.52||O(5)||O(5)||M|
|Chat using MSRP||5.5.3, 184.108.40.206||O(5)||O(5)||M|
|A/V Telephony||220.127.116.11, 9.6||O(5)||O(5)||O|
|Content Sharing||5.5.5, 18.104.22.168||O||O||O|
|HNI-IGI – HTTP option||5.6.1||O(5)||O(5)||M(1)|
|HNI-IGI – SIP option||6.2||O||O||M|
|RTSP profile without SIP session management||22.214.171.124||O||M||M|
|RTSP profile with SIP session management||126.96.36.199||O||O||M|
|RTSP/RTCP Monitoring||188.8.131.52, 7.2.1||O||O||O|
|DVBSTP (UNIS-7, UNIS-15)||184.108.40.206||O||M||M|
|Interactive application delivery using FLUTE (UNIS-6, UNIS-12)||220.127.116.11||O||O||O|
|MPEG-2 TS RTP/UDP for multicast content streaming||9.1.1||O||M||M|
|MPEG-2 TS RTP/UDP for unicast content streaming||9.1.2||O||M||M|
|DVB-IPTV base-layer AL-FEC||9.3||O||M||M|
|UPnP Discovery of the IG||10.1.1.1||O||O||M|
|UPnP Discovery of the AG||10.1.1.2||O||O||M|
|UPnP Discovery of the CSPG-DTCP||10.1.1.3||O||O||M|
|Network Attachment (DHCP-based)||12.1.1||M||M||M|
|DHCP options 1, 6, 61||18.104.22.168.1||M||M||M|
|DHCP options 15||22.214.171.124.2||M||M||M|
|DHCP options 43, 60||126.96.36.199.1||O||O||M|
|DHCP option 120||188.8.131.52.1||O||O||M|
|DHCP options 124/125||184.108.40.206.3||M(6)||M||M|
|Service provider discovery entry points|
|1) Pre-defined by manufacturer||[OIPF_ARCH2] 220.127.116.11||O(2)||O(2)||O(2)|
|2) Input from user||[OIPF_ARCH2] 18.104.22.168||O(3)||O(3)||O(3)|
|3) DHCP configuration option 124/125||22.214.171.124.3||M(4)||M(4)||M(4)|
|MPEG-2 TS UDP||126.96.36.199||O||O||M|
|NAT Traversal||Annex F.6||O||M||M|
|1.||The feature is optional for communication between the IG and OITF when integrated into a single device. The IG shall nevertheless provide HNI-IGI for other OITFs in the residential network.|
|2.||The OITF may include pre-configured service provider discovery entry points.|
|3.||The OITF may include a facility for the User to acquire service provider discovery entry points via the OITF UI.|
|4.||The OITF shall acquire service provider discovery entry points provided via this method and shall make these available to the User.|
|5.||Feature is however provided non-natively via DAE APIs.|
|6.||DHCP options 124/125 apply only to web page URLs in the OIP.|
|7.||The getParameter method is optional.|
|8.||Regulatory requirements might imply this feature to be mandatory to be implemented.|
|9.||The local PVR, local time-sjift and download CoD services rely on the presence of persistent local storage in the OITF. The OITF may support the local PVR and/or Local time-shift and/or download CoD services if persistent local storage is equipped in the OITF.|
|10.||The remote management feature is mandatory, but TR-069-based remote management of the OITF is optional when a functionally equivalent solution is implemented in the OITF, allowing a remote call of the methods and properties as specified in section 188.8.131.52.2|
|Status in OIP||Status in BMP||Status in EMP|
|Gateway Discovery and Control||4.2||O||O||M(12)|
|Widgets||4.3.9, 5.2.8, 7.2.1, 7.2.2, 7.2.8, 9.3.20, 11||O||O||O|
|Remote control function||4.9, 7.17, 8.5, 9.3.18, 10.3, Annex J||O||O||O|
|Power management||4.10, 7.2.4, 9.3.19||O||O||O|
|Display model||4.11, Annex H||M||M||M|
|Application Announcement & Signalling||5.2||M||M||M|
|Basics||5.2.1, 5.2.2, 5.2.5, 5.2.6||M||M||M|
|Broadcast related applications||5.2.3, 5.2.7||O||M||M|
|Service provider related applications||5.2.4, 5.2.7||O||O||M|
|Extended hybrid support||184.108.40.206||M-H(10)||M||M|
|Event Notification Framework based on CEA 2014||5.3.1||O||O||O|
|Outgoing request messages and in-session incoming request messages||220.127.116.11, 18.104.22.168||O(15)||O(15)||O(15)|
|Out of session incoming request messages||22.214.171.124||O||O||O|
|Web standards TV profile||6.1||M||M||M|
|Still image formats||6.2||M||M||M|
|Object Factory API||7.1||M||M||M|
|Applications Management APIs||7.2||M||M||M|
|The application/oipfConfiguration embedded object||7.3.1||M||M||M|
|Configuration and Setting APIs|
|The Configuration class||7.3.2||M(1)||M(1)||M(1)|
|The LocalSystem class||7.3.3||O||M(2)||M(2)|
|The NetworkInterface class, the NetworkInterfaceCollection class||7.3.4, 7.3.6||O||O||O|
|The AVOutput class, the AVOutputCollection class||7.3.5, 7.3.7||O||O||O|
|The TunerCollection class, the Tuner class, the SignalInfo class, the LNBInfo class||7.3.8, 7.3.9, 7.3.10, 7.3.11||O||O||O|
|The StartupInformation class||7.3.12||O||O||O|
|Content Download APIs|
|Basic content download – the application/oipfDownloadTrigger embedded object||7.4.1||M-D||M-D||M-D|
|Extensions to application/oipfDownloadTrigger||7.4.2||O-D(3)||O-D(3)||M-D|
|The application/oipfDownloadManager embedded object, The Download class, The DownloadCollection class||7.4.3, 7.4.4, 7.4.5||O-D||O-D||O-D|
|The DRMControlInformation class, The DRMControlInfoCollection class||7.4.6, 7.4.7||O-D||O-D||O-D|
|Content On Demand Metadata APIs||7.5||O||O||M|
|Content Service Protection API||7.6||M||M||M|
|Gateway Discovery and Control APIs||7.7||O(18)||M(4)||M(12)|
|IMS Related APIs|
|application/oipfIMS embedded object||7.8.1, 7.8.3, 7.8.4, 7.8.5, 7.8.6||O||O||M|
|Extensions to application/oipfIMS for presence and messaging services||7.8.2, 7.8.7, 7.8.8||O||O||M|
|Extensions to application/oipfIMS for voice telephony service||7.8.9||O||O||O|
|Extensions to application/oipfIMS for video telephony service||7.8.10||O||O||O|
|The DeviceInfo class, the DeviceInfoCollecion class, the CodecInfo class, the CodecInfoCollection class||7.8.11, 7.8.12, 7.8.13, 7.8.14||O||O||O|
|Parental access control APIs|
|application/oipfParentalControlManager embedded object||7.9.1, 7.9.2, 7.9.3||O(5)||O(5)||O(5)|
|ParentalRating and ParentalRatingCollection||7.9.4, 7.9.5||O-H(5)||O(5)||O(5)|
|Scheduled Recording APIs|
|Basic PVR support – the application/oipfRecordingScheduler embedded object||7.10.1, 7.10.2, 7.10.3||O-P||M-P||M-P|
|Advanced PVR support – Extension to application/oipfRecordingScheduler for control of recordings||7.10.4, 7.10.5, 7.10.6, 7.10.7||O-P(6)||M-P(6)||M-P(6)|
|OITF-centric Bookmark and BookmarkCollection||7.10.8, 7.10.9||O||O||O|
|Remote management APIs||7.11||M(16)||M||M|
|Metadata search APIs||7.12||O||O||M(7),(8)|
|Synchronisation to video||7.13.21||M-H(10)||M||M|
|video/broadcast embedded object||7.13.1, 7.13.4, 7.13.9, 7.13.10, 7.13.11||O||M||M|
|Extensions for recording and timeshift||7.13.2||O-P||O-P||O-P|
|Access to DVB-SI EIT p/f||7.13.3||M-H(10)||M||M|
|Extensions to video/broadcast for parental ratings errors||7.13.5||O(5)||O(5)||M|
|Extensions to video/broadcast for DRM rights errors||7.13.6||O||M||M|
|Extensions to video/broadcast for channel scan||7.13.7, 7.13.14||O-H(9)||O-H(9)||O-H(9)|
|Extensions to video/broadcast for creating Channel lists from SD&S fragments||7.13.8||O||M||M|
|Favourite lists||7.13.12, 7.13.13||O-H||O||O|
|Enhanced channel scan||7.13.15 - 7.13.20, 7.13.22||O-H||O-H||O-H|
|Media playback APIs|
|Basics||126.96.36.199, 188.8.131.52, 7.14.2, 7.14.3, 7.14.4, 7.14.8, 7.14.9||M||M||M|
|Using an A/V control object to play downloaded content||184.108.40.206||M-D||M-D||M-D|
|Using an A/V control object to play recorded content||220.127.116.11||M-P||M-P||M-P|
|Extensions to A/V object for parental rating errors||7.14.5||O(5)||O(5)||M|
|Extensions to A/V object for DRM rights errors||7.14.6||M||M||M|
|Extensions to A/V object for playing media objects (downloaded or recorded content or CoD via BCG)||7.14.7||M-D, M-P||M-D, M-P||M|
|Playback of memory audio||7.14.10||M||M||M|
|Extensions to A/V Control object for media queuing||7.14.11||M||M||M|
|Extensions to A/V Control object for volume control||7.14.12||M||M||M|
|Extensions to A/V Control object for resource management||7.14.13||M||M||M|
|application/oipfMDTF embedded object||7.15.1||O||O||O|
|application/oipfStatusView embedded object||7.15.2||O||O||O|
|application/oipfCapabilities embedded object||7.15.3||M||M||M|
|The Navigator class||7.15.4||M||M||M|
|Debug Print API||7.15.5||M||M||M|
|Shared utility classes and features|
|Programme - basics||18.104.22.168, 22.214.171.124, 7.16.3||M-H(10), M-P||M||M|
|Metadata extensions to Programme||126.96.36.199||O-H||M||M|
|DVB-SI extensions to Programme||188.8.131.52||O-H||M||M|
|Recording extensions to Programme||184.108.40.206||M-P||M-P||M-P|
|The DiscInfo class||7.16.4||M-D, M-P||M-D, M-P||M-D, M-P|
|Extensions for playback of selected media components||7.16.5||M||M||M|
|Additional support for protected content||7.16.6||M||M||M|
|HTTP User-Agent header||8.1.1||M||M||M|
|HTTP X-OITF-RCF-User-Agent header||8.1.2||M||M||M|
|Mapping from APIs to Protocols||8.2|
|CoD download over HTTP||8.2.1||M-D||M-D||M-D|
|CoD unicast streaming with SIP session management||8.2.2||O||O||M|
|Scheduled Content multicast streaming with SIP session management||8.2.3||O||O||M|
|Communication services with SIP session management||8.2.4||O||O||O|
|CoD unicast streaming over RTP and HTTP||8.2.5||M(21)||M||M|
|Scheduled content multicast streaming||8.2.6||O||O||M|
|URI Schemes and their usage||8.3||M(11),(14)||M(11)||M|
|Minimum DAE capability requirements||9.1||M||M||M|
|Multiple simultaneous applications||9.1||O||M||M|
|Default UI profiles||9.2||M||M||M|
|Client capability Description||9.3||M||M||M|
|HTML 5 <video> tag||Annex I, 9.3.17||O||O||O|
|Content Access Descriptor Syntax and Semantics|
|Content Access Download Descriptor Format||Annex E.1||M-D||M-D||M-D|
|Basic content access descriptor||Annex E.2, Annex E.3||M||M||M|
|Capability Extensions Schema||Annex F||M||M||M|
|Client Channel Listing Format||Annex G||O||O||O|
|1.||Read-only access to the following properties shall be supported – preferredAudioLanguage, preferredSubtitleLanguage and countryID. Read-write access to these properties, all the other properties and all methods are optional.|
|2.||The deviceID property shall be supported. Other properties and methods are optional.|
|3.||Only applicable where both BCG and download are supported.|
|4.||API mandatory but fails where protocol is not supported by the OIP-OITF or BMP-OITF.|
|5.||Aspects of this may be mandatory depending on applicable regulation.|
|6.||Recordings made by applications from one service provider shall not be visible to applications from other service providers.|
|7.||Mapping from this API to BCG shall be supported. Mapping from this API to DVB-SI may be supported in OITFs that support hybrid service.|
|8.||Support for processing searches on a remote server using the SOAP based protocol is optional.|
|9.||shall be supported if the OITF does not include a means for the user to initiate this manually, otherwise optional.|
|10.||shall be supported where DVB-SI is supported.|
|11.||The crid URI scheme is optional.|
|12.||The feature is optional for communication between the IG and OITF when integrated into a single device. The IG shall nevertheless provide HNI-IGI for other OITFs in the residential network.|
|13.||Only unicast mode streaming is required to be supported.|
|14.||The support of “rtsp” and "dvb-mcast" URLs is optional.|
|15.||Feature applies to DAE applications, rather than to the OITF.|
|16.||The getParameter method is optional.|
|17.||Only “http” URLs are required to be supported.|
|18.||If CSPG-DTCP or CSPG-CI+ is supported then the CSP Gateway Discovery and URL properties shall be supported, however the CSP Gateway URL has no meaning in the case of CSPG-CI+.|
|19.||Excluding requirements to support the application/oipfStatusView object which is optional.|
|20.||Section 220.127.116.11 “Applications provided by the AG through the remote UI" is only required where section 4.2 is supported.|
|21.||Only those elements of 18.104.22.168 relevant to HTTP are mandatory. Section 22.214.171.124 and elements of 126.96.36.199 relevant to RTSP are optional in line with the corresponding sections of [OIPF_PROT2].|
The complete Procedural Application Environment is required to be used as the core component of the Application Gateway (AG) functional entity; however the use of the AG is optional with all three OITF profiles.
|Status in OIP||Status in BMP||Status in EMP|
|Terminal Centric Approach (TCA)||4.1||O(1)||O(1)||O(1)|
|Marlin metering in OITF||4.1||O||O||O|
|Protected MPEG-2 TS||4.1.4, 4.1.5||M||M||M|
|Gateway Centric Approach (GCA)||4.2||O(1),(2)||O(1),(2)||O(1),(2)|
|HTTP basic and digest authentication||5.4.1||M||M||M|
|Web based authentication||5.4.3||M||M||M|
|HTTP Digest Authentication using IMS Gateway||5.4.4||O||O||M|
|GBA authentication using IMS Gateway||5.4.5||O||O||M|
|IMS registration – OITF||5.5||O||O||M|
|HTTP authentication session||5.6.3||M||M||M|
|SAML web-based SSO||5.6.4||M||M||M|
|Forced Play Out Using Media Zones||6||O||O||O|
|1.||At least one of TCA, GCA-CI+ or GCA-DTCP shall be supported.|
|2.||Support for Volume 7 [OIPF_CSP2] sections 4.2.1 and 4.2.2 on DAE and CSPG interfacing are also optional in the OITF if the GCA is not supported.|