IEC 62766-4-2:2017

IEC 62766-4-2 ®
Edition 1.0 2017-04
INTERNATIONAL
STANDARD
colour
inside
Consumer terminal function for access to IPTV and open internet multimedia
services –
Part 4-2: Examples of IPTV protocol sequences

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 20 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 16 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 65 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and

CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC 62766-4-2 ®
Edition 1.0 2017-04
INTERNATIONAL
STANDARD
colour
inside
Consumer terminal function for access to IPTV and open internet multimedia

services –
Part 4-2: Examples of IPTV protocol sequences

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.170; 35.240.95 ISBN 978-2-8322-4089-2

– 2 – IEC 62766-4-2:2017 © IEC 2017
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviations . 8
4 Examples of IPTV protocol sequences . 8
4.1 General . 8
4.2 IPTV service functions protocol sequences . 9
4.2.1 COD Sequences . 9
4.2.2 Content reporting and content reporting management . 11
4.2.3 Purchase of digital media Purchase request procedure of selected
digital media related to the content . 13
4.2.4 Pay per view . 15
4.2.5 Network-based scheduled content time shift . 18
4.2.6 What is on TV service . 20
4.2.7 What is on TV service – SMS initiated . 21
4.2.8 Parental control for scheduled content sequences . 22
4.2.9 Network-based user notification services . 23
4.2.10 Content bookmarking . 30
4.2.11 Personalised channel . 35
4.2.12 Local PVR . 38
4.2.13 Network PVR (nPVR) (managed model) . 45
4.2.14 Personalised channel . 51
4.2.15 Notification service . 54
4.3 Service access and control function protocol sequences . 61
4.3.1 Authentication. 61
4.3.2 IPTV service profile manipulation through XCAP . 66
4.3.3 Setup of RTSP/RTCP performance monitoring for CoD session in
managed networks over UNIT-18 . 68
4.3.4 Specifying metrics for RTSP/RTCP performance monitoring . 69
4.3.5 Non-native HNI-IGI . 71
4.4 Communication services . 73
4.4.1 Instant messaging . 73
4.4.2 Caller ID . 75
4.4.3 Presence . 77
4.4.4 Content sharing . 80
4.5 Content preparation . 84
4.5.1 Encryption sequences. 84
4.5.2 Content on demand . 85
4.5.3 Scheduled content with periodic key rotation controlled by the key
management function . 85
4.5.4 Scheduled content with periodic key rotation controlled by the
scheduled content encryption function . 86
4.5.5 Scheduled content with event based key rotation . 87
Bibliography . 88

Figure 1 – RTSP Procedure on UNIS-11 for managed model . 9

Figure 2 – RTSP Usage for COD on UNIS-11 and NPI-10 . 10
Figure 3 – Content reporting . 11
Figure 4 – Management of content reporting . 12
Figure 5 – Purchase request procedure of selected digital media related to the content . 14
Figure 6 – User-initiated PPV service without existing scheduled content session. 15
Figure 7 – User-initiated PPV service switched from the scheduled content service . 17
Figure 8 – IPTV end-user activation of scheduled content time shift . 18
Figure 9 – IPTV end-user deactivation of scheduled content time shift . 19
Figure 10 – Acquiring information on content streamed on an OITF . 21
Figure 11 – Call flow for an SMS initiated parental control request . 22
Figure 12 – Procedure for parental control command to change channels . 23
Figure 13 – IMS-based user notification setup request . 24
Figure 14 – DAE-based user notification setup request . 25
Figure 15 – IMS-based update of pending notification requests . 26
Figure 16 – DAE-based update of pending notification requests . 27
Figure 17 – DAE-based fetching of pending notification requests . 28
Figure 18 – Sending a notification to an OITF . 29
Figure 19 – Sending a notification to a cellular device . 29
Figure 20 – Content Bookmarking in a scheduled content session . 31
Figure 21 – Content bookmarking in a content on demand session . 32
Figure 22 – Content-related bookmark retrieval . 33
Figure 23 – Content bookmark update . 34
Figure 24 – Signalling flow of PCh configuration . 36
Figure 25 – Signalling flow of PCh service setup . 38
Figure 26 – Call flow for a local PVR recording session . 41
Figure 27 – Call flow for a remote request for a local PVR recording session . 44
Figure 28 – Call flow for network PVR recording session – Synchronous method . 47
Figure 29 – Call flow for network PVR recording – Asynchronous method . 50
Figure 30 – OITF-centric personalised channel . 53
Figure 31 – Retrieving emergency notifications . 54
Figure 32 – Procedure for network-generated notifications . 56
Figure 33 – High-level session procedure . 57
Figure 34 – Target device initiating a COD session in relation to session transfer . 58
Figure 35 – IG handling of CoD initiated sessions associated with session transfers . 59
Figure 36 – Transferor imitating a session transfer request to a transferee in push
mode . 60
Figure 37 – Post successful session establishment by the transferee . 61
Figure 38 – Default IMS public identity registration procedure in a managed model . 62
Figure 39 – IPTV end-user IMPU registration procedure in a managed model . 63
Figure 40 – IPTV end-user de-registration procedure in a managed model . 64
Figure 41 – IPTV default identity de-registration procedure in a managed model . 64
Figure 42 – Call flow for subscription to the registration event . 65
Figure 43 – Service profile management based on XCAP . 67

– 4 – IEC 62766-4-2:2017 © IEC 2017
Figure 44 – RTCP receiver report packet . 70
Figure 45 – RTCP XR packet . 71
Figure 46 – Registration for non-native HNI-IGI . 73
Figure 47 – Instant message origination call flow . 74
Figure 48 – Incoming message call flow . 75
Figure 49 – Caller identification call flow . 76
Figure 50 – IMS telephony service based caller identification . 77
Figure 51 – Subscription to presence . 78
Figure 52 – Cancellation of presence subscription . 79
Figure 53 – Publishing a presence event . 80
Figure 54 – Content sharing capability call flow . 81
Figure 55 – Content sharing session initiation, modification and terminaion . 82
Figure 56 – Content sharing session transfer . 84
Figure 57 – Multi-DRM main workflows . 84
Figure 58 – Encrypt content on demand . 85
Figure 59 – Encrypt scheduled content with periodic key rotation controlled by the Key
Management Function . 86
Figure 60 – Encrypt scheduled content with periodic key rotation controlled by
scheduled content encryption function . 86
Figure 61 – Encrypt scheduled content with event based key rotation . 87

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
CONSUMER TERMINAL FUNCTION FOR ACCESS TO IPTV
AND OPEN INTERNET MULTIMEDIA SERVICES –

Part 4-2: Examples of IPTV protocol sequences

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62766-4-2 has been prepared by IEC technical committee 100:
Audio, video and multimedia systems and equipment.
The text of this International Standard is based on the following documents:
CDV Report on voting
100/2547/CDV 100/2661/RVC
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
This International Standard is to be used in conjunction with IEC 62766-4-1.

– 6 – IEC 62766-4-2:2017 © IEC 2017
A list of all parts in the IEC 62766 series, published under the general title Consumer terminal
function for access to IPTV and open internet multimedia services, can be found on the IEC
website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
INTRODUCTION
The IEC 62766 series is based on a series of specifications that was originally developed by
the OPEN IPTV FORUM (OIPF). They specify the user-to-network interface (UNI) for
consumer terminals to access IPTV and open internet multimedia services over managed or
non-managed networks as defined by OIPF.

– 8 – IEC 62766-4-2:2017 © IEC 2017
CONSUMER TERMINAL FUNCTION FOR ACCESS TO IPTV
AND OPEN INTERNET MULTIMEDIA SERVICES –

Part 4-2: Examples of IPTV protocol sequences

1 Scope
This part of IEC 62766 provides informative examples of features defined in IEC 62766-4-1.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
IEC 62766-4-1, Consumer terminal function for access to IPTV and open internet multimedia
services – Part 4-1: Protocols
IETF RFC 3261, SIP: Session Initiation Protocol
IETF RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP)
for the 3rd-Generation partnership Project (3GPP)
IETF RFC 3588, Diameter Base Protocol
IETF RFC 3611, RTP Control Protocol Extended Reports (RTCP XR)
IETF RFC 4825, The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP)
3GPP TS 29.199-4, Open Service Access (OSA); Parlay X web services; part 4: Short
messaging
Broadband Forum TR-135, Data Model for a TR-069 Enabled STB
3 Terms, definitions and abbreviations
For the purposes of this document, the terms, definitions and abbreviations given in
IEC 62766-4-1 apply.
4 Examples of IPTV protocol sequences
4.1 General
All the examples in this document are based on the HNI-IGI HTTP option.
___________
Under preparation. Stage at time of publication: IEC CDV 62766-4-1:2016.

4.2 IPTV service functions protocol sequences
4.2.1 COD Sequences
4.2.1.1 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
IEC 62766-4-1.
The RTSP URI is: rtsp://Cluster.orangeCDN.net/chevaliers_du_ciel
The session ID is 940211290776250.
Figure 1 depicts an RTSP Procedure on UNIS-11 for managed model.
Cluster
OITF CDF
Controller
1. Play
2. Play
3. 200 OK
4. 200 OK
5. RTP Stream
IEC
Figure 1 – RTSP Procedure on UNIS-11 for managed model
The call flow steps shown in Figure 1 are described further as follows:
Step 1: The OITF sends an RTSP PLAY to the Cluster Controller
– PLAY rtsp://Cluster.orangeCDN.net/chevaliers_du_ciel
CSeq: 1981
Session: 940211290776250
Step 2: The Cluster Controller forwards the PLAY message to the CDF
– PLAY rtsp://server1.Cluster.orangeCDN.net/chevaliers_du_ciel
CSeq: 1981
Session: 940211290776250
Step 3: The CDF replies to the Cluster Controller
– 200 OK
CSeq: 1981
Session: 940211290776250
Step 4: The Cluster Controller replies to the OITF with the appropriate RTSP session ID
– 200 OK
CSeq: 1981
Session: 940211290776250
Step 5: The RTP media starts
– 10 – IEC 62766-4-2:2017 © IEC 2017
4.2.1.2 RTSP specific usage on UNIS-11 and NPI-10 for the unmanaged model
The following example is only one example of performing redirection at initiation using the 303
Moved message. It does not take into account the effects of Network Address Translation
(NAT).
Figure 2 depicts an RTSP Usage for COD on UNIS-11 and NPI-10.
Cluster Cluster
CDF
OITF Controller Controller
Default B
1. Describe
2. Moved
3. Describe
4. Describe
5. 200 OK /SDP
6. 200 OK /SDP
IEC
Figure 2 – RTSP Usage for COD on UNIS-11 and NPI-10
The call flow steps shown in figure 2 are described further as follows:
Step 1: The OITF to the Cluster Controller
– DESCRIBE rtsp://Cluster.orangeCDN.net/chevaliers_du_ciel RTSP/1.0
CSeq 1306
Accept: application/sdp
Step 2: The Cluster Controller responds to the OITF indicating redirection to Cluster
Controller B
– RTSP/1.0 302 Moved Temporarily
CSeq 1306
Location: rtsp://Cluster_B.orangeCDN.net/ chevaliers_du_ciel RTSP/1.0
Step 3: The OITF sends a DESCRIBE to the indicated Cluster Controller
– DESCRIBE rtsp://Cluster_B.orangeCDN.net/chevaliers_du_ciel
CSeq: 1979
Accept: application/sdp
Step 4: The Cluster Controller chooses the appropriate CDF and forwards the DESCRIBE
message to it
– DESCRIBE rtsp://Server1.orangeCDN.net/chevaliers_du_ciel RTSP/1.0
Cseq: 1979
Accept: application/sdp
Step 5: The CDF replies to the Cluster Controller with the appropriate SDP
– 200 OK
Cseq: 1979
content-Type: application/sdp
content length: ….
//// SDP////
Step 6: The Cluster Controller replies to OITF with the appropriate SDP
– 200 OK
CSeq: 1979
content-Type: application/sdp
content length: …
////SDP ////
4.2.2 Content reporting and content reporting management
4.2.2.1 Content reporting
Figure 3 shows a call flow for an OITF initiating content reporting. Below is a brief description
of the call flow.
Step 1: It is assumed that the OITF established a regular scheduled content session, and
that the IPTV Control FE indicated its willingness to receive content Reporting Info
Package (through Recv-Info header in SIP 200 OK response to the INVITE). It is
assumed that the timer for content reporting is pre-configured.
Step 2: If zapping is performed and stopped for the configured timer or in case of powerup
without zapping and the user settled on a channel for the configured timer, the
OITF issues a request to the IG for content reporting.
Step 3: The IG validates the request then issues a SIP INFO to the network including the
content Reporting Info Package to report the watched content.
Step 4: The ASM forwards the request to the IPTV control FE.
Steps 5-7: The IPTV control FE generates a 200 OK that is proxied all the way to the IG, then
from the IG to the OITF it is forwarded in an HTTP 200 OK response.
Step 8: The user performs channel zapping.
Step 9: The user stops zapping and finally settles on a channel for the configured timer.
Step 10: This step reports the watched content and is similar to steps 2-7.
IEC
Figure 3 – Content reporting
– 12 – IEC 62766-4-2:2017 © IEC 2017
4.2.2.2 Management of content reporting
Figure 4 shows a call flow for the management of content reporting. Below is a brief
description of the call flow.
Step 1: The OITF established a scheduled content and performs content reporting as
required by the IPTV Control FE.
Step 2: The OITF performs content reporting when user performs zapping then stops
for the configured time.
Step 3: The OITF issues an HTTP HNI-IG PENDING_IG request to the IG. This request
can be issued at any time after step 1.
Step 4: At some point in time, the IPTV control FE decided that it does not want any
more content reporting. The IPTV control FE sends a SIP UPDATE with the
Recv-Info header set to ‘nil’ to the ASM to that effect.
Step 5: The ASM forwards the SIP UPDATE to the IG.
Step 6: The IG forwards the SIP UPDATE in an HTTP 200 OK response to the OITF.
Steps 7-9: The OITF issues an HTTP POST request to the IG that includes the SIP 200
OK response. The SIP 200 OK is forwarded all the way to the IPTV control FE.
Step 10: The user performs channel zapping and no content reporting is performed.
Step 11: The OITF issues an HTTP HNI-IGI PENDING_IG request to the IG.
Steps 12-14: These steps request the OITF to start reporting the watched content and are
similar to steps 4-6. The difference is that the Recv-Info header is set to
content Reporting Info Package.
Steps 15-17: The OITF issues an HTTP POST request to the IG that includes the SIP 200
OK response. The SIP 200 OK is forwarded all the way to the IPTV Control FE.
Step 18: This step reports the watched content. See Figure 4 for the detailed call flow.
IEC
Figure 4 – Management of content reporting

4.2.3 Purchase of digital media
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 shall
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 receiving 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 receiving 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 purchase request success;
otherwise, the IPTV Control FE sends the SIP 403 Forbidden response (the message body is
Result-Code that is defined in IETF RFC 3588) 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.
– 14 – IEC 62766-4-2:2017 © IEC 2017

IEC
Figure 5 – Purchase request procedure of selected digital
media related to the content
Because the purchase request happens 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. Below is a brief description of the call flow.
Step 1: The OITF sends XCAP GET to IPTV Service Profile FE to get the user’s profile
about digital media.
Step 2: The IPTV Service Profile FE returns HTTP 200 OK with user’s profile to OITF. If
the requested digital media is already recorded in user’s profile, the OITF needs
to pop up a dialog box to let user know the repeat billing, and then stop sending
the purchase request.
Step 3: The OITF sends an HTTP POST (with SelecteddigitalmediaURI, UserID) to IG for
purchasing selected digital media.
Step 4: The IG sends a SIP INFO Request (with SelecteddigitalmediaURI, UserID) to ASM
FE for authentication.
Step 5: The ASM FE forwards the SIP INFO (with SelecteddigitalmediaURI, UserID) to
IPTV Control FE for purchase.
Step 6: The IPTV Control FE sends Accounting-Request (ACR) message (with
SelecteddigitalmediaURI, UserID) to Charging FE.
Step 7: The Charging FE returns Accounting-Answer (ACA) message with purchase result
(success or fail) to IPTV Control FE.
Step 8: The IPTV Control FE sends the digital purchase request (with
SelecteddigitalmediaURI, UserID) to IPTV applications FE.
Step 9: The IPTV applications FE issues an XCAP PUT request to IPTV Service Profile
FE to update user’s profile (adds a SelecteddigitalmediaURI and/or other
information). In order to avoid falsifying the information about Purchase of digital
media in user’s profile cannot be updated by OITF.

Step 10: The IPTV Service Profile FE returns an HTTP 200 OK to IPTV applications FE.
Step 11: The IPTV applications FE returns a response to IPTV Control FE.
Step 12: The IPTV Control FE returns SIP 200 OK (if purchase request success) or 403
Forbidden including Result-Code (if purchase request failure) to ASM FE.
Step 13: The ASM FE forwards SIP 200 OK (if purchase request success) or 403
Forbidden including Result-Code (if purchase request failure) to IG.
Step 14: The IG sends the HTTP response including purchase result to OITF.
4.2.4 Pay per view
4.2.4.1 General
The PPV stream may be protected, and the key may be retrieved in the PPV subscription
procedure.
4.2.4.2 PPV service initiation without existing scheduled content session
4.2.4.2.1 General
Figure 6 shows a typical call flow for watching an initiating PPV service without an existing
scheduled content session and the call flow is described in the steps below.
IEC
Figure 6 – User-initiated PPV service without existing
scheduled content session
Step 1: The OITF sends a HTTP POST to the IG to initiate a PPV session.
Step 2: The IG validates the request and sends an INVITE to the ASM. The ASM uses the
services of the “Resource and Admission Control” functional entity to perform
resource reservation.
– 16 – IEC 62766-4-2:2017 © IEC 2017
Step 3: The ASM uses the services of the RAC functional entity to perform resource
reservation.
Step 4: The ASM forwards the INVITE to the IPTV Control. Using the BC service ID and BC
program ID, the IPTV Control verifies that the user has a PPV subscription. The
IPTV Control verifies whether the program has started or not. If the program has
started and is encrypted, the IPTV Control may interact with CSP functions directly
or through the IPTV application to verify the user entitlements, and then performs
the following steps. If the program has started and is not encrypted, the IPTV
Control performs the following steps. If the program has not started, the IPTV
Control refuses the request.
Step 5: The IPTV Control sends a 200 OK response to the ASM with the bandwidth
required for the specific scheduled content channels and other parameters.
Step 6: The ASM instructs the RAC to commit the reserved resources.
Step 7: Finally, a 200 OK for the session setup request is forwarded to the OITF.
Step 8: The IG returns the SDP to the OITF in a HTTP 200 OK response.
Step 9: The OITF issues an IGMP Join request to the transport processing functions to
access the multicast channel for the PPV service.
Step 10: The media stream is delivered to the OITF.
4.2.4.2.2 User-initiated switch from PPV service to a scheduled content service
The user initiates a switch from the PPV service to a regular scheduled content.
If the scheduled content service is inside the set of channels negotiated at PPV 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 scheduled content service.
If the scheduled content service is outside the set of channels negotiated at PPV session
initiation, the OITF shall initiate a scheduled content Session Modification request as
described in IEC 62766-4-1.
4.2.4.2.3 User-initiated switch from regular scheduled content to PPV service
The user initiates a switch from the regular scheduled content to a PPV service.
The OITF shall initiate a PPV Session Modification request as described in IEC 62766-4-1.
4.2.4.3 User-initiated PPV service switched from the scheduled content service
4.2.4.3.1 General
Figure 7 shows a typical call flow for watching a PPV service switched from the scheduled
content service initiated by the user.

IEC
Figure 7 – User-initiated PPV service switched
from the scheduled content service
It is assumed that the user has established a scheduled content session. When the user
switches from the scheduled content service to a PPV service, the OITF shall send a HTTP
POST to the IG to modify the scheduled content session to a PPV session.
4.2.4.3.2 User-initiated switch from PPV service to a scheduled content service
The user initiates to switch from PPV service to a regular scheduled content.
If the scheduled content service is inside the set of channels negotiated at PPV 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 scheduled content service.
If the scheduled content service is outside the set of channels negotiated at PPV session
initiation, the OITF shall initiate a scheduled content Session Modification request as
described in IEC 62766-4-1.
4.2.4.3.3 User-initiated switch from a PPV service to another PPV service
The user initiates to switch from a PPV service to another PPV service.
The OITF shall initiate a PPV session modification request as described in IEC 62766-4-1.

– 18 – IEC 62766-4-2:2017 © IEC 2017
4.2.5 Network-based scheduled content time shift
4.2.5.1 User Activation for scheduled content time shift
Figure 8 shows a call flow for an IPTV end-user activating a scheduled content time shift.
Below is a brief description of the call flow (the procedure assumes that the scheduled
content to be time shifted is recorded in the network, and is thus available for time shifting).
Step 1: It is assumed that the OITF successfully established a scheduled content
session.
Step 2: The activation of time shift procedure can be triggered by the user, through a
menu selection, invoking the time shift option.
Step 3: The OITF issues a request to the IG to activate the scheduled content time
shift.
Step 4: The IG validates the request then issues a SIP re-INVITE to the network.
Step 5: The ASM performs initial resource modification as per the incoming request.
Step 6: The ASM forwards the re-INVITE to the IPTV Control FE.
Step 7: The IPTV Control FE performs the necessary validation as per IEC 62766-4-1.
Steps 8-18: These steps show how the unicast session is established.
Step 19: The IG forwards the SIP 200 OK to the OITF in an HTTP 200 OK response.
Step 20: The OITF issues an HTTP POST request to send an ACK.
Steps 21-24: The ACK is propagated to the IPTV Control server FE.
Step 25: The OITF can deploy RTSP media control commands to start streaming the
unicast content.
IEC
Figure 8 – IPTV end-user activation of scheduled content time shift

4.2.5.2 User deactivation for scheduled content time shift
Figure 9 shows a call flow for an IPTV end-user initiating a deactivation of a scheduled
content time shift. Below is a brief description of the call flow:
Step 1: It is assumed that the OITF is successfully streaming a unicast session
representing a time shifted scheduled content.
Step 2: The procedure can be triggered by the user, through a menu selection,
invoking the deactivation of the time shift option.
Step 3: The OITF issues a request to the IG to activate the scheduled content time
shift.
Step 4: The IG validates the request then issues a SIP re-INVITE to the network.
Step 5: The ASM performs initial resource modification as per the incoming request.
Step 6: The ASM forwards the re-INVITE to the IPTV Control FE.
Step 7: The IPTV Control FE performs the necessary validation as per IEC 62766-4-1.
Steps 8-18: These steps show how the unicast session is terminated.
Step 19: The IG forwards the SIP 200 OK to the OITF in an HTTP 200 OK response.
Step 20: The OITF issues an HTTP POST request to send an ACK.
Steps 21-24: The ACK is propagated to the IPTV Control server FE.
Step 25: OITF can issue an IGMP JOIN to join the multicast address for the last viewed
channel.
IEC
Figure 9 – IPTV end-user deactivation of scheduled
content time shift
– 20 – IEC 62766-4-2:2017 © IEC 2017
4.2.6 What is on TV service
Figure 10 shows a call flow for a user, with parental control authority, acquiring information
related to the content being streamed on an OITF, watched by another user under the
parental supervision of the request originator. Below is a brief description of the call flow.
Steps 1-4: These steps are optional and show how the IPTV control FE may store state
information to support the feature. Optionally this storage may be on the
presence server. The rest of the call flow describes this option.
Step 5: The OITF issues an HTTP POST request to subscribe to the Parental Control
Watched content event.
Step 6: The IG validates the request then issues a SIP SUBSCRIBE to the network.
Step 7: The ASM forwards the request to the IPTV control FE.
Steps 8-11: The IPTV control FE validates that the user is allowed to access the requested
information. If successful, steps 8-10 are optional and are implemented only if
the IPTV control FE uses presence to support the feature as per IEC 62766-1-4.
Step 12: The IPTV control FE generates a SIP 200 OK if the user is allowed access to
requested information or proxies the received 200 OK from the presence server
if steps 8-11 are performed. The SIP 200 OK response is sent to the ASM.
Step 13: The ASM proxies the SIP 200 OK response to the IG.
Step 14: The IG returns the SIP 200 OK to the OITF in an HTTP 200 OK response.
Step 15: The OITF issues an HTTP HNI-IGI PENDING_IG request to the IG in
anticipation of the incoming SIP NOTIFY.
Steps 16-17: These steps are implemented only if the IPTV control FE uses presence per
steps 1-4. In these steps, the SIP NOTIFY including the requested information
is sent to the IPTV control FE via the ASM.
Step 18: If presence is not used to support this feature, the IPTV control FE generates
the SIP NOTIFY, otherwise the received NOTIFY from the presence server is
proxied to the ASM.
Step 19: The ASM proxies the SIP NOTIFY to the IG.
Step 20: The IG forwards the SIP NOTIFY in an HTTP 200 OK response to the OITF.
Steps 21-23: The OITF issues an HTTP POST request to the IG that includes the SIP 200
OK response. The SIP 200 OK is forwarded all the way to the IPTV control FE.
Steps 24-25: These steps are optional if presence is used to support the feature.

IEC
Figure 10 – Acquiring information on content streamed on an OITF
4.2.7 What is on TV service – SMS initiated
Figure 11 shows a call flow for a user, with parental control authority, acquiring information
related to the content being streamed on an OITF, watched by another user under the
parental supervision of the request originator. Below is a brief description of the call flow.
Step 1: The end-user through his cellular device issues a text message to the MSISDN
(or short code) associate
...