Session Initiation

The HNI-IGI function in the OITF SHALL follow the following procedure for session initiation:

Retrieval of bandwidth parameter for FCC and/or RET enabled multicast content service

If the OITF intends to use FCC and/or RET, when the multicast content service is FCC and/or RET enabled, the OITF SHALL use the procedure defined in section 5.3.2.1.1, “”, with the following modifications:

• The Request-URI in the method line is set to well-known PSI for the multicast content service
• The OITF SHALL include an HTTP body that SHALL include an SDP that includes one m line that matches the m line associated with the multicast content service the OITF intends to join first (see section 5.3.1.1.1, “”) with the following exceptions:
  • No b-line is included
  • The following additional a attribute SHALL be included when the OITF intends to use RET:
    • a=rtcp-fb:<fmt> nack
      where <fmt> indicates the RTP payload type of the IP multicast stream that carries the content service.
  • The following additional a attribute SHALL be included when the OITF intends to use FCC:
    • a=rtcp-fb:<fmt> nack rai
      where <fmt> indicates the RTP payload type of the IP multicast stream that carries the content service.

The returned response SHALL include total bandwidth of the multicast content service with the highest total bandwidth, including the overhead bandwidth required for the FCC/RET stream. Maximum bandwidth will be signalled by means of the following media level bandwidth modifier:

• b=AS:<bandwidth>
  where <bandwidth> is the maximum calculated bandwidth according to the b=AS bandwidth modifier defined in RFC 4566 [[!SDP]] expressed in kbps.

Session Modification

To join a service outside the set of channels negotiated at session initiation or to perform a bandwidth modification, the OITF SHALL send a request to the IG for session modification. The OITF SHALL generate a re-INVITE request, as defined in Table .

The OITF SHALL include an SDP offer in the session modification request. The format of this request SHALL be the same as for a session initiation.

Session Termination

To terminate a multicast content streaming session, the OITF SHALL use the following procedure:

Session Refresh

It is the responsibility of the OITF application to refresh the multicast content streaming session before the session expires. The IG SHALL consider a session terminated if it is not refreshed.

Content Reporting and Management of Content Reporting of Watched Scheduled Content

Network-based multicast content streaming Time Shift

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oipf:iptv:IPTVAction:2009"
  xmlns:tns="urn:oipf:iptv:IPTVAction:2009"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:bc ="urn:org:etsi:ngn:params:xml:ns:iptvbcserviceactiondata"
  xmlns:co ="urn:org:etsi:ngn:params:xml:ns:iptvcodserviceactiondata"
  xmlns:np ="urn:org:etsi:ngn:params:xml:ns:iptvnpvrserviceactiondata"
  elementFormDefault="qualified" attributeFormDefault="unqualified">

  <xs:import namespace="urn:org:etsi:ngn:params:xml:ns:iptvbcserviceactiondata"
    schemaLocation="imports/iptvbcserviceactiondata.xsd"/>

  <xs:import namespace="urn:org:etsi:ngn:params:xml:ns:iptvcodserviceactiondata"
    schemaLocation="imports/iptvcodserviceactiondata.xsd"/>

  <xs:import
    namespace="urn:org:etsi:ngn:params:xml:ns:iptvnpvrserviceactiondata"
    schemaLocation="imports/iptvnpvrserviceactiondata.xsd"/>

  <xs:element name="IPTVAction" type="tns:IPTVActionType"/>

  <xs:complexType name="IPTVActionType">
    <xs:choice>
      <xs:element name="Notify" type="tns:NotifyType"/>
      <xs:element name="Record" type="tns:RecordType"/>
      <xs:element name="SwitchToTM" type="tns:SwitchToTMType"/>
      <xs:element name="SwitchToBC" type="tns:SwitchToBCType"/>
    </xs:choice>
  </xs:complexType>
  <xs:complexType name="NotifyType">
    <xs:choice>
      <xs:element ref="bc:IPTVBcActionData" />
      <xs:element ref="co:IPTVCoDActionData" />
      <xs:element ref="np:IPTVNpvrActionData" />
    </xs:choice>
  </xs:complexType>
  <xs:complexType name="RecordType">
    <xs:choice>
      <xs:element ref="bc:IPTVBcActionData" />
      <xs:element ref="np:IPTVNpvrActionData" />
    </xs:choice>
  </xs:complexType>
  <xs:complexType name="SwitchToTMType">
    <xs:choice>
      <xs:element ref="bc:IPTVBcActionData" />
    </xs:choice>
  </xs:complexType>
  <xs:complexType name="SwitchToBCType">
    <xs:choice>
      <xs:element ref="bc:IPTVBcActionData" />
    </xs:choice>
  </xs:complexType>
</xs:schema>

Retrieval of Session Parameters

If the OITF does not have all the necessary parameters to form the SDP offer the HNI-IGI function in the OITF SHALL retrieve missing SDP parameters using the following procedure:

Session Initiation

The OITF SHALL initiate the request for a unicast content streaming session using the following procedure.

When parsing the b=RR:<bandwidth-value> line by the OITF: if the bandwidth value agreed is non-zero, then the OITF SHALL send RTCP RRs and SHALL NOT send RTSP keep-alive messages. If the bandwidth value received is zero, then the OITF SHALL NOT sends RTCP RRs but instead it SHALL send RTSP keep-alive messages.

Session Termination

The OITF SHALL send the request for a unicast content streaming session termination using the following procedure:

Session Refresh

It is the responsibility of the OITF application to refresh the unicast content streaming session before the session expires. The IG SHALL consider a session terminated if it is not refreshed.

Purchase Procedure for Selected Digital Media Related to the Content

It is assumed that the OITF has an established session and has retrieved the necessary information to perform the purchase procedures as depicted in the steps below. It is also assumed that the network indicated its willingness to receive the Digital-Media-Purchase Info Package.

Management of Purchase Request for Digital Media by Network

The OITF SHALL comply with the following when it comes to network management for purchasing Digital Media:

Protocol for Retrieving Stored Purchased Digital Media

If the OITF desires to retrieve the lists of purchased digital media stored in the network over UNIP-1, it SHALL send an XCAP GET request to the IPTV Service Profile FE. The IPTV Service Profile FE SHALL returns all stored purchased digital media records in an HTTP 200 OK response.

Note that the purchased digital media record can only updated by the IPTV Control FE, not the OITF.

Protocol for Storing Purchased Digital Media

Upon receipt of a request to store purchased digital media from the IPTV Control FE, the IPTV Applications FE SHALL send the XCAP PUT request to IPTV Service Profile FE to store a new purchased digital media record.

After updating the user's profile, the IPTV Service Profile FE SHALL return a response to IPTV Applications FE, and then the IPTV Applications FE SHALL return a response to IPTV Control FE.

PPV Service initiation without existing multicast content streaming session

PPV service initiation without an existing multicast content session is similar to the multicast content session initiation described in section 5.3.1.1.1, “”, with the following differences:

The media level of the SDP offer in the HTTP Request Body has the following additional requirements:

• The m-line(s) SHALL be set according to the mapping defined in Annex D.1 for the multicast content service to which the PPV service belongs.
• The c-line(s) SHALL be set according to the mapping defined in Annex D.1 for the multicast content service to which the PPV service belongs.
• An a=bc_service:BCServiceId line to indicate the multicast content service to which the PPV program belongs SHALL be included.
• An a=bc_program:BCprogramId line to indicate the PPV program SHALL be included.

When the OITF receives the response to the request, it SHALL examine the media parameters in the received SDP. The OITF SHALL restrict the multicast content services that it joins according to the parameter (the a=bc_service_package attribute) received from the IPTV Control FE.

Switching from a PPV service to a multicast content service

To join a multicast content service outside the set of channels negotiated at session initiation, the OITF SHALL send a request to the IG for session modification. The OITF SHALL enforce a multicast content streaming session modification defined in section 5.3.1.1.3, “.”

To join a multicast content service inside the set of channels negotiated at session initiation, the OITF SHALL send an IGMP Leave request to stop watching the PPV service, and send an IGMP Join request to join the multicast content service. When FCC capability is available for the multicast content service, the OITF SHALL request a fast channel change as defined in Annex M.2, “”. Further, when multicast RET service is offered, the OITF SHALL join the RET stream as defined in Annex M.1, “”.

Switching to a PPV service from a multicast content service or another PPV service

The OITF SHALL send a request to the IG for session modification. The OITF SHALL generate a re-INVITE request, as defined in section 5.3.6.1.1, “.”

The OITF SHALL include an SDP offer in the session modification request. The format of this SDP offer SHALL be the same as for a session initiation. Note that session modification is only necessary if the PPV service is not included at session startup.

Session Termination

When the OITF wants to terminate the session, the OITF SHALL generate a HTTP POST request as described in section 5.3.1.1.4, “” for an originating OITF.

User Initiated Subscription to Acquire Information Related to Watched Content by another User

An IPTV end user having the parental control authority over another user can initiate subscription to acquire information related to the watched content by the user under his parental control. To initiate the request to receive the information, the OITF SHALL follow the following procedure:

Terminating a Subscription to the Parental Control Watched Content Event Package

This procedure SHALL be invoked at any time and/or prior to de-registering the user that created the subscription.

The procedure is the same as the procedure for initiating a subscription to the Parental Control Watched Content event, however in this case the X-OITF-Expires header in Table 27 SHALL be set to 0.

The IG SHALL consider a subscription terminated if is not refreshed.

Refreshing Subscription to Parental Control Watched Event Package

This procedure is the same as the procedure for initiating a subscription.

It is the responsibility of the application initiating the subscription procedure to refresh the subscription according to the refresh subscription timer information received in the response to the subscription request. Refreshing the subscription SHOULD be performed before the expiry of the refresh timer. A subscription that is not refreshed before the expiration of the refresh timer SHALL be terminated.

XML Schema for Parental Control Watched Content

Note: OITF contact information is mapped to DeviceId; OITF Call-ID is mapped to SessionId

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oipf:iptv:WhatsOnTv:2011"
  xmlns:tns="urn:oipf:iptv:WhatsOnTv:2011"
  xmlns:ct="urn:oipf:base:CommonTypes:2011"
  xmlns:xs=http://www.w3.org/2001/XMLSchema
  xmlns:pss="urn:org:etsi:ngn:params:xml:ns:PssContentSwitchData"
  xmlns:mbms="urn:org:etsi:ngn:params:xml:ns:MbmsContentSwitchData"
  elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:import namespace="urn:oipf:base:CommonTypes:2011"
    schemaLocation="base-CommonTypes.xsd" />
  <xs:import namespace="urn:org:etsi:ngn:params:xml:ns:PssContentSwitchData"
    schemaLocation="imports/PssSwitchData.xsd"/>
  <xs:import namespace="urn:org:etsi:ngn:params:xml:ns:MbmsContentSwitchData"
    schemaLocation="imports/MbmsSwitchData.xsd"/>
  <xs:element name="WhatsOnTvResponse" type="tns:WhatsOnTvResponseType"/>
  <xs:complexType name="WhatsOnTvResponseType">
    <xs:sequence>
      <xs:element name="User" type="tns:UserType" minOccurs="0"
        maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="UserType">
    <xs:sequence>
      <xs:element name="name" type="ct:UserIdType"/>
      <xs:element name="content" type="tns:WatchedContentType" minOccurs="0"
        maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="WatchedContentType">
    <xs:choice>
      <xs:element name="PssWatchedContent" type="tns:PssWatchedContentType"/>
      <xs:element name="MbmsWatchedContent" type="tns:MbmsWatchedContentType"/>
    </xs:choice>
  </xs:complexType>
  <xs:complexType name="PssWatchedContentType">
    <xs:sequence>
      <xs:element ref="pss:PssSwitchData"/>
      <xs:element name="DeviceId" type="xs:string"/>
      <xs:element name="SessionId" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="MbmsWatchedContentType">
    <xs:sequence>
      <xs:element ref="mbms:MbmsSwitchData"/>
      <xs:element name="DeviceId" type="xs:string"/>
      <xs:element name="SessionId" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Protocol for OITF Originating a Request for Parental Control

The user to be controlled is watching content and the controller finds out the information related to the watched content (SC Service ID or content ID, ratings etc.) as described in section 5.3.7.1, “.” When the controller wants to block the content program, the OITF of the controller SHALL originate a request for Parental Control. The SIP-specific information in the related messages is described in section 6.1.2.6, “.” The SIP-specific information is mapped to the HNI-IGI protocol, as described in section 5.6.1, “.”

Protocol for OITF Receiving a Request for Parental Control

The following procedure is supported in the OITF of the controlled user for receiving a request for Parental Control.

The incoming message can be handled either by a native application in the OITF, or in a DAE application. The same HNI-IGI message format is used in either case.

XML Schema for Parental Control

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oipf:iptv:parentalcontrol:2011"
  xmlns:tns="urn:oipf:itpv:parentalcontrol:2011"
  xmlns:ct="urn:oipf:base:CommonTypes:2011"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:annotation>
    <xs:documentation xml:lang="en">
      Defines the command for parental control
      associated with the controller
    </xs:documentation>
  </xs:annotation>
  <xs:import namespace="urn:oipf:base:CommonTypes:2011"
    schemaLocation="base-CommonTypes.xsd"/>
  <xs:element name="IPTVParentalControl" type="tns:tIPTVParentalControl" />
  <xs:complexType name="tIPTVParentalControl">
    <xs:sequence>
      <xs:element name="PC-Command" type="tns:tPCCommand" />
      <xs:element name="PC-ChannelChangedTo" type="tns:tPCChannelChangedTo"
        minOccurs="0" />
      <xs:element name="PC-ContentControlled" type="ct:ProgramIdType" >
        <xs:annotation><xs:documentation xml:lang="en">
          Identifier of the content being controled by the controller. MAY be SC
          service ID or content ID.
        </xs:documentation></xs:annotation>
      </xs:element>
      <xs:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>
  <xs:simpleType name="tPCCommand" final="list restriction">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Channel Change" />
      <xs:enumeration value="Session Teardown" />
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="tPCChannelChangedTo" final="list restriction">
    <xs:annotation>
      <xs:documentation xml:lang="en">
        Identifier of a new channel to which the controlled user SHALL change.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:minLength value="0" />
      <xs:maxLength value="16" />
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

Native HNI-IGI (IMS-based) Notification Request Setup Procedure

To initiate a request to setup a notification service, the OITF SHALL follow the following procedure:

DAE-based Notification Request Setup

Upon receipt of a notification setup request from the OITF, the IPTV application SHALL validate the request against the appropriate schema. Upon successful validation, the IPTV application stores the notification request in the user IPTV profile using XCAP PUT request for that purpose.

DAE-based Update of Pending Notifications

Update of pending notification requests is achieved through XML re-writing of the IPTV user service profile. It includes three steps; first all the user pending notification requests are retrieved from the user service profile; next the end user performs the necessary deletions/alterations; and finally the updated pending notification request is saved in the user service profile.

The IPTV application issue an XCAP GET to the user service profile and display the result to the user.

Upon receipt of a pending notification update request from the OITF, the IPTV application SHALL authorize the request, update its internal state, and subsequently SHALL issue an XCAP PUT to the IPTV service profile to store the updated pending notification requests. The IPTV service profile SHALL acknowledge the successful storage of the updated pending notification requests in an HTTP 200 OK to the IPTV application which in turn returns the response back to the OITF.

DAE-based Procedure for Retrieving Pending Notification Requests

Upon receipt of a pending notification retrieval request from the OITF, the IPTV application SHALL first authorize the request and subsequently SHALL issue an XCAP request to the IPTV service profile to retrieve all stored pending notification requests for the subject user. Upon receipt by the IPTV application of the stored information, it SHALL return to the OITF in an HTTP 200 OK response the requested information.

Protocol for Updating Pending Notification Requests

If the OITF desires to update pending notification requests stored in the network over UNIP-1, it SHALL send an XCAP GET request to the IPTV service profile. The IPTV service profile SHALL return all stored pending notification requests in an HTTP 200 OK response. Once the user completes the modification process, the OITF SHALL send an XCAP PUT request to the IPTV service profile to update pending notification requests.

If the IPTV service profile detects a change in the pending notification requests, it SHALL inform the IPTV Control FE, which in turn notifies the IPTV Application. The IPTV Control FE SHALL wait for the response before sending an HTTP 200 OK back to the OITF (or an appropriate error message if applicable).

Protocol for Retrieving Stored Pending Notification Requests

An OITF that desires to retrieve pending notification requests over UNIP-1, SHALL send an XCAP GET request to the IPTV service profile. The IPTV service profile SHALL return all pending notification requests in an HTTP 200 OK response.

Procedure for Notification Request Setup

Upon receipt of a store request for user notification from the IPTV Control FE, the IPTV application SHALL validate the request against the appropriate schema.

Upon successful validation, the IPTV application SHALL update its internal state and SHALL store the notification request in the user IPTV profile using XCAP PUT request for that purpose prior to returning a response.

Procedure for Updating (Deleting) a Pending Notification

Upon receipt of an update (delete request) for a pending user notification request from the IPTV Control FE, the IPTV application SHALL validate the request against its internal state and SHALL update its internal state accordingly.

Following that, the IPTV application SHALL acknowledge the update (deletion) or send an appropriate error response if applicable.

Incoming Request to the Notification AS for Delivery Notification to an IPTV User

Upon receipt by the Notification Services AS (MMS Parlay X web services AS) for an HTTP POST request for sending a delivery notification using the IMPagerMode, the Notification Services AS SHALL send a corresponding SIP MESSAGE to the Messaging AS, and SHALL wait for the SIP 200 OK (or other responses) before returning the corresponding HTTP response.

Upon receipt by the IPTV application of the HTTP 200 OK, it SHALL proceed to update its internal state and SHALL update as well the IPTV service profile to reflect the updated list of pending notification requests.

IMS-based Content Bookmark Creation Request

The OITF SHALL follow the following procedure for a content bookmark creation request:

Management of Content Bookmarking Creation Request by the Network

Content-related bookmark retrieval over HNI-IGI

The procedure for retrieval of content related bookmarks is similar to the procedure defined in section 5.3.2.1.2, “” with the addition that the OITF has indicated its willingness to receive the CoD-Bookmark Info Package according to section 12 of [[!PSS-MBMS]] at session initiation. Assuming that is the case, the following additional steps are added to the existing procedure:

After the OITF retrieves the content-related bookmark lists, the OITF displays the bookmark list to the user, and the user selects the bookmark from which she wishes to start viewing the content.

DAE-based Content Bookmark Creation Request

Upon receipt of an HTTP Request for a content bookmark creation request from the OITF, the bookmark IPTV Application SHALL authorize the request and SHALL verify if the bookmark is for scheduled content or CoD.

If the content bookmark is for a scheduled content, the bookmark IPTV application verifies first if the content is available for bookmarking, i.e. stored in the network. If available for bookmarking, the bookmark IPTV application, after performing the necessary adaptation, stores the bookmark information in the IPTV Service Profile using XCAP PUT request for that purpose.

For bookmarks related to CoD, the bookmark information is stored in the user IPTV Service Profile without any additional verification by the IPTV application.

DAE-based Bookmark Retrieval Request

Upon receipt of a content bookmark retrieval request from the OITF, the bookmark IPTV Application SHALL first authorize the request and subsequently SHALL issue an XCAP GET request to the IPTV Service Profile to retrieve all stored content bookmarks for the user.

DAE-based Content Bookmark Update over UNIS-6

Content Bookmark update is essentially achieved through XML re-writing of the content bookmarks in the IPTV user Service Profile. It includes three steps; first all the content bookmarks are retrieved from the IPTV Service Profile; next the end user performs locally the necessary update (deletions/alterations); and finally the updated content bookmark is saved in the IPTV Service Profile.

The bookmark IPTV Application SHALL authorize the request and subsequently SHALL issue an XCAP GET to the IPTV Service Profile and display the results to the user.

Upon receipt of a content bookmark request from the OITF, the bookmark IPTV Application SHALL authorize the request and subsequently SHALL issue an XCAP PUT to the IPTV Service Profile to store the updated content bookmarks. The IPTV Service Profile SHALL acknowledge the successful storage of the updated content bookmarks in an HTTP 200 OK to the bookmark IPTV application which in turn returns the response back to the OITF.

Note that XCAP supports several approaches for retrieving/storing bookmark information within the user profile. It is an implementation issue as to which approach the IPTV application implements.

Protocol for Storing Content Bookmarks

Upon receipt of a bookmark store request from the IPTV Control FE, the bookmark IPTV Application SHALL verify if the bookmark is for scheduled content or CoD.

If the content bookmark is for a scheduled content, the bookmark IPTV Application verifies first if the content is available for bookmarking, i.e. stored in the network. If available for bookmarking, the bookmark IPTV Application, after performing the necessary adaptation, stores the content bookmark information in the user IPTV Service Profile using XCAP PUT request for that purpose.

For bookmarks related to CoD, the content bookmark information is stored in the user IPTV Service Profile without any additional verification by the bookmark IPTV Application.

Following the completion of the XCAP transaction, a response is sent to the IPTV control server FE.

Protocol for Retrieving Stored Content Bookmarks

If the OITF desirers to retrieve content bookmarks stored in the network over UNIP-1, it SHALL send an XCAP GET request to the IPTV Service Profile. The IPTV Service Profile SHALL return all stored bookmarks in an HTTP 200 OK response.

Protocol for Updating Content Bookmarks

If the OITF desirers to update a content bookmark(s) stored in the network over UNIP-1, it SHALL send an XCAP GET request to the IPTV Service Profile. The IPTV Service Profile SHALL return all stored bookmarks in an HTTP 200 OK response. Once the user completes the update process, the OITF SHALL send an XCAP PUT request to the IPTV Service Profile to update the content bookmarks. The IPTV Service Profile SHALL acknowledge the successful storage of the updated content bookmarks in an HTTP 200 OK response.

PCh profile configuration

When the user wants to create a new Personalised Channel, the OITF of the user SHALL originate an HTTP GET request towards the IPTV Application via UNIS-6 reference point. The request SHALL carry the user ID.

When receiving the HTTP GET request for PCh configuration, the IPTV Application SHALL authorize and verify the request, and then send XCAP GET request to the IPTV Service Profile and retrieve the user's IPTV service profile. The XCAP GET request SHALL be delivered on NPI-17 and include the intended user ID.

After the request is authorized, the IPTV Application SHALL contact the IPTV Metadata Control via NPI-33 for searching and filtering of the content metadata, and generate the personalised content guide based on the user's personal setting (e.g. preference, location etc). The IPTV Application SHALL also create a valid Personalised Channel Identifier (PChId) for the generated PCh information.

The IPTV Application then responds 200 OK to the OITF via UNIS-6, carrying the generated PChId and associated PCh information, e.g., PCh item IDs (SC service ID or COD content ID), related time schedule, etc.

If the OITF desires to modify the PCh information that has been created, it SHALL send an HTTP PUT request through UNIS-6 to the IPTV Application, carrying the intended user ID and the PCh information for updating. The IPTV Application SHALL updates the PCh information towards the IPTV Service Profile FE through XCAP PUT over NPI-17, and then responds the OITF with a 200 OK.

PCh service provision

Generic Session Transfer Procedures

The procedures in this section are generic in nature and apply equally to the various modes of session transfer.

Session Transfer via Push Mode

The procedure at an OITF selected to be the target device (transferee OITF) in a push mode is as follows

Following that, all unicast content streaming procedures apply to the session.

Retrieval of Service Provider Discovery Information

The procedures in this section SHALL only be performed in the context of the default user. When the OITF supports native HNI-IGI, it SHALL follow the following procedure to retrieve Service Provider Discovery Information:

Procedure for Cancellation of the Subscription

The procedure for de-registering the IPTV default user MUST be preceded with a cancellation of subscription.

The procedure is the same as the procedure for initiating a subscription to the “ua-profile”, except that the X-OITF-Expires header in Table 50 SHALL be set to 0.

Note: Cancellation of subscription is not REQUIRED if the X-OITF-Expires header was set to 0 in the initial SUBSCRIBE request.

Refreshing the Subscription

The procedure for refreshing a subscription is the same as the procedure for initiating a subscription.

The application initiating the subscription procedure SHALL refresh the subscription based on the refresh subscription timer information received in the response to the subscription. Refreshing a subscription SHOULD be performed before the expiry of the refresh timer. A subscription that is not refreshed will be terminated.

The IG SHALL consider a subscription terminated if is not refreshed.

XCAP Application Usage for IPTV Service

Profile Management

The XML Configuration Access Protocol (XCAP) defined in RFC 4825 [[!XCAP]] is used for manipulating data stored in the IPTV Service Profile Functional Entity. XCAP allows a client to read, write and modify application configuration data, stored in XML format, on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. XCAP uses the HTTP methods PUT, GET, and DELETE to operate on documents stored in the Service Profile Functional Entity.

The data stored in the IPTV Service Profile Functional Entity relates to the operation of the IPTV service. This specification defines a new Application Usage to allow a client to manipulate data related to IPTV services.

XCAP requires the definition of XML documents that are compliant with the XML schema and constraints defined for a particular XCAP application usage. The application usage defines the XML schema for the data used by the application, along with other key pieces of information.

Central to XCAP is the construction of the HTTP URI that points to a particular document or certain components of it. A component in an XML document can be an XML element, attribute, or the value of it.

XCAP application usage

XCAP requires application usages to fulfil a number of steps in the definition of such application usage. The remainder of this section specifies the REQUIRED definitions of the IPTV services XCAP Application Usage.

Application Unique ID (AUID): Each XCAP application usage is associated with a unique name called the Application Unique ID (AUID). The AUID defined by this application usage falls into the vendor-proprietary namespace of XCAP AUID, where Open IPTV Forum is considered a vendor.
The proposed AUID to be allocated to the Open IPTV Forum IPTV services application usage SHALL be

XML schema: Implementations in compliance with this specification SHALL implement the XML schema defined in Annex C.

Default namespace: XCAP requires application usages to declare the default namespace. The default namespace of the IPTV services XCAP application usage SHALL be

MIME Type: The MIME type of IPTV service XML document SHALL be

Validation constraints: This specification does not specify any additional constraints beyond those defined by XCAP.

Data Semantics: The XML schema does not accept URIs that could be expressed as a relative URI reference causing a resolution problem. However, each of the supplementary services SHOULD consider if relative URIs are allowed in the subdocument tree, and in that case, they SHOULD indicate how to resolve relative URI references. In the absence of further indications, relative URI references SHOULD be resolved using the document URI as the base of the relative URI reference.

Naming conventions: By default, IPTV Service Profile XML documents are stored in the IPTV Service Profile Functional Entity. In order to facilitate the manipulation of an IPTV Service Profile XML document, the default XML file name SHALL be:

Resource interdependencies: This specification does not specify additional resource interdependency beyond those specified in the XML schema.

Authorization policies: The authorization policy for access and manipulation of an IPTV Service Profile document SHALL be defined by the Service Provider.

Subscription to notification of changes in the IPTV Service Profile

The procedure for subscription to notification of changes in the IPTV service profile SHALL be invoked from either a DAE application or an embedded application in the OITF. The procedures SHALL be as follows:

Refreshing the Subscription

It is the responsibility of the application initiating the subscription procedure to refresh the subscription according to the “refresh subscription timer” parameter received in the response to the subscription request. Refreshing the subscription SHOULD be performed before the expiry of the refresh timer. A subscription that is not refreshed SHALL be terminated after the expiration of the timer.

The IG SHALL consider a subscription terminated if is not refreshed.

Procedure for Cancellation of a Subscription

This procedure MAY be invoked at any time.

The procedure for de-registering the IPTV end user SHALL be preceded by the cancellation of any subscription for notification of changes in the user's IPTV Service Profile.

The procedure for cancellation of the subscription is the same as the procedure for initiating a subscription to the ua-profile event package, except that the X-OITF-Expires header in Table 54 SHALL be set to 0.

UNI-RMS for IG, AG and WAN Gateway

In addition to TR-069, the following specifications SHALL apply:

• TR-098 [[!TR098]] that defines the data model for the “internet gateway device” SHALL apply to the WAN Gateway FE (see RMS3 functional block of the “Open IPTV Forum — Functional Architecture” document [[.OIPF_ARCH2]])
• TR-106 [[!TR106]] that defines the data model for the generic CWMP-managed device SHALL apply to the IG, AG and WAN-Gateway FEs.
• TR-104 [[!TR104]] that defines the data model for the “SIP end-point” SHALL apply to the IG (see RMS2 functional block of the “Open IPTV Forum — Functional Architecture” document [[.OIPF_ARCH2]]).

UNI-RMS for OITF

Although the remote management functions are specified in the general framework document TR-069 [[!TR069]] by the Broadband Forum, the protocol to remotely manage OITF retail devices is intended to support limited functions mainly for Performance Monitoring and Diagnostics. Consequently, an OITF device doesn't fulfil all the requirements that are requested in TR-069 [[!TR069]]. The limitations outlined in the following sections SHALL apply.

OITF RPC Methods Support Requirements

An OITF SHALL implement the following RPC methods:

As an OITF device doesn't support all the RPC requirements as defined in [[!TR069]], the ACS SHALL implement the GetRPCMethods to discover the limited set of methods supported by the OITF.

The OITF RPC Methods SHALL respect the calling arguments and type as defined in [[!TR069]], with the following definition of the DeviceIdStruct that is used for the DeviceId argument of the Inform method:

• the 3 parameters ManufacturerOUI, ProductClass and Serial Number have slightly different semantic meanings in the context of OIPF and are obtained from the deviceID identifier (refer to section 6.1.3.2.1, “.”)
  • ManufacturerOUI = HEX(first 3 bytes of SHA-1(X))
  • ProductClass = "OIPF"
  • SerialNumber = HEX(remaining bytes, from 4th on, of SHA-1(X)) where, X = (MAC address as bytes) + (domain name in ASCII characters).

OITF Data Model

In the framework of the Open IPTV Forum, a specific data model for the Remote Management of a retail OITF device has been defined. The data model has been obtained from TR-135 [[!TR135]] and TR-106 [[!TR106]] with a selection of a reduced set of parameters using the same semantics (with a few exceptions) and the same types. The OITF data model is fully described in Annex J, “.”

Configuration of the IG via Configuration File

CPE WAN Management protocol based on Broadband Forum TR-069 [[!TR069]] SHALL be used to configure the IPTV application in the IG. An IPTV configuration file SHALL be used to populate the IG with the list of users with their IMPU, Alias and Passwords and also configure whether user authentication is to be performed by the IG.

If GBA Authentication or HTTP Digest Authentication is supported by the IG, the IG SHALL be configured with the following information:

• Whether it has to provide an intended identity or not in the GBA and HTTP Digest authentication procedures as described in [[.OIPF_CSP2]].
• The realm, username and password for regular HTTP Digest Authentication.

The file is downloaded to the IG during the IG power up procedure.

The configuration data SHALL be defined in XML and SHALL include the XML schema to be enforced against the configuration data.

Call Flow

There are 2 cases to be considered; the first case is when the remote server requests the IG to download the configuration file at power up of the IG. This requires the IG to contact the remote server. The download request is subsequently used by the server to request the IG to download the configuration file. Alternatively, if the server is configured (by some means) with the address of the IG, it can request the IG to contact it using the Connection Request Notification mechanism, if the remote server supports this mechanism.

The second case is when the process is initiated by the IG if it detects a corrupted file or if for some reason it lost the file due to a reboot or an internal error.

Figure 4 is a call flow depicting the configuration procedure.

The following is a brief description of the flow:

Steps 1-4:	Normal steps as per TR-069.
Step 5:	The IG sends an HTTP POST request with no HTTP entity body to the remote server.
Step 6:	The server returns an HTTP response that includes a Download request in the HTTP entity body. The arguments are set as follows: CommandKey: Mandatory — set by remote server FileType: Mandatory — set to 3: Vendor Configuration File. The vendor in this case is Open IPTV Forum URI: Mandatory — set by remote server Username: OPTIONAL — If used, MUST be configured in the IG and remote server Password: OPTIONAL — If used, MUST be configured in the IG and remote server TargetFileName: Mandatory — IPTV-ConfigurationParameters DelaySeconds: Mandatory — set to no delay Successful URI: Not provided Failure URI: Not provided
Step 7:	Following that, the IG proceeds to download the configuration file.
Steps 8-9:	Once the download is complete, the IG sends a TransferComplete request to the remote server. The arguments in the request are set as follows: CommandKey: Mandatory — Set to the value received in the Download request FaultStruct: Mandatory in case of failure according to TR-069 StartTime: Mandatory — Set according to TR-069 FinishTime: Mandatory — Set according to TR-069

Note that the above sequence is an example and there are other valid sequences that can achieve the same result.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oipf:config:ig:2009"
  xmlns:tns="urn:oipf:config:ig:2009"
  xmlns:enum="urn:ietf:params:xml:ns:enum-token-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema">
  <!--schema filename is config-ig.xsd -->
  <xs:annotation>
    <xs:documentation xml:lang="en">
      This schema is copyrighted by the Open IPTV Forum ("OIPF") and distributed in conjunction
      with Release 1 of the IPTV Solution Specification.
      Disclaimer
      The Open IPTV Forum members accept no liability whatsoever for any use of this document.
      This specification provides multiple options for some features. The Open IPTV Forum Profiling
      specification will complement the Release 1 specifications by defining the Open IPTV Forum
      implementation and deployment profiles. Any implementation based on Open IPTV Forum
      specifications that does not follow the Profiling specifications cannot claim Open IPTV Forum
      compliance.
      Copyright Notification
      No part MAY be reproduced except as authorized by written permission.
      Any form of reproduction and/or distribution of these works is prohibited.
      Copyright 2009 © Members of the Open IPTV Forum
      All rights reserved.
    </xs:documentation>
  </xs:annotation>
  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
    schemaLocation="xml.xsd" />
  <xs:import namespace="urn:ietf:params:xml:ns:enum-token-1.0"
    schemaLocation="imports/enum-token-1.0.xsd />
  <xs:element name="IGconfiguration" type="tns:IGconfigurationType" />
  <xs:complexType name="IGconfigurationType">
    <xs:sequence>
      <xs:element name="AuthenticationSet"
        type="tns:AuthenticationSetType" maxOccurs="unbounded" />
      <xs:element name="GatewayAuthentication" type="xs:boolean"
        minOccurs="0" />
      <xs:any namespace="##other" processContents="skip"
        minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="AuthenticationSetType">
    <xs:sequence>
      <xs:element name="Identifier" type="tns:IMSPublicIdType" />
      <xs:element name="Password" type="xs:string" />
      <xs:element name="Alias" type="xs:string" />
      <xs:sequence minOccurs="0">
        <xs:element name="IMPI" type="xs:string" />
        <xs:element name="SIPDigestPassword" type="xs:string" />
      </xs:sequence>
    </xs:sequence>
  </xs:complexType>
  <!-- ================== Definition for IMSPublicIdType ====================-->
  <xs:complexType name="IMSPublicIdType">
    <xs:choice>
      <xs:element name="e164Number" type="enum:e164numberType" />
      <xs:element name="SIPURI" type="tns:SIPURIType" />
    </xs:choice>
  </xs:complexType>
  <xs:simpleType name="SIPURIType">
    <xs:annotation>
      <xs:documentation xml:lang="en">
        SIP URI pattern is defined based on the SIP URI
        description provided in RFC 3261 (Section 2)
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:pattern
        value="[sS][iI][pP][sS]?:(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?" />
    <xs:restriction>
  </xs:simpleType>
</xs:schema>

<IGconfiguration>
  <AuthenticationSet>
    <Identifier><SIPURI>sip://operator.example.com/MickJ</SIPURI></Identifier>
    <Password>RollingStones</Password>
    <Alias>Mick Jagger</Alias>
    <IMPI>household123@operator.com</IMPI>
    <SIPDigestPassword>CCXDFGGH</SIPDigestPassword>
  </AuthenticationSet>
  <AuthenticationSet>
    <Identifier><SIPURI>sip://operator.example.com/BruceS</SIPURI></Identifier>
    <Password>TheBoss</Password>
    <Alias>BruceSpringstein</Alias>
    <IMPI>household123@operator.com</IMPI>
    <SIPDigestPassword>CCXDFGGH</SIPDigestPassword>
  </AuthenticationSet>
  <GatewayAuthentication>true</GatewayAuthentication>
</IGconfiguration>

User Registration

This procedure SHALL be invoked in following cases:

• When the OITF is turned on or restarted if the OITF supports the native HNI-IGI function.
• When an IPTV end user explicitly logs on at an OITF using an Alias or IMPU or a default IMPU.

The IG SHALL extract the deviceID from the sip instance feature tag.

If the deviceID and the IMPU match another deviceID and IMPU whose state is held in the IG, the IG SHALL conclude that the OITF has undergone a restart and SHALL proceed to immediately clear all SIP sessions belonging to the OITF. Following that, the IG SHALL de-register all users registered from that OITF.

If GRUU is not requested, the IG SHALL NOT perform IMS registration when the IMPU is already registered; however, the IG SHALL maintain a binding between the Alias/IMPU, the OITF device from which the registration is received (extracted from the sip instance feature tag) and the new contact information including the sip instance feature tag, which provides an easy way to guarantee uniqueness within the Address of Record (AOR).

Following the successful registration of the IMPU as per the procedure below, the IG SHALL maintain a binding between the Alias/IMPU, the OITF device (extracted from the sip instance feature tag described above) from which the registration is received, and the new contact information including the sip instance feature tag, which provides an easy way to guarantee uniqueness within the Address of Record (AOR).

If the identity being registered is the default identity, and if the default identity is not bound to any OITF in the consumer network, then the IG SHALL deregister its contact address for the default identity at the end of this procedure.

If the identity being registered is not the default identity and if the default identity is not bound to any OITF in the consumer network, then the IG SHALL deregister the default identity from the IG point of view at the end of this procedure.

If the OITF does not support native HNI-IGI, user registration SHALL be done through a DAE application.

User De-registration

This procedure is invoked in the following cases:

• The OITF is turned off and the OITF supports native HNI-IGI.
• An IPTV end user, who has registered with his own IMPU or a default IMPU, deregisters from an OITF.

Prior to de-registering the IMPU, the IG SHALL clear all SIP sessions in which the IMPU is engaged on the specific OITF device from which the de-registration occurred and SHALL subsequently remove all bindings between the IMPU and all SIP sessions on the impacted OIPF. Following successful deregistration of the IMPU, the IG SHALL remove the binding between the IMPU and the OITF device from which the de-registration has occurred.

If GRUU is not supported for this registration, the IG SHALL NOT perform IMS deregistration when an IMPU is already registered on multiple OITFs, but the IG SHALL remove the binding between the IMPU and the OITF from which the user has deregistered (extracted from the sip instance feature tag) including the contact information (including the sip instance feature tag).

If GRUU is not supported for this registration, the IG SHALL perform the IMS deregistration procedure if the IMPU was bound to a single OITF.

Following a successful de-registration, the IG SHALL remove the binding between the Alias/IMPU, the OITF device from which the registration is received (extracted from the sip instance feature tag).

Note that if following the successful de-registration of the IMPU, and if there are no more OITFs still turned on in the consumer network, the IG SHALL re-register the default identity from the IG point of view.

If the OITF does not support native HNI-IGI, user deregistration SHALL be done through a DAE application.

Procedure for Refreshing a Registration

This procedure MAY be initiated by the OITF at any time before the expiry of the registration refresh timer.

The procedure is the same as the procedure for registering a user. A registration SHALL be terminated if it is not refreshed before the expiry of the registration refresh timer.

For an OITF-initiated registration, the IG SHALL consider a registration terminated (that is, the user de-registered) if it is not refreshed. In this case, the IG executed the procedures associated with user deregistration.

Procedure for Subscription to the Registration Event Package

This procedure SHALL be invoked immediately after the successful registration of an IMPU (including the default identity) or an IPTV end-user identity.

Procedure for Terminating a Subscription to the Registration Event Package

This procedure SHALL be invoked prior to de-registering a user.

The procedure is the same as the procedure for initiating a subscription to the Registration event, however in this case the X-OITF-Expires header in Table 60 SHALL be set to 0.

For an OITF-initiated registration, the IG SHALL consider a subscription terminated if is not refreshed.

Refreshing Subscription to Registration Event

The procedure is the same as the procedure for initiating a subscription.

It is the responsibility of the application initiating the subscription procedure to refresh the subscription according to the refresh subscription timer information received in the response to the subscription request. Refreshing the subscription SHOULD be performed before the expiry of the refresh timer. A subscription that is not refreshed before the expiration of the refresh timer SHALL be terminated.

Registration of DAE/Embedded Applications

IMS applications, DAE or embedded, that are initiated in the OITF and expect unsolicited incoming messages SHALL register with the IMS network the feature tags and/or the appropriate service URN (ICSI) and /or IMS application reference identifier (IARI) for the initiated application where mandated by the specification governing the application [[!TS183063]], [[!SMPL-IM]], [[!TS124503]], [[!RFC3840]], [[!RFC3841]]. This allows unsolicited incoming SIP messages destined for users and targeted for these applications to be delivered to the appropriate application instance in the OITF.

The procedure used by an application for registering the appropriate feature tags and/or service URN (ICSI) and/or IARI is the same procedure used for user registration.

Initial GBA registration

After IMS registration is successfully performed, and if the IG supports GBA Authentication, OITFs supporting native HNI-IGI SHALL issue following GBA registration request to the IG. OITFs that do not support native HNI-IGI do not support GBA.

Credential Retrieval by an OITF for Re-use of GBA Authentication

The key Ks that is established during the GBA registration MAY be reused later for user authentication and service access by consumer network applications.

Each time an OITF needs to access a service that is offered by an AS (i.e. NAF) that requires GBA Authentication, a specific key Ks_NAF or Ks_ext_NAF SHALL be derived respectively by the IG or by the ISIM in the IG and the server side GBA Single Sign-on function (the BSF). This generated key SHALL be conveyed to the OITF in the consumer network by the IG, and to the AS by the server side GBA Single Sign-on function (the BSF). The key Ks_NAF or Ks_ext_NAF SHALL then be used for authentication between the OITF and the AS, using HTTP Digest authentication as specified by [[!UB-UA]]. The OITF SHALL act as the OIPF as specified in [[!UB-UA]].

As a pre-requisite to this procedure, the GBA procedure MUST have been successfully completed.

The complete procedure for retrieval of credentials by the OITF from the IG is specified in [[.OIPF_CSP2]].

The HNI-IGI procedure for credential retrieval is as follows:

HTTP Realm Retrieval by an OITF

HTTP Credential Retrieval by an OITF

If the OITF has registered to an IG which supports HTTP Digest Authentication using IG, each time the OITF needs to access a service offered by an application server that requires HTTP authentication, the OITF may use credentials retrieved from the IG. The conditions under which an OITF uses HTTP credentials retrieved from the IG are described in [[.OIPF_CSP2]].

The complete procedure for use of HTTP credentials by the OITF retrieved from the IG is specified in [[.OIPF_CSP2]].

The HNI-IGI procedure for HTTP credential retrieval is as follows:

Procedure on HNI-IGI

The OITF supports the following procedure for Caller ID. The incoming message carrying a Caller ID can either be handled by a native application in the OITF, or in a DAE application. The same HNI-IGI message format is used in either case.

Procedure for HNI-IGI — HTTP Option

The following procedure MAY be supported in the OITF for Caller ID presentation to the OITF user as a result for an incoming IMS voice call to the IG.

The incoming message, carrying information on the IMS voice call, can either be handled by a native application in the OITF, or by a DAE application. The same HNI-IGI message format is used in either case.

Procedure for OITF Originating an Instant Messaging

The following procedure is supported in the OITF to originate instant messages:

An instant message can either originate from a native application in the OITF or from a DAE application. The same HNI-IGI message format is used.

Incoming Instant Messaging Procedure

The following procedure is supported in the OITF for incoming instant messages.

The incoming message can be handled either by a native application in the OITF, or in a DAE application. The same HNI-IGI message format is used in either case.

Outgoing MSRP Chat Messages

Sending an MSRP Chat State Message

Receiving an MSRP Chat Message

Receiving an MSRP Chat State Message

OITF Target Discovery

An OITF that wants to locate a target OITF for session transfer purposes SHALL perform the procedures described in section 5.4.6.1.4, “”.

Subsequently a target OITF can be selected from the returned information.

Transferor OITF Initiating a Session Transfer Request - Push Mode

The following procedure SHALL be supported for the receiving OITF to select the appropriate OITF for consumption of the content.

A transferor SHALL initiate the request for a Content sharing session to transfer to an appropriate OITF. Upon successful transfer of the session, Content Sharing service will be streamed to the target device.

To initiate a session transfer request, the transferor OITF SHALL follow the following procedure:

Remote OITF Receiving an Incoming Session Transfer Request — Push Mode

Transferee OITF Receiving an Incoming Session Transfer Request — Push Mode

Refreshing of HNI-IGI PENDING_IG Message

HNI-IGI PENDING _IG messages SHALL have to be refreshed periodically by the OITF. The refresh time SHALL be maintained in the IG and SHALL NOT exceed a SIP Session Expiry timer, or a SIP subscription Refresh timer for the SIP session under consideration.

To enable an OITF to refresh an HNI-IGI PENDING_IG request, the IG SHALL, upon timer expiry, send an HTTP 200 OK response that does not include any X-OITF-<Extension headers>.

Upon receipt of such a response, the OITF MAY decide to resend a new HNI-IGI PENDING_IG request or simply gracefully terminate the session.

Cancelling an HNI-IGI PENDING_IG Message

The IG considers an HNI-IGI PENDING_IG Request cancelled SHOULD it encounter one of the following events:

• The TCP connection on which the HNI-IGI PENDING_IG Request has been received is explicitly disconnected or timed out
• The IG received from the OITF application with an outstanding HNI-IGI PENDING_IG Request an HNI IGI SIP Request to terminate the session (a SIP BYE)
• The IG received from the OITF application with an outstanding HNI-IGI PENDING_IG Request an HNI IGI SIP Request to terminate an ongoing subscription (a SIP SUBSCRIBE with X-OITF-Expiry set to 0)

For the last 2 cases, the IG SHALL send an HTTP 200 OK response that does not include any X-OITF-<Extension-headers> as a response to the PENDING-IG request. OPTIONALly, the IG MAY empty its internal buffers that MAY include in-transit messages destined for the applications.

getKeyScheduleSignaling operation

Input parameter structure definition

Hereunder is the XML schema of the GetKeyScheduleSignalingRequest message:

Table ####: GetKeyScheduleSignalingRequestType

Field name	Field type	Multiplicity	Description	Reference
contentId	xs:string	1	Identifier for a content, a content being either a scheduled content service, an event on a scheduled content service (i.e. with access criteria specific to the event) or a CoD asset. It is provided by the Scheduling Function (for Scheduled content) or the Content Management Function (for CoD).
encryptionProfile	EncryptionProfileType	1	Set of properties for the management of the content key and the signaling.	5.7.1.2.5.6
drmInfo	DrmInfoType	0..N	Information for addressed DRM systems. This allows the calling entity to provide a set of DRM systems for which the drmSignaling shall be provided. An empty list means that the called entity manages a DRM list from its own configuration.	5.7.1.2.5.2
pregenerationWindow	PregenerationWindowType	1	The time information for the Key Management Function to know the period it is expected to generate keys for.	5.7.1.2.5.8

Output parameter structure definition

Hereunder is the XML schema of the GetKeyScheduleSignalingResponse message:

Table ####: GetKeyScheduleSignalingResponseType

Field name	Field type	Multiplicity	Description	Reference
status	StatusType	1	The global status of the request.	5.7.1.2.4.2
errorCode	xs:unsignedInt	0..1	The code of the error in case the status is not OK. Values are specific to the implementation of the called entity. It is omitted in case the request succeeds.
errorMessage	xs:string	0..1	Any additional information related to the status in case of errors. It is omitted in case the request succeeds.
timeReference	TimeReferenceType	0..N	The dates and times for which keys have been generated. It is omitted in case the request failed.
contentKey	ContentKeyType	0..1	The content key to be used to protect the content. It is omitted in case the request failed.
drmSignaling	DrmSignalingType	0..N	The signaling information according to every provided streaming mode. This information allows the CSP client to find the key materials required to decrypt a given content, either locally when the key has already been retrieved or remotely when requested for the first time. Each DRM will provide signaling information for a given [content/content key] pair, such as URL of the CSP server or DRM. The DRM information is DRM specific. It is omitted in case the request failed.

The called entity generates the keys based on its schedule and provides:

• the key (i.e. contentKey element) to use at the requested time (i.e. timeReference element in the pregenerationWindow element of the request) provided by the calling entity,
• the signaling (i.e. list of drmSignaling elements) to be inserted by the Encryption Function when using the key,
• the times (i.e. timeReference element) for the current and next keys encompassing the window duration (i.e. windowDuration element in pregenerationWindow element of the request). These times should be used to perform the subsequent calls to this method.

One drmSignaling element is provided for every provided streamingMode. For each streamingMode either a dashSignaling or a privateSignaling element is provided for every addressed DRM. This element holds the drmSystemId and the signaling information (defined by the encryptionProfile). For DASH and CENC, either a manifestHeader (XML fragment) or a PSSH box data or both can be provided. The manifestHeader is to be inserted in the MPD, the psshBox is to be inserted in the content.

In case an error occurs, then no contentKey, no timeReference, and no drmSignaling elements will be provided.

setScheduleAndGetKeySignaling operation

Input parameter structure definition

Hereunder is the XML schema of the SetScheduleAndGetKeySignalingRequest message:

Table ####: SetScheduleAndGetKeySignalingRequestType

Field name	Field type	Multiplicity	Description	Reference
encryptionProfile	EncryptionProfileType	1	Set of properties for the management of the content key and the signaling.
drmInfo	DrmInfoType	0..N	Information for addressed DRM systems. This allows the calling entity to provide a set of DRM systems for which the drmSignaling shall be provided. An empty list means that the called entity manages a DRM list from its own configuration.
schedule	ScheduleType	1..N	The times provided by the Encryption Function for which the Key Management Function has to generate keys.

Output parameter structure definition

Hereunder is the XML schema of the SetScheduleAndGetKeySignalingResponse message:

Table ####: SetScheduleAndGetKeySignalingRequestType

Field name	Field type	Multiplicity	Description	Reference
status	StatusType	1	The global status of the request.
errorCode	xs:unsignedInt	0..1	The code of the error in case the status is not OK. Values are specific to the implementation of the called entity. It is omitted in case the request succeeds.
errorMessage	xs:string	0..1	Any additional information related to the status in case of errors. It is omitted in case the request succeeds.
contentKey	ContentKeyType	0..1	The content key to be used to protect the content. It is omitted in case the request failed.
drmSignaling	DrmSignalingType	0..N	The signaling information according to every provided streaming mode. This information allows the CSP client to find the key materials required to decrypt a given content, either locally when the key has already been retrieved or remotely when requested for the first time. Each DRM will provide signaling information for a given [content/content key] pair, such as URL of the CSP server or DRM. The DRM information is DRM specific. It is omitted in case the request failed.
keyIdSchedule	KeyIdScheduleType	0..N	The dates and times for which keys have been generated, and the keyId of these keys. It is omitted in case the request failed.

The called entity generates new keys based on the times provided by the calling entity and provides:

• the key (i.e. contentKey element) to use at the requested time (i.e. timeReference element in the schedule element of the request, with isCurrentKey set to true) provided by the calling entity,
• the signaling (i.e. list of drmSignaling elements) to be inserted by the Encryption Function when using the key,
• for the next keys, the key identifiers of the next keys with their times (i.e. keyId and timeReference elements in the schedule element of the request, with isCurrentKey set to false). These times and optionally key identifier should be used to perform the subsequent calls to this method.

One drmSignaling element is provided for every provided streamingMode. For each streamingMode either a dashSignaling or a privateSignaling element is provided for every addressed DRM. This element holds the drmSystemId and the signaling information (defined by the encryptionProfile). For DASH and CENC, either a manifestHeader (XML fragment) or a PSSH box data or both can be provided. The manifestHeader is to be inserted in the MPD, the psshBox is to be inserted in the content.

In case an error occurs, then no contentKey, no keyIdSchedule, and no drmSignaling elements will be provided.

setKeyScheduleAndGetSignaling operation

Input parameter structure definition

Hereunder is the XML schema of the SetKeyScheduleAndGetSignalingRequest message:

Table ####: SetKeyScheduleAndGetSignalingRequestType

Field name	Field type	Multiplicity	Description	Reference
encryptionProfile	EncryptionProfileType	1	Set of properties for the management of the content key and the signaling.
drmInfo	DrmInfoType	0..N	Information for addressed DRM systems. This allows the calling entity to provide a set of DRM systems for which the drmSignaling shall be provided. An empty list means that the called entity manages a DRM list from its own configuration.
scheduledKey	ScheduledKeyType	1..N	The keys provided by the Encryption Function.

Output parameter structure definition

Hereunder is the XML schema of the SetKeyScheduleAndGetSignalingResponse message:

Table ####: SetKeyScheduleAndGetSignalingResponseType

Field name	Field type	Multiplicity	Description	Reference
status	StatusType	1	The global status of the request.
errorCode	xs:unsignedInt	0..1	The code of the error in case the status is not OK. Values are specific to the implementation of the called entity. It is omitted in case the request succeeds.
errorMessage	xs:string	0..1	Any additional information related to the status in case of errors. It is omitted in case the request succeeds.
drmSignaling	DrmSignalingType	0..N	The signaling information according to every provided streaming mode. This information allows the CSP client to find the key materials required to decrypt a given content, either locally when the key has already been retrieved or remotely when requested for the first time. Each DRM will provide signaling information for a given [content/content key] pair, such as URL of the CSP server or DRM. The DRM information is DRM specific. It is omitted in case the request failed.

The calling entity provides both the keys and the times to use them. The called entity stores them and provides the signaling (i.e. list of drmSignaling elements) to be inserted by the Encryption Function when using the current key (i.e. scheduleKey element with isCurrentKey set to true).

One drmSignaling element is provided for every provided streamingMode. For each streamingMode either a dashSignaling or a privateSignaling element is provided for every addressed DRM. This element holds the drmSystemId and the signaling information (defined by the encryptionProfile). For DASH and CENC, either a manifestHeader (XML fragment) or a PSSH box data or both can be provided. The manifestHeader is to be inserted in the MPD, the psshBox is to be inserted in the content.

In case an error occurs, then no drmSignaling element will be provided.

Simple types

Data structures

Protocol over UNIS-8

Protocol over NPI-4