RTSP specific usage on UNIS-11 and NPI-10 for the managed model

In this example, the RTSP delivery parameters have been obtained as indicated in Volume 4 [[.OIPF_PROT2]].

The RTSP URI is: rtsp://Cluster.orangeCDN.net/chevaliers_du_ciel

The session ID is 940211290776250

PLAY  rtsp://Cluster.orangeCDN.net/chevaliers_du_ciel
	CSeq: 1981
	Session: 940211290776250

PLAY  rtsp://server1.Cluster.orangeCDN.net/chevaliers_du_ciel
	CSeq: 1981
	Session: 940211290776250

200 OK
	CSeq: 1981
	Session: 940211290776250

200 OK
	CSeq: 1981
	Session: 940211290776250

RTSP specific usage on UNIS-11 and NPI-10 for the unmanaged model

DESCRIBE rtsp://Cluster.orangeCDN.net/chevaliers_du_ciel RTSP/1.0
	CSeq 1306
	Accept: application/sdp

RTSP/1.0 302 Moved Temporarily
	CSeq 1306
	Location: rtsp://Cluster_B.orangeCDN.net/ chevaliers_du_ciel  RTSP/1.0

DESCRIBE rtsp://Cluster_B.orangeCDN.net/chevaliers_du_ciel
	CSeq: 1979
	Accept: application/sdp

DESCRIBE rtsp://Server1.orangeCDN.net/chevaliers_du_ciel  RTSP/1.0
	Cseq: 1979
	Accept: application/sdp

200 OK
	Cseq: 1979
	Content-Type: application/sdp
	Content length: ...
	//// SDP////

200 OK
	CSeq: 1979
	Content-Type: application/sdp
	Content length: ...
	////SDP ////

Content Reporting

Management of Content Reporting

Purchase Request procedure of selected Digital Media related to the content

Confirmation process: After retrieving and advertising the Digital Media, users can select the Digital Media they want to buy. When a user selects one Digital Media, the OITF pops up a dialog box to let the user confirm the selected Digital Media for purchase purpose.

Repeat billing check: Before sending the purchase request for Digital Media, the OITF must check the user's profile first (in order to avoid repeat billing). If the requested Digital Media is already recorded in user's profile, the OITF pops up a dialog box to let user know the repeat billing, and then stop sending the purchase request.

If the requested Digital Media is not recorded in user's profile, the OITF sends the HTTP purchase request to IG, and IG generates a SIP request to IPTV Control FE through ASM FE, and then the IPTV Control FE sends the purchase request (ACR) to Charging FE.

After receive the purchase response (ACA) from Charging FE, and if the purchase is successful, the IPTV Control FE sends Digital Purchase Request to IPTV Applications FE to update the user's profile, and then the IPTV Applications FE sends the XCAP PUT to IPTV Service Profile FE to update the purchased digital media record.

After receive the HTTP response sent from IPTV Service Profile FE, the IPTV Applications FE sends the response to IPTV Control FE. The IPTV Control FE sends the SIP 200 OK response (with no message body) to IG through ASM FE if the purchase request success; otherwise, the IPTV Control FE sends the SIP 403 Forbidden response (the message body is Result-Code that defined in [[!RFC3588]]) to IG through ASM FE. Finally, the IG sends the HTTP 200 OK to OITF with purchase result (it can be either “success” or Result-Code).

Figure 5 shows the purchase request procedure of selected Digital Media related to the content.

Because the purchase request happen in the period of pause during a Scheduled content (if supported) or a CoD content, the OITF has already established a session between itself and IPTV Control FE. The SIP INFO will use this established session to transmit information about purchase request.

PPV service initiation without existing Scheduled Content session

Figure 6 shows a typical call flow for watching a initiating PPV service without an existing Scheduled Content session.

User-initiated PPV service switched from the Scheduled Content service

User Activation for Scheduled Content Time Shift

User Deactivation for Scheduled Content Time Shift

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

DAE-based User Notification Setup Request

Figure 14 shows a call flow for a DAE-based user notification setup request. Below is a brief description of the call flow:

It is assumed that user is interacting with the EPG and made a selection for a notification request for one of the services offered by the service provider. This could include a broadcast reminder, or services related to recorded content requested by the user

Native HNI-IGI Update of Pending Notification Requests

Figure 15 shows an IMS-based call flow for updating pending user notification requests.

Below is a brief description of the call flow:

DAE-based Update of Pending Notification Requests

Figure 16 shows a DAE-based call flow for update of pending user requests.

Below is a brief description of the call flow:

DAE-based Fetching of Pending Notification Requests

Sending a Notification to an OITF

Figure 18 shows a Notification sent to an OITF using IMS pager mode (SIP MESSAGE).

Below is a brief description of the call flow:

Sending a Notification to a Cellular Device

Figure 19 shows a Notification sent to a cellular device

Below is a brief description of the call flow:

Content Bookmarking in a Scheduled Content Session

Content bookmarking in a scheduled content session essentially represents a mark in a file stored in the network for the scheduled content. As such, it is a pre-requisite that the scheduled content be stored in the network for any bookmarking to be available for a scheduled content. The stored bookmarking hence will be a pointer in the network stored scheduled content

Figure 20 shows a call flow for a user requesting a content bookmark to be stored within a scheduled content session. This call flows assumes that the scheduled content is already stored in the network. Below is a brief description of the call flow:

Content Bookmarking in a CoD Session

Content-related bookmark retrieval

Content-related retrieval allows a user to retrieve all the bookmarks previously set against the content item the user had chosen for viewing. For example, the user watches a show, and sets bookmarks on some terrific scenes so that they may be reviewed later. Some time later, when the user wants to review the show, the user requests the content for viewing. At the same time, all the bookmarks for that content item are transferred from the network to the OITF, and the user can watch from any of the bookmarked points.

Content Bookmark Update (DAE-Based)

Content Bookmark Update (e.g. for deleting a stored bookmark) is essentially achieved through XML re-writing of the IPTV user Service Profile content bookmarks. It includes three steps; first all the content bookmarks are retrieved from the IPTV Service Profile; next the end user performs the necessary update; and finally the updated content bookmark(s) is saved in the IPTV Service Profile.

Figure 23 shows a call flow for a updating a content bookmark. Below is a brief description of the call flow:

PCh Profile Configuration

Figure 24 depicts the call flow for configuration of the Personalised Channel where the IPTV Application generates the personalised content guide at the user's request based on the user profile and content metadata.

The user can update the personalised content guide with their own preferences as well.

The following is a brief description of the steps:

PCh Service Provision

The figure below depicts the call flow for PCh service provision, where a single unicast session between the ITF and the network is established for multiple items provided by the network, regardless of the content types (scheduled content item or content-on-demand item).

The following is a brief description of the steps:

Local Request for Service Provider Controlled Local PVR Recording

Based on the EPG, the user decides to set-up the recording of a program (immediate or scheduled). The recording is performed on Local Storage, under the control of the IPTV Service Provider.

It is also possible to achieve this procedure through a DAE application interacting with an IPTV Application directly, but this is not described in this subsection.

Figure 26 shows a call flow for a local PVR recording session.

The following is a brief description of the steps in the flow:

The user, based on information provided by the EPG, orders the recording of an available scheduled content item scheduled for future multicast delivery.

Note: Immediate recording is analogous to scheduled recording with the timer set to 0.

Remote Request for Service Provider Controlled Local PVR Recording

Remote requests for recording allow an authorized user to perform PVR requests from an OITF different than the one used for recording.

Figure 27 shows a call flow for a remote request for a local PVR recording session.

The following is a brief description of the steps in the flow:

The user, based on information provided by the EPG, orders the recording of an available scheduled content program scheduled for future multicast delivery on OITF 2.

OITF-initiated nPVR Recording — Synchronous Method

Based on the EPG, the user decides to set-up the recording of a program (immediate or scheduled). The recording is performed on Network Storage, under the control of the IPTV Service Provider.

Figure 28 shows a call flow for the synchronous method of setting up a nPVR recording session.

The following is a brief description of the steps in the flow:

OITF-initiated nPVR Recording — Asynchronous Method

Based on the EPG, the user decides to set-up the recording of a program (immediate or scheduled). The recording is performed in the CDN, under the control of the IPTV Service Provider.

Figure 29 shows a call flow for the asynchronous method of setting up a nPVR recording session.

The following is a brief description of the steps in the flow:

Remote request from a non-OITF device for a PVR Recording

OITF-Centric Personalised Channel

Emergency Notification service

Emergency notification is a type of notification about critical events, which the network initiates and sends to the OITF. Emergency notifications are discovered and obtained without user intervention.

Figure 31 shows the call flow for retrieving emergency notification.

The following is a brief description of the steps in the flow:

Network Generated Notification Service

Network generated notifications can be provided by the network to the user about events related to a scheduled content service, i.e. the notification service should only be consumed together with the related scheduled content service. To allow the independent purchase of such notifications, the notification service is described as a separate service from the related scheduled content. In this case, an extension to the scheduled content service mechanism, through the inclusion of a “Network Generated Notification” indicator, is used to identify such a notification service.

A network-generated notification message is a multimedia message consisting of text, picture and/or audio-video clips. Multicast delivery is used for delivering such network-generated notifications to multiple users at the same time.

To access to the scheduled content as well as the related notification service in one procedure, the scheduled content session initialization procedure is extended, as shown in Figure 32.

The following is a brief description of the steps:

Example — Push Mode

Generic Procedures

Target Device (Transferee OITF) initiating a new Session associated with Session Transfer

Figure 34 shows a typical call flow for a transferee initiating a session. Below is a brief description of the call flow:

Step 1:	It is assumed that target OITF (transferee) accepted a session transfer from a transferor, and is ready to initiate a new session to stream the content on the target OITF. The transferee OITF issues an HTTP POST request to the IG to request the service.
Step 2:	The IG performs the necessary procedure as per Volume 4 [[.OIPF_PROT2]] to take the appropriate action in case both OITFs involved in a session transfer are behind the same IG. Following that, IG performs the necessary validation then issues a SIP INVITE to the ASM.
Step 3:	The ASM performs the initial resource reservation then issues a SIP INVITE to the IPTV Control FE
Step 4:	The IPTV Control FE authorizes the session transfer, and then undertakes one of several actions depending on the SDP in the incoming INVITE. If the IPTV Control FE can re-use the existing CDF from the old session, it issues a SIP Re-INVITE towards the CDNC associated with the original session. If the IPTV Control FE cannot re-use the old CDF, it tears down the SIP leg associated with the delivery control channel and establishes a new SIP leg based on the incoming SDP. This is the case in this example.
Steps 5-15:	These steps are then identical to a regular CoD session set up procedure. The only exception being that before the IPTV Control FE forwards a SIP 200 OK to the transferee OITF via the ASM; it tears down the old SIP leg associated with the transferor.
Step 16:	At the end of this procedure, the IG returns to the transferee OITF an HTTP 200 OK that includes the SIP 200 OK to the session initiation. The RTSP session identifier is also included

IG handling of Session Initiation Requests Associated with Session Transfers

Figure 35 shows a typical call flow for the procedure followed by the IG during CoD session initiation associated with a session transfer. In particular, if the transferor and the transferee are behind the same IG, the IG must release the resources associated with the old IMS session belonging to the transferor, prior to establishing the new IMS session associated with the transferee. This avoids double booking for the resources on the access leg. Below is a brief description of the call flow:

Step 1:	The transferee OITF after accepting a session to be transferred is ready to initiate new session to stream the content on the target (transferee) OITF. The transferee OITF issues an HTTP POST request to the IG to initiate a new session to handle the transferred session.
Step 2:	If the IG determines that no session transfer is associated with the request, it terminates the procedure. If the new session request is associated with a session transfer, the IG verifies if the dialog identifier included in the request and that has to be replaced matches any of the SIP session states held in the IG. If there is no match implying that the transferor belongs to another IG, the procedure terminates. If there is match, implying that the transferor and the transferee are behind the same IG, the procedure continues through the remaining steps. It is assumed that the transferor OITF has an HTTP PENDING_IG request in anticipation of any incoming messages
Step 3:	The IG returns to the transferor OITF an HTTP 200 OK response that includes a SIP re-INVITE to put the media on hold.
Steps 4-7:	These steps are optional and are performed by the OITF in case the transferor OITF did not pause the stream.
Step 8:	Once the above steps are successfully completed, the transferor OITF issues an HTTP POST PENDING_IG request that includes the SIP 200 OK response.
Step 9:	The IG returns an HTTP 200 OK response that includes the ACK.
Steps 10-13:	The IG then issues a SIP UPDATE (or a SIP re-INVITE) to the IPTV Control FE to release the resources associated with the IMS session associated with transferor OITF

The procedure is completed with the reception of the SIP response to the SIP UPDATE message.

Session Transfer — Push Mode

Transferor initiating a transfer Request to a Transferee (Target Device)

Figure 36 shows a typical call flow for a transferor OITF initiating a transfer request to a transferee. Below is a brief description of the call flow:

Step 1:	It is assumed that transferor OITF has an established CoD session, has selected a target OITF2, to be the transferee.
Step 2:	The transferee OITF2 issues an HTTP POST PENDING_IG request to the IG in anticipation of incoming requests.
Step 3:	The transferor OITF1 issues an HTTP POST request to the IG.
Step 4:	The IG validates the request, and then issues a SIP REFER to the IPTV Control FE.
Step 5:	The transferor OITF1 issues an HTTP PENDING_IG request.
Step 6:	The IPTV Control FE validates and authorizes the session transfer then issues a SIP REFER to the IG associated with the transferee OITF2.
Step 7:	The IG returns an HTTP 200 OK response to the transferee OITF2 that includes the REFER request IG.
Step 8:	The transferee OITF2 issues an HTTP POST PENDING_IG request to the IG that includes the SIP 202 OK response (transferee accepting the transfer).
Step 9:	The IG returns the SIP 202 OK response to the IPTV Control FE via the ASM.
Step 10:	The IPTV control FE generates a SIP 202 OK that reaches the IG of the transferor OITF1 via the ASM.
Step 11:	The IG returns an HTTP 200 OK response to the transferor OITF1 that includes the SIP 202 OK response
Step 12:	The transferor OITF 1 issues an HTTP PENDING_IG request in anticipation of the incoming SIP NOTIFY confirming the outcome of the transfer.

Handling of Post Session Initiation setup by Target Device (Transferee OITF)

Figure 37 shows a typical call post successful session establishment by the transferee OITF2. Below is a brief description of the call flow:

Step 1:	It is assumed that the transferee OITF2 has successfully established a new CoD for session transfer purposes. The transferee OITF2 issues an HTTP POST request to the IG to report the outcome of the session transfer to the transferor OITF1.
Step 2:	The IG validates the request and then issues a SIP NOTIFY to the IPTV Control FE.
Step 3:	The IPTV Control FE validates the request then issues a SIP NOTIFY to the IG associated with the transferee OITF1.
Step 4:	The IG returns an HTTP 200 OK response to the transferor OITF1 that include the NOTIFY request.
Step 5:	The transferor OITF1 issues an HTTP POST PENDING_IG request to the IG that includes the SIP 200 OK response to the transferee OITF2.
Step 6:	The IG returns validates the response then issues a SIP 200 OK response to the IPTV Control FE via the ASM.
Step 7:	The IPTV control FE generates a SIP 200 OK that reaches the IG associated with the transferee OITF2 via the ASM.
Step 8:	The IG returns an HTTP 200 OK response to the transferee OITF2 that includes the SIP 200 OK response
Note that steps 1 to 8 are performed regardless if OITF2 was successful or unsuccessful in establishing the new session to handle the transferred session. The remaining steps, 9-13 in the call flow, are performed in case of successful session establishment by OITF2. In the event of unsuccessful establishment of the session by OITF2, OITF1 has the option to resume the original session, or tear down the session, If OITF1 decides to resume the original session, it must acquire the necessary resources if it has released them during the course of the session transfer procedure.
Step 9:	The transferee OITF 2 locates the content bookmark. If it has received it in the incoming SIP REFER request, proceeds to the next step. If it did not receive it, it fetches the bookmark associated with the content and locates the appropriate bookmark.
Steps 10-13:	The transferee OITF2 issues an RTSP play to start streaming the content from the bookmark location.

User Registration and Authentication in a Managed Model

Default User Identities Registration

The default user IMS Public Identity (IMPU) allocated to the subscription will be automatically registered in the provider network whenever the OITF is turned on.

Figure 38 shows a typical call flow for a default public identity registering in a provider network. The following is a brief description of the steps:

Step 1:	The procedure is triggered automatically without any user intervention. The OITF issues an HTTP POST request.
Step 2:	The IG validates that the request.
Step 3:	The IG performs the normal IMS registration procedure. If the IG does not perform IMS registration because the default identity is already registered (another OITF is activated), the IG still maintains a binding between the IMPU, the OITF 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).
Step 4:	The IG returns the outcome of the registration process to the OITF.
Step 5:	If the result of the registration procedure is successful, a registration state is created and maintained in the IG which is stateful to the registration process until such time as a de-registration occurs.
Step 6:	An indication is sent to the user that includes the outcome of the registration process.

IPTV End User Registration

Figure 39 shows a typical call flow for an IPTV end-user registering a specific IMPU in a provider network. The following is a brief description of the steps:

Step 1:	The procedure can be triggered by the user wanting to register himself (a specific IMPU associated with him) in the provider network. Other options (e.g. Configuration) can also trigger the procedure.
Step 2:	The IG validates the HTTP POST request.
Step 3:	The IG performs the normal IMS registration procedure. The IG does not perform an IMS registration if this IMPU is already registered (i.e. another OITF is activated with the same IMPU registered), the IG maintains a binding between the IMPU, the OITF device 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).
Step 4:	The IG returns the outcome of the registration process to the OITF.
Step 5:	If the result of the registration procedure is successful, a registration state is created and maintained in the IG which is stateful to the registration process until such time as a de-registration occurs.
Steps 6-7:	An indication is sent to the user that includes the outcome of the registration process.

IPTV End User De-registration

User de-registration is similar to user registration.

The call flow for the de-registration process is shown in Figure 40.

IPTV Default User De-registration

The call flow for the de-registration process is shown in Figure 41.

Subscription to the registration-state event package

Following the completion of a successful registration, for a default public identity or the IMPU associated with a specific IPTV end-user, the registration application SHALL subscribe to the Registration event. This is mandatory in order to notify the OITF of any event concerning registration (e.g., a registration timeout). This allows the application to take appropriate action, such as re-registering, etc.

Figure 42 shows a typical call flow for subscription to the registration event. The following is a brief description of the steps:

Step 1:	The OITF concludes a successful registration for a default identity or a specific IMPU associated with an IPTV user.
Step 2:	Immediately following a successful registration, the OITF issues an HTTP POST request for subscription to the Registration event.
Step 3:	The IG validates that the request.
Step 4:	The IG performs the normal IMS Subscription process.
Step 5:	The 200 OK is received from the network.
Step 6:	The IG returns an HTTP 200 OK response to the HTTP POST that includes the SIP 200 OK response to the SIP SUBSCRIBE.
Steps 7-11:	The mechanism for receiving and acknowledging the SIP NOTIFY from the network are covered in Steps 7 to 11.

Originating Instant Messages

Instant messaging uses paging mode, therefore it requires a session to be established between the 2 peers.

Figure 45 shows a call flow for an IPTV end-user invoking the Instant Messaging service. Below is a brief description for the call flow:

Incoming Instant Messages to IPTV end-users

Caller ID as a DAE or Embedded Application

Caller ID is identical to an incoming message to an IPTV end user.

Figure 47 shows a call flow for Caller ID

Communication Services — Telephony service (Caller identification) for an incoming IMS voice call

The IPTV solution provides a mechanism to enable the presentation of information on incoming IMS voice calls.

The managed networks, such as IMS, provide capability to connect multiple end-user terminals to communication services such as telephony service. The IMS Gateway, while registered to the IMS network, may also receive incoming SIP voice sessions and indicate the related information to the end-user.

The following figure shows a call flow with a caller identification based on the regular SIP INVITE request that is forwarded in parallel to the IMS Gateway and to a voice capable SIP/IMS UE. The IG gateway forwards the request towards the OITF, and also responds to the request with proper SIP response messages. The OITF gives a suitable indication to the end-user and the end-user can answer the incoming voice session using any of their voice capable clients connected to the IMS network.

The following procedure is supported in the OITF for caller identification

End User Presence Services

The following is a list of Presence related services available to an IPTV end user:

• Subscription to Presence for one or multiple targets
• Cancellation of Presence subscription for one or multiple targets
• Publishing presence information related to an IPTV end user

Subscription to Presence

Cancellation of Presence Subscription

Publishing Presence Information

Content Sharing Capability Query

Content Sharing session origination, session modification and session termination

OITF transferring a Content Sharing session

Content on Demand

The encrypting job is launched by the Content Management Function (NPI-49) which provides a contentId and the list of DRM used to protect the content.

The Key Management Function assigns key and keyId to the content and retrieves the drmSignaling that is to be inserted in the stream signaling from each concerned CSP Server (NPI-CSPT3/NPI-CSPG3). This information is returned to the CoD Encryption Function that uses it to encrypt the content (NPI-45).

Note: keyId/key pair may also be generated by the Encryption Function and provisioned to the Key Management Function. But in this case the system is not able to pre-generate licenses (to generate licenses before the corresponding content key is actually used to encrypt the content) if keys are not provided to the Key Management Function ahead of time.

Scheduled content with periodic key rotation controlled by the Key Management Function

On a regular basis the Scheduled Content Encryption Function requests keys to the Key Management Function for each scheduled content service (NPI-46). The keys have to be queried at a higher frequency than the key rotation period (e.g. every 10 minutes if the keys are changed every day).

• The Key Management Function assigns a key to the corresponding service for the time provided by the Scheduled Content Encryption Function.
• The Key Management Function manages the schedule for key changes for scheduled content services. It means that it maintains a list of keys associated with time. The keys are typically rotated once a day (e.g. during the night).

The Key Management Function centralizes all the information required to generate the drmSignaling to be included e.g. in DASH MPD and/or pssh box. This information is returned to the Scheduled Content Encryption Function which inserts it in the stream (NPI-46).

Scheduled content with periodic key rotation controlled by the Scheduled Content Encryption Function

Key change periodicity is configured in the Scheduled Content Encryption Function. The Scheduled Content Encryption Function has to provision the keys in the Key Management Function before they are actually used (NPI-46).

• The Scheduled Content Encryption Function manages the schedule for key changes for scheduled content services. It means that it maintains a list of keys associated with time. The keys are typically rotated once a day (e.g. during the night).
• The Scheduled Content Encryption Function provisions these keys in the Key Management Function which stores this information (NPI-46).

The Key Management Function centralizes all the information required to generate the drmSignaling to be included e.g. in DASH MPD and/or pssh box. This information is returned to the Scheduled Content Encryption Function which inserts it in the stream (NPI-46).

Scheduled content with event based key rotation

• The Scheduling Function provides a schedule of events to the Scheduled Content Encryption Function (NPI-53).
• The Scheduled Content Encryption Function requests a key to the Key Management Function for each event that is identified by its own contentId (NPI-46).
• The Key Management Function assigns a keyId/key to the corresponding event (identified by its contentId).
• The Key Management Function centralizes all the information required to generate the drmSignaling to be included e.g. in DASH MPD and/or pssh box. This information is returned to the Scheduled Content Encryption Function which inserts it in the stream (NPI-46).

Keys assigned to the channel (and not an event on this channel) can still be periodically changed as described in scheduled content with periodic key rotation.

Note: keyId/key pair can also be generated by the Scheduled Content Encryption Function and provisioned to the Key Management Function. But in this case the system is not able to pre-generate licenses (to generate licenses before the corresponding content key is actually used to encrypt the content) if keys are not provided to the Key Management Function ahead of time.