OIPF - Release 2 Specification - Volume 3, Content Metadata, V2.3

Abstract

This Technical Specification (TS) has been produced by the Open IPTV Forum.

This specification provides multiple options for some features. The Open IPTV Forum Profiles specification complements the Release 2 specifications by defining the Open IPTV Forum implementation and deployment profiles. This document is Volume 3 in the 10 Volume set of specifications that define the Open IPTV Forum Release 2 Solution.

The other Volumes in the set are:

Volume 1 – Overview [OIPF_OVIEW2],
Volume 2 – Media Formats [OIPF_MEDIA2],
Volume 2a – HTTP Adaptive Streaming [OIPF_HAS2],
Volume 3 – Content Metadata (the present volume),
Volume 4 – Protocols [OIPF_PROT2],
Volume 4a – Examples of Protocol Sequences [OIPF_PROT_EX2],
Volume 5 – Declarative Application Environment [OIPF_DAE2],
Volume 5a – Web Standards TV Profile [OIPF_WSTVP2],
Volume 6 – Procedural Application Environment [OIPF_PAE2], and
Volume 7 – Authentication, Content Protection and Service Protection [OIPF_CSP2].

Acronym	Explanation
AV	Audio/Video
CE-HTML	Consumer Equipment HTML
CRID	Content Reference Identifier
DVBSTP	DVB SD&S Transport Protocol
DVB	Digital Video Broadcast
EIT	Event Information Table
EIT P/F	EIT Present/Following
FCC	Fast Channel Change
FDT	File Delivery Table
HNED	Home Network End Device
IMI	Instance Metadata Identifier
NG	Network Generated
RET	Retransmission
SDT	Service Description Table
SOAP	Simple Object Access Protocol
SPTS	Single Program Transport Stream
SVG	Scalable Vector Graphics
TS	Transport Stream
XSD	XML Schema Definition

3. Metadata Content

This clause defines the Open IPTV Forum extensions to the SD&S and BCG schemas and the AV classification schemes. Please refer to the SD&S [SDNS] and BCG [BCG] specifications for the base schemas.

3.1 Schema Extension and Validation

Open IPTV Forum metadata is in the form of instance document which is validated against a schema defined in this specification. The Open IPTV Forum XML schema is obtained by extending SD&S [SDNS] and BCG [BCG] schemas.

3.1.1 Metadata Extensibility

This specification provides schema descriptions of those elements and attributes that are extended from original schema defined in [SDNS] for SD&S or [BCG] for BCG. The extension rule adopted in this specification follows the “forward compatibility” constraints specified for extending BCG Schema [TVA-UNID].

3.1.2 Metadata Validation

No specific XSD validation tool is mentioned in [SDNS] for SD&S or [BCG] for BCG. Content that is purported to conform to the extension specified in this specification must pass a validation test using any widely-accepted XSD validation engine. In cases where the narrative description of this specification conflicts with the extended schema, the narrative will be considered authoritative. A companion schema (.xsd) documents associated with this specification provides the consolidated XML schema definition of SD&S and BCG metadata extended as the Open IPTV Forum metadata.

3.2 SD&S (Service Discovery and Selection) Extensions

This clause describes the Open IPTV Forum extensions to the SD&S schema described in [SDNS] in conjunction with the generic application signalling defined in [TS102809]. SD&S records provide an XML-based description of Service Providers and their Services. They enable OITFs to discover and select appropriate services. In addition to [TS102809], the Open IPTV Forum provides extensions which provide a means to signal web-based applications from within SD&S records. There are also Open IPTV Forum extensions provided for

Bandwidth renegotiation,
Purchasing a Broadcast Service,
Indicating Container Format.

For FCC/RET, no extensions are required, but the definition of one SD&S element is extended in order to indicate to the OITF to use the cookie signalling method for FCC/RET services, without breaking the interpretation of this SD&S element for non-OIPF deployments.

All schema extensions are described in Annex B. For details of the original SD&S schema, please see [SDNS].

3.2.1 Service Provider Discovery Extensions

Service Provider Discovery information contains information about Service Providers including references to the Service offerings as along with any OIPF specific services (e.g. emergency notification service) they provide. Further details of the Service Provider XML schema can be found in clause 5.2.13.7 of [SDNS].

The Service Provider Type is extended by Open IPTV Forum to signal the access information for the Emergency Notification service.

The schema for the extension is provided in Annex B.3.

Figure 1: Outline of Service Provider Record updates

3.2.1.1 Emergency Notification Service

EmergencyNotificationService contains SDP-based session description that the terminal needs in order to receive emergency notification message. Two methods are used to carry session information:

Inline: where the SDP file is inlined in the Service Provider XML document as element content. This is useful for situations where the contents of the SDP file are fixed.
Out of band: where the SDP file is delivered independently of the Service Provider XML document. This is useful for situations where the contents of the SDP file are not necessarily fixed. In this case, the SDP file can be delivered via unicast or multicast.

For unicast, an URL is provided; for multicast, a SDPStream together with a SDPURI are provided. The schema for the extension is provided in Annex B.4. The following table provides a description of the parameters.

Table 1: Extract of EmergencyNotificationService Type Sementics
Element / Attribute Name	Element / Attribute Description
EmergencyNotificationService	A complex type to describe access information for emergency notification service of a specific Service Provider.
SDPURL	An element specifying unicast location of SDP file describing the access information for Emergency Notification Service.
inlineSDP	An element specifying embedding the SDP file describing the access information for Emergency Notification Service.
SDPRef	A complex type to describe multicast location for the SDP of emergency notification service.
SDPStream	An element specifying embedding the SDP file describing the access information of a multicast file delivery session.
SDPURI	An element specifying URI of a SDP file.

Figure 2: Emergency Notification structure

3.2.2 Service Discovery Extensions

Service Discovery records provide descriptive information about and access details to the services (e.g. service name, service URL, etc.) offered by a service provider, for example, linear TV broadcasts or BCG(s).

Three types of extension are defined by the Open IPTV Forum:

Bandwidth renegotiation
Purchasing broadcast services
Indicating Container Format

3.2.2.1 Bandwidth Renogiation

The MaxBitrate element in the IPService Record of SD&S [SDNS] shall be provided in case of scheduled content services with SIP session management provided in managed networks relying on IMS. It is used during session initiation or session modification to ensure that the necessary bandwidth is available in the network.

Table 2: Extract of Broadcast Discovery Record Indicating MaxBitrate Extension
Element / Attribute Name	Element / Attribute Description	Mandated/ Optional
BroadcastOffering type:	/BroadcastDiscovery
IPService type (one entry per service):	/BroadcastDiscovery/ServiceList/SingleService
MaxBitrate	Specifies the maximum bitrate of the overall stream carrying the service.	O

The IPService Record of SD&S [SDNS] is extended for scheduled content services with SIP session management with an optional TimeToRenegotiate element that when present is used to determine when down-sizing of the reserved bandwidth for the content session is performed.

See Annex B.7 for the IPServiceType schema extension.

Table 3: Extract of Broadcast Discovery Record Indicating TimeToRenegotiate Extension
Element / Attribute Name	Element / Attribute Description	Mandated/ Optional
BroadcastOffering type:	/BroadcastDiscovery
IPService type (one entry per service):	/BroadcastDiscovery/ServiceList/SingleService
TimeToRenegotiate	This element provides the duration in seconds to be used in conjunction with MaxBitrate to determine when renegotiation of network bandwidth is to occur.	O

Each service is represented by an IPService structure in the Broadcast Discovery Record. When the service is changed, typically through a user initiated channel change request, the TimeToRenegotiate value will be used for scheduled content services with SIP session management in conjunction with the MaxBitrate to determine how bandwidth re-negotiation will be performed.

Note that at every channel change if there is a pending timeout for session modification due to a previous service change then it is cancelled. The OITF may initiate a new session modification as described below.

The TimeToRenegotiate element should only be provided in an IPService structure representing a scheduled content service with SIP session management. When the TimeToRenegotiate element is provided with the IPService record then

If the MaxBitrate of the new service is greater than the reserved bandwidth, network bandwidth reservation using the MaxBitrate of the new service shall occur immediately to ensure sufficient bandwidth is made available for the new service.
If the MaxBitrate of the new service is equal to the reserved bandwidth, network bandwidth reservation procedures shall not be performed as sufficient bandwidth is already available for the new service.
If the MaxBitrate of the new service is less than the reserved bandwidth, network bandwidth reservation using the MaxBitrate of the new service shall occur after the period (in seconds) provided by the TimeToRenegotiate element of the new service.

3.2.2.2 Purchasing Broadcast Services

The IPService Record of SD&S [SDNS] is extended to include an optional PurchaseItem element. The PurchaseItem element allows conditions to be placed on the availability of purchased content.

See Annex B.7 for the IPServiceType schema extension.

Table 4: Extract of Broadcast Discovery Record Indicating PurchaseItem Extension
Element / Attribute Name	Element / Attribute Description	Mandated/ Optional
BroadcastOffering type:	/BroadcastDiscovery
IPService type (one entry per service):	/BroadcastDiscovery/ServiceList/SingleService
PurchaseItem	This element provides a means to purchase a service. This element has extended the tva:PurchaseItemType in order to include DRM control information.	O

For further details about PurchaseItem type, refer to section 3.3.2 of this document.

3.2.2.3 Container Format Indication

The IPService Record of SD&S [SDNS] is extended to include an optional FileFormat element as defined in “AVAttributesType” defined in clause 6.3.5 of TV-Anytime specification [TVA]. This element provides a means to indicate file format.

See Annex B.7 for the IPServiceType schema extension.

Table 5: Extract of Broadcast Discovery Record Indicating FileFormat Extension
Element / Attribute Name	Element / Attribute Description	Mandated/ Optional
BroadcastOffering type:	/BroadcastDiscovery
IPService type (one entry per service):	/BroadcastDiscovery/ServiceList/SingleService
FileFormat	This element provides a means to indicate file format.	O

The FileFormat element shall be provided in case of scheduled content services with SIP session management provided in networks relying on IMS, to signal the use of SIP session management.

3.2.2.4 FCC/RET Attribute Definition

The SD&S FCC/RET attributes are defined in [FCC].

Table 6: Extract of Broadcast Discovery Record indicating redefined FCC/RET attributes
Element / Attribute Name	Element / Attribute Description	Mandated/ Optional
BroadcastOffering type:	/BroadcastDiscovery
IPService type (one entry per service):	/BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/IPMulticastAddress/Server-based LMB Enhancement Service
Retransmission_session@SourcePort	See below Open IPTV extended definition	O
Retransmission_session@DestinationPort	See below Open IPTV extended definition	O

The Retransmission_session@DestinationPort SD&S attribute defined in [FCC] shall be interpreted by an OITF as

“UDP Destination Port of unicast RTP Retransmission session packets.”

If the Retransmission_session@DestinationPort attribute is not present, AND neither is the Retransmission_session@SourcePort attribute, the destination port of unicast RTP Retransmission session packets matches the source port of the RTCP packets issued by the OITF for RTCP reporting in the primary/original multicast session.

If the Retransmission_session@DestinationPort attribute is not present, but the Retransmission_session@SourcePort attribute is present, the destination port for the FCC/RET packets may be determined by means of an in-band RTCP port mapping request message exchange of the OITF with the FCC/RET server on the port Retransmission_session@SourcePort (using symmetrical RTP, with RTP and RTCP mixed on a single port).

This means that when the OITF must operate according to the cookie signaling method, the Retransmission_session@DestinationPort attribute shall not be present, whereas the Retransmission_session@SourcePort attribute shall be present, with the latter indicating the destination port on which the OITF must issue its port mapping request message.

3.2.3 Application Announcement & Signaling

This section describes how to signal applications with [TS102809]. Two types of applications can be signalled; service provider related applications and broadcast related applications. Those two types of applications shall be signalled either at the phase of Service Provider Discovery or Service Discovery Record such as Broadcast Discovery Record, Package Discovery Record, and Application Discovery Record.

In the Service Provider Discovery record, a service provider can only signal service provider related applications. However, in the service discovery phase, both service provider related applications and broadcast related applications can be signalled. The detailed description of how to signal is described in the following sections.

The definition of XML schema for signalling applications is defined in [TS102809].

3.2.3.3 Platform Specific Definitions

ETSI TS 102 809 [TS102809] requires this specification to provide the following platform specific definitions: application types, application profiling, profile versioning, and the graphic formats used for application icons. These properties are contained in the Application descriptor.

3.2.3.3.1 Type Element of ApplicationDescriptor

The type element of the application descriptor defines the actual application environment that is used by the application [TS102809]. The MIME type of the application is carried in the OtherApp element of the type element and takes one of the following values:

for DAE CE-HTML applications this value shall be "application/vnd.oipf.dae.xhtml+xml"
for DAE SVG applications this value shall "application/vnd.oipf.dae.svg+xml"
for PAE applications this value shall be "application/vnd.oipf.pae.gem"

3.2.3.3.2 mhpVersion Element of ApplicationDescriptor

The mhpVersion element defines the actual profile and profile version of the platform which is required to run an application. If the mhpVersion element is used in the ApplicationDescriptor [TS102809], the below values shall be set.

profile: as specified in the OIPF Profiles Specification
versionMajor: 2
versionMinor: 3
versionMicro: 0

Note that the name mhpVersion is historic.

3.2.3.3.3 Specific ApplicationUsage Element of ApplicationUsageDescriptor

OIPF defines specific application usages for ServiceDiscovery, Communication and ContentGuide applications. This is signalled using the ApplicationUsageDescriptor as defined in [TS102809]. If the ApplicationUsage element is used in the ApplicationDescriptor, it shall be set to one of the following values:

A Service Discovery application shall be signalled with a value of "urn:oipf:cs:ApplicationUsageCS:2010:servicediscovery".
A Communication application shall be signalled with a value of "urn:oipf:cs:ApplicationUsageCS:2010:communication".
An EPG application shall be signalled with a value of "urn:oipf:cs:ApplicationUsageCS:2010:epg".
A VoD application shall be signalled with a value of "urn:oipf:cs:ApplicationUsageCS:2010:vod".
An HNI-IGI application shall be signalled with a value of "urn:oipf:cs:ApplicationUsageCS:2010:hni-igi".
An NG Notification application shall be signalled with a value of "urn:oipf:cs:ApplicationUsageCS:2010:ngnotification".

The ApplicationUsageCS can be found in Annex D.

3.2.3.3.4 Graphic Format for Application Icons

The graphic formats used for application icons are defined in [OIPF_MEDIA2].

3.2.3.3.5 Application Extensions

In addition to the transport protocols defined in [TS102809], OIPF defines a multicast transport method using FLUTE. In order to signal this transport method the Application element of [TS102809] is extended by the FLUTESessionDescriptor. The schema extension of the Application element and the definition of the FLUTESessionDescriptor can be found in Annex B.6.

3.2.3.3.6 ApplicationSpecificDescriptor Extensions

The applicationSpecificDescriptor [TS102809] shall be used in order to signal the application location with following extension.

DAE applications [OIPF_DAE2] shall be signalled using the SimpleApplicationLocationDescriptorType from [TS102809].
PAE applications [OIPF_PAE2] shall be signalled using the DVBJDescriptor defined in [GEM].

3.3 BCG (Broadband Content guide) Extensions

BCG metadata instance shall conform to the profile of options that are either mandatory, optional or not used, as defined in BCG [BCG]. This section describes extended elements and classification scheme to be applied for Open IPTV Forum services. It provides descriptions, structural diagrams and semantics definitions of elements and attributes that extend their original BCG counterparts. The Open IPTV Forum extended XML schema is defined in the Annex C and Open IPTV Forum classification scheme definitions are defined in Annex D.

3.3.1 Signalling and Media Transport Protocol Extension

3.3.1.1 OnDemandProgramType Extension

Content on Demand can be delivered in Open IPTV Forum using a combination of different signalling and media transport protocols. Information about the protocols used may be signalled in the OnDemandProgramType using the following extension.

Table 7: Extract of OnDemandProgram Type Indicating Protocol Type Extension
Element / Attribute Name	Element / Attribute Description
OnDemandProgramType	A complex type derived from ProgramLocationType used to describe instances that can be acquired on demand (as opposed to broadcast).
Protocol	An element specifying the protocol for content item delivery. This element refers to the term defined in Protocol Classification Scheme, defined in Annex D.4

Extended OnDemandProgramType, defined in Annex C.5, has the following structure:

Figure 3: OnDemandProgramType Extension for the protocol element

3.3.1.2 Extension for Notification Information Table

The Service Information Type from [BCG] is extended by Open IPTV Forum to define the Notification Information Table for use by the Network Generated Notification service and User Notification service.

The Notification Information Table shall be carried in BCG as a new table under “ProgramDescription”, as depicted in Figure 4. Program description and schedule event description for notification service shall refer to the notification service fragment by “serviceIDRef”. The schema and semantics for notification program description and notification schedule event description shall be the same as those for scheduled content service.

Figure 4a — Figure 4: ProgramDescriptionType Extension for the notification information

Figure 4b — Figure 4: ProgramDescriptionType Extension for the notification information

3.3.1.3 Definition of Elements in RelatedMaterialType

The elements of the TV-Anytime RelatedMaterialType are used by the Open IPTV Forum to indicate the relationship between scheduled content and the related notification service, as described in the following table.

Table 8: Use of elements from RelatedMaterialType
Element	Semantics
HowRelated	Specifies the nature of the relationship between the described fragment and the related media assets. The value of this field can use the terms available in the classification scheme urn:tva:metadata:cs:HowRelatedCS:2007. In particular, term 24 “IsPartOf” shall be used to indicate the main service of the described notification service.
MediaLocator	Specifies the location of the media asset. Defined as an MPEG-7 datatype, MediaLocatorType (see clause 6.5.2 of ISO/IEC 15938-5 [MPEG-7] for a detailed description). When the HowRelated takes the term 24, it specifies the ID of the referred Service or ScheduleEvent of a regular service.
PromotionalText	Specifies promotional information about the link, which can be used as an additional attractor (e.g. record "Pride and Prejudice" series).
PromotionalMedia	Specifies non-text promotional information such as a logo.

3.3.2 DRM Control Information Extension

3.3.2.1 PurchaseItemType Extension

The BCG is extended to hold the elements used as DRM control parameters. The PurchaseItemType as defined in clause 6.3.4 of TV-Anytime specification [TVA] is extended by the following DRMControlInformation schema to signal those parameters. The usage of those parameters is described in volume 7 [OIPF_CSP2].

The existing DRMDeclaration element in the BCG shall not be used in Open IPTV Forum services.

Table 9: DRMControlInformation Type Semantics
Element / Attribute Name	Element / Attribute Description
DRMControlInformation
DRMSystemID	URN with the DVB CA System ID (16 bit number) in there or URN described in section 4.1.7.1 of [OIPF_CSP2]. Allocations of the DVB CA System ID value of this field are found in [DVB-ID]. DRMSystemID with the DVB CA System ID shall be signalled by prefixing the decimal number format of CA_System_ID with "urn:dvb:casystemid:". For example, hexadecimal 0x4AF4 is assigned as CA_System_ID for “Marlin” by DVB, “Marlin” DRMSystemID is encoded as “urn:dvb:casystemid:19188”. Note that the decimal number format of CA_System_ID shall not have leading zeroes.
DRMContentID	DRM Content ID for CoD or scheduled content item, e.g. the Marlin Content ID
RightsIssuerURL	A URL used by OITF to obtain rights for this content item
SilentRightsURL	A URL used by OITF to obtain rights silently, e.g. a Marlin Action Token.
PreviewRightsURL	A URL used by OITF to obtain rights silently for preview of this content item, e.g. a Marlin Action Token.
DoNotRecord	A flag indicates this content item is recordable or not. True means this content is not recordable.
DoNotTimeShift	A flag indicates this content item is allowed for time shift play back. True means time shift playback is not allowed.
DRMGenericData	Placeholder for generic data that is applicable to all DRM schemes to be applied for this content item.
DRMPrivateData	Private data for the DRM scheme indicated in DRMSystemID to be applied for this content item. This structure can be substituted by DRM system specific structure.

The extended PurchaseItemType, defined in Annex C.4, has the following structure.

Figure 5: PurchaseItemType extension for the DRMControlInformation

3.3.3 Open IPTV Forum Classification Schemes

The following classification schemes wholly replace the BCG equivalent classification schemes.

3.3.3.1 VideoCodingFormat Classification Scheme

The element “coding” in “VideoAttributesType” defined in clause 6.3.5 of TV-Anytime specification [TVA] shall refer to the terms listed in VisualCodingFormatCS (Annex D.1) of this specification.

3.3.3.2 AudioCodingFormat Classification Scheme

The element “coding” in “AudioAttributesType” defined in clause 6.3.5 of TV-Anytime specification [TVA] shall refer to the terms listed in AudioCodingFormatCS (Annex D.3) of this specification.

3.3.3.3 AVMediaFormat Classification Scheme

The element “FileFormat” in “AVAttributesType” defined in clause 6.3.5 of TV-Anytime specification [TVA] shall refer to the terms listed in AVMediaFormatCS (Annex D.3) of this specification.

3.3.3.4 Protocol Classification Scheme

The element “Protocol” in “OnDemandProgramType” defined in clause 3.3.1 of this specification shall refer to the terms listed in ProtocolCS (Annex D.4).

3.3.3.5 Reference to Parental Guidance Classification Scheme

The element “ParentalGuidance” in “BasicContentDescriptionType” defined in TV-Anytime specification [TVA] clause 6.3.4 shall refer to the terms referred by the description for “ParentalGuidance” and also the terms listed in GermanyFSKCS (Annex D.5).

3.3.4 Program Information Extension

The ProgramInformationType as defined in clause 6.3.6 of TV-Anytime specification [TVA] is extended to indicate the availability of bookmarking for content.

Table 10: Use of DoNotBookmark element in Program Information
Element / Attribute Name	Element / Attribute Description
ProgramInformationType	A complex type that describes a programme
DoNotBookmark	A flag indicating if this content item is allowed for bookmarking or not. True means bookmarking is not allowed.

3.3.5 Service Information Extension

The ServiceInformationType as defined in clause 6.4.3 of TV-Anytime specification [TVA] is extended to indicate the availability of bookmarking for all programs of a service. When it conflicts with program level indication, then program level indication has higher priority.

Table 11: Use of DoNotBookmark element in Service Information
Element / Attribute Name	Element / Attribute Description
ServiceInformationType	A complex type that describes a service
DoNotBookmark	A flag indicating if content items delivered in this service are allowed for bookmarking or not. True means bookmarking is not allowed.

4. Metadata Control and Delivery

This clause explains how to deliver metadata to the client and how the client may handle it, including how to manage metadata updates.

4.1 Metadata Delivery Mechanism

This clause explains how SD&S and BCG XML metadata is carried over the network.

Delivery of SD&S and BCG metadata shall be as described in the respective SD&S [SDNS] and BCG [BCG] specifications, with the following extensions.

4.1.1 Carriage of SD&S metadata

This clause specifies the protocols that are used to deliver SD&S metadata information for multicast and unicast. For the delivery over multicast, the DVBSTP protocol shall be used as defined in clause 5.4.1 of SD&S [SDNS]. For unicast delivery, the HTTP protocol shall be used as defined in clause 5.4.2 of SD&S [SDNS].

4.1.1.1 Encoding SD&S metadata

Encoding SD&S metadata may be supported as described in clause 5.5 of SD&S [SDNS].

4.1.1.2 Update mechanism for SD&S

The Update mechanism shall be supported as described in clause 5.4.3 of SD&S [SDNS].

4.1.2 Carriage of BCG metadata

BCG metadata has two different transport means to carry BCG metadata: Container Based delivery, and Text Based delivery based on Query mechanism.

Container based delivery of BCG metadata shall conform to clause 4.1 of [BCG].

The OITF may support the SOAP Query mechanism for text-based delivery.

4.1.2.1 Container based delivery

This clause specifies the protocols that are used to deliver BCG metadata information for multicast and unicast. For the delivery over the multicast, the DVBSTP protocol shall be used as defined in clause 4.1.2.2.1 of BCG [BCG]. For unicast delivery, the HTTP protocol shall be used as defined in clause 4.1.2.2.2 of BCG [BCG].

4.1.2.1.1 Encoding BCG metadata

Encoding BCG metadata may be supported as described in BCG [BCG]. BCG metadata can also be delivered without encoding.

4.1.2.1.2 Update mechanism for BCG

The lifecycle of delivered metadata is managed through a fragment updating method. The instance is identified through individual fragment id and its versioning is managed by fragment version. The details of update management and the unit of fragment are described in TV-Anytime specification [TVA-UNID]. OITF client is able to detect the changes of fragment version through the method described in clause 5.4.3 of SD&S [SDNS].

4.1.2.2 SOAP Query Mechanism

The query mechanism for metadata acquisition is described in this clause. It shall be implemented according to clause 4.2 of BCG [BCG].

As indicated in Table 4 of BCG [BCG], the mandatory SOAP methods (described in TV-Anytime specification [TVA-BID]) shall be:

Table 12: Methods of SOAP
Method	Service Provider	HNED
get_Data	M	M
describe_Get_Data	M	M

The following clauses outline each of these methods. The TV-Anytime specification [TVA-BID] should be referred to for more detailed guidelines.

In all examples the SOAP and HTTP wrappers are omitted for clarity.

4.1.2.2.1 get_Data (informative)

The get_Data method allows a client to query a server in order to retrieve BCG data for a set of programmes or programme groups. The flexibility of the query syntax enables simple or complex queries to best restrict the set and size of the metadata response. For example, a simple query could request program information for a specific content identifier or program title. Alternatively, more powerful queries can be generated by combining these simple queries, for example, to create an EPG a request can be made for all program and schedule information across a range of services between specific dates. Content resolution can also be performed using the same method to retrieve content referencing information for one or more content identifiers.

Optional parameters are available to limit the number of results (e.g. 10 results) and to sort them (e.g., sort alphabetically by title). Support for these features is optional on the server and indicated to the client in a describe_Get_Data response (see Example 4 in clause 4.1.2.2.2).

The query mechanism is fully defined in clause 5.1 of TV-Anytime specification [TVA-BID], with many examples of potential requests given in Annex C of TV-Anytime specification [TVA-BID].

The following is an example client get_Data request for the program information of all programs with a title equal to “News”:

<get_Data xmlns="urn:tva:transport:2007" ...>
  <QueryConstraints>
    <BinaryPredicate fieldID="tvaf:Title" fieldValue="News"/>
  </QueryConstraints>
  <RequestedTables>
    <Table type="ProgramInformationTable"/>
  </RequestedTables>
</get_Data>

Example 1: Client get_Data request [TVA-BID]

And the Server’s response to this request:

<get_Data_Result serviceVersion="1" xmlns="urn:tva:transport:2007"...>
  <TVAMain>
    <ProgramDescription>
      <ProgramInformationTable>
        <ProgramInformation programId="CRID://www.broadcaster.com/News1">
          <BasicDescription>
            <Title>News</Title>
            <Genre href="urn:tva:metadata:cs:ContentCS:2007" type="main">
              <Name>News</Name>
            </Genre>
          </BasicDescription>
        </ProgramInformation>
        <ProgramInformation programId="CRID://www.broadcaster.com/News2">
          <BasicDescription>
            <Title>News</Title>
            <Genre href="urn:tva:metadata:cs:ContentCS:2007" type="main">
              <Name>News</Name>
            </Genre>
          </BasicDescription>
        </ProgramInformation>
      </ProgramInformationTable>
    </ProgramDescription>
  </TVAMain>
</get_Data_Result>

Example 2: Server response to get_Data request [TVA-BID]

4.1.2.2.2 describe_Get_Data (informative)

The describe_Get_Data method provides a client with information concerning the server’s capabilities in terms of get_Data requests. For example, it will specify the metadata tables available to be queried, possibly also listing the particular fields that can be searched or sorted on.

The following example is a request for the Server’s get_Data capabilities:

<describe_Get_Data xmlns="urn:tva:transport:2007"/>

Example 3: Client describe_Get_Data request [TVA-BID]

The response (shown below) provides a description of the BCG provider along with its capabilities, such as supported domains, table types, specific fields that can be queried and sorted, and for which Services it provides metadata:

<describe_get_Data_Result serviceVersion="1" xmlns="urn:tva:transport:2007"
    xlmns:tva="urn:tva:metadata:2007"
    ulmns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Name>Metadata Service</Name>
  <Description>A Metadata Service</Description>
  <AuthorityList>
    <Authority>broadcaster.com</Authority>
  </AuthorityList>
  <AvailableTables xmlns:tvaf="urn:tva:transport:fieldIDs:2007">
    <Table xsi:type="ProgramInformationTable"
      canQuery="tvaf:CRID tvaf:Synopsis tvaf:KeyWord tvaf:Genre"/>
    <Table xsi:type="ServiceInformationTable"
      canQuery="tvaf:serviceID tvaf:Name tvaf:ServiceURL"/>
    <Table xsi:type="ProgramLocationTable"
        canQuery="tvaf:ServiceURL tvaf:PublishedTime"
        canSort="tvaf:ServiceURL tvaf:PublishedTime">
      <AvailableLocations>
        <Availability>P7D</Availability>
        <ServiceURL>dvb://2.7d1.13</ServiceURL>
        <ServiceURL>dvb://2.7d1.14</ServiceURL>
      </AvailableLocations>
    </Table>
  </AvailableTables>
</describe_get_Data_Result>

Example 4: Server’s describe_Get_Data Response [TVA-BID]

4.1.2.2.3 SOAP Update mechanism for BCG

The overall BCG XML document may have a version number associated with it. In addition, the BCG fragments may have an ID and version number associated with them, allowing the client to request fragment updates using the SOAP Query mechanism [TVA-BID]. Server support for fragment updates is indicated through the server’s describe_Get_Data capabilities. See clause 5.1.2.4 of TV-Anytime [TVA-BID] for further details.

4.1.3 Event Information Tables (EIT)

This section is related to the extension of TS Optional SI profile with EIT p/f (without SDT). The scope of this section is to allow an OITF to retrieve metadata embedded in a DVB Transport Stream.

A unicast mechanism for metadata retrieval can provoke server overload when a large number of OITFs try to access the same information at the same time (i.e. request information for an event during frequent channel changes). As EITs are synchronized with the content at TV head end level, EIT allows the OITF to have up-to-date information even if the content changes at the last minute or is longer than originally defined (e.g., prolongation in a football match) without any request to a server. The information contained in EIT can be used, for example, to show the title and duration of an item of content in a zapper application.

For IPTV services, if the OITF is able to use EIT embedded in a DVB Transport Stream, then the following section applies. This section is restricted to DVB world and is only applicable for MPEG-2 Transport Streams.

The EIT p/f contains metadata concerning events such as event name, start time, duration, etc. These metadata related to a piece of contents should be transported and synchronized directly into the transport stream using the EITs tables as describe in DVB-SI specification [DVBSI].

For Open IPTV Forum, EIT information is restricted to the following two main types of table:

actual TS, present/following event information = table_id = "0x4E";
other TS, present/following event information = table_id = "0x4F";

The schedule informations table_id = "0x5F" and "0x6F" are not in the scope of this specification.

4.1.3.1 How to link EIT p/f with SD&S without SDT

As there is no SDT in the MPEG-2 TS optional SI profile, the EIT p/f information is linked to the content using the "DVBTriplet" present in the SD&S information with the Original Network Id, TS Id, Service Id present in the EITs.

Table 13: DVBTriplet ID Explanation
DVBTriplet@Original Network Id	Identifies the network Id of the originating delivery system	M
DVBTriplet@TS Id	Identifies the Transport Stream	M
DVBTriplet@Service Id	Identifies a service from any other service within the TS. The service Id is the same as the program number in the corresponding program map table.	M

4.1.3.2 How to optimize the transport of EIT p/f (informative)

This section is an informative part that provides guidance in order to optimize the transport of EIT p/f actual/other tables over IP in MPEG-2 TS.

In this specification the usage of EIT p/f Actual TS and Other TS can be optimized to give the Open IPTV Forum user a better user experience. To achieve this goal, the cycle time of the EIT p/f actual TS can be reduced to 1second and a Service Provider may also choose to send more than one EIT p/f Actual table by SPTS.

Sending more than one EIT p/f Actuals tables allows the Service Provider to send a set of metadata related to some channels that are frequently used, at a quick cycle time (e.g. 1 or 2 second). For other channels that are less frequently viewed EIT p/f can be sent at a lower cycle time by using the EIT p/f other tables.

4.2 Link between SD&S and BCG (informative)

This clause details how to link from SD&S metadata [SDNS] to BCG [BCG] metadata, useful for creating EPGs (Electronic Program Guides). More detailed definitions and descriptions can be found in SD&S [SDNS], BCG [BCG], and TV-Anytime specification [TVA].

The SD&S metadata describes all services for each service provider such as broadcasting services, CoD services, BCG services, and so on. BCG metadata describes detailed information about pieces of content and services. If BCG service information is present, it shall take precedence over SD&S service information as described in clause 6.6 of BCG [BCG].

In order to make an EPG, some elements of SD&S metadata information and BCG metadata information should be linked.

4.2.1 Locating a BCG for a Service using SD&S

Access to a BCG service is described in a BCG Discovery Record, which is linked to from a Broadcast Discovery Record. To enable this, the following SD&S elements should be used:

Broadcast Discovery
- URI identifier of a BCG Discovery record. Either:
  - BroadcastDiscovery/SI/ServiceDescriptionLocation or
  - BroadcastDiscovery/ServicesDescriptionLocation

In accordance with clause 5.2.13.2 of SD&S [SDNS], if present, SI/ServiceDescriptionLocation shall take precedence. Furthermore, if more than one BCG Discovery record is specified, a single preferred record may optionally be signalled using the “preferred” attribute.

BCG Discovery
- Identifier of BCG Record
  - BCGDiscovery/BCG@Id
- One of delivery information of BCG metadata
  - BCGDiscovery/TransportMode/DVBSTP
  - BCGDiscovery/TransportMode/HTTP@Location or BCGDiscovery/TransportMode/HTTP@SOAP

Figure 6 indicates how to receive BCG metadata relating to a single service or a couple of services in Broadcast Discovery information. In order to signal BCG metadata for a single service or services’ list, the value of “ServiceDescriptionLocation” or “ServicesDescriptionLocation” in Broadcast Discovery must be the same. The transport address of BCG metadata is described in the children nodes of “TransportMode” element in the BCG Discovery. With this address, the OITF can receive BCG metadata for a single service or a couple of services (either through push or pull container based mechanism, or through SOAP querying).

Figure 6: How to link a service in Broadcast Discovery with BCG Discovery

4.2.2 Linking SD&S Service Information with BCG

The BCG Discovery record allows the OITF to receive all BCG metadata relating to a single service or a couple of services.

To create an EPG, for example, with the received BCG metadata and SD&S metadata, the following BCG metadata elements should be used:

ServiceInformationTable
- TVAMain/ProgramDescription/ServiceInformationTable/ServiceInformation@serviceId
  - Unique Identifier of Service whose syntax is defined in clause 5.2.1.2 of SD&S [SDNS] - equals the ServiceName attribute in the associated SD&S Broadcast Discovery record (See clause 6.4 in BCG [BCG]).
Schedule Element in ProgramLocationTable
- ProgramLocationTable/Schedule@serviceIDRef
  - Reference of a serviceId
  - serviceIDRef value must be the same as the associated serviceId in ServiceInformationTable
- ProgramLocationTable/Schedule/ScheduleEvent/Program@crid
  - CRID information of a program in a service. Provides link to detailed program description, found in the ProgramInformationTable.
- ProgramLocationTable/Schedule/ScheduleEvent/PublishedStartTime
  - Advertised start time of a single program in a service
- ProgramLocationTable/Schedule/ScheduleEvent/PublishedDuration
  - Advertised duration of a single program.
ProgramInformationTable
- ProgramInformationTable/ProgramInformation@programId
  - CRID value of a single program
  - programId value should be the same with one of CRID values in ProgramLocationTable

Figure 7 describes how to find description information in BCG from a single service of Broadcast Discovery. Service information in SD&S and BCG metadata is linked as described in clause 6.4 of BCG [BCG] (BCG ServiceInformation@serviceId = SD&S BroadcastDiscovery ServiceName attribute). Once the serviceId value in ServiceInformationTable is found, a single service’s schedule events can be retrieved from the ProgramLocationTable. Then, Program@CRIDs in ScheduleEvent values can be used to find detailed information of a single content by referencing ProgramInformation@programId.

Figure 7: How to Find Description Information in BCG from SD&S Metadata

In summary, an OITF can receive a single service, for example broadcaster1, from SD&S’s Broadcast Discovery record. With BCG@Id value in BCG Discovery, the OITF can collect BCG metadata which has all EPG information of broadcaster1 service. OITF compares serviceId values in ServiceInformationTable of BCG metadata in order to find a match with the same value of broadcaster1’s ServiceName attribute of Broadcast Discovery record. Once OITF finds the same service from the ServiceInformationTable, OITF can find the ScheduleEvents of broadcaster1’s service, allowing the OITF to create the EPG’s time table of a single channel. The detailed information of a single event can be described by BasicDescription using ProgramInformation@programId of ProgramInformationTable.

4.3 CRID Location Resolution

BCG CRID Location Resolution is the process of mapping a CRID to other CRIDs (e.g. for a series) or to a Locator (e.g. RTSP URL). A Locator provides accurate location and timing information for where and when to retrieve the content.

The OITF that supports BCG shall support content resolution:

The OITF may support terminal-side resolution. If so, it shall be delivered using the container-based mechanisms, as specified by clause 5 of BCG [BCG].
The OITF shall support server-side resolution using the protocol defined in [TVA-BID].

A service provider may provide content resolution information.

4.3.1 CoD Service with SIP session management

The BCG provides two approaches to identifying each instance of content (e.g. HD and SD versions of InterestingMovie):

one CRID per instance (e.g. a “HD InterestingMovie CRID” and an “SD InterestingMovie CRID”)
one CRID for the content (e.g. a “InterestingMovie CRID”) and two IMIs for each instance (e.g. a “HD IMI” and an “SD IMI”); the combination of CRID and IMI identifies the appropriate instance.

It is a service provider decision as to which approach is used.

To enable either approach to be used for Content on Demand services using SIP session management provided in managed networks relying on IMS, CoD session setup and initiation shall use the CRID and an Instance Metadata Identifier (where one exists) in conjunction with the process defined in clause 5.3.2 of the Protocol specification [OIPF_PROT2].

This clause defines the format of the wild card portion of the “Request URI”.

The wild card part (*) of the Request URI shall be constructed from the CoD’s CRID and Instance Metadata Identifier (IMI), as signalled in the BCG, in accordance with the following format, as specified in clause 12.1.4 of [DVBTRANS]

<CRID>[#<IMI>]

As a CRID is composed of an <authority> and <data> section and an IMI is composed of a <name> and <data> section, the above construction can be represented in greater detail as:

<CRID_authority>/<CRID_data>[#[<IMI_name>/]<IMI_data>]

The “CRID://” and “imi:” portions of the respective identifiers shall be omitted.

The IMI portion of the Request URI is optional; however, if an IMI is signalled in the BCG for a CoD instance, it shall be included in the Request URI.

For example:
In the case where the HD version of InterestingMovie is signalled with a CRID of “CRID://newstudio.com/InterestingMovieHD”, the wild card part of the Request URI would be:

newstudio.com/InterestingMovieHD

If however, InterestingMovie is signalled with a CRID of “CRID://newstudio.com/InterestingMovie”, and has a HD instance with the IMI: “imi:hd”, the wild card part of the Request URI for the HD instance would be:

newstudio.com/InterestingMovie#hd

Annex A. Open IPTV Forum SD&S Data Model (Informative)

The Open IPTV Forum service discovery model is represented in the Figure 8.

Figure 8: Open IPTV Forum SD&S Data Model

Annex B. Schema Extension for SD&S

B.1 Namespace

The namespace for Open IPTV Forum is “urn:oipf:service:sdns:2010-1”.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oipf:service:sdns:2010-1"
  xmlns:tns="urn:oipf:service:sdns:2010-1" xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:tva="urn:tva:metadata:2011"
  xmlns:oipfbcg="urn:oipf:service:bcg:2010-1"
  xmlns:mis="urn:dvb:mhp:2009">
<!-- schema filename is service-sdns.xsd -->

B.2 Import namespace and schema

<xs:import namespace="urn:tva:metadata:2011"
  schemaLocation="imports/tva_metadata_3-1_v171.xsd"/>
<xs:import namespace="urn:oipf:service:bcg:2010" schemaLocation="service-bcg.xsd"/>
<xs:import namespace="urn:dvb:mhp:2009" schemaLocation="imports/mis_xmlait.xsd"/>

B.3 Extension for ServiceProvider Type

<xs:complexType name="ServiceProviderType">
  <xs:complexContent>
    <xs:extension base="mis:ServiceProviderType">
      <xs:sequence>
        <xs:element name="EmergencyNotificationService"
          type="tns:EmergencyNotificationServiceType" minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

B.4 EmergencyNotificationService Type

<xs:complexType name="EmergencyNotificationServiceType">
  <xs:choice>
    <xs:element name="SDPURL" type="xs:anyURI"/>
    <xs:element name="inlineSDP" type="tns:inlineSDPType"/>
    <xs:element name="SDPRef" type="tns:SDPRefType"/>
  </xs:choice>
</xs:complexType>
<xs:simpleType name="inlineSDPType">
  <!--- Note: the InlinedSDP below must be embedded in a CDATA section -->
  <xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:complexType name="SDPRefType">
  <xs:sequence>
    <xs:element name="SDPStream" type="tns:inlineSDPType"/>
    <xs:element name="SDPURI" type="xs:anyURI"/>
  </xs:sequence>
</xs:complexType>

B.5 Application Extension

The following extension to the Application type (see section 5.4.4.2 of [TS102809] for the latest version of this specification) is defined to incorporate a FLUTESessionDescriptor (see Annex B.6)

<xs:complexType name="OIPFApplication">
  <xs:complexContent>
    <xs:extension base="mis:Application">
      <xs:sequence>
        <xs:element name="fluteSessionDescriptor" type="tns:FLUTESessionDescriptor" 
		  minOccurs="0" maxOccurs="unbounded" />
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

B.6 FLUTESessionDescriptor

The following extension is defined to the XML AIT to signal the session parameters needed for delivery of applications using FLUTE.

Parameters shall be as defined in section 6.1.13 ‘File delivery session description with SDP’ of [DATACAST].

This element is optional; if it is not supported, it shall be silently ignored without causing an error.

<xs:complexType name="FLUTESessionDescriptor">
  <xs:sequence>
    <xs:element name="senderIP" type="xs:string"/>
    <xs:element name="numChannels" type="xs:unsignedInt"/>
    <xs:element name="destIP" type="xs:string"/>
    <xs:element name="TSI" type="xs:unsignedInt"/>
    <xs:element name="sessionTimeParam" type="xs:string"/>
    <xs:element name="lang" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

B.7 Extension for IPServiceType

The IPServiceType defined in [TS102809] is an extension of the IPService type defined in [SDNS].

<xs:complexType name="OIPFIPServiceType">
  <xs:complexContent>
    <xs:extension base="mis:IPServiceType">
      <xs:sequence>
        <xs:element name="TimeToRenegotiate" type="xs:duration" minOccurs="0"/>
        <xs:element name="PurchaseItem" type="oipfbcg:PurchaseItemType" minOccurs="0"/>
        <xs:element name="FileFormat" type="tva:ControlledTermType" minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Annex C. Schema Extension for BCG

C.1 Namespace

The namespace for Open IPTV Forum is “urn:oipf:service:bcg:2010-1”.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oipf:service:bcg:2010-1"
  xmlns:tns="urn:oipf:service:bcg:2010-1"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:tva="urn:tva:metadata:2011"
  elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- schema filename is service-bcg.xsd -->

C.2 Import namespace and schema

<xs:import namespace="urn:tva:metadata:2011"
schemaLocation="imports/tva_metadata_3-1_v171.xsd"/>

C.3 Include definitions

<xs:include schemaLocation="csp-MarlinPrivateDataType.xsd"/>
<xs:include schemaLocation="csp-DRMPrivateDataType.xsd"/>
<xs:include schemaLocation="csp-HexBinaryPrivateDataType.xsd"/>

C.4 Extension for PurchaseItem Type

<xs:complexType name="PurchaseItemType">
  <xs:complexContent>
    <xs:extension base="tva:PurchaseItemType">
      <xs:sequence>
        <xs:element name="DRMControlInformation" type="tns:DRMControlInformationType"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>
<xs:complexType name="DRMControlInformationType">
  <xs:sequence>
    <xs:element name="DRMSystemID" type="xs:anyURI"/>
    <xs:element name="DRMContentID" type="xs:anyURI"/>
    <xs:element name="RightsIssuerURL" type="xs:anyURI" minOccurs="0"/>
    <xs:element name="SilentRightsURL" type="xs:anyURI" minOccurs="0"/>
    <xs:element name="PreviewRightsURL" type="xs:anyURI" minOccurs="0"/>
    <xs:element name="DoNotRecord" type="xs:boolean" minOccurs="0"/>
    <xs:element name="DoNotTimeShift" type="xs:boolean" minOccurs="0"/>
    <xs:element ref="tns:DRMGenericData" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="tns:DRMPrivateData" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>
<xs:element name="DRMGenericData" type="tns:DRMGenericDataType"/>
<xs:element name="DRMPrivateData" type="tns:DRMPrivateDataType"/>
<xs:element name="MarlinPrivateData" type="tns:MarlinPrivateDataType"
  substitutionGroup="tns:DRMPrivateData"/>
<xs:element name="HexBinaryPrivateData" type="tns:HexBinaryPrivateDataType"
  substitutionGroup="tns:DRMPrivateData"/>
<xs:complexType name="DRMGenericDataType">
  <xs:sequence>
    <xs:any namespace="##any" processContents="lax" minOccurs="0"
      maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

C.5 Extension for OnDemandProgram Type

<xs:complexType name="OnDemandProgramType">
  <xs:complexContent>
    <xs:extension base="tva:OnDemandProgramType">
      <xs:sequence>
        <xs:element name="Protocol" type="tva:ControlledTermType" minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

C.6 Extension for ProgramDescription Type

The following extensions are used to describe Notification service information

<xs:complexType name="ProgramDescriptionType">
  <xs:complexContent>
    <xs:extension base="tva:ProgramDescriptionType">
      <xs:sequence>
        <xs:element name="NotificationInformationTable"
          type="tns:NotificationInformationTableType" minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>
<xs:complexType name="NotificationInformationTableType">
  <xs:sequence>
    <xs:element name="NotificationService" type="tns:NotificationServiceType"
      maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>
<xs:complexType name="NotificationServiceType">
  <xs:complexContent>
    <xs:extension base="tva:ServiceInformationType">
      <xs:sequence>
        <xs:element name="NotificationServiceCategory"
          type="tns:NotificationServiceCategoryType"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>
<xs:simpleType name="NotificationServiceCategoryType">
  <xs:restriction base="xs:string">
    <xs:enumeration value="NGNotification"/>
    <xs:enumeration value="UserNotification"/>
  </xs:restriction>
</xs:simpleType>

C.7 Extension for ProgramInformation Type

<xs:complexType name="ProgramInformationType">
  <xs:complexContent>
    <xs:extension base="tva:ProgramInformationType">
      <xs:sequence>
        <xs:element name="DoNotBookmark" type="xs:boolean" default="false" 
		  minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

C.8 Extension for ServiceInformation Type

<xs:complexType name="ServiceInformationType">
  <xs:complexContent>
    <xs:extension base="tva:ServiceInformationType">
      <xs:sequence>
        <xs:element name="DoNotBookmark" type="xs:boolean" default="false"
          minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Annex D. Classification Schemes Extensions

An informative set of Classification Schemes has been developed by Open IPTV Forum to provide default set of classification terms to be applied in the context of Open IPTV Forum services.

D.1 VisualCodingFormatCS

The following Classification Scheme is introduced according to the Table 1 and Table 2 defined in clause 3 of Media Formats Specification [OIPF_MEDIA2].

<?xml version="1.0" encoding="UTF-8"?>
<ClassificationScheme uri="urn:oipf:cs:VisualCodingFormatCS:2013">
  <!-- schema file is cs-VisualCodinfFormatCS.xml -->
  <Term termId="AVC_HD_25">
    <Name xml:lang="en">AVC_HD_25</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, High Definition, 25Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_HD_30">
    <Name xml:lang="en">AVC_HD_30</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, High Definition, 30Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_SD_25">
    <Name xml:lang="en">AVC_SD_25</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, Standard Definition, 25Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_SD_30">
    <Name xml:lang="en">AVC_SD_30</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, Standard Definition, 30Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_SP_25">
    <Name xml:lang="en">AVC_SP_25</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, Sub-Picture, 25Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_SP_30">
    <Name xml:lang="en">AVC_SP_30</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, Sub-Picture, 30Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_3D_25">
    <Name xml:lang="en">AVC_3D_25</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, 3D, 25Hz systems
    </Definition>
  </Term>
  <Term termId="AVC_3D_30">
    <Name xml:lang="en">AVC_3D_30</Name>
    <Definition xml:lang="en">
      H.264/AVC video coding, 3D, 30Hz systems
    </Definition>
  </Term>
  <Term termId="MPEG2_HD_25">
    <Name xml:lang="en">MPEG2_HD_25</Name>
    <Definition xml:lang="en">
      MPEG-2 video coding, High Definition, 25Hz systems
    </Definition>
  </Term>
  <Term termId="MPEG2_SD_25">
    <Name xml:lang="en">MPEG2_SD_25</Name>
    <Definition xml:lang="en">
      MPEG-2 video coding, Standard Definition, 25Hz systems
    </Definition>
  </Term>
  <Term termId="MPEG2_SP_25">
    <Name xml:lang="en">MPEG2_SP_25</Name>
    <Definition xml:lang="en">
      MPEG-2 video coding, Sub-Picture, 25Hz systems
    </Definition>
  </Term>
</ClassificationScheme>

D.2 AudioCodingFormatCS

The following Classification Scheme is introduced according to the Table 1 and Table 2 defined in clause 3 of Media Formats Specification [OIPF_MEDIA2].

<?xml version="1.0" encoding="UTF-8"?>
<ClassificationScheme uri="urn:oipf:cs:AudioCodingFormatCS:2010">
  <!-- schema file is cs-AudioCodingFormatCS.xml -->
  <Term termId="HE_AAC">
    <Name xml:lang="en">HE_AAC</Name>
    <Definition xml:lang="en">HE-AAC and AAC audio coding</Definition>
  </Term>
  <Term termId="HE_AAC2">
    <Name xml:lang="en">HE_AAC2</Name>
    <Definition xml:lang="en">HE-AACv2 audio coding</Definition>
  </Term>
  <Term termId="HE_AAC_MPS">
    <Name xml:lang="en">HE_AAC_MPS</Name>
    <Definition xml:lang="en">HE-AAC with MPEG surround audio coding</Definition>
  </Term>
  <Term termId="AC3">
    <Name xml:lang="en">AC3</Name>
    <Definition xml:lang="en">AC3 audio coding</Definition>
  </Term>
  <Term termId="EAC3">
    <Name xml:lang="en">EAC3</Name>
    <Definition xml:lang="en">Enhanced AC3 audio coding</Definition>
  </Term>
  <Term termId="MPEG1_L2">
    <Name xml:lang="en">MPEG1_L2</Name>
    <Definition xml:lang="en">MPEG-1 Layer II audio coding</Definition>
  </Term>
  <Term termId="MPEG1_L2_MPS">
    <Name xml:lang="en">MPEG1_L2_MPS</Name>
    <Definition xml:lang="en">
      MPEG-1 Layer II with MPEG surround audio coding
    </Definition>
  </Term>
  <Term termId="MPEG1_L3">
    <Name xml:lang="en">MPEG1_L3</Name>
    <Definition xml:lang="en">MPEG-1 Layer III audio coding</Definition>
  </Term>
  <Term termId="WAV">
    <Name xml:lang="en">WAV</Name>
    <Definition xml:lang="en">WAV audio coding</Definition>
  </Term>
  <Term termId="DTS">
    <Name xml:lang="en">DTS</Name>
    <Definition xml:lang="en">DTS audio coding</Definition>
  </Term>
  <Term termId="AMR">
    <Name xml:lang="en">AMR</Name>
    <Definition xml:lang="en">AMR audio coding</Definition>
  </Term>
  <Term termId="AMR_WB">
    <Name xml:lang="en">AMR_WB</Name>
    <Definition xml:lang="en">AMR Wideband audio coding</Definition>
  </Term>
  <Term termId="AMR_WB+">
    <Name xml:lang="en">AMR_WB+</Name>
    <Definition xml:lang="en">Extended AMR Wideband audio coding</Definition>
  </Term>
</ClassificationScheme>

D.3 AVMediaFormatCS

The following Classification Scheme is introduced according to the Table 3 defined in clause 3 of Media Formats Specification [OIPF_MEDIA2].

<?xml version="1.0" encoding="UTF-8"?>
<ClassificationScheme uri="urn:oipf:cs:AVMediaFormatCS:2008">
  <!-- schema file is cs-AVMediaFormatCS.xml -->
  <Term termId="TS">
    <Name xml:lang="en">TS</Name>
    <Definition xml:lang="en">MPEG-2 transport stream</Definition>
  </Term>
  <Term termId="TS_BBTS">
    <Name xml:lang="en">TS_BBTS</Name>
    <Definition xml:lang="en">
      MPEG-2 transport stream, Marlin BB TS with AES encryption
    </Definition>
  </Term>
  <Term termId="TS_PF">
    <Name xml:lang="en">TS_PF</Name>
    <Definition xml:lang="en">MPEG-2 protected transport stream</Definition>
  </Term>
  <Term termId="TTS">
    <Name xml:lang="en">TTS</Name>
    <Definition xml:lang="en">MPEG-2 time stamped transport stream</Definition>
  </Term>
  <Term termId="TTS_BBTS">
    <Name xml:lang="en">TTS_BBTS</Name>
    <Definition xml:lang="en">
      MPEG-2 time stamped transport stream, Marlin BB TS with AES encryption
    </Definition>
  </Term>
  <Term termId="TTS_PF">
    <Name xml:lang="en">TTS_PF</Name>
    <Definition xml:lang="en">
      MPEG-2 time stamped protected transport stream
    </Definition>
  </Term>
  <Term termId="MP4">
    <Name xml:lang="en">MP4</Name>
    <Definition xml:lang="en">MP4 File Format</Definition>
  </Term>
  <Term termId="MP4_PDCF">
    <Name xml:lang="en">MP4_PDCF</Name>
    <Definition xml:lang="en">MP4 File Format, OMA PDCF</Definition>
  </Term>
  <Term termId="MP4_MIPMP">
    <Name xml:lang="en">MP4_MIPMP</Name>
    <Definition xml:lang="en">MP4 File Format, Marlin IP MP format</Definition>
  </Term>
  <Term termId="MP4_DCF">
    <Name xml:lang="en">MP4_DCF</Name>
    <Definition xml:lang="en">MP4 File Format, OMA DCF</Definition>
  </Term>
</ClassificationScheme>

D.4 ProtocolCS

The following Classification Scheme is introduced according to the protocols defined in Annex E.1 of the Protocols specification [OIPF_PROT2].

<?xml version="1.0" encoding="UTF-8"?>
<ClassificationScheme uri="urn:oipf:cs:ProtocolCS:2012">
  <!-- schema file is cs-ProtocolCS.xml -->
  <Term termId="sip-igmp-rtp-udp">
    <Name xml:lang="en">sip-igmp-rtp-udp</Name>
    <Definition xml:lang="en">
      Multicast Streaming over RTP with SIP session management
    </Definition>
  </Term>
  <Term termId="sip-igmp-udp">
    <Name xml:lang="en">sip-igmp-udp</Name>
    <Definition xml:lang="en">
      Multicast Streaming over UDP with SIP session management
    </Definition>
  </Term>
  <Term termId="sip-rtsp-rtp-udp">
    <Name xml:lang="en">sip-rtsp-rtp-udp</Name>
    <Definition xml:lang="en">
      Unicast CoD Streaming over RTP with SIP session management
    </Definition>
  </Term>
  <Term termId="sip-rtsp-udp">
    <Name xml:lang="en">sip-rtsp-udp</Name>
    <Definition xml:lang="en">
      Unicast Streaming over direct UDP with SIP session management
    </Definition>
  </Term>
  <Term termId="igmp-rtp-udp">
    <Name xml:lang="en">igmp-rtp-udp</Name>
    <Definition xml:lang="en">Multicast Streaming over RTP</Definition>
  </Term>
  <Term termId="igmp-udp">
    <Name xml:lang="en">igmp-udp</Name>
    <Definition xml:lang="en">Multicast Streaming over UDP</Definition>
  </Term>
  <Term termId="rtsp-rtp-udp">
    <Name xml:lang="en">rtsp-rtp-udp</Name>
    <Definition xml:lang="en">Unicast Streaming over RTP</Definition>
  </Term>
  <Term termId="http-get">
    <Name xml:lang="en">http-get</Name>
    <Definition xml:lang="en">Unicast Streaming/Download over HTTP</Definition>
  </Term>
  <Term termId="dash">
    <Name xml:lang="en">dash</Name>
    <Definition xml:lang="en">Dynanic adaptive streaming over HTTP</Definition>
  </Term>
  <Term termId="has">
    <Name xml:lang="en">has</Name>
    <Definition xml:lang="en">OIPF HTTP Adaptive Streaming</Definition>
  </Term>
</ClassificationScheme>

D.5 GermanyFSKCS

The following Classification Scheme is introduced according to the rating type 9, GermanyFSK rating system defined in Table 11 in [IEC62455] clause 7.2.1.1

<?xml version="1.0" encoding="UTF-8"?>
<ClassificationScheme uri="urn:oipf:cs:GermanyFSKCS:2008"
    domain="//CreationInformation/Classification/ParentalGuidance/ParentalRating">
  <!-- schema file is cs-GermanyFSKCS.xml -->
  <Description xml:lang="en">Thesaurus for movie rating</Description>
  <Term termId="0">
    <Name xml:lang="en">0</Name>
    <Definition xml:lang="en">Released without age restriction</Definition>
  </Term>
  <Term termId="6">
    <Name xml:lang="en">6</Name>
    <Definition xml:lang="en">Released to age 6 or older</Definition>
  </Term>
  <Term termId="12">
    <Name xml:lang="en">12</Name>
    <Definition xml:lang="en">
      Released to age 12 or older and to age 6 or older with parental guidance
    </Definition>
  </Term>
  <Term termId="16">
    <Name xml:lang="en">16</Name>
    <Definition xml:lang="en">Released to age 16 or older</Definition>
  </Term>
  <Term termId="18">
    <Name xml:lang="en">18</Name>
    <Definition xml:lang="en">
      No release to youths (released to age 18 or older)
    </Definition>
  </Term>
</ClassificationScheme>

D.6 ApplicationUsageCS

The following Classification Scheme is introduced to signal specific application usages.

<?xml version="1.0" encoding="UTF-8"?>
<ClassificationScheme uri="urn:oipf:cs:ApplicationUsageCS:2010">
  <!-- schema file is cs-ApplicationUsageCS.xml -->
  <Term termId="servicediscovery">
    <Name xml:lang="en">Service Discovery</Name>
    <Definition xml:lang="en">
      Application provides Service Discovery information
    </Definition>
  </Term>
  <Term termId="vod">
    <Name xml:lang="en">VoD Guide Application</Name>
    <Definition xml:lang="en">Application providing VoD content guide</Definition>
  </Term>
  <Term termId="epg">
    <Name xml:lang="en">EPG Guide Application</Name>
    <Definition xml:lang="en">Application providing EPG content guide</Definition>
  </Term>
  <Term termId="communication">
    <Name xml:lang="en">Communication Application</Name>
    <Definition xml:lang="en">Application providing communication services.</Definition>
  </Term>
  <Term termId="hni-igi">
    <Name xml:lang="en">HNI-IGI Application</Name>
    <Definition xml:lang="en">
      Application providing non-native HNI-IGI functionality.
    </Definition>
  </Term>
  <Term termId="ngnotification">
    <Name xml:lang="en">NG Notification Application</Name>
    <Definition xml:lang="en">
      Application providing NG notification services.
    </Definition>
  </Term>
</ClassificationScheme>

Annex E. Service Provider and Service Discovery XML examples (informative)

E.1 Service Provider Discovery

Upon determination of the Service Provider Discovery entry point (see [OIPF_ARCH2] section 6.2) the OITF creates an HTTP request as follows to obtain the Service Provider Discovery information

GET /dvb/sdns/sp_discovery?id=ALL
HOST: 195.238.226.224

The following is an example of XML document returned

<?xml version="1.0" encoding="UTF-8"?>
<dvb12:ServiceDiscovery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:oipf:service:sdns:2010 service-sdns.xsd"
    xmlns:oipf="urn:oipf:service:sdns:2010"
    xmlns:dvb="urn:dvb:metadata:iptv:sdns:2008-1"
    xmlns:dvb12="urn:dvb:metadata:iptv:sdns:2012-1"
    xmlns:mis="urn:dvb:mhp:2009" >
  <dvb12:ServiceProviderDiscovery >
    <dvb:ServiceProvider DomainName="tv.service.com"
        LogoURI="http://195.238.226.223/img/logo_service.gif" Version="00"
        xsi:type="oipf:ServiceProviderType">
      <dvb:Name Language="ENG">Service Provider</dvb:Name>
      <dvb:Description Language="ENG">
        Service Provider IPTV Offer
      </dvb:Description>
      <dvb:Offering>
	    <!-- Broadcast Discovery Information -->
        <dvb:Pull Location="195.238.226.223/dvb/sdns">
          <dvb:PayloadId Id="2">
            <dvb:Segment ID="1" Version="01"/>
          </dvb:PayloadId>
        </dvb:Pull>
        <!-- Package Discovery Information -->
        <dvb:Pull Location="195.238.226.223/dvb/sdns">
          <dvb:PayloadId Id="5">
            <dvb:Segment ID="1" Version="01"/>
          </dvb:PayloadId>
        </dvb:Pull>
        <!-- Application Discovery Information -->
        <dvb:Pull Location="195.238.226.223/dvb/sdns" >
          <dvb:PayloadId Id="C1">
            <dvb:Segment ID="1" Version="01"/>
          </dvb:PayloadId>
        </dvb:Pull>
      </dvb:Offering>
      <mis:AbstractService>
        <mis:svcName Language="ENG">TV Service Portal</mis:svcName>
        <mis:svcId>A1B2C3</mis:svcId>
        <mis:isAutoSelect>true</mis:isAutoSelect>
        <mis:ApplicationList>
          <mis:ApplicationReference>
            <mis:orgId>100</mis:orgId>
            <mis:appId>002</mis:appId>
          </mis:ApplicationReference>
        </mis:ApplicationList>
      </mis:AbstractService>
      <EmergencyNotificationService>
        <SDPURL>195.238.226.223/ems/emergency_svcs.spd</SDPURL>
      </EmergencyNotificationService>
    </dvb:ServiceProvider>
  </dvb12:ServiceProviderDiscovery>
</dvb12:ServiceDiscovery>

In this example, a single service provider is indicated by the name “Service Provider” with an offering titled “Service Provider IPTV Offer” and the domain “tv.service.com”. A logo file for the Service Provider’s offering is available at the URL specified by the LogoURI attribute. Information for the OITF to connect to the Emergency Service Notifications from the Service Provider can be retrieved from the URL specified in the EmergencyNotificationService element.

Three service types are available to the terminal

Broadcast Discovery, designated by Payload Id="02"
Package Discovery, designated by Payload Id="05"
Application Discovery, designated by Payload Id="C1"

Information on the Payload Id values are given in clause 5.4.4.1 of [SDNS].

E.2 Broadcast Discovery

If the Service Provider Discovery record indicates that Broadcast Discovery information is available (i.e. there is a dvb:Offering with Payload Id="02") about the Scheduled Content Services offered by the Service Provider, further interrogation by the OITF is required. This procedure would also be utilized when updated Broadcast Discovery records are available according to section 4.1.1.2.

In the Service Provider information, the Broadcast Discovery records are retrievable by HTTP GET operation (the offering only provides a dvb:Pull mechanism), the OITF creates an HTTP request as follows

GET /dvb/sdns/service_discovery?id=tv.service.com&Payload=02&Segment=0001&Version=01 
HOST: 195.238.226.223

The HTTP response will contain the Broadcast Discovery records similar to those in the following XML instance document

<?xml version="1.0" encoding="UTF-8"?>
<dvb12:ServiceDiscovery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:oipf:service:sdns:2010 service-sdns.xsd"
    xmlns:oipf="urn:oipf:service:sdns:2010"
    xmlns:dvb="urn:dvb:metadata:iptv:sdns:2008-1"
    xmlns:dvb12="urn:dvb:metadata:iptv:sdns:2012-1"
    xmlns:tva="urn:tva:metadata:2011">
  <dvb12:BroadcastDiscovery DomainName="tv.service.com" Version="01">
    <dvb:ServiceList>
      <dvb:SingleService>
        <dvb:ServiceLocation>
          <dvb:IPMulticastAddress Address="239.255.42.42" Port="50002"/>
        </dvb:ServiceLocation>
        <dvb:TextualIdentifier ServiceName="CHANNEL_MOVIE1"/>
        <dvb:DVBTriplet OrigNetId="167" ServiceId="1" TSId="1001"/>
        <dvb:MaxBitrate>3000</dvb:MaxBitrate>
        <dvb:SI ServiceType="16">
          <dvb:Name Language="ENG">Family channel</dvb:Name>
        </dvb:SI>
      </dvb:SingleService>
      <dvb:SingleService xsi:type="oipf:OIPFIPServiceType">
        <dvb:ServiceLocation>
          <dvb:IPMulticastAddress Address="239.255.42.42" Port="50000"/>
        </dvb:ServiceLocation>
        <dvb:TextualIdentifier ServiceName="CHANNEL_MOVIE2"/>
        <dvb:DVBTriplet OrigNetId="167" ServiceId="1" TSId="11002"/>
        <dvb:MaxBitrate>8000</dvb:MaxBitrate>
        <dvb:SI ServiceType="19">
          <dvb:Name Language="ENG">Scary Movies</dvb:Name>
        </dvb:SI>
        <oipf:TimeToRenegotiate>PT30S</oipf:TimeToRenegotiate>
      </dvb:SingleService>
      <dvb:SingleService>
        <dvb:ServiceLocation>
          <dvb:IPMulticastAddress Address="239.255.42.42" Port="50006"/>
        </dvb:ServiceLocation>
        <dvb:TextualIdentifier ServiceName="CHANNEL_SPORT_SD"/>
        <dvb:DVBTriplet OrigNetId="167" ServiceId="10" TSId="4029"/>
        <dvb:MaxBitrate>3000</dvb:MaxBitrate>
        <dvb:SI ServiceType="16">
          <dvb:Name Language="ENG">Sport</dvb:Name>
        </dvb:SI>
      </dvb:SingleService>
      <dvb:SingleService xsi:type="oipf:OIPFIPServiceType">
        <dvb:ServiceLocation>
          <dvb:IPMulticastAddress Address="239.255.42.42" Port="50004"
            Streaming="udp"/>
        </dvb:ServiceLocation>
        <dvb:TextualIdentifier ServiceName="CHANNEL_SPORT_HD"/>
        <dvb:DVBTriplet OrigNetId="167" ServiceId="10" TSId="11003"/>
        <dvb:MaxBitrate>8000</dvb:MaxBitrate>
        <dvb:SI ServiceType="19">
          <dvb:Name Language="ENG">Sport HD</dvb:Name>
        </dvb:SI>
        <oipf:FileFormat href="urn:oipf:cs:ProtocolCS:2010">
          <tva:Name>igmp-udp</tva:Name>
        </oipf:FileFormat>
      </dvb:SingleService>
    </dvb:ServiceList>
  </dvb12:BroadcastDiscovery>
</dvb12:ServiceDiscovery>

The broadcast service entry for the CHANNEL_MOVIE2 service uses the OIPF extended definition and includes the TimeToRegnotiate value of 30 seconds.

The broadcast service entry for the CHANNEL_SPORT_HD service uses the OIPF extended definition and includes the FileFormat element indicating that the content delivery does not use RTP encapsulation over UDP.

E.3 Package Discovery

If the Service Provider Discovery record indicates that Broadcast Discovery information is available (i.e. there is a dvb:Offering with Payload Id="05") about the Scheduled Content Services offered by the Service Provider, further interrogation by the OITF is required. This procedure would also be utilized when updated Package Discovery records are available according to section 4.1.1.2.

In the Service Provider information, the Package Discovery records are retrievable by HTTP GET operation (the offering only provides a dvb:Pull mechanism), the OITF creates an HTTP request as follows

GET /dvb/sdns/service_discovery?id=tv.service.com&Payload=05&Segment=00001&Version=01 
HOST: 195.238.226.223

The HTTP response will contain the Package Discovery records similar to those in the following XML instance document

<?xml version="1.0" encoding="UTF-8"?>
<dvb12:ServiceDiscovery Version="00"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:oipf:service:sdns:2010 service-sdns.xsd"
    xmlns:dvb="urn:dvb:metadata:iptv:sdns:2008-1"
    xmlns:dvb12="urn:dvb:metadata:iptv:sdns:2012-1" >
  <dvb12:PackageDiscovery DomainName="tv.service.com" Version="01">
    <dvb:Package Visible="true" Id="2">
      <dvb:PackageName Language="ENG">Premium bouquet</dvb:PackageName>
      <dvb:Service>
        <dvb:TextualID ServiceName="CHANNEL_MOVIE1"/>
        <dvb:LogicalChannelNumber>1</dvb:LogicalChannelNumber>
      </dvb:Service>
      <dvb:Service>
        <dvb:TextualID ServiceName="CHANNEL_MOVIE2"/>
        <dvb:LogicalChannelNumber>2</dvb:LogicalChannelNumber>
      </dvb:Service>
      <dvb:Service>
        <dvb:TextualID ServiceName="CHANNEL_SPORT_SD"/>
        <dvb:LogicalChannelNumber>3</dvb:LogicalChannelNumber>
      </dvb:Service>
      <dvb:Service>
        <dvb:TextualID ServiceName="CHANNEL_SPORT"/>
        <dvb:LogicalChannelNumber>4</dvb:LogicalChannelNumber>
      </dvb:Service>
    </dvb:Package>
  </dvb12:PackageDiscovery>
</dvb12:ServiceDiscovery>

E.4 Application Discovery

If the Service Provider Discovery record indicates that Broadcast Discovery information is available (i.e. there is a dvb:Offering with Payload Id="C1") about the Scheduled Content Services offered by the Service Provider, further interrogation by the OITF is required. This procedure would also be utilized when updated Application Discovery records are available according to section 4.1.1.2.

In the Service Provider information, the Application Discovery records are retrievable by HTTP GET operation (the offering only provides a dvb:Pull mechanism), the OITF creates an HTTP request as follows

GET /dvb/sdns/service_discovery?id=tv.service.com&Payload=C1&Segment=0001&Version=01 
HOST: 195.238.226.223

The HTTP response will contain the Application Discovery records similar to those in the following XML instance document

<?xml version="1.0" encoding="UTF-8"?>
<mis:ServiceDiscovery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:oipf:service:sdns:2010 service-sdns.xsd"
    xmlns:mis="urn:dvb:mhp:2009">
  <mis:ApplicationDiscovery DomainName="tv.service.com">
    <mis:ApplicationList>
      <mis:Application>
        <mis:appName Language="ENG">TV Service Portal</mis:appName>
        <mis:applicationIdentifier>
          <mis:orgId>100</mis:orgId>
          <mis:appId>002</mis:appId>
        </mis:applicationIdentifier>
        <mis:applicationDescriptor>
          <mis:type>
            <mis:OtherApp>application/vnd.oipf.dae+xml</mis:OtherApp>
          </mis:type>
          <mis:controlCode>AUTOSTART</mis:controlCode>
          <mis:visibility>VISIBLE_ALL</mis:visibility>
          <mis:serviceBound>false</mis:serviceBound>
          <mis:priority>1</mis:priority>
          <mis:version>01</mis:version>
          <!-- Required - values for mhpversion are defined in section 3.2.3.3.2 -->
          <mis:mhpVersion>
            <mis:profile>1</mis:profile>
            <mis:versionMajor>2</mis:versionMajor>
            <mis:versionMinor>1</mis:versionMinor>
            <mis:versionMicro>0</mis:versionMicro>
          </mis:mhpVersion>
          <mis:icon mis:filename="http://195.238.226.223/img/logo_application.gif"
            mis:aspectRatio="1_1" />
        </mis:applicationDescriptor>
        <!-- Required - application Boundary defines the URL prefix - Any URLs
             matching this prefix are considered to be within the application
             boundary -->
        <mis:applicationBoundary>
          <mis:BoundaryExtension>http://195.238.226.223/</mis:BoundaryExtension>
        </mis:applicationBoundary>
        <!-- Required - applicationTransport defines transport type, here HTTP -->
        <mis:applicationTransport xsi:type="mis:HTTPTransportType">
          <mis:URLBase>http://195.238.226.223/app/</mis:URLBase>
        </mis:applicationTransport>
        <!-- Required - applicationLocation defines the location of first page -->
        <mis:applicationLocation>index.html</mis:applicationLocation>
      </mis:Application>
    </mis:ApplicationList>
  </mis:ApplicationDiscovery>
</mis:ServiceDiscovery>

[BCG]	ETSI, TS 102 539 V1.3.1 (2010-04), "Digital Video Broadcasting: Carriage of Broadband Content Guide (BCG) information over Internet Protocol"
[DATACAST]	ETSI, TS 102 472 V1.2.1 (2006-12), "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols"
[DVB-ID]	DVB Services (DVB-SI \| CA_System_ID), http://www.dvbservices.com/identifiers/ca_system_id
[DVBSI]	ETSI, EN 300 468 V1.13.1 (2012-08), "Digital Video Broadcasting: Specification for Service Information (SI) in DVB systems"
[DVBTRANS]	ETSI, TS 102 323 V1.2.1 (2005-11) "Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams"
[FCC]	DVB, Blue book A152 "Server-based Fast Channel Change", July 2010
[GEM]	ETSI, TS 102 728 V1.2.1 (2011-09), "Digital Video Broadcasting (DVB); Globally Executable MHP (GEM) Specification 1.3 (including OTT and hybrid broadcast/broadband)"
[IEC62455]	IEC, IEC 62455, "Internet protocol (IP) and transport stream (TS) based service access", June 2007
[MPEG-7]	ISO/IEC 15938-5, "Multimedia Content Description Interface - Part 5:Multimedia description schemes", May 2003
[SDNS]	DVB, BlueBook A86 (future ETSI TS 102 034 V1.5.1), "Digital Video Broadcasting: Transport of MPEG-2 Based DVB Services over IP Based Networks"
[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".
[TVA]	ETSI, TS 102 822-3-1 V1.7.1 (2011-11), "Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems (“TV-Anytime”); Part 3: Metadata; Sub-part 1: Phase 1 - Metadata schemas"
[TVA-BID]	ETSI, TS 102 822-6-1 V1.7.1 (2011-11), "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems (“TV-Anytime”); Part 6: Delivery of metadata over a bi-directional network; Sub-part 1: Service and transport"
[TVA-UNID]	ETSI, TS 102 822-3-2 V1.6.1 (2012-07), "Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems (“TV-Anytime”); Part 3: Metadata; Sub-part 2: System aspects in a uni-directional environment"

[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_OVIEW2]	Open IPTV Forum, "Release 2 Specification, Volume 1 - Overview", V2.3, January 2014.
[OIPF_PAE2]	Open IPTV Forum, "Release 2 Specification, Volume 6 - Procedural Application Environment", 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.
[OIPF_WSTVP2]	Open IPTV Forum, "Release 2 Specification, Volume 5a - Web Standards TV Profile", V2.3, January 2014.

Abstract

Contents

Figures

Tables

1. References

1.1 Normative references

1.2 OIPF references

1.3 Informative references

2. Conventions and Terminology

2.1 Conventions

2.2 Terminology

2.2.1 Definitions

2.2.1.1 Metadata

2.2.1.2 Metadata Formats

2.2.2 Abbreviations

3. Metadata Content

3.1 Schema Extension and Validation

3.1.1 Metadata Extensibility

3.1.2 Metadata Validation

3.2 SD&S (Service Discovery and Selection) Extensions

3.2.1 Service Provider Discovery Extensions

3.2.1.1 Emergency Notification Service

3.2.2 Service Discovery Extensions

3.2.2.1 Bandwidth Renogiation

3.2.2.2 Purchasing Broadcast Services

3.2.2.3 Container Format Indication

3.2.2.4 FCC/RET Attribute Definition

3.2.3 Application Announcement & Signaling

3.2.3.1 Service Provider Related Application Signalling

3.2.3.2 Broadcast Related Application Signalling

3.2.3.3 Platform Specific Definitions

3.2.3.3.1 Type Element of ApplicationDescriptor

3.2.3.3.2 mhpVersion Element of ApplicationDescriptor

3.2.3.3.3 Specific ApplicationUsage Element of ApplicationUsageDescriptor

3.2.3.3.4 Graphic Format for Application Icons

3.2.3.3.5 Application Extensions

3.2.3.3.6 ApplicationSpecificDescriptor Extensions

3.3 BCG (Broadband Content guide) Extensions

3.3.1 Signalling and Media Transport Protocol Extension

3.3.1.1 OnDemandProgramType Extension

3.3.1.2 Extension for Notification Information Table

3.3.1.3 Definition of Elements in RelatedMaterialType

3.3.2 DRM Control Information Extension

3.3.2.1 PurchaseItemType Extension

3.3.3 Open IPTV Forum Classification Schemes

3.3.3.1 VideoCodingFormat Classification Scheme

3.3.3.2 AudioCodingFormat Classification Scheme

3.3.3.3 AVMediaFormat Classification Scheme

3.3.3.4 Protocol Classification Scheme

3.3.3.5 Reference to Parental Guidance Classification Scheme

3.3.4 Program Information Extension

3.3.5 Service Information Extension

4. Metadata Control and Delivery

4.1 Metadata Delivery Mechanism

4.1.1 Carriage of SD&S metadata

4.1.1.1 Encoding SD&S metadata

4.1.1.2 Update mechanism for SD&S

4.1.2 Carriage of BCG metadata

4.1.2.1 Container based delivery

4.1.2.1.1 Encoding BCG metadata

4.1.2.1.2 Update mechanism for BCG

4.1.2.2 SOAP Query Mechanism

4.1.2.2.1 get_Data (informative)

4.1.2.2.2 describe_Get_Data (informative)

4.1.2.2.3 SOAP Update mechanism for BCG

4.1.3 Event Information Tables (EIT)

4.1.3.1 How to link EIT p/f with SD&S without SDT

4.1.3.2 How to optimize the transport of EIT p/f (informative)

4.2 Link between SD&S and BCG (informative)

4.2.1 Locating a BCG for a Service using SD&S

4.2.2 Linking SD&S Service Information with BCG

4.3 CRID Location Resolution

4.3.1 CoD Service with SIP session management

Annex A. Open IPTV Forum SD&S Data Model (Informative)

Annex B. Schema Extension for SD&S

B.1 Namespace

B.2 Import namespace and schema

B.3 Extension for ServiceProvider Type

B.4 EmergencyNotificationService Type

B.5 Application Extension