5.3.1.1.1 Session Initiation

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

5.3.1.1.2 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, “Retrieval of Session Parameters”, 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, “Session Initiation”) 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.

5.3.1.1.3 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 5.

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.

5.3.1.1.4 Session Termination

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

5.3.1.1.5 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.

5.3.1.1.6 Content Reporting and Management of Content Reporting of Watched Scheduled Content

5.3.1.1.7 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>

5.3.2.1.1 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:

5.3.2.1.2 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.

5.3.2.1.3 Session Termination

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

5.3.2.1.4 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.

5.3.5.3.1 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.

5.3.5.3.2 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:

5.3.5.4.1 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.

5.3.5.5.1 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.

5.3.6.1.1 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, “Session Initiation”, 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.

5.3.6.1.2 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, “Session Modification.”

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, “Fast Channel Change (FCC)”. Further, when multicast RET service is offered, the OITF shall join the RET stream as defined in Annex M.1, “Application Layer Retransmission (RET)”.

5.3.6.1.3 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, “PPV Service initiation without existing multicast content streaming session.”

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.

5.3.6.1.4 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, “Session Termination” for an originating OITF.

5.3.7.1.1 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:

5.3.7.1.2 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.

5.3.7.1.3 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.

5.3.7.1.4 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>

5.3.7.2.1 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, “Protocol for What is on TV – OITF initiated – HTTP Option.” 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, “Parental Control for Content using SIP.” The SIP-specific information is mapped to the HNI-IGI protocol, as described in section 5.6.1, “OITF-IG Interface (HNI-IGI).”

5.3.7.2.2 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.

5.3.7.2.3 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>

5.3.8.1.1 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:

5.3.8.2.1 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.

5.3.8.2.2 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.

5.3.8.2.3 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.

5.3.8.3.1 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).

5.3.8.3.2 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.

5.3.8.4.1 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.

5.3.8.4.2 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.

5.3.8.5.1 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.

5.3.9.1.1 IMS-based Content Bookmark Creation Request

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

5.3.9.1.2 Management of Content Bookmarking Creation Request by the Network

5.3.9.1.3 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, “Session Initiation” 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.

5.3.9.2.1 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.

5.3.9.2.2 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.

5.3.9.2.3 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.

5.3.9.3.1 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.

5.3.9.4.1 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.

5.3.9.4.2 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.

5.3.12.1.1 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.

5.3.12.1.2 PCh service provision

5.3.13.1.1 Generic Session Transfer Procedures

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

5.3.13.1.2 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.

5.4.1.1.1 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:

5.4.1.1.2 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.

5.4.1.1.3 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.

5.4.4.1.1 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.

5.4.4.3.1 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:

5.4.4.3.2 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.

5.4.4.3.3 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.

5.4.5.1.1 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]).

5.4.5.1.2 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, “User Identity Modelling.”)
  • 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, “OITF-specific TR-135 and TR-106 Remote Management Objects.”

5.4.5.1.3 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.

5.4.5.1.3.1 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.